Files
command-center/agent/managed-skills/docker-pin-latest-census/SKILL.md
T
Frank 8af40c402b chore(agent): commit the machine tier and the doctrine text the checkout was already running
Landing blocker for #61 and #63: the deployment checkout is 12 commits behind and
`merge --ff-only` refuses while tracked paths are dirty. Discard is not available here
(workspace policy: no `checkout`/`stash` on shared state), so the dirt is committed.

- `agent/APPEND_SYSTEM.md`: the point-of-use / one-work-log / PR-link doctrine, already
  byte-identical to `origin/main` (`cmp` against the trunk blob: no difference). No new
  prose — the commit exists so the trunk merge can proceed.
- `agent/config.yml` and `agent/managed-skills/**`: the machine-live tier the heartbeat
  owns (AGENTS.md § Live-sync tiers).

`ALLOW_SECRETS=1` was used, deliberately and after auditing the staged diff by hand: the
only credential-shaped strings in it are two copies of `AKIA0000000000000EXAMPLE` — the
inert all-zero AWS example id — and they appear inside the two skill pages that teach
that exact placeholder shape. This checkout is still running the pre-#61 hook; the merged
gate (value-scoped placeholder filter, `71601f7`) exempts this value, so the refusal
dies with this landing. No `--no-verify` was used: the gate ran and its verdict is
recorded here.

Refs #61
2026-10-21 01:44:51 -07:00

2.8 KiB

name, description
name description
docker-pin-latest-census Prove a Docker Hub / lscr.io image pin is the latest version before bumping it: registry-API tag census plus digest-equals-latest verification, no docker CLI needed.

Is my pinned image actually the latest?

Use when bumping a pinned container image tag (e.g. lscr.io/linuxserver/* quadlet Image= lines) and "latest" must be PROVEN, not assumed. Works from any box with curl — no podman/docker daemon required. lscr.io fronts Docker Hub; its tags are NOT on quay.io (querying quay returns nothing and reads like "no newer tags exist" — false).

1. Full tag census via the registry API

tok=$(curl -s "https://auth.docker.io/token?service=registry.docker.io&scope=repository:<owner>/<repo>:pull" \
      | python3 -c "import json,sys;print(json.load(sys.stdin)['token'])")
curl -s "https://registry-1.docker.io/v2/<owner>/<repo>/tags/list?n=2000" \
      -H "Authorization: Bearer $tok" | python3 - <<'PY'
import json,sys,re
tags=json.load(sys.stdin).get('tags') or []
# linuxserver form: <version>-<sha>-ls<N>; group by version, keep newest ls per version
v={}
for t in tags:
    m=re.match(r'^(\d+(?:\.\d+)+)-([0-9a-f]+)-ls(\d+)$',t)
    if m: v.setdefault(tuple(map(int,m.group(1).split('.'))),[]).append((int(m.group(3)),t))
for k in sorted(v)[-5:]:
    print('.'.join(map(str,k)),'-> newest:',max(v[k])[1])   # max on (ls#, tag) tuple
PY
  • Sort versions as tuples of ints, never strings (1.4.10 < 1.4.9 lexicographically).
  • Keep the max ls build per version, then the newest version — both can lag independently.
  • Trap already eaten: joining the tuple key to a string mid-loop then re-looking-it-up → KeyError. Keep keys as tuples; format only when printing.
  • Some channels have NO latest tag in /tags/list (or the endpoint truncates) — absence there is not evidence.

2. Digest-proof the candidate against latest

for t in latest <candidate-tag>; do
  curl -sI "https://registry-1.docker.io/v2/<owner>/<repo>/manifests/$t" \
    -H "Authorization: Bearer $tok" \
    -H "Accept: application/vnd.oci.image.index.v1+json,application/vnd.docker.distribution.manifest.list.v2+json,application/vnd.docker.distribution.manifest.v2+json" \
    | grep -i '^docker-content-digest'
done

Equal digests ⇒ the pinned tag IS what latest serves right now — the strongest "ensure latest" evidence, and recordable in the endpoint page's pin note (the dank-fleet law: pinned; verified == the registry's latest manifest digest at pin time). A multi-arch index digest matches only if both requests send the same Accept set — send all three types above.

3. Bump through git, not by hand

Edit the quadlet/unit Image= line + the vault page's pin row (one owner each), run the repo suite, PR, deploy --service <svc> only. Rollback stays "revert one line".