ci: use different builders for different archs#1640
Conversation
📝 WalkthroughWalkthroughThis set of changes updates GitHub Actions workflows to use a new multi-architecture Docker image release workflow, restructures the release process for wardend binaries, modifies Docker build and artifact naming conventions, and simplifies the build logic in the justfile. It introduces a dedicated workflow for building and publishing wardend binaries and removes obsolete or redundant workflows. Changes
Sequence Diagram(s)sequenceDiagram
participant Workflow as GitHub Actions Workflow
participant Builder as Build Runner (amd64/arm64)
participant Registry as GHCR/Release
Workflow->>Builder: Checkout code
Workflow->>Builder: Setup runtime, Docker Buildx, just
Workflow->>Builder: Build Docker image or binary (arch-specific)
Builder->>Registry: Push Docker image or upload artifact
Workflow->>Registry: Publish release assets (binaries, checksums)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Possibly related PRs
Suggested labels
Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. ✨ Finishing Touches🧪 Generate 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
cmd/wardend/Dockerfile (1)
19-23: DefaultingWARDEND_VERSIONto "unknown" can leak into artefact namesIf callers forget to pass the build arg you’ll publish
wardend-unknown-linux-amd64, which is hard to trace later.
Consider failing fast when the arg is missing.ARG WARDEND_VERSION="unknown" +# Fail build early if version wasn’t provided +RUN test "$WARDEND_VERSION" != "unknown" || (echo "WARDEND_VERSION build-arg required" && exit 1).github/workflows/release-docker-images.yml (1)
21-55: Duplicate job definitions – use a matrix to DRY things up
release-image-amd64andrelease-image-arm64are identical except for the runner label.
A single job with a two-value matrix (runs-on) would cut the YAML in half and make future tweaks safer.No functional issue, purely maintainability.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (8)
.github/workflows/faucet.yml(1 hunks).github/workflows/release-docker-images.yml(4 hunks).github/workflows/release-wardend-binaries.yaml(1 hunks).github/workflows/release-wardend.yaml(0 hunks).github/workflows/wardend.yaml(1 hunks).github/workflows/wardenkms.yml(1 hunks)cmd/wardend/Dockerfile(1 hunks)justfile(2 hunks)
💤 Files with no reviewable changes (1)
- .github/workflows/release-wardend.yaml
🧰 Additional context used
🧠 Learnings (2)
cmd/wardend/Dockerfile (2)
Learnt from: jlehtimaki
PR: #1240
File: .goreleaser.yaml:171-214
Timestamp: 2025-02-14T08:33:02.071Z
Learning: The --insecure flags in Docker manifest configuration for the wardend project are temporarily required and should not be flagged as an issue in code reviews.
Learnt from: backsapc
PR: #810
File: cmd/wardenkms/wardenkms.go:45-50
Timestamp: 2024-10-24T13:01:55.558Z
Learning: In the cmd/wardenkms/wardenkms.go file and the codebase, use Grpc instead of GRPC for acronym casing in type names, such as GrpcNodeConfig and GrpcNodeConfigDecoder, even though Go naming conventions suggest capitalizing acronyms.
justfile (1)
Learnt from: jlehtimaki
PR: #1240
File: .goreleaser.yaml:171-214
Timestamp: 2025-02-14T08:33:02.071Z
Learning: The --insecure flags in Docker manifest configuration for the wardend project are temporarily required and should not be flagged as an issue in code reviews.
⏰ 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). (6)
- GitHub Check: lint
- GitHub Check: lint
- GitHub Check: test
- GitHub Check: test
- GitHub Check: Analyze (javascript-typescript)
- GitHub Check: Analyze (go)
🔇 Additional comments (17)
.github/workflows/wardend.yaml (1)
65-68: Workflow reference updated correctly – no further action neededThe switch to
./.github/workflows/release-docker-images.ymllooks correct and keeps theapp_nameinput intact.
No issues spotted here..github/workflows/wardenkms.yml (1)
60-63: Consistent migration to the new reusable workflowThe job now delegates to
release-docker-images.yml, matching the other apps. Implementation looks sound..github/workflows/faucet.yml (1)
66-69: Release job correctly re-pointedReference, inputs and permissions all line up with the new multi-arch workflow. Nothing to change.
cmd/wardend/Dockerfile (2)
8-12: 👍 Efficient dependency caching introducedCopying only
go.mod/go.sumand runninggo mod downloadunder a cache mount speeds up cold builds. Looks good.
22-23: Minor: binary stage is unused by subsequent stagesOnly the
runtimestage is referenced (COPY --from=build).
If the binary artefact is consumed outside the Docker build (e.g. byjust release-wardend-binary), ignore this. Otherwise, consider deleting thebinarystage or referencing it explicitly to avoid dead weight..github/workflows/release-docker-images.yml (1)
56-89: Ensure theubuntu-24.04-armrunner is available in your orgSelf-hosted and GH-hosted ARM64 runners use different labels across organisations. Verify that this exact label exists to avoid silent queue timeouts.
.github/workflows/release-wardend-binaries.yaml (6)
4-7: LGTM: Clean trigger configurationThe workflow correctly triggers on semantic version tags, which aligns with the PR objective of automating releases for version tags.
9-10: LGTM: Appropriate permissionsThe
contents: writepermission is correctly scoped for uploading release assets.
13-41: LGTM: Well-structured amd64 build jobThe build job follows GitHub Actions best practices with proper checkout, setup steps, and artifact upload. The use of
fetch-depth: 0ensures full git history for version tagging.
42-70: LGTM: Consistent arm64 build jobThe ARM64 build job maintains consistency with the AMD64 job, using the appropriate
ubuntu-24.04-armrunner for native ARM64 builds as mentioned in the PR objectives.
89-95: LGTM: Comprehensive release asset uploadThe release publishing correctly uploads both binaries and checksums using the established
softprops/action-gh-releaseaction.
81-88: Checksum generation directory assumptions are valid
We confirmed that therelease-wardend-binaryjust target always outputs its binaries intodist/(via--output dist .), which are then uploaded in the build jobs as artifacts namedbinary-amd64andbinary-arm64(pathdist/*). The download step recreates those subdirectories underartifacts/, so the checksum step can reliablycdintoartifacts/binary-amd64andartifacts/binary-arm64and runsha256sum. No changes required.justfile (5)
40-40: LGTM: Simplified release targetThe simplified
release-wardendtarget appropriately focuses on Docker image publishing, delegating binary builds to the separate workflow.
64-64: LGTM: Disabled provenance and SBOM for compatibilityDisabling provenance and SBOM generation is appropriate for binary-focused builds and avoids potential compatibility issues with older Docker clients.
69-81: LGTM: Well-designed binary build targetThe new
release-wardend-binarytarget properly:
- Cleans the output directory
- Uses the binary build stage
- Includes the new
WARDEND_VERSIONargument- Applies GitHub Actions caching
- Outputs to the expected
distdirectory
76-76: WARDEND_VERSION build argument usage confirmedThe
cmd/wardend/Dockerfilecorrectly declares and usesWARDEND_VERSIONfor naming the output binary:
- Defines
ARG WARDEND_VERSION="unknown"- Uses it in
COPY --from=build /dist/wardend /wardend-$WARDEND_VERSION-$TARGETOS-$TARGETARCH- Sets
ENTRYPOINT ["/wardend-$WARDEND_VERSION-$TARGETOS-$TARGETARCH"]No changes required.
63-67: Investigate GitHub Actionstype=ghacache limitationsThe current invocation in
justfile(lines 63–67) uses--cache-from type=gha --cache-to type=gha,mode=maxNote that:
- GitHub Actions caches are scoped per workflow and generally include branch/tag in the cache key.
- There is no automatic cross-tag or cross-workflow sharing with
type=gha.- Cache size (5 GB) and retention (7–90 days) may also lead to misses.
If you require reuse of layers across different image tags or workflows, consider:
- Retaining
type=ghafor single-tag builds but accepting isolated caches,- Or switching to a registry-based cache (
type=registry) or custom cache keys to enable cross-tag downloads.File needing your review:
- justfile (lines 63–67)
1 participant
This PR uses different github action runners for building different architectures (i.e. amd64 cpu for amd64 binaries, arm64 cpu for arm64 binaries, and only linux at this time). This is way faster than using qemu. A
wardendbuild now takes around 5 minutes.Additionally, every time a tag like
vX.Y.Zis pushed, the correspondingwardendbinaries are created automatically and the GitHub release is created with those binaries and checksums.I also enabled the type=gha mode for buildx cache (docs: https://docs.docker.com/build/cache/backends/gha/) but it's very limited by GitHub cache policies. For example, a tag cannot see the cache being made by another tag. So we can't really rely on this.