Skip to content

Add multi-arch Docker build workflow for Docker Hub and GHCR#74

Open
melihi wants to merge 3 commits into
PeterDaveHello:masterfrom
melihi:feat/multi-arch-build
Open

Add multi-arch Docker build workflow for Docker Hub and GHCR#74
melihi wants to merge 3 commits into
PeterDaveHello:masterfrom
melihi:feat/multi-arch-build

Conversation

@melihi
Copy link
Copy Markdown

@melihi melihi commented Apr 27, 2026

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 username
  • DOCKERHUB_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):

  • Ensure "Read and write permissions" is enabled, or that workflow-level
    permissions: packages: write is 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.

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.
@gemini-code-assist
Copy link
Copy Markdown

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

@qodo-code-review
Copy link
Copy Markdown

qodo-code-review Bot commented Apr 27, 2026

Review Summary by Qodo

(Agentic_describe updated until commit 71684e4)

Add multi-arch Docker build workflow for Docker Hub and GHCR

✨ Enhancement

Grey Divider

Walkthroughs

Description
• 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
Diagram
flowchart 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"]
Loading

Grey Divider

File Changes

1. .github/workflows/docker-build.yml ✨ Enhancement +84/-0

Multi-arch Docker build and push workflow

• Creates new GitHub Actions workflow for automated Docker image builds
• Configures triggers for master branch, version tags, PRs, and weekly schedule
• Sets up QEMU and Docker Buildx for multi-platform builds
• Implements Dockerfile linting with hadolint before build
• Authenticates with Docker Hub and GitHub Container Registry
• Extracts and applies semantic versioning tags and metadata
• Enables GitHub Actions build cache for faster builds

.github/workflows/docker-build.yml


Grey Divider

Qodo Logo

@qodo-code-review
Copy link
Copy Markdown

qodo-code-review Bot commented Apr 27, 2026

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. Uppercase GHCR image name🐞 Bug ≡ Correctness
Description
GHCR_IMAGE uses ghcr.io/${{ github.repository }} which can contain uppercase characters (e.g.,
PeterDaveHello/...) and produce an invalid Docker image reference, causing the build/push step to
fail for GHCR tags.
Code

.github/workflows/docker-build.yml[15]

+  GHCR_IMAGE: ghcr.io/${{ github.repository }}
Evidence
The workflow constructs the GHCR image name directly from github.repository. This repo’s owner is
referenced with uppercase in README, so the resulting image reference can include uppercase and
violate Docker image naming rules, breaking tagging/pushing.

.github/workflows/docker-build.yml[13-16]
README.md[7-24]
Best Practice: Docker image reference format

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`GHCR_IMAGE` is derived from `${{ github.repository }}`, which may include uppercase characters and can produce an invalid Docker image reference for GHCR.
### Issue Context
README references the repo owner with uppercase (e.g., `PeterDaveHello/...`), while Docker image references require lowercase.
### Fix Focus Areas
- .github/workflows/docker-build.yml[13-16]
### Suggested fix
Use a lowercase-safe value, e.g.:
- Hardcode: `GHCR_IMAGE: ghcr.io/peterdavehello/tor-socks-proxy` (matches README), or
- Expression: `GHCR_IMAGE: ghcr.io/${{ toLower(github.repository) }}` (if supported in your org), or
- Construct from known-lowercase vars you control.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. PR cache poisoning risk🐞 Bug ⛨ Security
Description
The workflow writes Buildx cache to type=gha even on pull_request runs, allowing untrusted PR
builds (especially from same-repo branches) to populate a shared cache used by later trusted builds.
Code

.github/workflows/docker-build.yml[R79-83]

+          push: ${{ github.event_name != 'pull_request' }}
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
Evidence
push is correctly disabled for PRs, but cache-to remains unconditional, meaning PR builds can
still write cache entries that subsequent non-PR builds restore via cache-from.

