c4eba5b (run 340) bakes a worker template without imagePullSecrets, so the new admission rule refuses worker Jobs. df36d9b is agent-runner:main == :sha-ddd04d460ef6 (measured on the registry), and its /etc/pm-agent/worker-job-template.yaml carries imagePullSecrets: pm-agent-registry (read from the published layer). Renovate found df36d9b but holds it under "Awaiting Schedule" on dashboard #91: the operator's dispatch (run 385) was a real run at 12:14 New York, outside the 03:00-06:00 window. The renovate-digest markers are unchanged, so later bumps remain Renovate's. Co-Authored-By: Claude Opus 5.5 <[email protected]>
4.2 KiB
date, branch, title
| date | branch | title |
|---|---|---|
| 2026-10-31 | chore/pm-agent-runner-digest | Bump pm-agent to the run-383 agent-runner digest by hand; Renovate saw it but the schedule withheld it |
What changed
platform/pm-agent/deployment.yaml (the dispatcher image:) and platform/pm-agent/configmap.yaml
(PM_WORKER_IMAGE) move:
- from
agent-runner@sha256:c4eba5b3c508bf456a03391ac76f8275e7ea28a829da1450d99f6f6f25c6eb42, the run-340 publish; - to
agent-runner@sha256:df36d9b7fef56d141220a387f64fb864cede8e5af30513ebfeb3ab566d3f771d, the images run 383 publish ofddd04d4.
Both # renovate-digest: markers are unchanged, directly above their values.
pm-agent.homelab.keithjackson.dev/config-generation goes "2" → "3". That is the convention in
deployment.yaml's own comment: "bump it in the same commit as a change to configmap.yaml". The
image change alone would roll the pod, but the convention is followed regardless.
No *.sops.yaml file is touched. Branched from 06d4a9a, which already contains the operator's #95.
Why Renovate did not do this: the schedule, not a config defect
- Run 385 (dispatch, 2026-10-31 16:14 UTC, on
ddd04d4) was a real run. It loggedDeleting orphan branch (… renovate/pin-dependencies), not aDRY-RUN:line. It ran at 12:14 America/New_York, outside"schedule": ["after 3am and before 6am"], so it created and updated no branch. - The lookup DID see the new digest. Dependency Dashboard issue #91 lists, under "Awaiting
Schedule":
chore(deps): Update gitea.home.keithjackson.dev/home-network/agent-runner:main Docker digest to df36d9b. - Nothing else blocked it. There are no open Renovate PRs and no
renovate/*branch on Gitea (111 branches listed across all pages). The previous agent-runner PR, #90 (to c4eba5b), was auto-merged by renovate-bot at 08:22 on 10-31. No PR limit was hit, and digests are not dashboard-approval gated. - The registry, read-only, with Docker/OCI
Acceptheaders:HEAD …/agent-runner/manifests/main→docker-content-digest: sha256:df36d9b7…771dHEAD …/agent-runner/manifests/sha-ddd04d460ef6→ the same digest.
Without this PR the next scheduled run (08:15 UTC, 04:15 EDT) would open it, and it would
auto-merge as a digest update. Ticking that "Awaiting Schedule" checkbox on #91 makes the next
run of any kind create it out of schedule.
Found on the way: Renovate's labels have never been applied
- The repo has exactly one label,
agent. The org has none. - Every Renovate PR so far (#89, #90, #92, #93) was created with
"labels": []. - On Gitea, Renovate drops a label that does not exist in the repo. So
needs-review,blast-radius,range-widen,own-image,dependencies,automated-update,breakingandci-toolingare never attached. - The automerge flags still work. Only the labels, the visible review signal, are missing.
- Operator fix: create those labels on the repo. This was not changed here.
What I verified
-
The new image carries the fix. I fetched both images' layers read-only from the registry and read
/etc/pm-agent/worker-job-template.yamlfrom each (infra/agent/Containerfile:116copies it there):- df36d9b's has
imagePullSecrets:/- name: pm-agent-registry; - c4eba5b's has no
imagePullSecretsat all.
This matches
infra/agent/worker-job-template.yaml:76-77atddd04d4. - df36d9b's has
-
main=sha-ddd04d460ef6= df36d9b, both measured. -
No other file references c4eba5b. No admission policy pins it.
-
No override is needed.
infra/gitea/approval-policy.jsonlists onlyplatform/kyverno/**underplatform/, soplatform/pm-agent/**is not sensitive. -
I read the whole job logs of runs 362, 367 and 385.
What I did NOT verify
- That the rolled dispatcher starts on df36d9b and that a worker Job is admitted. That needs Flux to apply this and a real dispatch. Both are operator actions.
- That the
pm-agent-registrySecret exists and decrypts in-cluster (#95's sops file). I did not read it. - That Renovate will treat this hand bump as current. It should: its next lookup finds
main== the pinned digest, so it proposes nothing and drops the dashboard entry. Not observed.