Files
home-network-k3s-impl/decisions/2026-10-31-pm-agent-digest-99.md
jakman85andClaude Opus 5.5 19097e4d4f
gate / gate (pull_request) Successful in 2m57s
gate / conformance (pull_request) Has been skipped
chore(pm-agent): pin agent-runner to the run-394 digest (466f63e, PR #99), bump config-generation
Dispatcher image and PM_WORKER_IMAGE both move to
sha256:14a42ba8281ecd98005f5d99ecda4fb729104c783b01584097c32e104ced1bb2, the digest the
registry returns for agent-runner:sha-466f63ec3c3d and :main. config-generation 4 -> 5.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-31 12:17:00 -05:00

2.1 KiB

date, branch, title
date branch title
2026-10-31 chore/pm-agent-digest-99 Pin pm-agent dispatcher and worker to the agent-runner digest built from PR

What changed

  • platform/pm-agent/deployment.yaml: the dispatcher image: moves from agent-runner@sha256:df36d9b7… (images run 383) to agent-runner@sha256:14a42ba8281ecd98005f5d99ecda4fb729104c783b01584097c32e104ced1bb2. config-generation goes from "4" to "5" so the pod rolls.
  • platform/pm-agent/configmap.yaml: PM_WORKER_IMAGE gets the same digest. A comment line records where it came from. The # renovate-digest: marker still sits directly above both values.
  • No other values changed. PM_DRY_RUN stays "false". PM_DECISION_MAX_TURNS is not set, so it keeps its in-code default of 1. No *.sops.yaml was touched.

What I verified

  • PR #99's merge commit is 466f63ec3c3df968a1dab25a8811dcd41961efde (origin/main HEAD at branch time).
  • The Gitea Actions tasks API shows the images workflow (images.yaml) on that commit as run 394 (task 643), with event push and status success.
  • I resolved the digest read-only from the registry by HEADing the manifests with OCI and Docker Accept headers. Both agent-runner:sha-466f63ec3c3d and agent-runner:main returned 200, an application/vnd.oci.image.manifest.v1+json content type, and docker-content-digest: sha256:14a42ba8281ecd98005f5d99ecda4fb729104c783b01584097c32e104ced1bb2. The two are identical.
  • Toolbox gate: the rc and skipped stages are in the PR description.

What I did NOT verify

  • That the dispatcher actually rolls to the new digest after merge, and that Flux applies it. Flux's lastAppliedRevision and the pod's image were not checked. That is post-merge work.
  • That the new image surfaces the triage failure's real cause. It will show only on the next failing triage, in the dispatcher log.
  • That admission (rule 7, imagePullSecrets) admits worker Jobs from this digest. The template comes from infra/agent/ at PR #99's merge, which still carries the imagePullSecrets entry, but no Job was created to prove it.
  • I did not run the image's own selftest against this digest.