V2.0.0/fix docker attestation - #8
Conversation
Adds optional attest_image parameter (default true) to allow operators to disable attestation as a fallback when registry support is unavailable. Includes docker login/logout steps in both staging and dockerhub attestation jobs, environment gates for production safety, and updates conditional logic for the promotion job to handle skipped attestation.
Documents that attestation is enabled by default and explains the attest_image fallback parameter for cases where registry attestation is unavailable. Clarifies how disabling attestation affects the release artifact and digest gates.
Greptile SummaryThis PR adds an explicit attestation toggle, authenticates attestation jobs to their target registries, and permits Docker Hub promotion when attestations are deliberately disabled.
Confidence Score: 4/5The release workflow should not be merged until the redundant post-publication Production approval is removed or intentionally incorporated into the documented release process. Docker Hub promotion and its downstream attestation now create separate sequential deployments to the reviewer-protected Production environment, leaving the workflow waiting after the image has already been published unless an operator approves it again. Files Needing Attention: .github/workflows/ci-pipeline.yml Important Files Changed
Sequence DiagramsequenceDiagram
participant Operator
participant Promote as Docker Hub promotion
participant Production as Production environment
participant Attest as Docker Hub attestation
Operator->>Production: Approve promotion job
Production->>Promote: Release job
Promote->>Promote: Push image
Promote->>Attest: Promotion succeeds
Attest->>Production: Request separate deployment approval
Operator->>Production: Approve attestation job
Production->>Attest: Release job
Attest->>Attest: Publish provenance and SBOM
Prompt To Fix All With AI### Issue 1
.github/workflows/ci-pipeline.yml:563
**Duplicate Production approval gate**
When `Production` requires reviewers as documented, `container_promote_dockerhub` first passes that environment’s approval and publishes the image, then this downstream job creates a separate Production deployment that requires another approval before provenance and SBOM attestations are published, leaving the release unattested and the workflow incomplete until a second approval occurs.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.Reviews (1): Last reviewed commit: "💬 document attestation feature and rele..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| name: attest-container-dockerhub | ||
| needs: [init, container_build, container_promote_dockerhub] | ||
| runs-on: ubuntu-24.04 | ||
| environment: Production |
There was a problem hiding this comment.
When Production requires reviewers as documented, container_promote_dockerhub first passes that environment’s approval and publishes the image, then this downstream job creates a separate Production deployment that requires another approval before provenance and SBOM attestations are published, leaving the release unattested and the workflow incomplete until a second approval occurs.
Prompt To Fix With AI
This is a comment left during a code review.
Path: .github/workflows/ci-pipeline.yml
Line: 563
Comment:
**Duplicate Production approval gate**
When `Production` requires reviewers as documented, `container_promote_dockerhub` first passes that environment’s approval and publishes the image, then this downstream job creates a separate Production deployment that requires another approval before provenance and SBOM attestations are published, leaving the release unattested and the workflow incomplete until a second approval occurs.
---
For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.
2 participants
No description provided.