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]>
42 lines
2.1 KiB
Markdown
42 lines
2.1 KiB
Markdown
---
|
|
date: 2026-10-31
|
|
branch: chore/pm-agent-digest-99
|
|
title: Pin pm-agent dispatcher and worker to the agent-runner digest built from PR #99's merge
|
|
---
|
|
|
|
## 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.
|