.github/workflows/docker-build.yml[74-84]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`cache-to: type=gha` is unconditional, so PR runs can write to the shared GitHub Actions cache.
### Issue Context
PR runs are explicitly set to `push: false`, but cache writes are still enabled. This can allow cache poisoning and also wastes cache space.
### Fix Focus Areas
- .github/workflows/docker-build.yml[74-84]
### Suggested fix
Gate cache writes to trusted events only, for example:
- Split the build step into two steps:
1) PR build: `cache-from` only
2) Non-PR build: `cache-from` + `cache-to`
Or conditionally set `cache-to` only when `github.event_name != 'pull_request'` (via separate steps or `if:` guarding a step).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

3. Scheduled builds use edge 🐞 Bug ☼ Reliability
Description
The new weekly scheduled rebuild increases the likelihood of CI breakage because the Dockerfile
installs moving @edge packages without version pinning, so builds can fail unpredictably over time
and across architectures.
Code

.github/workflows/docker-build.yml[R9-10]

+  schedule:
+    - cron: '0 0 * * 0'
Evidence
The workflow adds a weekly schedule, and the Dockerfile pulls from Alpine edge repositories and
installs tor@edge/obfs4proxy@edge without pinning versions. This combination makes scheduled
rebuilds non-deterministic.

.github/workflows/docker-build.yml[9-10]
Dockerfile[7-12]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Weekly scheduled builds can start failing unexpectedly because the Dockerfile installs unpinned `@edge` packages from moving repositories.
### Issue Context
This risk existed already, but the new scheduled multi-arch workflow will surface it more frequently.
### Fix Focus Areas
- .github/workflows/docker-build.yml[9-10]
- Dockerfile[7-13]
### Suggested fix
Pick one approach:
- Prefer stable Alpine repos/packages (avoid `@edge`), or
- Pin exact package versions (`tor@edge=<ver>`, `obfs4proxy@edge=<ver>`) and update intentionally, or
- If the goal is “nightly/weekly latest edge”, accept the risk but adjust workflow expectations/alerts accordingly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Actions not SHA pinned 🐞 Bug ⛨ Security
Description
All referenced GitHub Actions are pinned only by version tags (e.g., @v4, @v6), which are
mutable and increase supply-chain risk if an upstream tag is compromised or moved.
Code

.github/workflows/docker-build.yml[R22-43]

+      - uses: actions/checkout@v4
+      - uses: hadolint/hadolint-action@v3.1.0
+        with:
+          dockerfile: Dockerfile
+          failure-threshold: error
+
+  build:
+    needs: lint
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
Evidence
The workflow uses multiple third-party and first-party actions by floating tags rather than
immutable commit SHAs.

.github/workflows/docker-build.yml[22-23]
.github/workflows/docker-build.yml[38-43]
.github/workflows/docker-build.yml[59-62]
.github/workflows/docker-build.yml[74-76]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Actions are referenced by mutable tags (`@vX`) instead of immutable commit SHAs.
### Issue Context
This is a supply-chain hardening best practice; it reduces the blast radius of a compromised/moved tag.
### Fix Focus Areas
- .github/workflows/docker-build.yml[22-23]
- .github/workflows/docker-build.yml[38-43]
- .github/workflows/docker-build.yml[44-57]
- .github/workflows/docker-build.yml[59-62]
- .github/workflows/docker-build.yml[74-76]
### Suggested fix
Update each `uses:` line to pin to a specific commit SHA (optionally keeping the tag in a comment for readability), e.g.:
- `uses: actions/checkout@<sha>`
- `uses: docker/build-push-action@<sha>`
- `uses: hadolint/hadolint-action@<sha>`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

5. Image provenance disabled 🐞 Bug ⛨ Security
Description
The workflow explicitly disables build provenance (provenance: false), removing attestation
metadata that can improve consumer confidence and supply-chain verification for published images.
Code

.github/workflows/docker-build.yml[84]

+          provenance: false
Evidence
The build-push step turns off provenance generation via an explicit flag.

.github/workflows/docker-build.yml[84-84]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`provenance: false` disables build provenance/attestation.
### Issue Context
This may be intentional (compatibility/perf), but if not required, enabling provenance improves supply-chain posture.
### Fix Focus Areas
- .github/workflows/docker-build.yml[84-84]
### Suggested fix
Remove `provenance: false` to use defaults, or set `provenance: true` if you want to enforce attestation for pushed images.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

