Skip to content

policy: establish one canonical GHCR retention and pruning implementation #8

Description

@thedancingdeveloper

Objective

Create one organization-wide GHCR retention policy and one implementation for all container packages owned by TheDancingDeveloper-org.

Repository-specific issues must not define different retention numbers or cleanup algorithms. They should consume this policy and report package-specific exceptions only when explicitly approved.

Canonical target policy

1. What is retained

For every package:

  • Keep every supported release tag (vMAJOR.MINOR.PATCH, plus any documented stable channel such as latest).
  • Keep the currently deployed immutable digest and the previous 10 deployed/released revisions for rollback.
  • Keep the newest 10 revisions per active non-release channel (dev, beta, feat, feat-slim, or equivalent).
  • Keep signatures, attestations, SBOMs, provenance, platform manifests, and child manifests required by any retained image index.
  • Keep explicitly configured base-image pins and the immediately previous pin for rollback.
  • Keep paired package revisions together where a deployment consumes multiple images (for example gateway/web, API/web, or gateway/external-probe).

2. What is removed

  • Untagged or unreachable manifests older than 7 days.
  • Superseded non-release channel revisions outside the newest-10 window.
  • Stale feature-branch images after the branch is deleted, outside the rollback window.
  • Orphaned signatures, attestations, SBOMs, and platform manifests whose subject/index is no longer retained.
  • Migration-canary and smoke-test artifacts after they are no longer referenced and have passed the 7-day grace period.

Nothing is deleted solely because it is untagged: the implementation must first resolve the OCI manifest/index/signature dependency graph.

3. Exceptions

Exceptions must be declared centrally in a machine-readable allowlist with:

  • package name;
  • tag or digest pattern;
  • reason;
  • owner;
  • expiry date.

Exceptions expire after 90 days unless renewed. No repository workflow may silently expand retention.

4. Execution model

Implement this in github-policy as:

  • one canonical retention configuration;
  • one reusable cleanup workflow or one centrally scheduled org workflow;
  • a dry-run mode that produces a per-package deletion plan;
  • a scheduled dry-run report;
  • an explicitly gated apply mode;
  • audit logging of actor, timestamp, package, version ID, digest, reason, and result.

The first apply run should require review of the generated dry-run report. Subsequent runs may be scheduled automatically once the policy has been validated.

5. Target outcome

After the initial cleanup:

  • stable release history remains intact;
  • each active development channel has at most 10 retained revisions;
  • each package retains no more than 10 recent rollback revisions beyond those required by stable tags;
  • untagged storage is limited to the 7-day grace period plus dependency-linked artifacts;
  • paired images are pruned consistently;
  • all repositories use the same retention algorithm and exception file.

The implementation must report before/after version counts and estimated storage reclaimed per package.

Scope

The first rollout covers:

  • rustnzbd
  • indexarr-rs
  • rusttorrent
  • egressy
  • egressy-external-probe
  • ngms
  • aidevenv
  • rdpapp-gateway
  • rdpapp-web
  • ausfarms-api
  • ausfarms-web
  • paddockmuster-site
  • vogt
  • vogt-stack
  • vogt-base/node
  • vogt-base/python
  • vogt-base/rust
  • vogt-base/ubuntu
  • vogt-pod-base
  • vogt-demo

Related repository issues:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions