ci: restructure release workflow with gated matrix builds#3
Conversation
Add a fast linux/amd64 gate build that runs on every PR/push, then fan out to a 4-way matrix (dockerhub + swr × amd64 + arm64) only on tag pushes. SWR builds use provenance=false to satisfy registry requirements; push-swr now pulls directly from SWR per-arch images instead of retagging from Docker Hub. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
WalkthroughRefactors the release workflow to centralize tag/version resolution in a ChangesRelease Workflow Per-Registry Split
🎯 4 (Complex) | ⏱️ ~45 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 104-105: The cache-from line uses comma-separated entries which is
invalid: replace the single comma-separated value for the cache-from key with
multiple newline-delimited cache source entries so each source is its own item
(use separate lines for type=gha,scope=buildkit-linux-amd64 and
type=gha,scope=buildkit-${{ matrix.registry }}-linux-${{ matrix.arch }}); keep
cache-to as-is (it already targets the matrix-specific scope) and ensure the
keys remain exactly cache-from and cache-to in the workflow.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 93d86d5e-6e74-484f-83fe-bb06c94e02d9
📒 Files selected for processing (1)
.github/workflows/release.yml
There was a problem hiding this comment.
Pull request overview
Restructures the release GitHub Actions workflow to add an amd64 “gate” build on every PR/tag, and to run tagged multi-arch/multi-registry release builds only after the gate succeeds.
Changes:
- Replaces per-arch build jobs with a single non-pushing
buildgate job (linux/amd64). - Adds a gated
build-releasematrix for Docker Hub + Huawei SWR across amd64/arm64, with SWR usingprovenance: false. - Updates SWR publishing to create the multi-arch manifest from SWR-native per-arch images.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 63e44fcbbc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/release.yml (1)
104-105:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThe gate cache is not actually reused by the amd64 release builds.
buildexports tobuildkit-linux-amd64, but this job only imports the registry-scoped cache. Both amd64 release legs will rebuild from scratch, so the shared-cache objective in this PR is not met.Suggested fix
- cache-from: type=gha,scope=buildkit-${{ matrix.registry }}-linux-${{ matrix.arch }} + cache-from: | + type=gha,scope=buildkit-${{ matrix.registry }}-linux-${{ matrix.arch }} + ${{ matrix.arch == 'amd64' && 'type=gha,scope=buildkit-linux-amd64' || '' }} cache-to: type=gha,mode=max,scope=buildkit-${{ matrix.registry }}-linux-${{ matrix.arch }}🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 104 - 105, The release job currently only imports the registry-scoped buildkit cache (cache-from: scope=buildkit-${{ matrix.registry }}-linux-${{ matrix.arch }}) but the build step exports to buildkit-linux-amd64, so amd64 legs rebuild; update the cache-imports to include the shared `buildkit-linux-${{ matrix.arch }}` scope as well (add a second cache-from entry with type=gha,scope=buildkit-linux-${{ matrix.arch }} or otherwise import both scopes) and ensure cache-to still writes the desired scopes (cache-to should continue exporting both registry-scoped and shared buildkit scopes) so the amd64 release legs will reuse the exported cache.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Line 42: The current workflow guard "if: github.event_name == 'push' &&
startsWith(github.ref, 'refs/tags/')" prevents manual runs (workflow_dispatch)
from reaching the build-release job and therefore its downstream manifest jobs;
either broaden this condition to allow workflow_dispatch (e.g., include
github.event_name == 'workflow_dispatch' in the if) so manual triggers can run
build-release and its dependent manifest jobs, or remove the workflow_dispatch
trigger if manual releases should not be supported; update the conditional
controlling the build-release path (the line with the if) and ensure jobs named
build-release and the manifest jobs retain their needs relationships.
---
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 104-105: The release job currently only imports the
registry-scoped buildkit cache (cache-from: scope=buildkit-${{ matrix.registry
}}-linux-${{ matrix.arch }}) but the build step exports to buildkit-linux-amd64,
so amd64 legs rebuild; update the cache-imports to include the shared
`buildkit-linux-${{ matrix.arch }}` scope as well (add a second cache-from entry
with type=gha,scope=buildkit-linux-${{ matrix.arch }} or otherwise import both
scopes) and ensure cache-to still writes the desired scopes (cache-to should
continue exporting both registry-scoped and shared buildkit scopes) so the amd64
release legs will reuse the exported cache.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: ced12395-41b3-4a32-ac59-24267910644d
📒 Files selected for processing (1)
.github/workflows/release.yml
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
3-8:⚠️ Potential issue | 🟠 Major | ⚡ Quick win
on.pushis still tag-only, so branch pushes never hit the CI gate.Lines 4-6 only match
refs/tags/v*. That means the newbuildjob runs for PRs and releases, but not for ordinary pushes tomainor feature branches, which misses the stated “every PR and push” behavior. If the gate is meant to cover all pushes, widenon.pushto branches too or drop the tag filter and keep the tag-only guards on the release jobs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 3 - 8, The workflow's trigger block currently restricts on.push to tags ("v*") so ordinary branch pushes never run CI; update the release.yml triggers by changing the on.push configuration (the on.push/tags entry) to include branch refs (e.g., add branches or branches-ignore patterns) or remove the tag-only filter and instead put tag-only conditions on the release job(s); modify the on: push/pull_request section accordingly so that both branch pushes and pull requests invoke the build job while keeping release-specific jobs gated by tag checks.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 29-33: The Build steps using
useblacksmith/build-push-action@fb9e3e6a9299c78462bfadd0d93352c316adc9b8 are not
writing/reading a shared cache, so downstream release jobs rebuild amd64; update
each Build invocation (the "Build" job and the other two occurrences) to wire
Docker build cache by adding cache-to and cache-from parameters (e.g., cache-to:
type=gha,mode=max and cache-from: type=gha) and ensure they use the same cache
reference/name across the gate build and the registry-specific release jobs so
the gate-produced cache is reusable by the release matrix.
---
Outside diff comments:
In @.github/workflows/release.yml:
- Around line 3-8: The workflow's trigger block currently restricts on.push to
tags ("v*") so ordinary branch pushes never run CI; update the release.yml
triggers by changing the on.push configuration (the on.push/tags entry) to
include branch refs (e.g., add branches or branches-ignore patterns) or remove
the tag-only filter and instead put tag-only conditions on the release job(s);
modify the on: push/pull_request section accordingly so that both branch pushes
and pull requests invoke the build job while keeping release-specific jobs gated
by tag checks.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 9aacfc2b-8645-4d42-a571-71e5df16ace2
📒 Files selected for processing (1)
.github/workflows/release.yml
- workflow_dispatch accepts a `tag` input (e.g. v1.2.3 or v1.2.3-dev.1) - build-release-* jobs now trigger on both tag push and workflow_dispatch - manifest creation distinguishes stable (x.y.z) from pre-release: stable → latest, x, x.y, x.y.z pre-release → only the exact version tag Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Add prepare job that centralises version resolution and Docker tag computation using docker/metadata-action (semver patterns + latest=auto) - build-release-* and push-* jobs consume version/tags from job outputs instead of repeating the logic inline in each job - build and prepare run in parallel; build-release-* waits on both - metadata-action handles stable vs pre-release automatically: x.y.z → latest, x, x.y, x.y.z x.y.z-pre.N → only x.y.z-pre.N Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8ae23de78c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.github/workflows/release.yml (1)
29-30:⚠️ Potential issue | 🟠 Major | ⚡ Quick winManual releases can publish the wrong source revision.
workflow_dispatchusesinputs.tagonly for naming, but every checkout defaults to the ref selected when the workflow is started. A manual run frommainwithtag=v1.2.3would therefore publishmainasv1.2.3.Suggested fix
- name: Checkout uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2 + with: + ref: ${{ github.event_name == 'workflow_dispatch' && format('refs/tags/{0}', github.event.inputs.tag) || github.ref }}Apply the same
with.refto all three checkout steps (lines 29–30, 103–104, 138–139) so the build and both release jobs build the requested tag on manual runs.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 29 - 30, The checkout steps currently always check out the workflow run ref, which makes manual workflow_dispatch runs publish the wrong source; update each actions/checkout usage (the steps using "uses: actions/checkout@...") to include a with.ref that uses the requested tag when provided (e.g., use the workflow input) and falls back to the run ref; apply this change to all three checkout steps so build and release jobs use the user-supplied tag: add a with.ref expression that references the workflow input (github.event.inputs.tag) with a fallback to github.ref.
♻️ Duplicate comments (1)
.github/workflows/release.yml (1)
35-39:⚠️ Potential issue | 🟠 Major | ⚡ Quick winThe shared amd64 cache still isn’t wired in.
The new gate build never writes a cache, and the release matrix never reads one, so tag pushes still rebuild amd64 multiple times. That misses the PR’s “shared GHA cache” objective and adds avoidable release latency.
Also applies to: 115-121, 151-157
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 35 - 39, The Build steps using useblacksmith/build-push-action@fb9e3e6a9299c78462bfadd0d93352c316adc9b8 currently do not produce or consume a shared amd64 cache; change the gate/build job’s Build step to push the cache (enable the action’s cache/push option so it writes an amd64 cache) and update the release-matrix Build steps to read that cache (configure cache-from / cache options or the action’s cache: true + cache-from settings to pull the shared linux/amd64 cache), and apply the same change to the other Build occurrences (the other Build steps shown later in the file) so tag pushes reuse the shared GHA cache instead of rebuilding amd64 repeatedly.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.github/workflows/release.yml:
- Around line 29-30: The checkout steps currently always check out the workflow
run ref, which makes manual workflow_dispatch runs publish the wrong source;
update each actions/checkout usage (the steps using "uses:
actions/checkout@...") to include a with.ref that uses the requested tag when
provided (e.g., use the workflow input) and falls back to the run ref; apply
this change to all three checkout steps so build and release jobs use the
user-supplied tag: add a with.ref expression that references the workflow input
(github.event.inputs.tag) with a fallback to github.ref.
---
Duplicate comments:
In @.github/workflows/release.yml:
- Around line 35-39: The Build steps using
useblacksmith/build-push-action@fb9e3e6a9299c78462bfadd0d93352c316adc9b8
currently do not produce or consume a shared amd64 cache; change the gate/build
job’s Build step to push the cache (enable the action’s cache/push option so it
writes an amd64 cache) and update the release-matrix Build steps to read that
cache (configure cache-from / cache options or the action’s cache: true +
cache-from settings to pull the shared linux/amd64 cache), and apply the same
change to the other Build occurrences (the other Build steps shown later in the
file) so tag pushes reuse the shared GHA cache instead of rebuilding amd64
repeatedly.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 39fc244e-aa7f-48bb-a8c3-04a0dc4cc96d
📒 Files selected for processing (1)
.github/workflows/release.yml
Summary
buildjob (linux/amd64, no push) that runs on every PR and push as a CI gatebuild-releasematrix (dockerhub + swr × amd64 + arm64) that only runs if the gate build passesprovenance: falseto satisfy Huawei SWR's manifest format requirementspush-swrnow creates its multi-arch manifest from SWR-native per-arch images instead of retagging from Docker HubTest plan
build (linux/amd64)job runs (no matrix)build-releasematrix jobs run after the gate succeedspush-dockerhubandpush-swrmanifest jobs run after the matrix completes🤖 Generated with Claude Code
Need help on this PR? Tag
@codesmithwith what you need.Summary by CodeRabbit