chore: Extract or delete the fleet's Docker CLI install step

ahmad commented

2026-09-08 05:44:30 +00:00

Owner

Context

The "Install the Docker CLI" step is duplicated across the fleet: every one of the twelve app repositories carries at least one docker-ce-cli install site in its workflows (the template's publish job), and ahmad/expiro/ahmad/larda carry four each — 16+ copies. Only the expiro/larda copies have the dead-suite sed guard (their #67/#69/#72 and #21), so the copies have already diverged once. The conventions forbid exactly this class of duplication.

The sequencing question this needs

amtronics/infrastructure-vps#420 (move the runner default image off bullseye) may land an image that ships the Docker CLI — in which case the fleet-wide fix is deleting these steps, not extracting them, and an extraction converted into twelve repos would be churn twice. The issue is parked on that answer:

If #420's image will include the CLI (or #420 lands soon): close this in favour of per-repo deletions afterwards.
If #420 is far off or its image stays CLI-less: extract the proven step into install-docker-cli here, convert consumers, and future changes (like the sed guard) happen once.

Scope (if extraction is chosen)

In: a composite action wrapping the proven install step (sed guard included); README row; consumers converted in their own repos as follow-ups.
Out: changing what gets installed; the runner image itself.

Acceptance criteria (if extraction is chosen)

Given a consumer using the action, when its job runs in the current default container, then the Docker CLI is available afterwards.
Given the fleet, when the census is re-run, then no workflow carries an inline copy.

### Context The "Install the Docker CLI" step is duplicated across the fleet: every one of the twelve app repositories carries at least one `docker-ce-cli` install site in its workflows (the template's publish job), and `ahmad/expiro`/`ahmad/larda` carry four each — 16+ copies. Only the expiro/larda copies have the dead-suite sed guard (their #67/#69/#72 and #21), so the copies have already diverged once. The conventions forbid exactly this class of duplication. ### The sequencing question this needs `amtronics/infrastructure-vps#420` (move the runner default image off bullseye) may land an image that ships the Docker CLI — in which case the fleet-wide fix is **deleting** these steps, not extracting them, and an extraction converted into twelve repos would be churn twice. The issue is parked on that answer: - If #420's image will include the CLI (or #420 lands soon): close this in favour of per-repo deletions afterwards. - If #420 is far off or its image stays CLI-less: extract the proven step into `install-docker-cli` here, convert consumers, and future changes (like the sed guard) happen once. ### Scope (if extraction is chosen) - In: a composite action wrapping the proven install step (sed guard included); README row; consumers converted in their own repos as follow-ups. - Out: changing what gets installed; the runner image itself. ### Acceptance criteria (if extraction is chosen) - [ ] Given a consumer using the action, when its job runs in the current default container, then the Docker CLI is available afterwards. - [ ] Given the fleet, when the census is re-run, then no workflow carries an inline copy.

ahmad added the

priority/P3

size/M

state/needs-refinement

type/chore

labels

2026-09-08 05:44:31 +00:00

ahmad commented

2026-09-08 09:32:56 +00:00

Author

Owner

Human decision recorded (2026-09-08): wait for infrastructure-vps#420's runner-image outcome — extraction first would risk churn twice. Stays parked on that issue; if the new image ships the CLI, this closes in favour of per-repo deletions.

ahmad commented

2026-09-08 20:03:35 +00:00

Author

Owner

The sequencing question is answered, so this is no longer parked and can be picked up.

amtronics/infrastructure-vps#420 landed today: the runner's default job image is node:22-bookworm, converged on the host and verified — the runner re-declared the four labels at start, and apt-get update succeeds in the image, which is what was dead on bullseye.

I checked what the new image actually ships, since that was the whole question here:

docker run --rm node:22-bookworm
  command -v docker  -> NO_DOCKER_CLI
  command -v jq      -> NO_JQ
  command -v curl    -> /usr/bin/curl
  git --version      -> 2.39.5

No Docker CLI. So the answer is the second branch: extract the proven install step into a composite action here and convert the consumers. Deleting the steps is not an option — nothing in the default image provides docker.

Two things that follow, and neither needs a decision from anyone:

The dead-suite sed guard that expiro and larda carry can be dropped in the extracted version. It existed because bullseye's security suite stopped serving; bookworm's does not. Keep the extraction faithful otherwise.
curl is present but jq is not, which is why openbao-fetch installs both on demand. That install now works again, but it is the same duplication smell in a second place — see the issue I am opening about the notify path being a hard failure.

Moving to state/ready.

The sequencing question is answered, so this is no longer parked and can be picked up. `amtronics/infrastructure-vps#420` landed today: the runner's default job image is `node:22-bookworm`, converged on the host and verified — the runner re-declared the four labels at start, and `apt-get update` succeeds in the image, which is what was dead on bullseye. I checked what the new image actually ships, since that was the whole question here: ``` docker run --rm node:22-bookworm command -v docker -> NO_DOCKER_CLI command -v jq -> NO_JQ command -v curl -> /usr/bin/curl git --version -> 2.39.5 ``` **No Docker CLI.** So the answer is the second branch: extract the proven install step into a composite action here and convert the consumers. Deleting the steps is not an option — nothing in the default image provides `docker`. Two things that follow, and neither needs a decision from anyone: - The dead-suite `sed` guard that expiro and larda carry can be dropped in the extracted version. It existed because bullseye's security suite stopped serving; bookworm's does not. Keep the extraction faithful otherwise. - `curl` is present but `jq` is not, which is why `openbao-fetch` installs both on demand. That install now works again, but it is the same duplication smell in a second place — see the issue I am opening about the notify path being a hard failure. Moving to `state/ready`.

ahmad referenced this issue

2026-09-08 20:03:54 +00:00

fix: A failed notification must not fail the release #65

ahmad added

state/ready

and removed

state/needs-refinement

labels

2026-09-08 20:04:03 +00:00

ahmad referenced this issue

2026-09-08 20:41:29 +00:00

fix: Parallel image pushes race on shared layers and fail the release #66