ci: inline the ghcr prune instead of delete-package-versions - #56
Merged
Merged
Conversation
actions/delete-package-versions is unmaintained — last release v5.0.0 in January 2024, default branch still `using: node20`, which the runners now force onto node24 with a deprecation warning on every tag build. Two community PRs to move it to node24 (#236, #241) sit unmerged upstream, so there is nothing to bump to: our SHA pin already IS v5.0.0. Replaced with a `gh api` step doing the same thing: keep the 5 newest UNTAGGED container versions, delete older untagged ones. Same semantics as `min-versions-to-keep: 5` + `delete-only-untagged-versions: true`, where the count applies to the untagged subset only. Also drops a third-party action from the job that publishes the deployed image. Safety: `continue-on-error` (pruning must never fail a release), a 50-version cap so an unexpected API response can't become a mass delete, per-delete failures warn rather than abort, and only versions with zero tags are ever candidates. Verified by running the step's exact script read-only against the live package with the delete neutered: at KEEP=5 it selects nothing (there are exactly 5 untagged right now), and at KEEP=1 it selects precisely the four older untagged versions, leaving 1.0.8/latest/1/1.0, main and 1.0.7 alone.
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
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.
actions/delete-package-versionsis unmaintained. Last release v5.0.0, January 2024; the default branch still declaresusing: node20, which the runners now force onto node24 with a deprecation warning on every tag build. Community PRs to fix it (#236, #241) sit unmerged, so there is nothing to bump to — our SHA pine5bc658already is v5.0.0, and so is the floatingv5tag.Replaced with a
gh apistep doing the identical job: keep the 5 newest untagged container versions, delete older untagged ones. That matchesmin-versions-to-keep: 5+delete-only-untagged-versions: true, where the retention count applies to the untagged subset only — tagged versions are never candidates.Side benefit: one fewer third-party action in the job that publishes the deployed image.
Safety
continue-on-error— pruning is housekeeping and must never fail a releaseVerification
Ran the step's exact script (extracted from the YAML) read-only against the live package with the delete call neutered:
KEEP=5→ selects nothing, correct: there are exactly 5 untagged versions right nowKEEP=1→ selects precisely the four older untagged versions, leaving1.0.8/latest/1/1.0,mainand1.0.7untouchedThe one thing that can't be verified until this runs for real is whether
GITHUB_TOKENis accepted onDELETE /users/{owner}/packages/container/{pkg}/versions/{id}. If it isn't, the step logswarn: could not delete <id>and the build still passes — worth a glance at the first run's log after merge.