Add multi-arch Docker build workflow for Docker Hub and GHCR#74
Conversation
Adds a GitHub Actions workflow that uses Buildx + QEMU to build the image for linux/amd64, linux/arm64, linux/arm/v7 and linux/386, and pushes to Docker Hub and GitHub Container Registry on master, tags, and weekly schedule. Includes hadolint and GHA build cache. PRs build (no push) for validation.
|
Note Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported. |
Review Summary by Qodo(Agentic_describe updated until commit 71684e4)Add multi-arch Docker build workflow for Docker Hub and GHCR
WalkthroughsDescription• Adds GitHub Actions workflow for multi-architecture Docker builds • Supports linux/amd64, linux/arm64, linux/arm/v7, linux/386 platforms • Pushes to Docker Hub and GitHub Container Registry automatically • Includes Dockerfile linting and GitHub Actions build caching Diagramflowchart LR
A["Push/Tag/Schedule"] --> B["Lint Dockerfile"]
B --> C["Setup QEMU & Buildx"]
C --> D["Login to Registries"]
D --> E["Extract Metadata"]
E --> F["Build & Push Multi-Arch"]
F --> G["Docker Hub & GHCR"]
File Changes1. .github/workflows/docker-build.yml
|
Code Review by Qodo
1.
|
Code Review by Qodo
1. Uppercase GHCR image name
|
📝 WalkthroughWalkthroughAdds a new GitHub Actions workflow that lints the Dockerfile, sets up QEMU and Buildx, computes image metadata/tags, conditionally authenticates to Docker Hub and GHCR, performs multi-platform builds with cache handling, and pushes images when not a pull request. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Dev as Developer
participant GH as GitHub Actions
participant Lint as Hadolint
participant QEMU as QEMU/Buildx setup
participant Meta as docker/metadata-action
participant Registry as Docker Hub / GHCR
Dev->>GH: push / PR / schedule / manual
GH->>Lint: run Dockerfile lint
Lint-->>GH: lint result (pass/fail)
GH->>QEMU: setup QEMU & Buildx
QEMU-->>GH: builder ready
GH->>Meta: generate tags & labels (branch, semver, sha, latest)
Meta-->>GH: tags/labels
alt event != pull_request
GH->>Registry: login (Docker Hub / GHCR) if secrets present
Registry-->>GH: auth success
GH->>Registry: build & push multi-platform images (with cache-to)
Registry-->>GH: push result
else pull_request
GH->>Registry: build only (no push, no cache-to)
Registry-->>GH: build result
end
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 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)
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 |
Code Review SummaryStatus: 3 Issues Remain (2 Resolved) | Recommendation: Remaining items are non-blocking; safe to merge after verifying repo-level GHCR permission Overview
Changes Since Last Review
Remaining Issues (click to expand)WARNING
SUGGESTION
Other Observations (not in diff)
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Reviewed by claude-opus-4.7 · 259,021 tokens |
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/docker-build.yml (2)
74-84: Reconsider disabling build provenance.Setting
provenance: falseopts out of SLSA provenance attestations thatdocker/build-push-action@v6emits by default, weakening supply-chain guarantees for the published image. Unless you hit a concrete consumer issue (e.g., manifest list incompatibility with a specific registry), prefer leaving it on (or explicitlymode=max) and optionally addingsbom: true.♻️ Proposed change
cache-from: type=gha cache-to: type=gha,mode=max - provenance: false + provenance: mode=max + sbom: true🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-build.yml around lines 74 - 84, The workflow step "Build and push" currently disables SLSA provenance by setting provenance: false; restore supply-chain attestations by removing provenance: false or setting provenance: true (or provenance: mode=max) and consider enabling sbom: true on the docker/build-push-action@v6 step so the action emits provenance and SBOMs for published images (locate the step named "Build and push" that uses docker/build-push-action@v6 and update the provenance/sbom keys accordingly).
1-12: Add aconcurrencyblock to cancel superseded runs.Without
concurrency, rapid pushes tomasteror PR updates can run multi-arch builds in parallel and race thelatest/master/sha-…tag publish. Cancelling superseded runs saves CI minutes and avoids non-deterministic tag overwrites; preserve in-progress runs for tag pushes so releases aren't aborted.♻️ Proposed change
on: push: branches: [master] tags: ['v*'] pull_request: branches: [master] schedule: - cron: '0 0 * * 0' workflow_dispatch: + +concurrency: + group: ${{ github.workflow }}-${{ github.ref }} + cancel-in-progress: ${{ github.event_name == 'pull_request' }}🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/docker-build.yml around lines 1 - 12, Add a top-level concurrency block to the "Docker Build & Push" workflow to cancel superseded runs: create a concurrency group that keys off the workflow and the git ref (so runs for the same branch/sha share a group) and set cancel-in-progress to true for non-tag pushes but false for tag refs so release/tag pushes are not aborted; place this block at the top level of the workflow (near the workflow "name" or "on" keys) so it applies to the existing push/PR/tag triggers.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/docker-build.yml:
- Around line 74-84: The workflow step "Build and push" currently disables SLSA
provenance by setting provenance: false; restore supply-chain attestations by
removing provenance: false or setting provenance: true (or provenance: mode=max)
and consider enabling sbom: true on the docker/build-push-action@v6 step so the
action emits provenance and SBOMs for published images (locate the step named
"Build and push" that uses docker/build-push-action@v6 and update the
provenance/sbom keys accordingly).
- Around line 1-12: Add a top-level concurrency block to the "Docker Build &
Push" workflow to cancel superseded runs: create a concurrency group that keys
off the workflow and the git ref (so runs for the same branch/sha share a group)
and set cancel-in-progress to true for non-tag pushes but false for tag refs so
release/tag pushes are not aborted; place this block at the top level of the
workflow (near the workflow "name" or "on" keys) so it applies to the existing
push/PR/tag triggers.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 07472754-9fca-4864-8284-f7ec7389004d
📒 Files selected for processing (1)
.github/workflows/docker-build.yml
📜 Review details
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: Kilo Code Review
🔇 Additional comments (1)
.github/workflows/docker-build.yml (1)
16-16: Verify theDockerfileactually builds forlinux/386.
linux/386is the most likely platform to fail in a multi-arch matrix — Alpine has historically had partial i386 support and some packages (including networking tooling) can be missing or broken for that arch. If the currentDockerfile(and its base image / installed packages such astor) doesn't have working i386 artifacts, the entire matrix build will fail and block publishes to the other three working platforms.Please confirm whether the project's
Dockerfilewas previously published for 386 and that the base image +torpackage have an i386 variant on the registry/distribution being used.#!/bin/bash # Inspect the Dockerfile to identify the base image and installed packages. fd -t f '^Dockerfile$' --exec cat {}Does Alpine Linux currently provide a tor package for the i386 (x86) architecture in the latest stable release?
- Compute GHCR image name in a step to lowercase the GitHub repository slug, so pushes work for namespaces with uppercase characters. - Remove type=ref,event=pr from metadata tags since PRs build without pushing, making the pr-N tag unused dead weight.
Pull request builds now only read from the cache via cache-from and skip cache-to entirely. GitHub Actions already isolates cache writes by branch (PRs cannot poison the default-branch cache), but skipping the write also removes any same-branch self-poisoning window between PR runs and keeps cache writes limited to trusted master/tag/schedule events.
Adds a GitHub Actions workflow that uses Buildx + QEMU to build the image for linux/amd64, linux/arm64, linux/arm/v7 and linux/386, and pushes to Docker Hub and GitHub Container Registry on master, tags, and weekly schedule. Includes hadolint and GHA build cache. PRs build (no push) for validation.
Maintainer setup required
Before this can push to registries, the following needs to be configured:
Secrets (
Settings → Secrets and variables → Actions):DOCKERHUB_USERNAME— Docker Hub usernameDOCKERHUB_TOKEN— Docker Hub Personal Access Token (Read & Write)GHCR uses the auto-provided
GITHUB_TOKEN, no extra secret needed.Workflow permissions (
Settings → Actions → General → Workflow permissions):permissions: packages: writeis honored (which this workflow declares).Until these are in place, PR builds will still pass (build-only, no push),
but merges to master / tags / scheduled runs will fail at the push step.