Automate clean-up of attestations

[Copilot]

Attestations were kept indefinitely even after their associated container images were removed. This extends both cleanup workflows to also delete attestations, keeping only those tied to active resources.

Changes

image-cleanup.yml

Three-phase pipeline where image deletion is leading:

1. collect-digests — snapshots all current package version digests per package before any cleanup (uploaded as artifacts)
2. cleanup-images — deletes images using ghcr-cleanup-action as before (if: always() ensures cleanup runs even if digest collection partially failed)
3. cleanup-attestations — downloads the snapshot, compares it to remaining digests after image cleanup, and deletes attestations only for digests that were actually removed

pr-image-cleanup.yml

Three-phase pipeline where image deletion is leading:

1. collect-pr-digests — resolves the pr-<N> tag to a digest per package and uploads as artifacts
2. delete-images — deletes the PR images first using ghcr-cleanup-action (if: always())
3. delete-attestations — deletes attestations for the PR digest collected in step 1, after the image is already gone

Retention decisions (what images to keep) are made entirely by ghcr-cleanup-action. Attestation cleanup is driven by what was actually deleted, with no duplicate tag-evaluation logic.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Automate clean-up of Attestations</issue_title>
<issue_description>## Current situation

Currently all generated attestations are kept indefinite, even when the resources that they point to are cleaned up.

Required situation

Extend the current clean up process to automatically clean up attestations. Keeping only the ones that point to active release or edge builds, as is specified in the acceptance criteria below.

Acceptance criteria

• Attestations that don't point to a valid resource are cleaned up
• Attestations from release branches are kept indefinite
• Attestations for open pull requests are kept
• Attestations for the last build on the default branch (tagged as edge) are kept</issue_description>

Comments on the Issue (you are Copilot in this section)

• Fixes Automate clean-up of Attestations #1134

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[github-actions]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

⚠️ Details

No release type found in pull request title "[WIP] Automate clean-up of attestations". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:

• feat: A new feature
• fix: A bug fix
• docs: Documentation only changes
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• refactor: A code change that neither fixes a bug nor adds a feature
• perf: A code change that improves performance
• test: Adding missing tests or correcting existing tests
• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• chore: Other changes that don't modify src or test files
• revert: Reverts a previous commit

[github-actions]

✅⚠️MegaLinter analysis: Success with warnings

Descriptor	Linter	Files	Fixed	Errors	Warnings	Elapsed time
✅ ACTION	actionlint	23		0	0	0.34s
✅ DOCKERFILE	hadolint	3		0	0	0.34s
✅ JSON	npm-package-json-lint	yes		no	no	0.62s
✅ JSON	prettier	21	4	0	0	1.02s
✅ JSON	v8r	21		0	0	9.57s
✅ MARKDOWN	markdownlint	12	0	0	0	1.19s
✅ MARKDOWN	markdown-table-formatter	12	0	0	0	0.36s
✅ REPOSITORY	checkov	yes		no	no	26.71s
✅ REPOSITORY	gitleaks	yes		no	no	1.06s
✅ REPOSITORY	git_diff	yes		no	no	0.02s
✅ REPOSITORY	grype	yes		no	no	43.38s
✅ REPOSITORY	secretlint	yes		no	no	2.22s
✅ REPOSITORY	syft	yes		no	no	2.28s
✅ REPOSITORY	trivy	yes		no	no	12.32s
✅ REPOSITORY	trivy-sbom	yes		no	no	0.42s
✅ REPOSITORY	trufflehog	yes		no	no	6.35s
⚠️ SPELL	lychee	83		7	0	9.57s
✅ YAML	prettier	31	0	0	0	1.21s
✅ YAML	v8r	31		0	0	14.07s
✅ YAML	yamllint	31		0	0	1.26s

Detailed Issues

⚠️ SPELL / lychee - 7 errors

[IGNORED] docker://pandoc/extra:3.9.0.0-ubuntu@sha256:72afa9c8d3300e5f10c9c4330e101725687f2179bffd912fb859c6d2ae85de62 | Unsupported: Error creating request client: builder error for url (docker://pandoc/extra:3.9.0.0-ubuntu@sha256:72afa9c8d3300e5f10c9c4330e101725687f2179bffd912fb859c6d2ae85de62)
[403] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads | Network error: Forbidden
[IGNORED] https://vscode.dev/redirect?url=vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/philips-software/amp-devcontainer | Unsupported: Error creating request client: builder error for url (vscode://ms-vscode-remote.remote-containers/cloneInVolume?url=https://github.com/philips-software/amp-devcontainer)
[429] https://github.com/philips-software/amp-devcontainer/blob/main/.github/CONTRIBUTING.md | Network error: Too Many Requests
[429] https://github.com/philips-software/amp-devcontainer/blob/main/LICENSE | Network error: Too Many Requests
[429] https://github.com/philips-software/amp-devcontainer/blob/main/LICENSE | Network error: Too Many Requests
[429] https://github.com/philips-software/amp-devcontainer/blob/main/README.md | Network error: Too Many Requests
[429] https://github.com/philips-software/amp-devcontainer/blob/main/README.md | Network error: Too Many Requests
[429] https://github.com/opencontainers/image-spec/blob/main/spec.md | Network error: Too Many Requests
📝 Summary
---------------------
🔍 Total..........126
✅ Successful.....117
⏳ Timeouts.........0
🔀 Redirected.......0
👻 Excluded.........0
❓ Unknown..........0
🚫 Errors...........7

