Repository navigation
ci: stamp OCI labels on the testing image - #1052
Merged
Merged
Conversation
The testing image carried no labels at all, so the documented deployment check
on Zeus returned an empty string instead of a commit:
docker image inspect ghcr.io/starosdev/scrutiny:develop-omnibus \
-f '{{index .Config.Labels "org.opencontainers.image.revision"}}'
That check is how an operator confirms a pull actually delivered the develop
commit they expect. Returning empty is worse than returning the wrong value,
because it reads as "no revision recorded" rather than as a failure.
Two workflows publish `develop` and `develop-omnibus` on a push to develop: the
Docker workflow, which attaches labels through docker/metadata-action, and this
one, which did not. Whichever finishes last owns the tag, so the image an
operator pulls had labels or not depending on a race. Stamping the same labels
here removes the difference regardless of ordering.
Only `labels` is taken from the metadata step. The tag list stays explicit,
because this workflow publishes a fixed pair rather than deriving tags from the
ref.
Consolidating the two publishers behind one workflow is the larger fix and is
not attempted here.
This was referenced Oct 30, 2026
Starosdev
added a commit
that referenced
this pull request
Nov 5, 2026
## Summary `deploy-beta.yml` now stamps the same OCI labels as the Docker workflow, so `beta` and `beta-omnibus` always carry `org.opencontainers.image.revision`. This applies the #1052 fix for `develop` to the beta workflow. ## Type of Change - [x] CI/CD or infrastructure change ## Related Issues Same race as #1052, for the beta channel. No issue filed. ## Changes Made - Add a `docker/metadata-action@v6` step (`id: meta`) before the beta build, configured like `deploy-testing.yml`. - Pass `labels: ${{ steps.meta.outputs.labels }}` to `docker/build-push-action`. ## Testing - [ ] I have tested this locally - [ ] I have added/updated tests that prove my fix/feature works - [ ] All existing tests pass `actionlint .github/workflows/deploy-beta.yml` passes, and the file parses as YAML. The workflow runs only on a push to `beta`. This PR changes no tag names, platforms or cache scopes. Evidence for the problem: on 2026-11-05, Zeus pulled `beta-omnibus` after #1114 merged (`8500fbc3`). `docker image inspect` showed an empty `org.opencontainers.image.revision`, although both Publish Beta Image and Docker succeeded for that commit. ## Additional Notes Review: required (a workflow change that takes effect on merge with no separate deploy step). `deploy-beta.yml` is identical on `develop`, `master` and `beta`. The fix reaches the beta workflow only after the next promotion to `master` and the `master` into `beta` sync. Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The testing image carries no OCI labels, so the deployment check documented for the Zeus develop instance returns an empty string instead of a commit.
That command is how an operator confirms a pull actually delivered the develop commit they expect. Empty output is worse than a wrong value, because it reads as "no revision recorded" rather than as a failed check. Observed on Zeus against
develop-omnibusbuilt from 3a006d1: the image reports zero labels, and confirming the deployed code required grepping the served frontend chunk instead.Type of Change
Related Issues
No issue; found while verifying a deploy of #1039 and #1050 on the Zeus develop instance.
Changes Made
.github/workflows/deploy-testing.yml: adddocker/metadata-action@v6and pass itslabelsoutput todocker/build-push-action, matching whatdocker-build.yamlalready does for release and branch images.Only
labelsis taken from the metadata step. The tag list stays explicit, because this workflow publishes a fixed pair of tags rather than deriving them from the ref.Testing
Verified by reading both workflows rather than by running them:
docker-build.yamlalready builds this label set throughdocker/metadata-action@v6, and this change reuses the same action with the same registry and image inputs. The real proof is the next push to develop, after which the inspect command above should report the commit. Nothing else in the build changes, and no application code is touched.Checklist
Additional Notes
Review: not required (CI metadata only; no application code, no security or access boundary, no deploy-on-merge step, trivially revertible).
Worth knowing for a later change: two workflows publish
developanddevelop-omnibuson a push to develop.docker-build.yamldoes it under path filters and attaches labels; this workflow does it underpaths-ignorefor markdown and docs, and did not. Whichever finishes last owns the tag, so until now an operator's pull had labels or not depending on a race. This change removes the difference, but consolidating the two publishers behind one workflow is the larger fix and is not attempted here.