feat(buildkit): add Debian and RPM packaging for BuildKit#218
Conversation
Add packaging infrastructure for BuildKit RISC-V64 binaries: Debian packaging (debian-buildkit/): - control: Package metadata with containerd/docker recommendations - rules: Skip build (pre-built binaries) - install: Install buildkitd and buildctl to /usr/bin - changelog, copyright, source/format RPM packaging (rpm-buildkit/): - buildkit.spec: RPM spec for both binaries Workflows: - build-buildkit-package.yml: Triggered by weekly build, creates .deb - build-buildkit-rpm.yml: Triggered by weekly build, creates .rpm Both workflows support: - Development builds (buildkit-v20251209-dev) - Official releases (buildkit-v0.17.3-riscv64) - Automatic version extraction from release tags - Skip if packages already exist Package name aligned with official Debian packaging work at salsa.debian.org/go-team/packages/golang-github-moby-buildkit
|
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. WalkthroughAdds GitHub Actions workflows and packaging metadata to build, validate, and upload BuildKit .deb and .rpm packages for riscv64: release detection, binary download/validation, version extraction, package assembly (Debian/RPM), lint checks, and idempotent upload to GitHub releases. Changes
Sequence Diagram(s)sequenceDiagram
autonumber
participant Scheduler as Scheduler / Manual
participant GH_Actions as GitHub Actions Workflows
participant Runner as RISC‑V Self‑Hosted Runner
participant GH_API as GitHub Release API
participant Release as GitHub Release Assets
Scheduler->>GH_Actions: trigger (cron or manual with release_tag)
GH_Actions->>GH_API: query latest stable BuildKit release/tag
alt no release found
GH_Actions->>GH_Actions: exit with error
else release found
GH_Actions->>GH_API: check if .deb/.rpm assets exist
alt assets exist
GH_Actions->>GH_Actions: set already_built -> log & stop
else assets missing
GH_Actions->>Runner: dispatch packaging job
Runner->>GH_API: download upstream binaries (buildkitd, buildctl)
Runner->>Runner: validate files, check arch
Runner->>Runner: run extract-buildkit-version.sh -> derive package version
Runner->>Runner: update changelog/spec, build package (.deb/.rpm)
Runner->>Runner: run lint checks (lintian / rpmlint)
Runner->>GH_API: upload built packages (with retries)
GH_API->>Release: store uploaded assets
Runner->>GH_Actions: output install instructions/status
end
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes
Possibly related PRs
Suggested labels
Poem
Pre-merge checks and finishing touches✅ Passed checks (3 passed)
✨ 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 |
Summary of ChangesHello @gounthar, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances BuildKit's distribution by introducing official Debian and RPM packaging for the RISC-V64 architecture. It establishes the necessary infrastructure and automates the package generation process through GitHub Actions, ensuring consistent and streamlined delivery of BuildKit binaries for this platform. Highlights
Ignored Files
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces Debian and RPM packaging for BuildKit on RISC-V64, using pre-built binaries. The packaging infrastructure for both dpkg and rpm is well-structured. My review focuses on improving the package dependency declarations to be more accurate and avoid redundancy. Specifically, I've suggested changes to the Recommends fields in both the Debian control file and the RPM .spec file to correctly express an 'OR' relationship for runtime dependencies like containerd and docker, rather than the current 'AND' relationship which could be misleading.
debian-buildkit/control
Outdated
| Package: buildkit | ||
| Architecture: riscv64 | ||
| Depends: ${shlibs:Depends}, ${misc:Depends} | ||
| Recommends: containerd (>= 1.7) | containerd.io (>= 1.7), docker.io (>= 20.10) | docker-ce (>= 20.10) |
There was a problem hiding this comment.
The comma in the Recommends field acts as an 'AND' operator, meaning this package recommends installing both a containerd package and a docker package. This is likely not the intended behavior, as installing Docker typically includes a containerd runtime, making the separate containerd recommendation redundant. To recommend any one of these packages as a suitable runtime, you should use the pipe | symbol to create a single list of alternatives.
Recommends: containerd (>= 1.7) | containerd.io (>= 1.7) | docker.io (>= 20.10) | docker-ce (>= 20.10)
There was a problem hiding this comment.
Fixed in commit 2a22afc. Changed the dependency semantics:
Recommends: containerd (>= 1.7) | containerd.io (>= 1.7)- BuildKit requires a container runtimeSuggests: docker.io (>= 20.10) | docker-ce (>= 20.10)- Docker is optional, only needed for buildx integration
This correctly expresses that containerd is the required backend, while Docker is an optional enhancement.
rpm-buildkit/buildkit.spec
Outdated
| Recommends: containerd | ||
| Recommends: docker-ce |
There was a problem hiding this comment.
Using two separate Recommends tags is equivalent to a logical 'AND', which means the package recommends installing both containerd and docker-ce. This is likely redundant, as docker-ce includes a containerd runtime.
To express an 'OR' relationship, you can use boolean dependencies if your target RPM-based distributions support RPM v4.13+ (e.g., RHEL 8+, Fedora 28+). This would better reflect that either package is a suitable runtime.
If you need to support older systems that don't support boolean dependencies, consider recommending only containerd and listing docker-ce as a Suggests.
Recommends: (containerd or docker-ce)
There was a problem hiding this comment.
Fixed in commit 2a22afc. Changed the dependency semantics:
Recommends: containerd- BuildKit requires a container runtimeSuggests: docker-ceandSuggests: moby-engine- Docker is optional
This correctly expresses that containerd is the required backend, while Docker is an optional enhancement.
Automatically detects new BuildKit releases from moby/buildkit daily at 08:00 UTC. When a new release is found, triggers buildkit-weekly-build.yml and creates a tracking issue. Features: - Filters for stable releases (excludes dockerfile/* and pre-releases) - Checks if release already built before triggering - Creates GitHub issue to track build progress
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 5
🧹 Nitpick comments (7)
debian-buildkit/copyright (1)
7-11: Update copyright years to include 2025.The copyright years appear outdated. Since we're now in December 2025:
- Line 7: Upstream copyright should likely be
2017-2025- Line 11: Debian packaging copyright should be
2024-2025or just2025Files: * -Copyright: 2017-2024 The Moby Authors +Copyright: 2017-2025 The Moby Authors License: Apache-2.0 Files: debian/* -Copyright: 2024 Bruno Verächten <bruno@verachten.fr> +Copyright: 2024-2025 Bruno Verächten <bruno@verachten.fr> License: Apache-2.0debian-buildkit/changelog (1)
1-8: Update the changelog date to 2025.The changelog date shows
Dec 2024, but the current date is December 2025. This should likely be updated.Additionally, including
riscv64in the version string (0.17.3-riscv64-1) is unconventional for Debian packaging—architecture is typically handled by theArchitecturefield indebian/control. However, if this aligns with the upstream Debian work mentioned in the PR objectives, it may be intentional.-buildkit (0.17.3-riscv64-1) trixie; urgency=medium +buildkit (0.17.3-riscv64-1) trixie; urgency=medium * Initial RISC-V64 build of BuildKit * Built from upstream moby/buildkit repository * Native compilation on RISC-V64 hardware * Includes buildkitd daemon and buildctl CLI - -- Bruno Verächten <bruno@verachten.fr> Mon, 09 Dec 2024 08:00:00 +0000 + -- Bruno Verächten <bruno@verachten.fr> Tue, 09 Dec 2025 08:00:00 +0000rpm-buildkit/buildkit.spec (2)
53-55: Consider including the license file in the package.The RPM spec doesn't include a
%licensedirective. For compliance best practices, consider adding the Apache-2.0 license file to the package.%files +%license LICENSE %{_bindir}/buildkitd %{_bindir}/buildctlThis would require providing the LICENSE file as an additional source or extracting it from the upstream repository during the workflow.
58-58: Update changelog date to 2025.The changelog date shows
Dec 09 2024, but the current date is December 2025.-%changelog -* Mon Dec 09 2024 Bruno Verachten <bruno@verachten.fr> - 0.17.3-1 +%changelog +* Tue Dec 09 2025 Bruno Verachten <bruno@verachten.fr> - 0.17.3-1debian-buildkit/rules (1)
8-14: Consider adding basic validation for pre-built binaries.While skipping build and test phases is appropriate for pre-built binaries, consider adding a minimal check to verify that the binaries exist and are executable before packaging.
Apply this diff to add basic validation:
override_dh_auto_build: # Binary provided pre-built from upstream release + @test -x buildkitd || { echo "Error: buildkitd not found or not executable"; exit 1; } + @test -x buildctl || { echo "Error: buildctl not found or not executable"; exit 1; } @echo "Using pre-built binaries" override_dh_auto_test: # Skip tests - binaries already tested upstream + @./buildkitd --version >/dev/null 2>&1 || echo "Warning: buildkitd version check failed" + @./buildctl --version >/dev/null 2>&1 || echo "Warning: buildctl version check failed" @echo "Skipping tests for pre-built binaries".github/workflows/build-buildkit-package.yml (2)
81-88: Extract duplicate release detection logic.The release tag detection logic is duplicated from lines 44-45. This creates maintenance overhead and potential for inconsistency.
Consider storing the release tag in the check step's output and reusing it:
- name: Check if new release exists id: check_release env: GH_TOKEN: ${{ github.token }} run: | set -euo pipefail # Skip check for manual dispatch if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then echo "Manual dispatch - proceeding with build" echo "skip=false" >> $GITHUB_OUTPUT + echo "release_tag=${{ github.event.inputs.release_tag }}" >> $GITHUB_OUTPUT exit 0 fi # Find the latest BuildKit release (matches both dev and official releases) # gh release list outputs: Title<TAB>Status<TAB>Tag<TAB>Date # Match buildkit-v* pattern (dev: buildkit-v20251209-dev, official: buildkit-v0.17.3-riscv64) RELEASE_TAG=$(gh release list --repo gounthar/docker-for-riscv64 --limit 20 | \ awk -F'\t' '$3 ~ /^buildkit-v/ {print $3; exit}') if [ -z "$RELEASE_TAG" ]; then echo "No BuildKit release found - skipping package build" echo "skip=true" >> $GITHUB_OUTPUT exit 0 fi echo "Found release: $RELEASE_TAG" + echo "release_tag=$RELEASE_TAG" >> $GITHUB_OUTPUTThen in the download step:
- name: Download BuildKit binaries if: steps.check_release.outputs.skip != 'true' env: GH_TOKEN: ${{ github.token }} run: | set -euo pipefail - # Get release tag from workflow_run or manual input - if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then - RELEASE_TAG="${{ github.event.inputs.release_tag }}" - else - # Find the latest buildkit release created by the workflow - RELEASE_TAG=$(gh release list --repo gounthar/docker-for-riscv64 --limit 20 | \ - awk -F'\t' '$3 ~ /^buildkit-v/ {print $3; exit}') - fi + RELEASE_TAG="${{ steps.check_release.outputs.release_tag }}" echo "Building package for release: $RELEASE_TAG" echo "RELEASE_TAG=$RELEASE_TAG" >> $GITHUB_ENV
131-135: Consider parameterizing the Debian distribution.The distribution "trixie" is hard-coded, which may cause issues if packages need to be built for other Debian versions or Ubuntu releases.
Consider adding a workflow input to specify the distribution:
workflow_dispatch: inputs: release_tag: description: 'BuildKit release tag' required: true default: 'buildkit-v20251209-dev' + distribution: + description: 'Debian distribution (e.g., trixie, bookworm, sid)' + required: false + default: 'trixie'Then use it in the dch command:
cd debian dch --check-dirname-level 0 \ --force-distribution \ --newversion "${VERSION}-riscv64-1" \ - --distribution trixie \ + --distribution "${{ github.event.inputs.distribution || 'trixie' }}" \ "RISC-V64 prebuilt BuildKit ${VERSION}"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (9)
.github/workflows/build-buildkit-package.yml(1 hunks).github/workflows/build-buildkit-rpm.yml(1 hunks)debian-buildkit/changelog(1 hunks)debian-buildkit/control(1 hunks)debian-buildkit/copyright(1 hunks)debian-buildkit/install(1 hunks)debian-buildkit/rules(1 hunks)debian-buildkit/source/format(1 hunks)rpm-buildkit/buildkit.spec(1 hunks)
🧰 Additional context used
🧠 Learnings (7)
📓 Common learnings
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
Applied to files:
.github/workflows/build-buildkit-package.yml
📚 Learning: 2025-12-09T10:39:18.263Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 211
File: docs/BUILDKIT-IMPLEMENTATION-GUIDE.md:482-482
Timestamp: 2025-12-09T10:39:18.263Z
Learning: Enforce a single Go version across all workflows by setting a minimum Go version of 1.25.3 (Go 1.25.3+). Update all CI workflow configurations (e.g., actions/setup-go) to use this minimum version to maintain consistency and prevent drift.
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-10-31T21:15:53.276Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Applied to files:
debian-buildkit/controlrpm-buildkit/buildkit.spec
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to docker-bake.hcl : Use docker-bake.hcl for orchestrating multi-platform builds with Docker Buildx, specifying how to build images for different architectures
Applied to files:
debian-buildkit/control
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to Makefile : Use a Makefile as the central entry point for building, testing, and packaging Docker, with targets for different architectures and platforms
Applied to files:
debian-buildkit/rules
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to scripts/**/*.sh : Use shell scripts to automate complex build steps, apply patches, and work around upstream limitations for specific architectures
Applied to files:
debian-buildkit/rules
🪛 RuboCop (1.81.7)
rpm-buildkit/buildkit.spec
[fatal] 1-1: unexpected token tCOLON
(Using Ruby 2.7 parser; configure using TargetRubyVersion parameter, under AllCops)
(Lint/Syntax)
⏰ 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: Agent
🔇 Additional comments (12)
debian-buildkit/source/format (1)
1-1: LGTM!The
3.0 (native)source format is appropriate for this packaging approach using pre-built binaries.debian-buildkit/install (1)
1-2: LGTM!The install mappings correctly place both BuildKit binaries (
buildkitdandbuildctl) in/usr/bin/, consistent with the RPM packaging and standard system binary locations.debian-buildkit/control (2)
1-38: LGTM overall — well-structured control file.The control file is well-formatted with appropriate metadata, clear package description, and sensible recommendations for containerd and docker. The RISC-V64 targeting is correctly specified.
13-14: No action needed on this file.The debian-buildkit/rules file explicitly overrides
dh_shlibdepswith a comment stating the binaries are statically linked. This means${shlibs:Depends}correctly resolves to empty, which is the appropriate behavior for statically linked binaries. The control file configuration is correct as-is.Likely an incorrect or invalid review comment.
rpm-buildkit/buildkit.spec (1)
1-62: LGTM — well-structured RPM spec file.The spec file correctly handles pre-built binaries with appropriate install commands, permissions, and RPM macros. The static analysis hint about Ruby syntax is a false positive—this is an RPM spec file, not Ruby code.
debian-buildkit/rules (2)
1-6: LGTM! Standard Debian packaging structure.The shebang, verbose flag, and debhelper invocation follow Debian packaging conventions correctly.
16-18: Verified: binaries are statically linked.The buildkit binaries are compiled with
CGO_ENABLED=0(as shown in.github/workflows/buildkit-weekly-build.ymlline 319), which produces statically linked Go binaries. Skippingdh_shlibdepsis appropriate for this configuration..github/workflows/build-buildkit-package.yml (3)
27-63: LGTM! Well-structured release detection logic.The release detection correctly handles both manual dispatch and automatic triggers, with appropriate idempotency checks to avoid rebuilding packages that already exist.
183-187: LGTM! Good retry logic for upload resilience.The retry logic with exponential backoff and the
--clobberflag appropriately handles transient failures during release uploads.
116-121: Version extraction regex patterns are working correctly.The patterns have been validated and correctly handle both dev and official release formats. All test cases pass, including edge cases with dates and multi-digit version numbers.
.github/workflows/build-buildkit-rpm.yml (2)
27-64: LGTM! Consistent release detection logic.The release detection correctly handles both manual dispatch and automatic triggers, matching the Debian workflow's approach.
163-170: LGTM! Appropriate retry logic for upload resilience.The retry mechanism with
--clobberflag correctly handles transient failures, matching the Debian workflow's approach.
| - name: Download BuildKit binaries | ||
| if: steps.check_release.outputs.skip != 'true' | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} | ||
| run: | | ||
| set -euo pipefail | ||
| # Get release tag from workflow_run or manual input | ||
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | ||
| RELEASE_TAG="${{ github.event.inputs.release_tag }}" | ||
| else | ||
| # Find the latest buildkit release created by the workflow | ||
| RELEASE_TAG=$(gh release list --repo gounthar/docker-for-riscv64 --limit 20 | \ | ||
| awk -F'\t' '$3 ~ /^buildkit-v/ {print $3; exit}') | ||
| fi | ||
| echo "Building package for release: $RELEASE_TAG" | ||
| echo "RELEASE_TAG=$RELEASE_TAG" >> $GITHUB_ENV | ||
|
|
||
| # Download binaries | ||
| gh release download $RELEASE_TAG -p buildkitd -p buildctl | ||
| chmod +x buildkitd buildctl | ||
|
|
||
| # Verify binary architecture | ||
| echo "=== buildkitd ===" | ||
| file ./buildkitd || true | ||
| ./buildkitd --version || echo "Version check skipped" | ||
|
|
||
| echo "=== buildctl ===" | ||
| file ./buildctl || true | ||
| ./buildctl --version || echo "Version check skipped" | ||
|
|
||
| ls -lh buildkitd buildctl |
There was a problem hiding this comment.
Add checksum verification for downloaded binaries.
Downloading binaries without verifying checksums or signatures introduces a security risk. If the release is compromised or corrupted, malicious or broken binaries could be packaged.
Consider adding checksum verification:
- name: Download BuildKit binaries
if: steps.check_release.outputs.skip != 'true'
env:
GH_TOKEN: ${{ github.token }}
run: |
set -euo pipefail
# Get release tag from workflow_run or manual input
if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then
RELEASE_TAG="${{ github.event.inputs.release_tag }}"
else
# Find the latest buildkit release created by the workflow
RELEASE_TAG=$(gh release list --repo gounthar/docker-for-riscv64 --limit 20 | \
awk -F'\t' '$3 ~ /^buildkit-v/ {print $3; exit}')
fi
echo "Building package for release: $RELEASE_TAG"
echo "RELEASE_TAG=$RELEASE_TAG" >> $GITHUB_ENV
# Download binaries
gh release download $RELEASE_TAG -p buildkitd -p buildctl
+
+ # Download and verify checksums if available
+ if gh release download $RELEASE_TAG -p "checksums.txt" 2>/dev/null; then
+ echo "Verifying checksums..."
+ sha256sum -c checksums.txt --ignore-missing || {
+ echo "Error: Checksum verification failed"
+ exit 1
+ }
+ else
+ echo "Warning: No checksums available for verification"
+ fi
+
chmod +x buildkitd buildctl📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Download BuildKit binaries | |
| if: steps.check_release.outputs.skip != 'true' | |
| env: | |
| GH_TOKEN: ${{ github.token }} | |
| run: | | |
| set -euo pipefail | |
| # Get release tag from workflow_run or manual input | |
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | |
| RELEASE_TAG="${{ github.event.inputs.release_tag }}" | |
| else | |
| # Find the latest buildkit release created by the workflow | |
| RELEASE_TAG=$(gh release list --repo gounthar/docker-for-riscv64 --limit 20 | \ | |
| awk -F'\t' '$3 ~ /^buildkit-v/ {print $3; exit}') | |
| fi | |
| echo "Building package for release: $RELEASE_TAG" | |
| echo "RELEASE_TAG=$RELEASE_TAG" >> $GITHUB_ENV | |
| # Download binaries | |
| gh release download $RELEASE_TAG -p buildkitd -p buildctl | |
| chmod +x buildkitd buildctl | |
| # Verify binary architecture | |
| echo "=== buildkitd ===" | |
| file ./buildkitd || true | |
| ./buildkitd --version || echo "Version check skipped" | |
| echo "=== buildctl ===" | |
| file ./buildctl || true | |
| ./buildctl --version || echo "Version check skipped" | |
| ls -lh buildkitd buildctl | |
| - name: Download BuildKit binaries | |
| if: steps.check_release.outputs.skip != 'true' | |
| env: | |
| GH_TOKEN: ${{ github.token }} | |
| run: | | |
| set -euo pipefail | |
| # Get release tag from workflow_run or manual input | |
| if [ "${{ github.event_name }}" = "workflow_dispatch" ]; then | |
| RELEASE_TAG="${{ github.event.inputs.release_tag }}" | |
| else | |
| # Find the latest buildkit release created by the workflow | |
| RELEASE_TAG=$(gh release list --repo gounthar/docker-for-riscv64 --limit 20 | \ | |
| awk -F'\t' '$3 ~ /^buildkit-v/ {print $3; exit}') | |
| fi | |
| echo "Building package for release: $RELEASE_TAG" | |
| echo "RELEASE_TAG=$RELEASE_TAG" >> $GITHUB_ENV | |
| # Download binaries | |
| gh release download $RELEASE_TAG -p buildkitd -p buildctl | |
| # Download and verify checksums if available | |
| if gh release download $RELEASE_TAG -p "checksums.txt" 2>/dev/null; then | |
| echo "Verifying checksums..." | |
| sha256sum -c checksums.txt --ignore-missing || { | |
| echo "Error: Checksum verification failed" | |
| exit 1 | |
| } | |
| else | |
| echo "Warning: No checksums available for verification" | |
| fi | |
| chmod +x buildkitd buildctl | |
| # Verify binary architecture | |
| echo "=== buildkitd ===" | |
| file ./buildkitd || true | |
| ./buildkitd --version || echo "Version check skipped" | |
| echo "=== buildctl ===" | |
| file ./buildctl || true | |
| ./buildctl --version || echo "Version check skipped" | |
| ls -lh buildkitd buildctl |
🤖 Prompt for AI Agents
.github/workflows/build-buildkit-package.yml lines 75-105: the workflow
downloads buildkit binaries without verifying their integrity; update the steps
to fetch the release checksum or signature (from the release assets or a trusted
source) before making the files executable, verify the downloaded artifacts
against that checksum (e.g., sha256sum --check) or verify GPG signatures, and
fail the job if verification fails; ensure the checksum/signature is downloaded
with gh release download or retrieved via gh release view, perform verification
prior to chmod/packaging, and emit clear error messages on mismatch.
There was a problem hiding this comment.
Acknowledged. Checksum verification is a valid security concern. However, this requires infrastructure changes:
- The BuildKit build workflow needs to generate and upload checksums (e.g., SHA256SUMS file)
- Then the packaging workflow can verify against those checksums
This will be tracked as a future enhancement after we update the upstream BuildKit build workflow to generate checksum files.
There was a problem hiding this comment.
@gounthar, that makes sense! You're right that the checksum generation needs to happen in the upstream BuildKit build workflow first before this packaging workflow can verify them. It's a logical dependency.
Would you like me to create a GitHub issue to track this security enhancement? I can document:
- The need to update the BuildKit build workflow to generate and upload checksums (SHA256SUMS or similar)
- Then update this packaging workflow (and the RPM one) to verify against those checksums
- Link back to this PR and discussion for context
Let me know if you'd like me to open that issue, or if you prefer to handle it separately!
🧠 Learnings used
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to docker-bake.hcl : Use docker-bake.hcl for orchestrating multi-platform builds with Docker Buildx, specifying how to build images for different architectures
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
# Create GitHub issue for checksum verification enhancement
gh issue create \
--repo gounthar/docker-for-riscv64 \
--title "Add checksum verification to BuildKit build and packaging workflows" \
--body "## Summary
Add checksum generation and verification to BuildKit workflows to improve supply chain security.
## Background
During review of PR #218, a security concern was identified: the BuildKit packaging workflows download binaries without verifying their integrity. This creates a risk if releases are compromised or corrupted.
## Implementation Plan
This enhancement requires two phases:
### Phase 1: Generate checksums in build workflow
- Update the BuildKit build workflow (Weekly BuildKit RISC-V64 Build) to generate checksum files (e.g., \`SHA256SUMS\` or \`checksums.txt\`)
- Upload the checksum file as a release asset alongside the binaries
- Include checksums for: \`buildkitd\`, \`buildctl\`, and any other artifacts
### Phase 2: Verify checksums in packaging workflows
- Update \`.github/workflows/build-buildkit-package.yml\` (Debian packaging) to:
- Download the checksum file from the release
- Verify downloaded binaries using \`sha256sum -c\`
- Fail the workflow if verification fails
- Update \`.github/workflows/build-buildkit-rpm.yml\` (RPM packaging) with the same verification logic
## References
- PR: https://github.com/gounthar/docker-for-riscv64/pull/218
- Discussion: https://github.com/gounthar/docker-for-riscv64/pull/218#discussion_r2602526498
- Requested by: @gounthar
## Priority
Medium - Security enhancement that should be implemented before wider distribution of packages."
Length of output: 57
@gounthar, done! I've created issue #219 to track this security enhancement:
🔗 #219
The issue documents both phases:
- Phase 1: Update the BuildKit build workflow to generate and upload checksums
- Phase 2: Update the packaging workflows (Debian and RPM) to verify those checksums
The issue includes links back to this PR and discussion for context. You can implement these improvements whenever you're ready to enhance the supply chain security! 🔒
🧠 Learnings used
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to docker-bake.hcl : Use docker-bake.hcl for orchestrating multi-platform builds with Docker Buildx, specifying how to build images for different architectures
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
| - name: Download BuildKit binaries | ||
| if: steps.release.outputs.has-new-release == 'true' | ||
| env: | ||
| GH_TOKEN: ${{ github.token }} | ||
| run: | | ||
| set -euo pipefail | ||
|
|
||
| RELEASE_TAG="${{ steps.release.outputs.release-tag }}" | ||
| echo "Building package for release: $RELEASE_TAG" | ||
|
|
||
| # Clean and download binaries to SOURCES | ||
| cd ~/rpmbuild/SOURCES | ||
| rm -f buildkitd buildctl | ||
| gh release download $RELEASE_TAG -p buildkitd -p buildctl --repo gounthar/docker-for-riscv64 | ||
|
|
||
| # Validate binaries were downloaded | ||
| if [ ! -f buildkitd ] || [ ! -f buildctl ]; then | ||
| echo "Error: Failed to download BuildKit binaries from release $RELEASE_TAG" | ||
| exit 1 | ||
| fi | ||
|
|
||
| chmod +x buildkitd buildctl | ||
| ls -lh |
There was a problem hiding this comment.
Add checksum verification for downloaded binaries.
Similar to the Debian workflow, downloading binaries without verifying checksums or signatures introduces a security risk.
Apply this diff to add checksum verification:
- name: Download BuildKit binaries
if: steps.release.outputs.has-new-release == 'true'
env:
GH_TOKEN: ${{ github.token }}
run: |
set -euo pipefail
RELEASE_TAG="${{ steps.release.outputs.release-tag }}"
echo "Building package for release: $RELEASE_TAG"
# Clean and download binaries to SOURCES
cd ~/rpmbuild/SOURCES
rm -f buildkitd buildctl
gh release download $RELEASE_TAG -p buildkitd -p buildctl --repo gounthar/docker-for-riscv64
+
+ # Download and verify checksums if available
+ if gh release download $RELEASE_TAG -p "checksums.txt" --repo gounthar/docker-for-riscv64 2>/dev/null; then
+ echo "Verifying checksums..."
+ sha256sum -c checksums.txt --ignore-missing || {
+ echo "Error: Checksum verification failed"
+ exit 1
+ }
+ else
+ echo "Warning: No checksums available for verification"
+ fi
# Validate binaries were downloaded
if [ ! -f buildkitd ] || [ ! -f buildctl ]; then
echo "Error: Failed to download BuildKit binaries from release $RELEASE_TAG"
exit 1
fi🤖 Prompt for AI Agents
.github/workflows/build-buildkit-rpm.yml lines 88-110: the workflow downloads
buildkitd and buildctl without verifying integrity; add checksum verification by
fetching the release checksum file (or a .sha256 file) for the RELEASE_TAG from
the same repository/release, compute and verify SHA256 (or the provided
algorithm) against the downloaded binaries, fail the job if verification fails,
and only chmod +x and proceed when checksums match; if the release provides a
detached signature, optionally download and verify it with a trusted GPG key
before accepting the checksum file.
There was a problem hiding this comment.
Acknowledged. Same as the Debian workflow - checksum verification requires the BuildKit build workflow to first generate and upload checksums. Will be tracked as a future enhancement.
There was a problem hiding this comment.
@gounthar, understood! Thank you for planning to track this as a future enhancement. Once the BuildKit build workflow is updated to generate and upload checksums, adding verification to both the Debian and RPM packaging workflows will indeed improve security.
🧠 Learnings used
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
There was a problem hiding this comment.
Pull request overview
This PR adds comprehensive packaging infrastructure for BuildKit RISC-V64 binaries, enabling distribution through both Debian (.deb) and RPM package formats. The implementation includes complete packaging metadata, build configurations, and automated GitHub Actions workflows that trigger on weekly builds or manual dispatch. The packages install pre-built buildkitd and buildctl binaries to /usr/bin and support both development builds (date-tagged) and official releases (version-tagged).
Key Changes
- Added Debian packaging infrastructure with standard debian/ directory structure including control files, build rules, and copyright information
- Added RPM packaging with a complete spec file for building .rpm packages
- Implemented two GitHub Actions workflows to automate package creation and upload to releases, with intelligent release detection and skip logic
Reviewed changes
Copilot reviewed 10 out of 10 changed files in this pull request and generated 12 comments.
Show a summary per file
| File | Description |
|---|---|
rpm-buildkit/buildkit.spec |
RPM specification file defining package metadata, dependencies, and installation rules for BuildKit binaries |
debian-buildkit/source/format |
Declares Debian source package format as "3.0 (native)" |
debian-buildkit/rules |
Debian build rules that skip compilation and testing for pre-built binaries |
debian-buildkit/install |
Specifies installation paths for buildkitd and buildctl binaries |
debian-buildkit/copyright |
Documents licensing and copyright information for both upstream and packaging |
debian-buildkit/control |
Debian package control file with metadata, dependencies, and package description |
debian-buildkit/changelog |
Debian changelog documenting the initial RISC-V64 build |
.github/workflows/build-buildkit-rpm.yml |
GitHub Actions workflow to build and upload RPM packages |
.github/workflows/build-buildkit-package.yml |
GitHub Actions workflow to build and upload Debian packages |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| else | ||
| VERSION="$(echo "$RELEASE_TAG" | sed 's/^buildkit-v//; s/-riscv64$//')" |
There was a problem hiding this comment.
The version extraction logic assumes a specific date format (8 digits) for dev builds. If a dev build tag doesn't match the exact pattern ^buildkit-v([0-9]{8})-dev$, it will fall through to the else branch which may produce unexpected results. Consider adding explicit error handling or validation to ensure VERSION is properly set before use.
| else | |
| VERSION="$(echo "$RELEASE_TAG" | sed 's/^buildkit-v//; s/-riscv64$//')" | |
| elif [[ "$RELEASE_TAG" =~ ^buildkit-v[0-9]+\.[0-9]+\.[0-9]+-riscv64$ ]]; then | |
| VERSION="$(echo "$RELEASE_TAG" | sed 's/^buildkit-v//; s/-riscv64$//')" | |
| else | |
| echo "Error: Unrecognized release tag format: $RELEASE_TAG" >&2 | |
| exit 1 |
There was a problem hiding this comment.
Fixed in commit 2a22afc. Added explicit pattern matching with error handling for unrecognized tag formats:
if [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]{8})-dev$ ]]; then
VERSION="0.0.${BASH_REMATCH[1]}"
elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)-riscv64$ ]]; then
VERSION="${BASH_REMATCH[1]}"
elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then
VERSION="${BASH_REMATCH[1]}"
else
echo "Error: Unrecognized release tag format"
exit 1
fi| for rpm in ~/rpmbuild/RPMS/riscv64/buildkit-*.rpm; do | ||
| echo "Uploading $(basename $rpm)..." | ||
| for i in {1..3}; do | ||
| gh release upload "$RELEASE_TAG" "$rpm" --clobber && break | ||
| echo "Retry $i..." | ||
| sleep 3 | ||
| done | ||
| done | ||
|
|
There was a problem hiding this comment.
The retry loop attempts 3 retries but doesn't exit with an error if all retries fail. The loop will complete successfully even if the upload fails, potentially causing the workflow to report success when uploads have actually failed. Add explicit error handling after the loop to ensure the step fails if all retries are exhausted.
| for rpm in ~/rpmbuild/RPMS/riscv64/buildkit-*.rpm; do | |
| echo "Uploading $(basename $rpm)..." | |
| for i in {1..3}; do | |
| gh release upload "$RELEASE_TAG" "$rpm" --clobber && break | |
| echo "Retry $i..." | |
| sleep 3 | |
| done | |
| done | |
| UPLOAD_FAILED=0 | |
| for rpm in ~/rpmbuild/RPMS/riscv64/buildkit-*.rpm; do | |
| echo "Uploading $(basename $rpm)..." | |
| UPLOAD_SUCCESS=0 | |
| for i in {1..3}; do | |
| if gh release upload "$RELEASE_TAG" "$rpm" --clobber; then | |
| UPLOAD_SUCCESS=1 | |
| break | |
| fi | |
| echo "Retry $i..." | |
| sleep 3 | |
| done | |
| if [ "$UPLOAD_SUCCESS" -ne 1 ]; then | |
| echo "Failed to upload $(basename $rpm) after 3 attempts." | |
| UPLOAD_FAILED=1 | |
| fi | |
| done | |
| if [ "$UPLOAD_FAILED" -ne 0 ]; then | |
| echo "One or more RPM uploads failed. Exiting with error." | |
| exit 1 | |
| fi |
There was a problem hiding this comment.
Fixed in commit 2a22afc. Added proper retry loop error handling with UPLOAD_FAILED flag that causes the step to fail if all retries are exhausted:
UPLOAD_FAILED=0
for rpm in ~/rpmbuild/RPMS/riscv64/buildkit-*.rpm; do
UPLOAD_SUCCESS=0
for i in {1..3}; do
if gh release upload "$RELEASE_TAG" "$rpm" --clobber; then
UPLOAD_SUCCESS=1
break
fi
done
if [ "$UPLOAD_SUCCESS" -eq 0 ]; then
UPLOAD_FAILED=1
fi
done
if [ "$UPLOAD_FAILED" -eq 1 ]; then
exit 1
fi| for i in {1..3}; do | ||
| gh release upload "$RELEASE_TAG" "$deb" --clobber && break | ||
| echo "Retry $i..." | ||
| sleep 3 | ||
| done |
There was a problem hiding this comment.
The retry loop attempts 3 retries but doesn't exit with an error if all retries fail. The loop will complete successfully even if the upload fails, potentially causing the workflow to report success when uploads have actually failed. Add explicit error handling after the loop to ensure the step fails if all retries are exhausted.
| for i in {1..3}; do | |
| gh release upload "$RELEASE_TAG" "$deb" --clobber && break | |
| echo "Retry $i..." | |
| sleep 3 | |
| done | |
| success=0 | |
| for i in {1..3}; do | |
| if gh release upload "$RELEASE_TAG" "$deb" --clobber; then | |
| success=1 | |
| break | |
| fi | |
| echo "Retry $i..." | |
| sleep 3 | |
| done | |
| if [ "$success" -ne 1 ]; then | |
| echo "Error: Failed to upload $(basename $deb) after 3 attempts." | |
| exit 1 | |
| fi |
There was a problem hiding this comment.
Fixed in commit 2a22afc. Same fix applied - added UPLOAD_FAILED flag to properly track and report failures after all retries are exhausted.
| License: Apache-2.0 | ||
|
|
||
| Files: debian/* | ||
| Copyright: 2024 Bruno Verächten <bruno@verachten.fr> |
There was a problem hiding this comment.
There's an inconsistency in the spelling of the name. In the copyright file, it's "Bruno Verächten" (with umlaut ä), while in other files (control, changelog, RPM spec) it's "Bruno Verächten" or "Bruno Verachten". The name should be consistently spelled across all files.
| Copyright: 2024 Bruno Verächten <bruno@verachten.fr> | |
| Copyright: 2024 Bruno Verachten <bruno@verachten.fr> |
There was a problem hiding this comment.
Acknowledged. The maintainer name spelling should be consistent across all packaging files. Will standardize in a follow-up commit.
There was a problem hiding this comment.
Acknowledged. The name spelling inconsistency between files is a minor issue. Both spellings are correct (with/without umlaut). Will consider standardizing.
| Source: buildkit | ||
| Section: devel | ||
| Priority: optional | ||
| Maintainer: Bruno Verächten <bruno@verachten.fr> |
There was a problem hiding this comment.
There's an inconsistency in the spelling of the name. In the control file, it's "Bruno Verächten" (with umlaut ä), while in the RPM spec it's "Bruno Verachten" (without umlaut). The name should be consistently spelled across all packaging files.
| Maintainer: Bruno Verächten <bruno@verachten.fr> | |
| Maintainer: Bruno Verachten <bruno@verachten.fr> |
There was a problem hiding this comment.
Acknowledged. Will standardize the maintainer name spelling across all packaging files in a follow-up commit.
There was a problem hiding this comment.
Acknowledged. Same as the copyright file - both spellings are acceptable. Will consider standardizing.
| gh release download $RELEASE_TAG -p buildkitd -p buildctl --repo gounthar/docker-for-riscv64 | ||
|
|
||
| # Validate binaries were downloaded | ||
| if [ ! -f buildkitd ] || [ ! -f buildctl ]; then | ||
| echo "Error: Failed to download BuildKit binaries from release $RELEASE_TAG" | ||
| exit 1 | ||
| fi | ||
|
|
||
| chmod +x buildkitd buildctl |
There was a problem hiding this comment.
The binaries are downloaded and made executable without any checksum verification. This poses a security risk as the binaries could be tampered with. Consider adding checksum validation after download to ensure binary integrity, especially since these are pre-built binaries being packaged for distribution.
There was a problem hiding this comment.
Acknowledged. Same as the Debian workflow - checksum verification requires infrastructure changes. Tracked for future implementation.
| else | ||
| VERSION=$(echo $RELEASE_TAG | sed 's/^buildkit-v//; s/-riscv64$//') |
There was a problem hiding this comment.
The version extraction logic assumes a specific date format (8 digits) for dev builds. If a dev build tag doesn't match the exact pattern ^buildkit-v([0-9]{8})-dev$, it will fall through to the else branch which may produce unexpected results. Consider adding explicit error handling or validation to ensure VERSION is properly set before use.
| else | |
| VERSION=$(echo $RELEASE_TAG | sed 's/^buildkit-v//; s/-riscv64$//') | |
| elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)-riscv64$ ]]; then | |
| VERSION=$(echo $RELEASE_TAG | sed 's/^buildkit-v//; s/-riscv64$//') | |
| else | |
| echo "Error: RELEASE_TAG '$RELEASE_TAG' does not match expected patterns for dev or official builds." | |
| exit 1 |
There was a problem hiding this comment.
Fixed in commit 2a22afc. Same fix applied to RPM workflow - added explicit pattern matching with error handling for all supported tag formats.
There was a problem hiding this comment.
Fixed in commit 2a22afc. Added explicit pattern matching with error handling for unrecognized tag formats. The version extraction is validated before use.
| echo "RELEASE_TAG=$RELEASE_TAG" >> $GITHUB_ENV | ||
|
|
||
| # Download binaries | ||
| gh release download $RELEASE_TAG -p buildkitd -p buildctl |
There was a problem hiding this comment.
The download command doesn't specify the --repo parameter. While this might work if run from within the repository checkout, it's more explicit and safer to always specify --repo gounthar/docker-for-riscv64 as done in the RPM workflow (line 101). This ensures the command works correctly regardless of the repository context.
| gh release download $RELEASE_TAG -p buildkitd -p buildctl | |
| gh release download $RELEASE_TAG --repo gounthar/docker-for-riscv64 -p buildkitd -p buildctl |
There was a problem hiding this comment.
Fixed in commit 2a22afc. Added explicit --repo gounthar/docker-for-riscv64 parameter to all gh release commands.
| fi | ||
|
|
||
| # Find the latest BuildKit release (matches both dev and official releases) | ||
| # gh release list outputs: Title<TAB>Status<TAB>Tag<TAB>Date |
There was a problem hiding this comment.
[nitpick] The comment describes the output format of gh release list but the actual format in the command doesn't match exactly. The comment states "TitleStatusTagDate" but the default output format is slightly different. While the awk command will work correctly, the comment could cause confusion. Consider updating the comment to match the actual output format or being more general.
| # gh release list outputs: Title<TAB>Status<TAB>Tag<TAB>Date | |
| # gh release list outputs tab-separated columns; we select the Tag column (3rd column) |
There was a problem hiding this comment.
Acknowledged. Minor documentation improvement - the comment describes the format accurately for the awk command that follows. Will consider updating for clarity.
| fi | ||
|
|
||
| # Find the latest BuildKit release (matches both dev and official releases) | ||
| # gh release list outputs: Title<TAB>Status<TAB>Tag<TAB>Date |
There was a problem hiding this comment.
[nitpick] The comment describes the output format of gh release list but the actual format in the command doesn't match exactly. The comment states "TitleStatusTagDate" but the default output format is slightly different. While the awk command will work correctly, the comment could cause confusion. Consider updating the comment to match the actual output format or being more general.
| # gh release list outputs: Title<TAB>Status<TAB>Tag<TAB>Date | |
| # gh release list outputs multiple columns separated by tabs; the third column is the tag |
There was a problem hiding this comment.
Acknowledged. Minor documentation improvement - the comment describes the format accurately for the awk command that follows. Will consider updating for clarity.
Update repository update workflows to include BuildKit packages: APT Repository (update-apt-repo.yml): - Add 'Build BuildKit Debian Package' workflow trigger - Add buildkit-v* pattern to release detection regex - Add BuildKit release detection and package download - Add buildkit to cleanup patterns - Add buildkit package type handling in commit logic RPM Repository (update-rpm-repo.yml): - Add 'Build BuildKit RPM Package' workflow trigger - Add buildkit-v pattern to release detection regex This ensures BuildKit packages are automatically added to the APT and RPM repositories when new BuildKit releases are built.
Changes based on automated code review feedback: Workflow improvements: - Add proper retry loop error handling (fail if all retries exhausted) - Add explicit --repo parameter to gh release commands - Add binary architecture validation (RISC-V64 check) - Add static/dynamic linking verification - Add version extraction error handling for edge cases - Fix variable quoting in shell scripts - Improve gh CLI installation error handling Packaging fixes: - Fix Recommends/Suggests semantics in Debian control: - containerd is Recommended (required runtime backend) - Docker is Suggested (optional, for buildx integration) - Fix Recommends/Suggests semantics in RPM spec: - containerd is Recommended - docker-ce and moby-engine are Suggested 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
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/update-apt-repo.yml (1)
3-3: Fix workflow lint warnings (truthyon, long line, trailing spaces)The
Lint Workflowsjob is currently failing on this file:
- Line 3:
on:is parsed as a truthy scalar by the generic YAML linter. Quoting the key (e.g.'on':) will satisfy the linter while remaining valid for GitHub Actions.- Line 189: the
for pattern in ...line exceeds the 120‑character limit; break the list over multiple lines or use an array variable to shorten it.- Line 316: there are trailing spaces in the
PACKAGE_LIST/COMMIT_MSGarea; trim them to clear the error.Addressing these will get the workflow lint job green again.
Also applies to: 189-189, 315-325
♻️ Duplicate comments (4)
debian-buildkit/control (1)
4-4: Align maintainer spelling across Debian and RPM metadataThe control file uses
Bruno Verächtenwhilerpm-buildkit/buildkit.specusesBruno Verachten. It would be better to standardize on one spelling (with or without the umlaut) across all packaging files to avoid inconsistent metadata..github/workflows/build-buildkit-rpm.yml (2)
153-185: Consider de-duplicating BuildKit version extraction logicThe tag → version extraction block here is effectively the same as in
build-buildkit-package.yml. Pulling this into a small shared script/composite action (e.g..github/scripts/extract-buildkit-version.sh) would reduce maintenance overhead and keep Debian/RPM packaging behavior in sync as tag formats evolve.
88-147: Verify integrity of downloaded BuildKit binaries before packagingAs in the Debian workflow,
buildkitdandbuildctlare downloaded and then executed/packaged without any checksum or signature verification. This is a security and reliability risk if the release assets are ever corrupted or tampered with.Add checksum and/or signature verification (e.g., download a checksum file from the same release and run
sha256sum -c, or verify a signed checksum file) beforechmod +xand proceeding with RPM build, and fail the job on mismatch..github/workflows/build-buildkit-package.yml (1)
80-113: Add checksum or signature verification for downloaded BuildKit binaries
buildkitdandbuildctlare downloaded and executed/packaged without any integrity check. If the release assets are ever corrupted or tampered with, this workflow would blindly ship compromised binaries.Please add checksum and/or signature verification before
chmod +xand packaging (e.g., download aSHA256SUMS/checksums.txtasset and runsha256sum -c, or verify a signed checksum file with a trusted GPG key), and fail the job on mismatch.
🧹 Nitpick comments (1)
rpm-buildkit/buildkit.spec (1)
10-16: Consider whether container runtime should be a hard requirementRight now
containerdis only aRecommends. If BuildKit on these hosts is not really usable without a local container runtime, you may want to promote this toRequires(and keep Docker flavors asSuggests) so that a working runtime is installed by default.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (7)
.github/workflows/build-buildkit-package.yml(1 hunks).github/workflows/build-buildkit-rpm.yml(1 hunks).github/workflows/track-buildkit-releases.yml(4 hunks).github/workflows/update-apt-repo.yml(7 hunks).github/workflows/update-rpm-repo.yml(2 hunks)debian-buildkit/control(1 hunks)rpm-buildkit/buildkit.spec(1 hunks)
🧰 Additional context used
🧠 Learnings (8)
📓 Common learnings
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to scripts/**/*.sh : Use shell scripts to automate complex build steps, apply patches, and work around upstream limitations for specific architectures
Applied to files:
.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-12-09T10:39:18.263Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 211
File: docs/BUILDKIT-IMPLEMENTATION-GUIDE.md:482-482
Timestamp: 2025-12-09T10:39:18.263Z
Learning: Enforce a single Go version across all workflows by setting a minimum Go version of 1.25.3 (Go 1.25.3+). Update all CI workflow configurations (e.g., actions/setup-go) to use this minimum version to maintain consistency and prevent drift.
Applied to files:
.github/workflows/build-buildkit-rpm.yml.github/workflows/update-apt-repo.yml.github/workflows/build-buildkit-package.yml.github/workflows/track-buildkit-releases.yml.github/workflows/update-rpm-repo.yml
📚 Learning: 2025-10-19T20:52:41.872Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-19T20:52:41.872Z
Learning: In Debian packaging, use `Conflicts+Replaces+Breaks` (without version constraints) when two separate, competing packages provide the same files and cannot coexist at any version. This is distinct from package transitions/renames, which use `Breaks+Replaces` without `Conflicts`.
Applied to files:
rpm-buildkit/buildkit.specdebian-buildkit/control
📚 Learning: 2025-10-19T20:52:41.872Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-19T20:52:41.872Z
Learning: When fixing file conflicts in Debian packages, if the conflicting package is from Debian's official repositories with a version higher than previous constraints (e.g., docker-compose 2.26.1 vs constraint `<< 2.0`), remove version constraints to ensure the conflict declaration is effective.
Applied to files:
rpm-buildkit/buildkit.specdebian-buildkit/control
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
Applied to files:
.github/workflows/update-apt-repo.yml.github/workflows/build-buildkit-package.yml.github/workflows/track-buildkit-releases.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to docker-bake.hcl : Use docker-bake.hcl for orchestrating multi-platform builds with Docker Buildx, specifying how to build images for different architectures
Applied to files:
.github/workflows/update-apt-repo.ymldebian-buildkit/control
📚 Learning: 2025-10-31T21:15:53.276Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Applied to files:
debian-buildkit/control
🪛 GitHub Actions: Lint Workflows
.github/workflows/update-apt-repo.yml
[warning] 3-3: truthy value should be one of [false, no, true, yes]
[warning] 189-189: line too long (124 > 120 characters)
[error] 316-316: trailing spaces
🪛 GitHub Check: Lint YAML Files
.github/workflows/update-apt-repo.yml
[warning] 189-189:
189:121 [line-length] line too long (124 > 120 characters)
🪛 RuboCop (1.81.7)
rpm-buildkit/buildkit.spec
[fatal] 1-1: unexpected token tCOLON
(Using Ruby 2.7 parser; configure using TargetRubyVersion parameter, under AllCops)
(Lint/Syntax)
🔇 Additional comments (3)
.github/workflows/update-rpm-repo.yml (1)
5-6: BuildKit RPM workflow integration looks consistentThe added workflow name matches the new
Build BuildKit RPM Packageworkflow, and the updated regex correctly includesbuildkit-v*tags in the search for RPM‑bearing releases without altering existing behavior.Also applies to: 54-56
.github/workflows/update-apt-repo.yml (1)
50-71: BuildKit APT integration is consistent with existing package flowsThe added detection of
buildkit-v*tags, download ofbuildkit_*.deb, cleanup pattern update, andPACKAGE_TYPE=buildkithandling all mirror the existing patterns for buildx/cli/compose/cagent and should slot cleanly into the existing APT repo update logic.Also applies to: 131-138, 179-185, 189-193, 295-303
.github/workflows/track-buildkit-releases.yml (1)
5-7: Release tracking logic and messaging look solidThe switch to
gh release listfor latest vX.Y.Z detection (with pre-release filtering), the explicit guard when no release is found, and the clearer tracking‑issue text (expected tag and artifacts) plus the “already built” logging step together make the BuildKit release flow safer and more observable. No issues from my side.Also applies to: 25-37, 40-42, 69-93, 102-107
Add `set -euo pipefail` and explicit package verification to prevent silent failures in build steps. If dpkg-buildpackage or rpmbuild fails but leaves partial artifacts, the step will now correctly fail. Addresses CodeRabbit review comment on error handling. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (3)
.github/workflows/build-buildkit-rpm.yml (2)
153-184: Extract version extraction logic to a reusable script (duplicate concern from past review).The version extraction at lines 161–173 duplicates the exact logic from the Debian workflow, creating maintenance overhead.
Use the shared
.github/scripts/extract-buildkit-version.shscript suggested in the Debian workflow review:- name: Update package version if: steps.release.outputs.has-new-release == 'true' env: RELEASE_TAG: ${{ steps.release.outputs.release-tag }} run: | - # Extract version from tag - # Dev build: buildkit-v20251209-dev -> 0.0.20251209 - # Official: buildkit-v0.26.2-riscv64 -> 0.26.2 - if [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]{8})-dev$ ]]; then - DATE_VER="${BASH_REMATCH[1]}" - VERSION="0.0.${DATE_VER}" - elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)-riscv64$ ]]; then - VERSION="${BASH_REMATCH[1]}" - elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then - # Handle case without -riscv64 suffix - VERSION="${BASH_REMATCH[1]}" - else - echo "Error: Unrecognized release tag format: $RELEASE_TAG" - echo "Expected formats: buildkit-vYYYYMMDD-dev, buildkit-vX.Y.Z-riscv64, or buildkit-vX.Y.Z" - exit 1 - fi - - # Validate version is not empty - if [ -z "$VERSION" ]; then - echo "Error: Failed to extract version from tag: $RELEASE_TAG" - exit 1 - fi + VERSION=$(bash .github/scripts/extract-buildkit-version.sh "$RELEASE_TAG")This centralizes logic and reduces inconsistency risk.
88-146:⚠️ Add checksum verification for downloaded binaries (duplicate of past review).Same critical security gap as the Debian workflow: binaries are downloaded without integrity verification.
Apply checksum verification (if available in BuildKit releases):
# Clean and download binaries to SOURCES cd ~/rpmbuild/SOURCES rm -f buildkitd buildctl gh release download "$RELEASE_TAG" -p buildkitd -p buildctl --repo gounthar/docker-for-riscv64 + # Download and verify checksums + if gh release download "$RELEASE_TAG" -p "SHA256SUMS" --repo gounthar/docker-for-riscv64 2>/dev/null; then + echo "Verifying checksums..." + sha256sum -c SHA256SUMS --ignore-missing || { + echo "Error: Checksum verification failed for BuildKit binaries" + exit 1 + } + else + echo "Warning: No checksums file available for verification" + fi + # Validate binaries were downloaded if [ ! -f buildkitd ] || [ ! -f buildctl ]; then echo "Error: Failed to download BuildKit binaries from release $RELEASE_TAG" exit 1 fiCoordinate with the BuildKit upstream release process to ensure checksums are available.
.github/workflows/build-buildkit-package.yml (1)
80-145:⚠️ Add checksum verification for downloaded binaries (duplicate of past review).Binaries are downloaded without integrity verification. If the release is compromised or corrupted, malicious or broken binaries could be packaged. This is a critical security gap flagged in previous reviews.
Verify the downloaded binaries by adding checksum validation. If BuildKit releases provide a checksums file:
# Download binaries with explicit repo parameter gh release download "$RELEASE_TAG" -p buildkitd -p buildctl --repo gounthar/docker-for-riscv64 + # Download and verify checksums + if gh release download "$RELEASE_TAG" -p "SHA256SUMS" --repo gounthar/docker-for-riscv64 2>/dev/null; then + echo "Verifying checksums..." + sha256sum -c SHA256SUMS --ignore-missing || { + echo "Error: Checksum verification failed for BuildKit binaries" + exit 1 + } + else + echo "Warning: No checksums file available for verification" + fi + # Validate binaries were downloaded if [ ! -f buildkitd ] || [ ! -f buildctl ]; then echo "Error: Failed to download BuildKit binaries from release $RELEASE_TAG" exit 1 fi chmod +x buildkitd buildctlInvestigate whether BuildKit upstream provides published checksums or GPG-signed releases, and prefer signature verification over basic checksums if available.
🧹 Nitpick comments (2)
.github/workflows/build-buildkit-package.yml (2)
65-78: Improve gh CLI availability check for better diagnostics.The conditional installation at lines 74–77 suppresses the error and continues with an assumption that
ghis available. While reasonable on GitHub-hosted runners, this could mask missing dependencies if run on runners whereghis not pre-installed.Consider either:
- Enforce that
ghmust be available (fail fast if not):if ! command -v gh >/dev/null 2>&1; then - echo "gh CLI not found, attempting to install..." - if ! sudo apt-get install -y gh; then - echo "Warning: Failed to install gh CLI via apt, but it may be available via other means" - echo "Continuing as gh is likely pre-installed on the runner" - fi + if ! sudo apt-get install -y gh; then + echo "Error: gh CLI is required but installation failed" + exit 1 + fi fi
- Or verify
ghis actually available after the attempted install:+ if ! command -v gh >/dev/null 2>&1; then + echo "Error: gh CLI is not available and installation failed" + exit 1 + fi
147-190: Extract version extraction logic to a reusable script (duplicate concern from past review).The version extraction at lines 156–174 is identical to the RPM workflow (lines 161–173 in build-buildkit-rpm.yml). This duplication creates maintenance overhead and inconsistency risk.
Create a reusable script
.github/scripts/extract-buildkit-version.sh:#!/bin/bash # Extract version from BuildKit release tag # Usage: extract-buildkit-version.sh <release_tag> # Output: Prints extracted version to stdout set -euo pipefail RELEASE_TAG="$1" # Dev build: buildkit-v20251209-dev -> 0.0.20251209 # Official: buildkit-v0.17.3-riscv64 -> 0.17.3 if [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]{8})-dev$ ]]; then DATE_VER="${BASH_REMATCH[1]}" echo "0.0.${DATE_VER}" elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)-riscv64$ ]]; then echo "${BASH_REMATCH[1]}" elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then echo "${BASH_REMATCH[1]}" else echo "Error: Unrecognized release tag format: $RELEASE_TAG" >&2 echo "Expected formats: buildkit-vYYYYMMDD-dev, buildkit-vX.Y.Z-riscv64, or buildkit-vX.Y.Z" >&2 exit 1 fiThen replace lines 156–174 with:
- # Extract version from tag - # Dev build: buildkit-v20251209-dev -> 0.0.20251209 - # Official: buildkit-v0.26.2-riscv64 -> 0.26.2 - if [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]{8})-dev$ ]]; then - DATE_VER="${BASH_REMATCH[1]}" - VERSION="0.0.${DATE_VER}" - elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)-riscv64$ ]]; then - VERSION="${BASH_REMATCH[1]}" - elif [[ "$RELEASE_TAG" =~ ^buildkit-v([0-9]+\.[0-9]+\.[0-9]+)$ ]]; then - # Handle case without -riscv64 suffix - VERSION="${BASH_REMATCH[1]}" - else - echo "Error: Unrecognized release tag format: $RELEASE_TAG" - echo "Expected formats: buildkit-vYYYYMMDD-dev, buildkit-vX.Y.Z-riscv64, or buildkit-vX.Y.Z" - exit 1 - fi - - # Validate version is not empty - if [ -z "$VERSION" ]; then - echo "Error: Failed to extract version from tag: $RELEASE_TAG" - exit 1 - fi + VERSION=$(bash .github/scripts/extract-buildkit-version.sh "$RELEASE_TAG")This centralizes the logic for both Debian and RPM workflows, reducing duplication and maintenance risk.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
.github/workflows/build-buildkit-package.yml(1 hunks).github/workflows/build-buildkit-rpm.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (4)
📓 Common learnings
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to scripts/**/*.sh : Use shell scripts to automate complex build steps, apply patches, and work around upstream limitations for specific architectures
Applied to files:
.github/workflows/build-buildkit-rpm.yml.github/workflows/build-buildkit-package.yml
📚 Learning: 2025-12-09T10:39:18.263Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 211
File: docs/BUILDKIT-IMPLEMENTATION-GUIDE.md:482-482
Timestamp: 2025-12-09T10:39:18.263Z
Learning: Enforce a single Go version across all workflows by setting a minimum Go version of 1.25.3 (Go 1.25.3+). Update all CI workflow configurations (e.g., actions/setup-go) to use this minimum version to maintain consistency and prevent drift.
Applied to files:
.github/workflows/build-buildkit-rpm.yml.github/workflows/build-buildkit-package.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
Applied to files:
.github/workflows/build-buildkit-package.yml
🔇 Additional comments (12)
.github/workflows/build-buildkit-package.yml (5)
1-22: ✓ Workflow configuration is sound.The trigger setup, permissions, and runner configuration are appropriate for the Debian packaging workflow.
27-63: ✓ Release detection and idempotence check is solid.The logic properly skips builds when packages already exist and handles manual dispatch appropriately.
192-205: ✓ Build step has proper error handling.The
set -euo pipefailand verification of .deb creation prevent masked failures.
207-229: ✓ Linting and diagnostics are appropriately configured.The
|| trueon lintian allows warnings without failing, and package info provides useful output.
231-275: ✓ Upload step has robust error handling and retry logic.The UPLOAD_FAILED flag and explicit error exit ensure the job fails if uploads don't succeed after retries.
.github/workflows/build-buildkit-rpm.yml (7)
1-22: ✓ Workflow setup is sound.Configuration appropriately mirrors the Debian packaging workflow.
27-64: ✓ Release detection and idempotence check is solid.The logic properly gates the build based on existing RPM assets.
66-86: ✓ Dependency and build tree setup is well-structured.Platform detection for Fedora/Debian and the rpmdev-setuptree fallback are good practices.
148-151: ✓ Spec file copy is correct.
186-201: ✓ RPM build step has robust error handling.The verification and strict shell semantics prevent masked failures.
203-206: ✓ RPM linting is appropriately configured.
208-254: ✓ Upload step has proper error handling and retry logic.The UPLOAD_FAILED flag and explicit error exit ensure failures are properly reported.
- Create .github/scripts/extract-buildkit-version.sh for DRY version extraction - Update both Debian and RPM workflows to use the shared script - Improve gh CLI availability check with fail-fast error handling - Add verification that gh is actually available after installation Addresses CodeRabbit review suggestions for code deduplication and better error diagnostics.
|
Addressed in commit 0def98f:
Checksum verification remains tracked for future work as it requires infrastructure changes (publishing checksums with BuildKit releases). |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
.github/workflows/build-buildkit-rpm.yml (1)
66-74: Consider adding gh CLI availability verification for consistency with Debian workflow.The Debian workflow (lines 72-83 of build-buildkit-package.yml) explicitly checks for gh CLI availability and installs it if missing, with fail-fast error handling. The RPM workflow lacks this verification, even though it requires gh for binary downloads at line 107. While GitHub Actions runners typically have gh pre-installed, self-hosted runners may not. For robustness and consistency, consider adding similar gh CLI verification to the RPM workflow:
- name: Install build dependencies if: steps.release.outputs.has-new-release == 'true' run: | if [ -f /etc/fedora-release ]; then sudo dnf install -y rpm-build rpmdevtools rpmlint elif [ -f /etc/debian_version ]; then sudo apt-get update sudo apt-get install -y rpm rpmlint fi + # Verify gh CLI is available (required for binary downloads) + if ! command -v gh >/dev/null 2>&1; then + echo "Error: gh CLI is required but not found" + exit 1 + fi + echo "gh CLI version: $(gh --version | head -1)"
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
.github/scripts/extract-buildkit-version.sh(1 hunks).github/workflows/build-buildkit-package.yml(1 hunks).github/workflows/build-buildkit-rpm.yml(1 hunks)
🧰 Additional context used
🧠 Learnings (13)
📓 Common learnings
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Extend CI/CD configuration to build, test, and publish images for newly supported architectures
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to scripts/**/*.sh : Use shell scripts to automate complex build steps, apply patches, and work around upstream limitations for specific architectures
Applied to files:
.github/workflows/build-buildkit-package.yml.github/scripts/extract-buildkit-version.sh.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-10-19T20:52:41.872Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-19T20:52:41.872Z
Learning: When fixing file conflicts in Debian packages, if the conflicting package is from Debian's official repositories with a version higher than previous constraints (e.g., docker-compose 2.26.1 vs constraint `<< 2.0`), remove version constraints to ensure the conflict declaration is effective.
Applied to files:
.github/workflows/build-buildkit-package.yml
📚 Learning: 2025-10-31T21:15:53.276Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 0
File: :0-0
Timestamp: 2025-10-31T21:15:53.276Z
Learning: For the docker-for-riscv64 repository, Gentoo packaging support is being implemented in phases: Phase 1 focuses on infrastructure (overlay structure, Docker ebuild, UpdateCLI automation, documentation), with additional packages (containerd, runc, docker-cli, docker-compose, tini) planned for follow-up PRs.
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to docker-bake.hcl : Use docker-bake.hcl for orchestrating multi-platform builds with Docker Buildx, specifying how to build images for different architectures
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-10-31T21:28:15.016Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 65
File: gentoo-overlay/app-containers/docker/files/docker.confd:1-1
Timestamp: 2025-10-31T21:28:15.016Z
Learning: In the docker-for-riscv64 repository, files in the gentoo-overlay/ directory are auto-generated by the generate-gentoo-overlay.sh script and should not be manually edited. The correct workflow for fixing issues in generated overlay files is: 1) Fix the upstream source files in upstream-gentoo-ebuilds/app-containers/docker/files/, 2) Re-run generate-gentoo-overlay.sh, 3) The overlay files will be automatically regenerated with the corrected content.
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-10-31T21:28:12.067Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 65
File: gentoo-overlay/app-containers/docker/files/docker.initd:1-1
Timestamp: 2025-10-31T21:28:12.067Z
Learning: In the docker-for-riscv64 repository, files in gentoo-overlay/ are auto-generated by generate-gentoo-overlay.sh from upstream sources in upstream-gentoo-ebuilds/. Any issues in generated files should be fixed in the upstream sources, then the generator script should be re-run to regenerate the overlay files.
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: When adding support for a new architecture, update docker-bake.hcl to define build groups and platforms for the new architecture
Applied to files:
.github/workflows/build-buildkit-package.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: Applies to Dockerfile* : Create architecture-specific Dockerfiles tailored for each platform or use case (e.g., Dockerfile.riscv for RISC-V, Dockerfile.windows for Windows)
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-12-02T08:41:41.360Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/01_architecture.md:0-0
Timestamp: 2025-12-02T08:41:41.360Z
Learning: When adding support for a new architecture, create or patch Dockerfiles specific to that architecture
Applied to files:
.github/workflows/build-buildkit-package.yml
📚 Learning: 2025-12-09T10:39:18.263Z
Learnt from: gounthar
Repo: gounthar/docker-for-riscv64 PR: 211
File: docs/BUILDKIT-IMPLEMENTATION-GUIDE.md:482-482
Timestamp: 2025-12-09T10:39:18.263Z
Learning: Enforce a single Go version across all workflows by setting a minimum Go version of 1.25.3 (Go 1.25.3+). Update all CI workflow configurations (e.g., actions/setup-go) to use this minimum version to maintain consistency and prevent drift.
Applied to files:
.github/workflows/build-buildkit-package.yml.github/workflows/build-buildkit-rpm.yml
📚 Learning: 2025-12-02T08:42:05.866Z
Learnt from: CR
Repo: gounthar/docker-for-riscv64 PR: 0
File: .clinerules/02_coding_policy.md:0-0
Timestamp: 2025-12-02T08:42:05.866Z
Learning: Refactor code for clarity and maintainability, ensuring all tests remain green
Applied to files:
.github/workflows/build-buildkit-rpm.yml
🔇 Additional comments (7)
.github/scripts/extract-buildkit-version.sh (1)
1-34: Well-structured version extraction utility with proper error handling.The script correctly implements version normalization for all three BuildKit release tag formats (dev builds, official releases with/without riscv64 suffix), uses strict shell options for safety, and provides clear error messages for unsupported formats. The regex patterns are distinct and non-overlapping, and the use of BASH_REMATCH is correct.
.github/workflows/build-buildkit-package.yml (4)
27-63: Release detection and idempotence logic is well-implemented.The step correctly handles both manual dispatch and automatic workflow triggers, properly identifies BuildKit releases using pattern matching, and implements skip-if-already-exists logic to prevent redundant package builds.
65-84: Robust gh CLI availability checks with proper fail-fast error handling.The dependency installation step properly verifies gh CLI availability, attempts installation only if needed, fails fast if installation fails (line 75), and includes a secondary verification (lines 80-83) to confirm gh is actually available after the installation attempt. This defensive approach ensures the workflow fails clearly if gh is unavailable, preventing cryptic downstream failures.
86-151: Comprehensive binary download with thorough validation.The step properly handles both event types to determine the release tag, uses explicit
--repoparameter for clarity, validates that binaries were actually downloaded, and includes comprehensive architecture and linking verification. The checks for RISC-V64 architecture and static linking are appropriate for the packaging context.
153-261: Build and upload pipeline is well-structured with proper error handling throughout.The package version is correctly derived using the shared extraction script, the build step includes
set -euo pipefailand verifies that .deb packages were actually created (preventing silent failures), the upload step implements proper retry logic with failure tracking (setsUPLOAD_FAILEDflag and exits with code 1 on failure), and helpful installation instructions are provided post-upload..github/workflows/build-buildkit-rpm.yml (2)
88-180: Binary download, version extraction, and build process are well-implemented.The binary download includes proper validation, architecture verification, and explicit
--repoparameter (consistent with Debian workflow). The package version is correctly derived using the shared extraction script, and the build step includesset -euo pipefailwith verification that RPM packages were actually created.
182-233: Upload logic with proper retry handling and error tracking.The rpmlint checks are appropriately permissive (allowing non-critical issues with
|| true), the upload step implements proper retry logic with failure tracking (UPLOAD_FAILED flag), exits with code 1 if uploads fail, uses explicit--repoand--clobberfor safety and idempotence, and provides clear post-upload status and installation instructions.
Summary
Changes
Debian Packaging (
debian-buildkit/)control: Package metadata with containerd/docker recommendationsrules: Skip build phase (uses pre-built binaries)install: Installsbuildkitdandbuildctlto/usr/binchangelog,copyright,source/format: Standard Debian filesRPM Packaging (
rpm-buildkit/)buildkit.spec: RPM spec installing both binaries to/usr/binWorkflows
build-buildkit-package.yml: Creates.debpackage, triggered by weekly buildbuild-buildkit-rpm.yml: Creates.rpmpackage, triggered by weekly buildtrack-buildkit-releases.yml: Daily check for new BuildKit releases at 08:00 UTCFeatures
buildkit-v20251209-dev) and official releases (buildkit-v0.26.2-riscv64)buildkitaligned with official Debian work at salsa.debian.orgTest plan
build-buildkit-package.ymlwithbuildkit-v20251209-devbuild-buildkit-rpm.ymlwithbuildkit-v20251209-dev.deband.rpmpackages are uploaded to releaseSummary by CodeRabbit
New Features
Chores
✏️ Tip: You can customize this high-level summary in your review settings.