Victor Wiebe
498003f83d
Some checks failed
Release production image / production-image (push) Has been cancelled
60 lines
3.5 KiB
Markdown
60 lines
3.5 KiB
Markdown
# Release Construction and Publication
|
|
|
|
This procedure publishes the Conductor application release. The application version is `v1.0.0`; canonical project documents continue to use schema version `0.1.0`.
|
|
|
|
## Image identity and architecture
|
|
|
|
Each production image must correlate to one source revision and include OCI version, revision, creation-time, source, title, and description labels.
|
|
|
|
Release tags are:
|
|
|
|
- `vX.Y.Z`: immutable application release;
|
|
- `git-<12-character-sha>`: immutable source-revision identity; and
|
|
- `latest`: optional convenience pointer, never used in controlled installation instructions.
|
|
|
|
Conductor v1.0.0 supports `linux/amd64`. ARM64 is not a supported v1.0.0 artifact because its native SQLite build has not completed the required release smoke test.
|
|
|
|
## Build locally
|
|
|
|
From a clean release commit:
|
|
|
|
```bash
|
|
scripts/release-image.sh --version v1.0.0 --platforms linux/amd64
|
|
```
|
|
|
|
Run the production lifecycle tests against that image before publication.
|
|
|
|
## Publish the image
|
|
|
|
Use exactly one publication path. Do not allow an automated tag job and a manual push to race on the same immutable tag.
|
|
|
|
The tag-triggered Gitea workflow builds and pushes `v1.0.0` and `git-<sha>` image tags. It requires an available compatible runner and configured registry credentials. It publishes container images only; it does not create the human-facing Gitea Release entry.
|
|
|
|
If a controlled manual publication is required, first ensure no tag-triggered workflow can later rebuild or overwrite the tag. Authenticate with a scoped publisher token, check out the exact approved release commit, and run:
|
|
|
|
```bash
|
|
docker login gitea.skeletonworks.online
|
|
scripts/release-image.sh \
|
|
--version v1.0.0 \
|
|
--platforms linux/amd64 \
|
|
--push
|
|
```
|
|
|
|
Registry authentication is for publishers only. Consumers must be able to pull the final release without credentials.
|
|
|
|
## Release sequence
|
|
|
|
1. Prepare one clean release commit containing the code, documentation, production assets, and `1.0.0` package metadata.
|
|
2. Run governance, documentation, schema, frontend, backend, browser, and production lifecycle suites.
|
|
3. Confirm missing-key startup fails and configured startup, health, root UI, and published deep links pass.
|
|
4. Confirm first-run administration, restart persistence, online backup, verified restore, upgrade, and rollback behavior.
|
|
5. Obtain explicit release approval.
|
|
6. Create the immutable annotated `v1.0.0` source tag on the approved commit and push it, using the automated image path only when its runner is available.
|
|
7. Publish the `v1.0.0` and matching `git-<12-character-sha>` Linux/AMD64 images through the single selected publication path.
|
|
8. From an unauthenticated environment, download the tagged source archive and pull the container image.
|
|
9. Confirm the OCI `version` is `v1.0.0`, the OCI `revision` matches the tagged source commit, and the AMD64 image passes its smoke test.
|
|
10. Create the Gitea Release entry for `v1.0.0` and record the source commit, archive checksums, OCI index and AMD64 manifest digests, Git-SHA image tag, supported architecture, anonymous verification result, limitations, and upgrade/rollback notes.
|
|
11. Complete the post-publication checks in [Release Validation](RELEASE_VALIDATION.md) and record the external/manual acceptance result; publication is not complete while any final artifact check is blocked or failed.
|
|
|
|
If Gitea cannot provide anonymous image pulls, publish the same release image to a supported public registry, verify it anonymously, and update the installation guide and release entry before sign-off.
|