@qodo-free-for-open-source-projects
Copy link
Copy Markdown

qodo-free-for-open-source-projects Bot commented Apr 27, 2026

Code Review by Qodo

🐞 Bugs (5) 📘 Rule violations (0)

Grey Divider


Action required

1. Uppercase GHCR image name 🐞 Bug ≡ Correctness
Description
GHCR_IMAGE uses ghcr.io/${{ github.repository }} which can contain uppercase characters (e.g.,
PeterDaveHello/...) and produce an invalid Docker image reference, causing the build/push step to
fail for GHCR tags.
Code

.github/workflows/docker-build.yml[15]

+  GHCR_IMAGE: ghcr.io/${{ github.repository }}
Evidence
The workflow constructs the GHCR image name directly from github.repository. This repo’s owner is
referenced with uppercase in README, so the resulting image reference can include uppercase and
violate Docker image naming rules, breaking tagging/pushing.

.github/workflows/docker-build.yml[13-16]
README.md[7-24]
Best Practice: Docker image reference format

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`GHCR_IMAGE` is derived from `${{ github.repository }}`, which may include uppercase characters and can produce an invalid Docker image reference for GHCR.

### Issue Context
README references the repo owner with uppercase (e.g., `PeterDaveHello/...`), while Docker image references require lowercase.

### Fix Focus Areas
- .github/workflows/docker-build.yml[13-16]

### Suggested fix
Use a lowercase-safe value, e.g.:
- Hardcode: `GHCR_IMAGE: ghcr.io/peterdavehello/tor-socks-proxy` (matches README), or
- Expression: `GHCR_IMAGE: ghcr.io/${{ toLower(github.repository) }}` (if supported in your org), or
- Construct from known-lowercase vars you control.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. PR cache poisoning risk 🐞 Bug ⛨ Security
Description
The workflow writes Buildx cache to type=gha even on pull_request runs, allowing untrusted PR
builds (especially from same-repo branches) to populate a shared cache used by later trusted builds.
Code

.github/workflows/docker-build.yml[R79-83]

+          push: ${{ github.event_name != 'pull_request' }}
+          tags: ${{ steps.meta.outputs.tags }}
+          labels: ${{ steps.meta.outputs.labels }}
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
Evidence
push is correctly disabled for PRs, but cache-to remains unconditional, meaning PR builds can
still write cache entries that subsequent non-PR builds restore via cache-from.

.github/workflows/docker-build.yml[74-84]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`cache-to: type=gha` is unconditional, so PR runs can write to the shared GitHub Actions cache.

### Issue Context
PR runs are explicitly set to `push: false`, but cache writes are still enabled. This can allow cache poisoning and also wastes cache space.

### Fix Focus Areas
- .github/workflows/docker-build.yml[74-84]

### Suggested fix
Gate cache writes to trusted events only, for example:
- Split the build step into two steps:
 1) PR build: `cache-from` only
 2) Non-PR build: `cache-from` + `cache-to`

Or conditionally set `cache-to` only when `github.event_name != 'pull_request'` (via separate steps or `if:` guarding a step).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

3. Scheduled builds use edge 🐞 Bug ☼ Reliability
Description
The new weekly scheduled rebuild increases the likelihood of CI breakage because the Dockerfile
installs moving @edge packages without version pinning, so builds can fail unpredictably over time
and across architectures.
Code

.github/workflows/docker-build.yml[R9-10]

+  schedule:
+    - cron: '0 0 * * 0'
Evidence
The workflow adds a weekly schedule, and the Dockerfile pulls from Alpine edge repositories and
installs tor@edge/obfs4proxy@edge without pinning versions. This combination makes scheduled
rebuilds non-deterministic.

.github/workflows/docker-build.yml[9-10]
Dockerfile[7-12]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Weekly scheduled builds can start failing unexpectedly because the Dockerfile installs unpinned `@edge` packages from moving repositories.

### Issue Context
This risk existed already, but the new scheduled multi-arch workflow will surface it more frequently.

### Fix Focus Areas
- .github/workflows/docker-build.yml[9-10]
- Dockerfile[7-13]

