Skip to content

ci: inline the ghcr prune instead of delete-package-versions - #56

Merged
eetu merged 1 commit into
mainfrom
ci/inline-ghcr-prune
Sep 3, 2026
Merged

eetu merged 1 commit into
mainfrom
ci/inline-ghcr-prune

Conversation

@eetu

@eetu eetu commented Sep 3, 2026

Copy link
Copy Markdown
Owner

actions/delete-package-versions is unmaintained. Last release v5.0.0, January 2024; the default branch still declares using: 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 pin e5bc658 already is v5.0.0, and so is the floating v5 tag.

Replaced with a gh api step doing the identical job: keep the 5 newest untagged container versions, delete older untagged ones. That matches min-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 release
  • a 50-version cap, so a surprising API response can't turn into a mass delete
  • individual delete failures warn instead of aborting the loop
  • only versions with zero tags are ever selected

Verification

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 now
  • KEEP=1 → selects precisely the four older untagged versions, leaving 1.0.8/latest/1/1.0, main and 1.0.7 untouched

The one thing that can't be verified until this runs for real is whether GITHUB_TOKEN is accepted on DELETE /users/{owner}/packages/container/{pkg}/versions/{id}. If it isn't, the step logs warn: could not delete <id> and the build still passes — worth a glance at the first run's log after merge.

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.
@eetu
eetu merged commit a05d627 into main Sep 3, 2026
6 checks passed
@eetu
eetu deleted the ci/inline-ghcr-prune branch September 3, 2026 10:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant