fix(release): set up docker-container buildx driver for attestations#317
Merged
Merged
Conversation
The release build requests `sbom: true` + `provenance: mode=max`, but with no `docker/setup-buildx-action` step buildx runs on the runner's default `docker` driver, which rejects attestations — the v0.1.0-beta.1 release build failed with "ERROR: failed to build: Attestation is not supported for the docker driver." Add a SHA-pinned Set up Buildx step (v4.2.0) so buildx uses the docker-container driver that supports SBOM/provenance. build.yml needs no equivalent — it publishes dev images with no attestations, so the default driver is fine there. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![icebergai-review-bot[bot]](https://avatars.githubusercontent.com/u/290878036?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
IcebergAutoReview
Verdict: approve
The release workflow now initializes Buildx with the default docker-container driver before the attested build. The action is immutable-SHA pinned with the required version comment, and the change is correctly scoped.
Findings
- No blocking findings.
Validation
- Inspected the complete
main...HEADdiff and surrounding release workflow context. - Verified the PR contains one commit changing only
.github/workflows/release.yml. - Ran
git diff --check main...HEAD; passed.
Residual risks / optional notes
- PR CI does not execute the tag-triggered image publication path, so end-to-end attestation publication remains verifiable only by a release run.
Automated review by Codex d43b44402108 using IcebergAutoReview.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The v0.1.0-beta.1 release build failed:
release.yml's build step requestssbom: true+provenance: mode=max, but there was nodocker/setup-buildx-actionstep, so buildx ran on the runner's defaultdockerdriver — which can't produce attestations. This adds a SHA-pinned Set up Buildx step (v4.2.0) so buildx uses thedocker-containerdriver.build.ymlneeds no equivalent: it publishes dev images with no attestations, so the default driver is fine there.Releasing after this merges
Because a tag-triggered workflow uses
release.ymlas it exists at the tagged commit, the existingv0.1.0-beta.1tag (pointing at the pre-fix commit) can't use the fix. The failed run published nothing (no GitHub Release, no image manifest — it failed during build assembly, before push). After merge I'll move the tag onto the fixed commit and re-push to re-trigger the release.🤖 Generated with Claude Code