fix(ci): scan pushed image digest with Trivy

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.

[joryirving]

Summary

The Trivy vulnerability scan has been silently failing on every release. It scans ${IMAGE_NAME}:sha-${{ github.sha }} — the full 40-char commit SHA — but docker/metadata-action tags the image with the short SHA (type=sha,prefix=sha-,format=short → sha-<short>). The full-SHA tag is never pushed, so Trivy can't pull the image:

image-ref: ghcr.io/misospace/dispatch:sha-d9c1610592a3aa71e67c53c90346ec89ce0c6139 # requested
pushed: ghcr.io/misospace/dispatch:sha-d9c1610 # actual

continue-on-error: true hides the failure (job stays green), so no SARIF is produced, the upload step is skipped via hashFiles(...), and the run shows a stray exit code 1 annotation.

Fix

Add id: build to the build-push step and scan ${IMAGE_NAME}@${{ steps.build.outputs.digest }}. The digest always points at the image just pushed, regardless of the SHA tag format — so it won't disturb the existing sha-<short> tag scheme that renovate pins to.

Test plan

• On merge to main, confirm the Trivy step pulls the image and the "Upload Trivy results" step runs (SARIF appears in the Security tab), with no exit code 1 annotation.

🤖 Generated with Claude Code

[its-saffron]

AI Automated Review

Analysis engine: MiniMax-M2.7@https://litellm.jory.dev/v1 (anthropic)

Review: fix(ci): scan pushed image digest with Trivy

Summary

This PR fixes a bug where the Trivy vulnerability scanner in the image workflow was silently failing on every release because it referenced an image tag (full 40-char SHA) that was never pushed. The metadata action creates a short SHA tag (sha-<short>), but the scan was looking for sha-<full40charsha>.

Change Analysis

Modified file:.github/workflows/image.yaml

Change	Description
id: build added	Labels the build-push-action step so its outputs can be referenced
image-ref syntax change	Switches from tag-based (sha-<full-sha>) to digest-based (@sha256:...) referencing

Before:

image-ref: ${{ env.IMAGE_NAME }}:sha-${{ github.sha }}

After:

image-ref: ${{ env.IMAGE_NAME }}@${{ steps.build.outputs.digest }}

Why This Works

1. docker/build-push-action exports the content-addressable digest of the pushed image as outputs.digest
2. The @sha256:... syntax references the exact image by its content hash, independent of any tags
3. This reliably points to the image that was just pushed, regardless of the tag scheme used
4. No longer dependent on the mismatch between full SHA (40 chars) and short SHA format

Standards Compliance

GitHub Actions Conventions (AGENTS.md):

• ✅ Trivy scanning is documented as continue-on-error: true — unchanged, still appropriate for advisory scanning
• ✅ Push to main creates main and sha-<shortsha> tags — this fix respects that scheme by not relying on tag names
• ✅ This is a CI-specific change; application code standards do not apply

Linked Issue Fit

No linked issues found. The PR body documents the problem thoroughly with a clear example showing the tag mismatch.

Evidence Provider Findings

No evidence providers configured for this PR.

Tool Harness Findings

No tool output captured. Planning warning noted but does not affect review.

Unknowns / Needs Verification

None identified. The fix is a targeted, minimal change to a CI workflow. The approach is well-understood:

• Using step outputs with id: is standard GitHub Actions pattern
• Digest-based image references (@sha256:...) are canonical in container registries
• The build-push-action clearly documents the digest output

Recommendation

Approve. The fix correctly resolves the silent Trivy scan failure by referencing the pushed image via its content digest rather than a tag that was never created. The approach is robust and respects existing tag conventions.