### Suggested fix
Pick one approach:
- Prefer stable Alpine repos/packages (avoid `@edge`), or
- Pin exact package versions (`tor@edge=<ver>`, `obfs4proxy@edge=<ver>`) and update intentionally, or
- If the goal is “nightly/weekly latest edge”, accept the risk but adjust workflow expectations/alerts accordingly.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


4. Actions not SHA pinned 🐞 Bug ⛨ Security
Description
All referenced GitHub Actions are pinned only by version tags (e.g., @v4, @v6), which are
mutable and increase supply-chain risk if an upstream tag is compromised or moved.
Code

.github/workflows/docker-build.yml[R22-43]

+      - uses: actions/checkout@v4
+      - uses: hadolint/hadolint-action@v3.1.0
+        with:
+          dockerfile: Dockerfile
+          failure-threshold: error
+
+  build:
+    needs: lint
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      packages: write
+    steps:
+      - name: Checkout
+        uses: actions/checkout@v4
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        uses: docker/setup-buildx-action@v3
+
Evidence
The workflow uses multiple third-party and first-party actions by floating tags rather than
immutable commit SHAs.

.github/workflows/docker-build.yml[22-23]
.github/workflows/docker-build.yml[38-43]
.github/workflows/docker-build.yml[59-62]
.github/workflows/docker-build.yml[74-76]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Actions are referenced by mutable tags (`@vX`) instead of immutable commit SHAs.

### Issue Context
This is a supply-chain hardening best practice; it reduces the blast radius of a compromised/moved tag.

### Fix Focus Areas
- .github/workflows/docker-build.yml[22-23]
- .github/workflows/docker-build.yml[38-43]
- .github/workflows/docker-build.yml[44-57]
- .github/workflows/docker-build.yml[59-62]
- .github/workflows/docker-build.yml[74-76]

### Suggested fix
Update each `uses:` line to pin to a specific commit SHA (optionally keeping the tag in a comment for readability), e.g.:
- `uses: actions/checkout@<sha>`
- `uses: docker/build-push-action@<sha>`
- `uses: hadolint/hadolint-action@<sha>`

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

5. Image provenance disabled 🐞 Bug ⛨ Security
Description
The workflow explicitly disables build provenance (provenance: false), removing attestation
metadata that can improve consumer confidence and supply-chain verification for published images.
Code

.github/workflows/docker-build.yml[84]

+          provenance: false
Evidence
The build-push step turns off provenance generation via an explicit flag.

.github/workflows/docker-build.yml[84-84]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`provenance: false` disables build provenance/attestation.

### Issue Context
This may be intentional (compatibility/perf), but if not required, enabling provenance improves supply-chain posture.

### Fix Focus Areas
- .github/workflows/docker-build.yml[84-84]

### Suggested fix
Remove `provenance: false` to use defaults, or set `provenance: true` if you want to enforce attestation for pushed images.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

@coderabbitai
Copy link
Copy Markdown

coderabbitai Bot commented Apr 27, 2026

📝 Walkthrough

Walkthrough

Adds 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

Cohort / File(s) Summary
Docker CI/CD Workflow
​.github/workflows/docker-build.yml
New workflow: Hadolint lint job; build job that sets up QEMU and Docker Buildx, computes lowercase GHCR image name, conditionally logs into Docker Hub and GHCR for non-PR runs, uses docker/metadata-action to generate tags/labels (branch refs, semver parts, short SHA, latest on default branch), builds for configured PLATFORMS, uses GitHub Actions cache for build layers with cache-to only on non-PR runs, and disables provenance generation. Triggers: pushes to master, PRs against master, weekly cron, and manual dispatch.

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
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

