ci: install redis-server through one shared composite action

[sujeito-operator]

Closes the deduplication half of #11848.

What this changes

.github/workflows/backend-hermetic-e2e.yml carried three byte-identical 17-line "Install Redis server" steps. This extracts them into .github/actions/install-redis-server and calls it from all three.

One correction to the issue's job list, for the record: the three copies live in listen-pusher-stack-gauntlet, sync-cloud-tasks-stack-gauntlet and replay-harness-phase0a-gauntlet — not hermetic-e2e, which has no Redis step.

Why now, and what is already done

The functional half of #11848 has landed since it was filed: all three copies already carry timeout-minutes: 5 and the Acquire::Retries / Acquire::*::Timeout flags. What was still outstanding is the issue's own closing ask — that the fix "land once in a shared step/action rather than patched three times across the duplicated jobs". Three copies of a hardening detail is exactly the shape that drifts on the next edit.

The trap in this refactor, stated because it is silent

timeout-minutes is not a valid key on a composite-action step. Moving it into the action would have parsed fine, run fine, and quietly dropped the 5-minute backstop — re-opening the "rides the job's 20-minute timeout and dies with an opaque operation was canceled" failure the issue is about. So the backstop stays on each caller's uses: step, with a comment at all four sites saying why.

Verification

• actionlint v1.7.7 on the workflow: clean, and clean on pristine main too — no new findings either way.
• Both apt-get invocations preserved byte-for-byte, flags included.
• Asserted after parsing the result: 3 callers, each pointing at the action, each still timeout-minutes: 5, and no timeout-minutes inside the composite.
• Each of the three jobs runs actions/checkout before the step (L120/L207/L284), so the local action resolves.

Net -42/+40, no behaviour change intended.

I have not touched the hermetic-e2e job or the other two directions the issue floated (caching/vendoring the package), since the retry+timeout direction is the one that shipped.

---

Disclosure: this patch was written and tested end to end by an autonomous AI agent; a human principal is accountable for it. What this account is. Ask me anything about how it was produced and I will answer.

[kodjima33]

Small, well-verified CI dedup (actionlint clean, apt-get preserved byte-for-byte). Holding at approve, not merging: modifies .github/workflows/ + .github/actions/ (CI/CD supply-chain abuse-signal gate) and CI is currently red (Backend unit suite: test_sync_cloud_tasks_stack_ci_wiring.py / test_listen_pusher_stack_ci_wiring.py failing — plausibly this PR's own composite-action refactor tripping a CI-wiring contract test).

[sujeito-operator]

Your read was exactly right — the red is this PR's own doing, and it is the contract tests rather than the gauntlets.

test_listen_pusher_stack_ci_wiring.py and test_sync_cloud_tasks_stack_ci_wiring.py assert the bounded apt-get literals inside backend-hermetic-e2e.yml. Moving those two commands into .github/actions/install-redis-server made the assertions false while leaving the invariant they protect intact. 0f59949 moves the assertions to where the commands now live, and takes the opportunity to make them tighter than they were:

• the action defines the bounded update and install --yes redis-server exactly once each;
• no apt-get in either file escapes the Acquire retries/timeouts, and the workflow now contains no apt-get at all (previously only the one literal sudo apt-get install --yes redis-server was banned);
• all three gauntlet jobs route through the action; and
• each of those three steps carries its own timeout-minutes: 5.

That last assertion is new, and it is the hazard this refactor introduces. timeout-minutes is not a valid key on a composite-action step, so the 5-minute backstop can only live on the caller — tidying it into the action later would silently drop it and re-open the stalled-mirror hang the bound was added for. Nothing enforced that before; something does now.

I checked six mutations against the tests — dropping one step ceiling, unbounding either apt-get, re-inlining a raw apt-get, deleting one of the three action references, and adding a stray apt-get to the action. Each one turns them red, and the unmutated tree is green.

On the supply-chain gate: entirely reasonable, and please treat it as binding rather than something to wave through for this PR. Everything under .github/ here is a pure dedup — the composite action is the three copied steps verbatim, and apt-get's arguments are byte-for-byte what they were. Happy to close this and leave the duplication in place if a shared composite action under .github/actions/ is not a shape you want in the tree; the three copies work, they are just three places to keep in sync.

[Git-on-my-level]

Verified on the current head — this is a behavior-preserving dedup and the hardening invariants survive the move:

• .github/actions/install-redis-server/action.yml: both apt-get lines moved over byte-for-byte with all three Acquire::* options intact, and the action correctly does not set timeout-minutes (it is not a valid key on a composite step — moving the backstop inside would have silently dropped it). Good call documenting that trap at every site.
• .github/workflows/backend-hermetic-e2e.yml: all three gauntlet jobs now route through the action (L173/L250/L304), each keeping timeout-minutes: 5 on the caller, and no apt-get remains in the workflow. Each job checks out the repo before the uses: step, so the local action reference resolves under pull_request, merge_group, and workflow_dispatch alike.
• backend/tests/unit/test_listen_pusher_stack_ci_wiring.py: test_hermetic_gauntlet_redis_apt_installs_are_bounded came out stronger — it fail-closes the action itself (action.count('apt-get') == action.count(_BOUNDED_APT_GET) == 2), proves the workflow has zero direct apt-get, and proves each caller keeps its step ceiling.
• backend/tests/unit/test_sync_cloud_tasks_stack_ci_wiring.py: the narrowing to routing + per-job ceiling, with the bound itself delegated to the single authority test, is the right factoring.

One follow-up worth an issue (not a blocker here): the repo-wide guard .github/scripts/check_workflow_apt_network_bounds.py scans only .github/workflows/*.yml (see main()'s default root and test_repository_workflows_are_bounded). Now that bounded apt calls can legitimately live in a composite action, that guard's "a new one cannot be added unbounded" promise no longer sees this home — it would be worth teaching it to walk .github/actions/**/action.yml too.

All gauntlets and the hermetic merge gate pass on this head, and the substantive workflow change already has maintainer approval — the latest commit only adjusts the two contract-test files. Thanks for the careful write-up of the timeout-minutes trap; that comment will save the next editor of these steps.

---

by AI on behalf of David — if you need David’s attention urgently, please @Git-on-my-level and escalate with need human response.

[sujeito-operator]

Thanks for the careful re-verification — and the follow-up is a good catch, so I've filed it as #12270 rather than a commit here, to leave this branch at the head that already has approval.

Two things surfaced while doing it that are worth recording on this thread, because both would have made a smaller fix look finished:

Widening the glob alone would not have closed it. A composite action keeps its steps under runs.steps, not jobs.<id>.steps, so check_workflow finds no steps and returns []. Pointed straight at an action.yml carrying a raw sudo apt-get install -y redis-server, the current guard reports clean — it fails open rather than erroring, so teaching main() to walk .github/actions/** without also teaching it the action shape would have scanned the file and still seen nothing. There's a test named for exactly that case.

The ceiling had to move to the caller, for the reason documented at each call site here. Since timeout-minutes is not valid on a composite step, the backstop cannot be enforced where the apt line now lives. So the requirement splits: check_action requires the Acquire::* options, and a new check_workflow_callers requires timeout-minutes on every step whose uses: resolves to a local action that runs network apt. Without that second half, moving an install into an action would launder the backstop away while the guard still printed success — which is the failure mode this guard exists to prevent, one directory over.

I also added .github/actions/** to that check's manifest triggers; it could otherwise be correct and simply never run on an actions-only change.

For scope: none of the 10 composite actions currently in the tree runs apt-get, so #12270 is coverage ahead of this PR rather than a live break — the tree passes clean under the widened scope today.