Releasing
Nothing deploys by itself. Every push to master that touches the server runs the tests and builds ghcr.io/allay-ai/server:sha-<commit>. Servers pin a released version.
#Make a release
Add a
## X.Y.Zsection toCHANGELOG.md: patch for fixes, minor for features, major for breaking changes. Push it.Run the “Release” workflow:
gh workflow run release.yml -R allay-ai/server -f version=X.Y.ZIts
changelogfield overrides the section; one of the two must be there.Watch it with
gh run watch.
The workflow tests the code, pushes ghcr.io/allay-ai/server:X.Y.Z, tags vX.Y.Z, and creates the GitHub release with a docker pull line.
#The version
Nothing in the repository holds the version. The image gets it as the APP_VERSION build argument, and /api/health reports it.
#After the release
With its moonlands switch on (the default), the workflow's deploy job starts Moonlands' ship-plugin.yml, which puts the new backend on that server. It needs the FAMILY_ACTIONS_TOKEN secret.
Never delete or re-tag a published release; finish a half-failed one by hand.
#The weekly autopilot
.github/workflows/autopilot.yml runs Claude every Monday at 03:00 UTC. It updates dependencies, fixes what they break, pushes to master, and runs the “Release” workflow when what the project ships changed. It needs the CLAUDE_CODE_OAUTH_TOKEN secret.
Next: Development