Prepare and publish cubeplex releases across backend, frontend, sandbox, Helm, Docker Compose, Git tags, and container registries. Use when cutting a release, bumping release versions, publishing Docker images, promoting image digests, updating deployment values, or troubleshooting release ordering.
Cubeplex release workflow
Use this skill for a production or self-hosted cubeplex release. Follow the
workflow in references/release-workflow.md for
the exact version, image, tag, and deployment contracts.
Required sequence
Inspect the current branch, worktree, origin/main, and existing release tags.
Prepare a release PR that bumps the application package/chart versions and,
only when sandbox contents change, deploy/images/sandbox/VERSION.
Run the version-consistency check and the repository CI-equivalent checks.
Merge the release PR into main.
Create v<semver> on that exact merged commit and push the tag.
The tag push triggers two concurrent workflows: images.yml builds and pushes
version-tagged images; release.yml verifies versions, waits for those images,
writes the release manifest, and creates the GitHub Release.
Deploy using the manifest's release tags or digests. Do not edit chart defaults
or use latest for production.
Guardrails
Never overwrite an existing application or sandbox version tag.
Do not run sandbox runtime compatibility tests from the image release workflow;
existing sandbox E2E/nightly workflows remain separate.
Keep registry credentials and runtime secrets out of release manifests.
If the image build fails, fix the build; do not manually push a replacement image
under the same tag.
