ci: parallelize push-latest-images workflow using matrix#318
ci: parallelize push-latest-images workflow using matrix#318Shivampal157 wants to merge 1 commit intocontainer-registry:mainfrom
Conversation
📝 WalkthroughWalkthroughThe PR parallelizes multi-architecture image builds using GitHub Actions matrix strategy, enabling concurrent builds across platforms (amd64, arm64, ppc64le, s390x, riscv64). A dependent job creates and signs manifest lists after per-platform builds complete. New action inputs and Taskfile tasks support single-platform builds and manifest-only workflows. Changes
Sequence DiagramsequenceDiagram
participant GitHub Actions as Workflow
participant Matrix as Matrix Strategy
participant Builders as Build Runners<br/>(Per-Platform)
participant Registry as Container Registry
participant Manifest as Manifest Job
participant Cosign as Cosign Signer
GitHub Actions->>Matrix: Trigger with platforms<br/>[amd64, arm64, ppc64le, s390x, riscv64]
par Parallel Builds
Matrix->>Builders: Build for amd64
Matrix->>Builders: Build for arm64
Matrix->>Builders: Build for ppc64le
Matrix->>Builders: Build for s390x
Matrix->>Builders: Build for riscv64
end
Builders->>Registry: Push per-platform images<br/>with TAG_SUFFIX
Note over Manifest: Depends on all matrix jobs
GitHub Actions->>Manifest: Trigger manifest job
Manifest->>Registry: Fetch per-platform images
Manifest->>Registry: Create manifest list<br/>(combines all architectures)
Manifest->>Cosign: Sign manifest list
Cosign->>Registry: Store signed manifest
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 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)
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 |
Codacy's Analysis Summary0 new issue (≤ 0 issue) Review Pull Request in Codacy →
|
Signed-off-by: Shivampal157 <shivampal60076@gmail.com>
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
1 issue found across 3 files
Prompt for AI agents (all issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="taskfiles/publish.yml">
<violation number="1" location="taskfiles/publish.yml:162">
P2: manifest-list-and-sign uses BASE_TAG directly without stripping a leading "v", while image builds strip it. If BASE_TAG comes from a Git tag (e.g., v1.0.0), the manifest task will reference non-existent images (v1.0.0-<arch>).</violation>
</file>
Since this is your first cubic review, here's how it works:
- cubic automatically reviews your code and comments on bugs and improvements
- Teach cubic by replying to its comments. cubic learns from your replies and gets better over time
- Ask questions if you need clarification on any suggestion
Reply with feedback, questions, or to request a fix. Tag @cubic-dev-ai to re-run a review.
| for COMPONENT in satellite ground-control; do | ||
| SOURCES="" | ||
| for suf in {{.SUFFIXES}}; do | ||
| SOURCES="$SOURCES {{.REGISTRY}}/{{.PROJECT_NAME}}/$COMPONENT:{{.BASE_TAG}}-$suf" |
There was a problem hiding this comment.
P2: manifest-list-and-sign uses BASE_TAG directly without stripping a leading "v", while image builds strip it. If BASE_TAG comes from a Git tag (e.g., v1.0.0), the manifest task will reference non-existent images (v1.0.0-).
Prompt for AI agents
Check if this issue is valid — if so, understand the root cause and fix it. At taskfiles/publish.yml, line 162:
<comment>manifest-list-and-sign uses BASE_TAG directly without stripping a leading "v", while image builds strip it. If BASE_TAG comes from a Git tag (e.g., v1.0.0), the manifest task will reference non-existent images (v1.0.0-<arch>).</comment>
<file context>
@@ -106,17 +120,57 @@ tasks:
+ for COMPONENT in satellite ground-control; do
+ SOURCES=""
+ for suf in {{.SUFFIXES}}; do
+ SOURCES="$SOURCES {{.REGISTRY}}/{{.PROJECT_NAME}}/$COMPONENT:{{.BASE_TAG}}-$suf"
+ done
+ echo "Creating manifest list for $COMPONENT:{{.BASE_TAG}}..."
</file context>
There was a problem hiding this comment.
Thanks for pointing this out.
In this PR, the parallelization only applies to the push-latest-images workflow.
The tagged release pipeline (publish-release on refs/tags/*) is intentionally kept unchanged
and still builds and signs all architectures in a single job.
For the matrix-based path, the manifest is created only after the per-arch images
are successfully pushed, so BASE_TAG should already exist at that point.
That said, I agree this edge case is worth improving. I can follow up with a small
safety check or refactor in a separate PR if maintainers think it’s required here.
1 participant
Fixes #312
Description
This PR refactors the push-latest-images workflow to use a GitHub Actions
matrix strategy so that images for different architectures are built and
pushed in parallel instead of sequentially.
What changed
Result
→ Total wall time reduced to roughly the slowest single-arch build
Notes
Summary by cubic
Parallelized the push-latest-images workflow using a per-arch matrix so each architecture builds and pushes in parallel, then a separate job assembles and signs the multi-arch manifest. This reduces wall time from ~1.5h to roughly the slowest single-arch build.
Written for commit a25e4c7. Summary will update on new commits.
Summary by CodeRabbit