ci(hubble): stamp org.opencontainers.image.revision on the image - #29
Conversation
The pd/store/server publish path passes the resolved source SHA to the build as --label org.opencontainers.image.revision (and the matching --set "*.labels...." for the Bake path), so hugegraph/pd:latest, hugegraph/store:latest and hugegraph/server:latest can be traced back to the apache/hugegraph commit they were built from. The standard image path resolves the same SHA in its prepare job and uses it only as the checkout ref, so hugegraph/hubble:latest carries no org.opencontainers.image.revision label and a running Hubble container cannot be tied to a hugegraph-toolchain commit. Hubble is built on its own nightly schedule, so it can also lag the other three images with nothing on the image to show it. Pass the resolved SHA and the source repository URL to docker/build-push-action as labels, which brings hubble in line with pd/store/server. Every other wrapper that calls this reusable workflow gains the same two labels.
There was a problem hiding this comment.
🟢 Approval recommended
The workflow changes are minimal, consistent across all build steps, and correctly derive labels from already-validated/used inputs and outputs.
Pull request overview
This PR updates the shared image publishing reusable workflow so all images it builds (including smoke-test builds) are stamped with OCI provenance metadata, making hugegraph/hubble:latest traceable back to the exact apache/hugegraph-toolchain commit it was built from.
Changes:
- Define a job-level
IMAGE_LABELSenv var that includesorg.opencontainers.image.revision(resolvedsource_sha) andorg.opencontainers.image.source(GitHub repo URL). - Pass
labels: ${{ env.IMAGE_LABELS }}into alldocker/build-push-actionbuild steps (smoke-test and publish). - Document the added responsibility in
README.md.
File summaries
| File | Description |
|---|---|
| README.md | Documents that the standard reusable publisher stamps OCI revision and source labels. |
| .github/workflows/_publish_image_reusable.yml | Adds a shared label block and applies it consistently to all build/push steps. |
Review details
- Files reviewed: 2/2 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. Walkthrough发布工作流新增 ChangesOCI 镜像标签
Estimated code review effort: 1 (简单) | ~5 分钟 Merge Risk: ⚪ Minimal · up to The change adds source and revision metadata to images without altering build inputs, tags, caching, platforms, or gating behavior; no actionable merge-blocking risk remains after normal checks and review. Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.) ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
imbajin
left a comment
imbajin
left a comment
There was a problem hiding this comment.
LGTM. The resolved source SHA and repository are applied consistently to all build paths, restoring image-level provenance without changing publication semantics.
Purpose
hugegraph/hubble:latestcarries noorg.opencontainers.image.revisionlabel, so a running Hubble container cannot be tied to theapache/hugegraph-toolchaincommit it was built from. The other three images in a HugeGraph deployment can.Labels read from the image configs on Docker Hub on 2026-09-02:
org.opencontainers.image.revisionorg.opencontainers.image.sourcehugegraph/pd:latest98477f0f56a3ad49593ec7632f2f0ee13e72f0ddhttps://github.com/apache/hugegraphhugegraph/store:latest98477f0f56a3ad49593ec7632f2f0ee13e72f0ddhttps://github.com/apache/hugegraphhugegraph/server:latest98477f0f56a3ad49593ec7632f2f0ee13e72f0ddhttps://github.com/apache/hugegraphhugegraph/hubble:latestHubble's only label is
org.opencontainers.image.version=22.04, inherited from the base image.This matters beyond tidiness. Hubble publishes on its own nightly cron (
0 23 * * *inpublish_latest_hubble_image.yml) againstapache/hugegraph-toolchain@master, while pd/store/server publish separately againstapache/hugegraph@master. Hubble can therefore lag the other three by more than a day, and there is nothing on the image that says so. Deployment test reports that record image digests have to write "Hubble: no revision label" in every table.What the pd/store/server path does
_publish_image_reusable.ymlalready resolves the source commit. Itspreparejob runsgit ls-remoteand publishessource_sha:The
publishjob then uses that value only asactions/checkout'sref. Nothing carries it into the image, because none of the fourdocker/build-push-actionsteps passes alabels:input.The pd/store/server path stamps the same value explicitly. In
_publish_pd_store_server_reusable.ymlon thetopling-runtime-variantbranch (open as #28), the serial build passes:and the Bake path passes the same two values through
--set:with
SOURCE_URL: https://github.com/${{ inputs.source_repository }}andSOURCE_SHAfrom the prepare job. Those lines are what put the labels on the pd/store/server images currently on Docker Hub, since the recent publishes of those three were manual runs from that branch. The master copy of the pd/store/server workflow does not stamp them yet, so this change and #28 arrive at the same behaviour from the two sides.Main changes
.github/workflows/_publish_image_reusable.ymlpublishjob gains oneenventry that builds the label list from values it already has:docker/build-push-actionsteps gainlabels: ${{ env.IMAGE_LABELS }}next to their existingtags:. The two smoke-test builds are included so the image that is tested and the image that is pushed carry identical metadata.README.md_publish_image_reusable.ymlresponsibility list.No input, tag, cache, platform or gating behaviour changes. Labels are image config metadata, so no layer is rebuilt and the registry caches stay valid.
tests/test_publish_prepare.shpasses unchanged.The other wrappers that call this reusable workflow (
publish_latest_loader_image.yml,publish_latest_ai_image.yml,publish_latest_vermeer_image.yml) gain the two labels as well. That is deliberate: every image this workflow publishes becomes traceable by the same rule.How to verify
An image built from this branch would carry, for the current
apache/hugegraph-toolchain@master:publish: false. The renderedlabelsinput is printed in the "Build and push image with mvn args" step log, and the resolved SHA is in the prepare job output.docker buildx imagetools inspect --format '{{json .Image.Config.Labels}}' hugegraph/hubble:latestdocker inspect --format '{{index .Config.Labels "org.opencontainers.image.revision"}}' hugegraph/hubble:latestThe value must equal the
apache/hugegraph-toolchaincommit the run checked out, the same wayhugegraph/pd:latestreports itsapache/hugegraphcommit today.Related
Summary by CodeRabbit
新功能
文档