🚥 Pre-merge checks | ✅ 5
✅ Passed checks (5 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately and concisely describes the main change: adding a multi-architecture Docker build workflow for Docker Hub and GHCR. It is clear, specific, and directly aligned with the primary purpose of the changeset.
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Description check ✅ Passed The description provides specific details about the workflow functionality, configuration requirements, and setup instructions, directly relating to the changeset.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests

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.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

Comment thread .github/workflows/docker-build.yml Outdated
Comment thread .github/workflows/docker-build.yml
Comment thread .github/workflows/docker-build.yml Outdated
Comment thread .github/workflows/docker-build.yml
Comment thread .github/workflows/docker-build.yml
@kilo-code-bot
Copy link
Copy Markdown

kilo-code-bot Bot commented Apr 27, 2026

Code Review Summary

Status: 3 Issues Remain (2 Resolved) | Recommendation: Remaining items are non-blocking; safe to merge after verifying repo-level GHCR permission

Overview

Severity Count
CRITICAL 0
WARNING 1
SUGGESTION 2

Changes Since Last Review

Status Issue
✅ Resolved CRITICAL (prev. line 15) — Lowercase GHCR image name. Now computed at runtime via echo "GHCR_IMAGE=ghcr.io/${GITHUB_REPOSITORY,,}" >> "$GITHUB_ENV". Correct bash lowercase expansion; default shell on ubuntu-latest is bash, and $GITHUB_ENV values are available to subsequent steps via ${{ env.GHCR_IMAGE }}.
✅ Resolved WARNING (prev. line 68) — type=ref,event=pr removed from metadata tags.
➕ New (benign) cache-to is now gated per-event: `${{ github.event_name != 'pull_request' && 'type=gha,mode=max'
Remaining Issues (click to expand)

WARNING

File Line Issue
.github/workflows/docker-build.yml 57 GHCR push with GITHUB_TOKEN requires repo-level Settings → Actions → Workflow permissions set to Read and write. Job-level packages: write alone is not sufficient if the repo default is read-only — the first push will 403.

SUGGESTION

File Line Issue
.github/workflows/docker-build.yml 72 Weekly cron only rebuilds :latest / :master / :sha-*, not released semver tags. If the intent is to keep version tags patched against Alpine CVEs, they will go stale.
.github/workflows/docker-build.yml 84 provenance: false disables SLSA build provenance, weakening supply-chain attestation. Enable unless a known registry/tooling incompatibility exists.
Other Observations (not in diff)
File Line Issue
.github/workflows/docker-build.yml n/a No concurrency: block. Rapid pushes to master or multiple tag pushes run full multi-arch QEMU builds in parallel, burning minutes and causing cache contention. Consider concurrency: { group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: ${{ github.event_name == 'pull_request' }} }.
.github/workflows/docker-build.yml n/a Third-party actions are pinned by floating major tag rather than commit SHA. For a workflow holding registry push credentials, SHA pinning with Renovate (already configured in renovate.json) is stronger supply-chain posture.
.github/workflows/docker-build.yml n/a Semver tag patterns omit {{major}}-only (e.g. :1). Consumers expecting a floating major tag won't get one.
.github/workflows/docker-build.yml n/a cache-to: type=gha,mode=max with four architectures can dominate the 10 GB GHA cache quota and evict other caches. Consider mode=min or a registry cache.
.travis.yml n/a Existing Travis CI config remains. If this workflow replaces it, remove .travis.yml in a follow-up to avoid duplicate CI signals.
Files Reviewed (1 file)
  • .github/workflows/docker-build.yml - 3 remaining issues, 2 resolved

Fix these issues in Kilo Cloud


Reviewed by claude-opus-4.7 · 259,021 tokens

Copy link
Copy Markdown

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (2)
.github/workflows/docker-build.yml (2)

74-84: Reconsider disabling build provenance.

Setting provenance: false opts out of SLSA provenance attestations that docker/build-push-action@v6 emits 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 explicitly mode=max) and optionally adding sbom: 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 a concurrency block to cancel superseded runs.

Without concurrency, rapid pushes to master or PR updates can run multi-arch builds in parallel and race the latest/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

📥 Commits

Reviewing files that changed from the base of the PR and between 8265a4a and 71684e4.

📒 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 the Dockerfile actually builds for linux/386.

linux/386 is 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 current Dockerfile (and its base image / installed packages such as tor) 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 Dockerfile was previously published for 386 and that the base image + tor package 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?

Comment thread .github/workflows/docker-build.yml Outdated
Comment thread .github/workflows/docker-build.yml Outdated
melih isbilen added 2 commits April 27, 2026 15:45
- 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant