fix: enable Docker Buildx to eliminate legacy builder deprecation warnings #461
Conversation
📝 WalkthroughWalkthroughAdds a Docker Buildx setup step ( Changes
Sequence Diagram(s)sequenceDiagram
actor GH as GitHub Actions
participant Job as Job (macOS / trivy)
participant Vault as Vault step
participant Buildx as setup-buildx
participant Docker as docker build step
GH->>Job: start job
alt trivy flow
Job->>Vault: retrieve secrets
Vault-->>Job: secrets
end
Job->>Buildx: Set up Docker Buildx (docker/setup-buildx-action@v3)
Buildx-->>Job: Buildx ready
Job->>Docker: docker build / docker buildx build
Docker-->>Job: build result
Job-->>GH: job complete
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes
Possibly related PRs
Suggested reviewers
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 |
🔍 Vulnerabilities of
|
| digest | sha256:a4270403a2cb8386bd7cb10dec216610429f11f054ab13d4ebb64371395db642 |
| vulnerabilities |     |
| platform | linux/amd64 |
| size | 127 MB |
| packages | 206 |
📦 Base Image eclipse-temurin:21-jre
| also known as |
|
| digest | sha256:d665ca47131b82e94b17ec6b8d9ee72924268c509f9407a766ffe3d3defbaa32 |
| vulnerabilities |   |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
|
|
||
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium test
| parse-json-secrets: true | ||
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
jnewton03
force-pushed
the
fix/enable-docker-buildx-for-workflows
branch
from
5f5cfae to
832b263
Compare
![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
♻️ Duplicate comments (2)
.github/workflows/test.yml (1)
40-41: Unpinned action tag already flagged—pin to commit hash for security.This unpinned reference to
docker/setup-buildx-action@v3was already flagged by CodeQL in the past review. While this aligns with the repository's existing pattern in create-release.yml and build-qa-docker.yml (per PR context), pinning to a specific commit hash hardens the security posture against tag mutation.For example:
uses: docker/setup-buildx-action@3f1ac8c9e63aaab0a3cf3a1c1ebc0e86c206b40f # v3That said, the core change is sound: the step is correctly positioned before the docker build commands and will run on both Ubuntu and macOS runners as intended.
.github/workflows/trivy.yml (1)
55-56: Unpinned action tag already flagged—pin to commit hash for security.This unpinned reference to
docker/setup-buildx-action@v3was already flagged by CodeQL in the past review. While this aligns with the repository's existing pattern, pinning to a specific commit hash improves security posture:uses: docker/setup-buildx-action@3f1ac8c9e63aaab0a3cf3a1c1ebc0e86c206b40f # v3The core change is solid: the step is correctly placed before the docker build commands in the trivy job.
🧹 Nitpick comments (1)
.github/workflows/trivy.yml (1)
109-127: Optional: Consider adding Buildx to the scout job for consistency.The
scoutjob (lines 109–197) also usesdocker buildat lines 124–126, which would similarly benefit from Buildx for the same deprecation warning elimination and performance improvements. However, this is outside the current PR scope. Consider as a follow-up improvement to align both jobs in this workflow.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
.github/workflows/test.yml(1 hunks).github/workflows/trivy.yml(1 hunks)
🧰 Additional context used
🪛 GitHub Check: CodeQL
.github/workflows/test.yml
[warning] 41-41: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Dockerfiles' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
.github/workflows/trivy.yml
[warning] 56-56: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Vulnerability Scanning' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
⏰ 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: Build & Test DockerfileSecure - macos-15-intel
- GitHub Check: Build & Test Dockerfile.alpine - macos-15-intel
- GitHub Check: Build & Test DockerfileSecure - ubuntu-latest
- GitHub Check: Build & Test Dockerfile - ubuntu-latest
- GitHub Check: Build & Test Dockerfile.alpine - ubuntu-latest
- GitHub Check: Build & Test Dockerfile - macos-15-intel
…nings Adds Docker Buildx setup to test.yml and trivy.yml workflows to resolve deprecation warnings and align with production workflows. Changes: - test.yml: Add docker/setup-buildx-action@v3 after macOS Docker setup - trivy.yml: Add docker/setup-buildx-action@v3 before image builds Benefits: - Removes "The legacy builder is deprecated" warnings from all workflows - Aligns with production workflows (create-release.yml, build-qa-docker.yml) - Enables BuildKit for faster builds and better caching - No changes required to existing docker build commands - Future-proofs workflows before legacy builder removal All workflows now use consistent Docker build approach: ✅ create-release.yml - Already using Buildx ✅ build-qa-docker.yml - Already using Buildx ✅ test.yml - Now using Buildx (this PR) ✅ trivy.yml - Now using Buildx (this PR) 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
jnewton03
force-pushed
the
fix/enable-docker-buildx-for-workflows
branch
from
832b263 to
dd82af7
Compare
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
.github/workflows/trivy.yml (1)
55-56: Address unpinned tag in docker/setup-buildx-action to meet supply chain security best practices.The CodeQL static analysis tool has flagged that
docker/setup-buildx-action@v3uses a mutable tag instead of an immutable commit hash. Version tags can be re-tagged or updated, creating a supply chain risk. Pinning to a specific commit SHA (e.g.,docker/setup-buildx-action@abc123def456...) is the security best practice for Actions.Confirm whether this unpinned-tag pattern is accepted as part of your organization's GitHub Actions security policy. If stricter pinning is required, you can find the commit SHA for
v3at https://github.com/docker/setup-buildx-action/releases/tag/v3.
🧹 Nitpick comments (1)
.github/workflows/trivy.yml (1)
109-126: Consider adding Buildx setup to the scout job for consistency.The scout job in this same file (lines 109–197) also builds the same three Dockerfile variants (line 124–126) but lacks the Buildx setup step. If the PR goal is to eliminate legacy builder deprecation warnings repository-wide, adding Buildx to the scout job would ensure consistent build paths and performance improvements across both scanning jobs that operate on identical Dockerfiles.
This is a minor consistency improvement and may be outside the current PR scope, but worth considering as a follow-up to maximize the benefits of Buildx adoption.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (2)
.github/workflows/test.yml(1 hunks).github/workflows/trivy.yml(1 hunks)
🧰 Additional context used
🪛 GitHub Check: CodeQL
.github/workflows/trivy.yml
[warning] 56-56: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Vulnerability Scanning' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
.github/workflows/test.yml
[warning] 41-41: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Dockerfiles' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
⏰ 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: Build & Test Dockerfile - macos-15-intel
- GitHub Check: Build & Test DockerfileSecure - macos-15-intel
- GitHub Check: Build & Test DockerfileSecure - ubuntu-latest
- GitHub Check: Build & Test Dockerfile.alpine - ubuntu-latest
- GitHub Check: Build & Test Dockerfile.alpine - macos-15-intel
- GitHub Check: Build & Test Dockerfile - ubuntu-latest
🔇 Additional comments (2)
.github/workflows/test.yml (1)
40-41: Buildx setup is correctly positioned for all test matrix runners.The step placement is sound—it runs after macOS Docker setup (which only executes on macos-15-intel) and enables BuildKit for all subsequent docker build commands across both ubuntu-latest and macos-15-intel runners. This ensures deprecation warnings are eliminated and build performance (caching, efficient context transfer) is improved.
.github/workflows/trivy.yml (1)
55-56: Buildx setup is correctly positioned in the trivy job.The step placement is correct—it runs after vault secrets retrieval and before the docker build command (line 60), enabling BuildKit for the image build and Trivy vulnerability scan. This improves build performance and eliminates deprecation warnings for the Dockerfile variants scanned in this job.
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 |
There was a problem hiding this comment.
❓ Verification inconclusive
Address unpinned tag in docker/setup-buildx-action to meet supply chain security best practices.
The CodeQL static analysis tool has flagged that docker/setup-buildx-action@v3 uses a mutable tag instead of an immutable commit hash. Version tags can be re-tagged or updated, creating a supply chain risk. Pinning to a specific commit SHA (e.g., docker/setup-buildx-action@abc123def456...) is the security best practice for Actions, even if this pattern exists in other workflows in the repo.
Confirm whether this unpinned-tag pattern is accepted as part of your organization's GitHub Actions security policy. If stricter pinning is required, you can find the commit SHA for v3 at https://github.com/docker/setup-buildx-action/releases/tag/v3.
I'll verify the security claims in this review by searching for GitHub Actions best practices.
Let me verify if there are any organizational security policies in the codebase that would clarify the context of this review.
I've verified the review comment against current GitHub Actions security best practices and real-world data. Here are my findings:
Key verification results:
Although pinning to a commit SHA is the most secure option, version tags can be moved or deleted if a bad actor gains access to the repository storing the action. The review comment's claim about mutability is correct.
The popular GitHub Action tj-actions/changed-files was compromised in March 2025, with all tags tampered to point to a revision with malicious code. This demonstrates the real-world risk is not theoretical.
GitHub recommends that workflows pin dependency versions to a specific commit SHA to prevent malicious code added to a new or updated branch or tag from being automatically used.
Docker's setup-buildx-action is manually verified by GitHub as an official partner organization, making it from a trusted source—but this doesn't eliminate the supply chain risk identified in the review.
Address unpinned tag in docker/setup-buildx-action to meet supply chain security best practices.
Pinning an action to a full-length commit SHA is currently the only way to use an action as an immutable release. Update line 41 from docker/setup-buildx-action@v3 to pin to a commit SHA (e.g., docker/setup-buildx-action@abc123def...) and include a comment referencing the v3 tag to aid future dependency updates.
🏁 Script executed:
#!/bin/bash
# Search for security policy files or documentation
fd -i 'security\|policy\|codeql' --type f -e md -e yml -e yaml -e txtLength of output: 0
Pin docker/setup-buildx-action to a commit SHA instead of the v3 version tag.
Version tags like v3 are mutable and can be retagged or updated, creating a supply chain risk. Pin to a specific commit SHA (available at https://github.com/docker/setup-buildx-action/releases/tag/v3) to ensure you're running a known, immutable version. This is the recommended security practice for GitHub Actions.
🧰 Tools
🪛 GitHub Check: CodeQL
[warning] 41-41: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Test Dockerfiles' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
🤖 Prompt for AI Agents
.github/workflows/test.yml lines 40-41: the workflow currently uses the mutable
tag "docker/setup-buildx-action@v3"; replace it with the specific commit SHA for
the v3 release to pin the action to an immutable version. Retrieve the commit
SHA from the v3 release page
(https://github.com/docker/setup-buildx-action/releases/tag/v3) and update the
"uses" reference to the full repo@SHA format so the workflow runs a fixed,
auditable commit.
Adds Docker Buildx setup to the scout job (Docker Scout security scanning) to eliminate remaining legacy builder deprecation warnings. Changes: - trivy.yml: Add docker/setup-buildx-action@v3 to scout job (line 124-125) This completes the repository-wide elimination of legacy builder warnings: ✅ test.yml - Main build uses Buildx (line 40-41) ✅ test.yml - Custom entrypoint builds use Buildx (inherited from line 40-41) ✅ trivy.yml - Trivy scan job uses Buildx (line 55-56) ✅ trivy.yml - Scout scan job uses Buildx (line 124-125, this commit) Addresses CodeRabbit review feedback on PR #461. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
| uses: actions/checkout@v6 | ||
|
|
||
| - name: Set up Docker Buildx | ||
| uses: docker/setup-buildx-action@v3 |
Check warning
Code scanning / CodeQL
Unpinned tag for a non-immutable Action in workflow Medium
There was a problem hiding this comment.
Actionable comments posted: 0
♻️ Duplicate comments (1)
.github/workflows/trivy.yml (1)
55-56:⚠️ Pin action to commit SHA instead of version tag for supply-chain security.Lines 55–56 (trivy job) and 124–125 (scout job) both use
docker/setup-buildx-action@v3without a pinned commit hash. Version tags can be reassigned or unexpectedly updated, introducing supply-chain risk. GitHub Advanced Security flagged this concern previously; it remains unresolved.Recommend pinning to a specific commit hash. For example, find the commit SHA for v3 release of docker/setup-buildx-action and update both occurrences:
- uses: docker/setup-buildx-action@v3 + uses: docker/setup-buildx-action@<commit-sha>To find the correct commit SHA:
- Visit the docker/setup-buildx-action releases page
- Look up the commit SHA for the v3 release tag
- Update both lines 56 and 125
Alternatively, if your repository policy permits unpinned version tags, document that decision explicitly.
🧹 Nitpick comments (1)
.github/workflows/trivy.yml (1)
124-125: Inconsistent placement of Buildx setup in scout job.The scout job places Buildx setup (line 124–125) before vault secrets retrieval (lines 131–143), whereas the trivy job places it after vault setup. While the docker build command itself doesn't consume vault secrets, the ordering inconsistency may indicate oversight or unclear intent.
Consider moving the Buildx setup in the scout job to after the vault secrets step (after line 143) to align with the trivy job pattern and follow a consistent sequence: checkout → setup infrastructure → retrieve secrets → build.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Jira integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/trivy.yml(2 hunks)
🧰 Additional context used
🪛 GitHub Check: CodeQL
.github/workflows/trivy.yml
[warning] 56-56: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Vulnerability Scanning' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
[warning] 125-125: Unpinned tag for a non-immutable Action in workflow
Unpinned 3rd party Action 'Vulnerability Scanning' step Uses Step uses 'docker/setup-buildx-action' with ref 'v3', not a pinned commit hash
⏰ 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). (8)
- GitHub Check: Scout (DockerfileSecure, liquibase/liquibase-secure)
- GitHub Check: Scout (Dockerfile, liquibase/liquibase)
- GitHub Check: Build & Test DockerfileSecure - ubuntu-latest
- GitHub Check: Build & Test DockerfileSecure - macos-15-intel
- GitHub Check: Build & Test Dockerfile.alpine - macos-15-intel
- GitHub Check: Build & Test Dockerfile - macos-15-intel
- GitHub Check: Build & Test Dockerfile - ubuntu-latest
- GitHub Check: Build & Test Dockerfile.alpine - ubuntu-latest
Summary
Changes
File 1:
.github/workflows/test.ymlAdded Docker Buildx setup after macOS Docker setup (line 40-41):
File 2:
.github/workflows/trivy.ymlAdded Docker Buildx setup before image builds (line 55-56):
Why This Change
Deprecation Warning Resolved
The following warning appears in both test.yml and trivy.yml workflows:
This change eliminates these warnings by enabling Docker BuildKit through the official Buildx action.
Alignment with Production Workflows
This change brings consistency across all workflows:
docker/setup-buildx-action@v3+docker/build-push-action@v6docker/setup-buildx-action@v3+docker/build-push-action@v6docker build→ Now using BuildKitdocker build→ Now using BuildKitBenefits
1. Eliminates Deprecation Warnings
2. Improved Build Performance
3. Consistency Across Workflows
4. No Breaking Changes
docker buildcommands work identicallyTechnical Details
How BuildKit is Enabled
The
docker/setup-buildx-action@v3automatically:docker buildcommandsCompatibility
Command Compatibility
No changes needed to existing commands. These continue to work identically:
Testing Impact
Related PRs
Test Plan
🤖 Generated with Claude Code