Release Strategy
Releases are automated, immutable, and never mutate main.
How it works
Section titled “How it works”Every merge to main runs the CI pipeline: build, test, scan, push, release.
The release step runs semantic-release, which reads the squash-merge commit message (the PR title) to decide what happens:
feat:— minor bump, creates a GitHub Releasefix:— patch bump, creates a GitHub Release- Anything else (
ci:,docs:,chore:, etc.) — no release
When a GitHub Release is created, release.yml fires and:
- Promotes existing
sha-tagged images to version tags on GHCR and DockerHub (no rebuild) - Generates standalone compose files and uploads them as release assets
- Appends an image table and quick start to the release notes
Image tags
Section titled “Image tags”| Tag | Purpose |
|---|---|
sha-<gitsha> | CI artifact, 1:1 with source |
v0.1.0 | Pinned release (recommended for operators) |
latest | Latest main build |
Zabbix version is not part of the image tag. It is recorded as an OCI label
(dev.omniglass.zabbix-version) and noted in the release notes. Zabbix is
compiled from source via zabbix-docker bake with Omniglass patches applied;
the ZABBIX_VERSION file pins the source tag used for all components.
Manual release
Section titled “Manual release”gh release create v0.1.0 --target <commit-sha> --generate-notesRequired secrets
Section titled “Required secrets”| Name | Type | Purpose |
|---|---|---|
DOCKERHUB_USERNAME | Variable | DockerHub push |
DOCKERHUB_TOKEN | Secret | DockerHub push |
RELEASE_APP_ID | Variable | GitHub App token for release events |
RELEASE_APP_PRIVATE_KEY | Secret | GitHub App token for release events |