Errors in templates/rust/devcontainer-template.json
[429] https://github.com/philips-software/amp-devcontainer/blob/main/LICENSE | Network error: Too Many Requests
[429] https://github.com/philips-software/amp-devcontainer/blob/main/README.md | Network error: Too Many Requests

Errors in .github/TOOL_VERSION_ISSUE_TEMPLATE.md
[403] https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads | Network error: Forbidden

Errors in test/cpp/features/compatibility.feature
[429] https://github.com/opencontainers/image-spec/blob/main/spec.md | Network error: Too Many Requests

Errors in .github/PULL_REQUEST_TEMPLATE.md
[429] https://github.com/philips-software/amp-devcontainer/blob/main/.github/CONTRIBUTING.md | Network error: Too Many Requests

Errors in templates/cpp/devcontainer-template.json
[429] https://github.com/philips-software/amp-devcontainer/blob/main/README.md | Network error: Too Many Requests
[429] https://github.com/philips-software/amp-devcontainer/blob/main/LICENSE | Network error: Too Many Requests

See detailed reports in MegaLinter artifacts

You could have the same capabilities but better runtime performances if you use a MegaLinter flavor:

• oxsecurity/megalinter/flavors/salesforce@v9.4.0 (58 linters)
• oxsecurity/megalinter/flavors/javascript@v9.4.0 (61 linters)

Your project could benefit from a custom flavor, which would allow you to run only the linters you need, and thus improve runtime performances. (Skip this info by defining FLAVOR_SUGGESTIONS: false)

• Documentation: Custom Flavors
• Command: npx mega-linter-runner@9.4.0 --custom-flavor-setup --custom-flavor-linters ACTION_ACTIONLINT,DOCKERFILE_HADOLINT,JSON_V8R,JSON_PRETTIER,JSON_NPM_PACKAGE_JSON_LINT,MARKDOWN_MARKDOWNLINT,MARKDOWN_MARKDOWN_TABLE_FORMATTER,REPOSITORY_CHECKOV,REPOSITORY_GIT_DIFF,REPOSITORY_GITLEAKS,REPOSITORY_GRYPE,REPOSITORY_SECRETLINT,REPOSITORY_SYFT,REPOSITORY_TRIVY,REPOSITORY_TRIVY_SBOM,REPOSITORY_TRUFFLEHOG,SPELL_LYCHEE,YAML_PRETTIER,YAML_YAMLLINT,YAML_V8R

Show us your support by starring ⭐ the repository

[github-actions]

📦 Container Size Analysis

Note

Comparing ghcr.io/philips-software/amp-devcontainer-base:edge ➔ ghcr.io/philips-software/amp-devcontainer-base:pr-1200

📈 Size Comparison Table

OS/Platform	Previous	Current	Change	Trend
linux/amd64	144.68 MB	144.68 MB	857 B (0%)	🔽
linux/arm64	137.05 MB	137.04 MB	112 B (0%)	🔽

[github-actions]

📦 Container Size Analysis

Note

Comparing ghcr.io/philips-software/amp-devcontainer-rust:edge ➔ ghcr.io/philips-software/amp-devcontainer-rust:pr-1200

📈 Size Comparison Table

OS/Platform	Previous	Current	Change	Trend
linux/amd64	455.17 MB	455.17 MB	791 B (0%)	🔽
linux/arm64	408.4 MB	408.4 MB	+494 B (+0%)	🔼

[github-actions]

📦 Container Size Analysis

Note

Comparing ghcr.io/philips-software/amp-devcontainer-cpp:edge ➔ ghcr.io/philips-software/amp-devcontainer-cpp:pr-1200

📈 Size Comparison Table

OS/Platform	Previous	Current	Change	Trend
linux/amd64	538.72 MB	538.72 MB	1.42 kB (0%)	🔽
linux/arm64	520.66 MB	520.66 MB	+529 B (+0%)	🔼

[Ron (rjaegers)]

Copilot can we change the strategy to make image deletion leading, and then delete orphaned attestations? I don't like the detail and duplication of current approach. Also the attestation endpoint for deletion seems incorrect.

[Copilot]

Copilot can we change the strategy to make image deletion leading, and then delete orphaned attestations? I don't like the detail and duplication of current approach. Also the attestation endpoint fo...

Refactored both workflows in commit 6419753 so image deletion is now leading:

image-cleanup.yml — 3-phase pipeline:

1. collect-digests — snapshots all current package digests before any cleanup (uploaded as artifacts)
2. cleanup-images — deletes images as before using ghcr-cleanup-action (if: always() ensures it always runs)
3. cleanup-attestations — downloads the snapshot, compares it to the remaining digests after cleanup, and only deletes attestations for digests that were actually removed

pr-image-cleanup.yml — same pattern:

1. collect-pr-digests — resolves the pr-<N> tag to a digest
2. delete-images — deletes the image first
3. delete-attestations — cleans up the attestation for the digest collected in step 1

This removes all the duplicate tag-evaluation logic — what images to keep is decided entirely by ghcr-cleanup-action, and attestation cleanup simply follows from what was actually deleted.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud