Context
PR #37 changed the publish pipeline so each per-arch build pushes to a GHCR staging repo (`ghcr.io/kingpin/php-docker`) by digest, and a separate `publish-merge` job assembles the final tagged manifests on Docker Hub, GHCR, and Quay using `docker buildx imagetools create`.
The staging pushes land as untagged digest references in the GHCR staging repo. They are referenced by the final manifest list, but the per-arch manifest entries themselves remain untagged forever. Over time these accumulate with every CI run and make the GHCR untagged-image view noisy. There is no built-in retention.
Options
- Add an explicit cleanup step in `publish-merge`. After `imagetools create` succeeds and the inspect step passes, run `actions/delete-package-versions` filtered to untagged versions older than N days.
- Use a separate scheduled workflow. Daily/weekly job that prunes untagged versions on the staging repo. Decouples cleanup from the publish path so a transient delete failure can't block publishes.
- Use a dedicated staging registry (e.g. a separate GHCR repo with package retention policy enabled via GitHub UI). No workflow changes needed, just configuration.
Caveats
- The per-arch digests must remain reachable long enough for downstream pulls of the manifest list to resolve blobs. Same-registry manifest lists share blobs by digest, so they will still resolve as long as the blobs themselves exist — but be conservative on the retention window.
- Don't run cleanup against the final tagged repos (`docker.io/sumguy/...`, `ghcr.io/kingpin/php-docker` for tagged images, `quay.io/...`).
Acceptance
- Untagged digest references on `ghcr.io/kingpin/php-docker` (staging) are bounded — either by an automatic prune or a documented retention policy.
- Verify a fresh `docker pull ghcr.io/kingpin/php-docker:` still works after a prune cycle.
Original Copilot review comments: #37 (two duplicate threads, on the push step and the staging output line).
Context
PR #37 changed the publish pipeline so each per-arch build pushes to a GHCR staging repo (`ghcr.io/kingpin/php-docker`) by digest, and a separate `publish-merge` job assembles the final tagged manifests on Docker Hub, GHCR, and Quay using `docker buildx imagetools create`.
The staging pushes land as untagged digest references in the GHCR staging repo. They are referenced by the final manifest list, but the per-arch manifest entries themselves remain untagged forever. Over time these accumulate with every CI run and make the GHCR untagged-image view noisy. There is no built-in retention.
Options
Caveats
Acceptance
Original Copilot review comments: #37 (two duplicate threads, on the push step and the staging output line).