Release Workflow: From Tag to Docker Image
How ImgCompress releases work: push a release tag, CI builds the Docker image and a draft release, you review and publish, and latest moves to the new version.
DevelopmentReleases
How ImgCompress releases work: push a release tag, CI builds the Docker image and a draft release, you review and publish, and latest moves to the new version.
Push a tag, check the draft, publish: CI does the rest.
Tag the commit and push the tag.
bashgit tag release_1.0.0-rc.1 # stable: release_1.0.0 git push origin release_1.0.0-rc.1
Wait for the build. The Deployment for imgcompress to Docker Hub workflow (Deployment below) writes the release notes, builds the image and pushes it as karimz1/imgcompress:1.0.0-rc.1 to Docker Hub and GHCR. latest is not touched.
Review the draft. Only after the image is pushed does a draft appear under Releases. Fix the notes if needed. Nothing is published automatically.
Publish the draft. For a stable release, latest now points to the image you just tested. Nothing is rebuilt.
texttag push ─► release notes ─► build + push 1.0.0 ─► draft release │ you publish ▼ stable? move latest ─► Docker Hub README
latest?#| Release | Version tag | latest |
|---|---|---|
RC, e.g. release_1.0.0-rc.1 | 1.0.0-rc.1 | stays |
Newest stable, e.g. release_1.0.0 | 1.0.0 | moves to 1.0.0 |
Older stable (backport), e.g. release_0.9.1 after 1.0.0 | 0.9.1 | stays |
latest is only moved on publish, with docker buildx imagetools create. It points to the exact image that was built for the tag, so what you tested is what people pull.
main that passes CI is built as nightly.main has moved on in the meantime, the older nightly is skipped.main without a tag.All deployments share one queue, so a slow older run can never overwrite a newer image.
| Problem | Fix |
|---|---|
| Build failed, no draft | Fix the cause, then run Deployment from main with the tag, or make release-draft RELEASE_TAG=release_1.0.0-rc.1. |
| Wrong commit tagged | Delete the tag (locally and on GitHub) and tag again. Unpublished tags can be rebuilt. |
| Published by mistake | Published tags are never rebuilt. Make a new version instead. |
Closes #123 in a PR description so the issue shows up in the notes.skip-release-notes to leave it out.main.make release-tests (needs Node 24).