Conversation
…kes venv now #4583 added `actions/setup-python` to this job on 2026-09-17 because the self-hosted ARC image shipped python3 WITHOUT ensurepip, so publish-bake-bundles.sh could not build the venv it installs its pinned Azure SDKs into — and every satellite's publish step went red with the rest of the run green (MeshWeaver.Crm 35199593887, Manufacturing 35205340142). Its own comment said to delete it once the image baked python3-venv. The image does: meshweaver-ci-runner 20260917-3c61f83 (Systemorph/Memex#396), rolled onto both scale sets, its build asserting `python3 -m venv: works as uid 1001, pip present inside the venv` and runner-proof*.yml asserting on a real runner that /usr/bin/python3 builds a venv whose pip installs THIS script's own SDK pins from PyPI. Both runners this job can land on are covered — the `ubuntu-latest` fallback always was: runner-images' install-python.sh does `apt-get install python3 python3-dev python3-pip python3-venv`. The requirement is stated where the step used to be rather than deleted silently, because the next person to see an ensurepip failure should find out here that it is the image's job, not this workflow's. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
🟡 Changes recommended
The workflow can still select runner images without verified venv support, risking publication failures.
Get a fresh assessment by requesting another Copilot review.
Pull request overview
Removes the interim Python setup step from the publish-bake workflow, relying on runner images to provide venv and pip.
Changes:
- Deletes
actions/setup-python. - Documents the runner-image prerequisite.
File summaries
| File | Description |
|---|---|
.github/workflows/node-repo-publish-bake.yml |
Removes Python environment provisioning before bundle publication. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 1
- Review effort level: Lite
💡 Configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| # It is gone because the image bakes `python3-venv` (Systemorph/Memex | ||
| # deployments/aks/ci-runners/runner-image/Dockerfile, meshweaver-ci-runner 20260917-3c61f83), | ||
| # and the `ubuntu-latest` fallback above has always had it (runner-images' | ||
| # install-python.sh: `apt-get install python3 python3-dev python3-pip python3-venv`). Both | ||
| # runners this job can land on therefore satisfy it — if a third ever appears, assert it |
There was a problem hiding this comment.
Verified REAL, and load-bearing. Fixed in 19093c0.
You are right on both halves of the mechanism. runs-on here is ${{ vars.MW_RUNNER_DOCKER || 'ubuntu-latest' }} — an ORG VARIABLE resolved from the CALLER at queue time — and check-reusable-workflow-runners.py validates only the expression SHAPE. Its own docstring says so: the rule is which operands may appear and that the last one is the 'ubuntu-latest' fallback. It cannot see which image a label selects, so a re-pointed scale set, a rolled-back runner image or a third label reaches this job with nothing red, and the run dies at publish-bake-bundles.sh:480 (python3 -m venv "$VENV") with its real cause several steps upstream. That is precisely the 2026-09-17 outage shape.
What I did NOT do is add an assertion that only fails earlier — that replaces the diagnosis, not the guarantee, and the publication would still be lost. The three steps that now stand where setup-python stood replace the guarantee itself:
- PROVE —
python3 -m venvis actually executed into$RUNNER_TEMPandbin/pipchecked. A CAPABILITY probe, deliberately not a version check:python3 --versionwas green on the runner that took the fleet down, becauseensurepipships as a separate package. - HEAL —
actions/setup-python@v7runs ONLY when the probe failed, with a::warning::naming$RUNNER_NAME, so the image defect is loud rather than hidden by a step that runs unconditionally. A correct runner pays a sub-second probe and no interpreter download, which was the point of the PR. - ASSERT — the healed interpreter is re-probed and the job fails RED with
::error::if it still cannot build a venv. This sits before the publish step, so nothing has been written and the existing publication stays sealed.
So all three of the cases you named are covered — stale image, private image, third label — and the requirement is asserted at the point of use instead of being documented in a comment. Gates run on the change: check-reusable-workflow-runners 0 violations over 24 jobs, check-workflow-shell 0 live findings, check-workflow-yaml-keys / -timeouts / -permission-pairing clean.
Copilot's review of #4594 is right and the point is load-bearing: dropping the unconditional `actions/setup-python` removed the only RUNTIME guarantee that `python3 -m venv` can succeed, and nothing else supplies one. `runs-on` here is `${{ vars.MW_RUNNER_DOCKER || 'ubuntu-latest' }}` — an ORG VARIABLE resolved from the caller at queue time — and check-reusable-workflow-runners.py validates only the EXPRESSION SHAPE (its own docstring: the rule is about which operands appear, never which image a label selects). So a re-pointed scale set, a rolled-back runner image or a third label reaches this job with nothing red, and the failure lands at publish-bake-bundles.sh's own `python3 -m venv` — which is exactly the 2026-09-17 fleet-wide publication outage (MeshWeaver.Crm run 35199593887, MeshWeaver.Manufacturing run 35205340142). An assertion that merely fails earlier would replace the DIAGNOSIS, not the guarantee, so this replaces the guarantee instead — three steps where the step used to be: 1. PROVE — actually create a venv on the interpreter this job will use. A CAPABILITY probe, never a version check: `python3 --version` was green on the runner that took the fleet down, because ensurepip ships separately. 2. HEAL — `actions/setup-python` ONLY when the probe failed, with a `::warning::` naming the runner, so the image defect is loud instead of hidden. A good runner pays a sub-second probe and no download. 3. ASSERT — re-probe the healed interpreter and fail RED before anything is written. Nothing has been published at that point, so the existing publication stays sealed. Gates: check-reusable-workflow-runners 0 violations (24 jobs), check-workflow-shell 0 live findings, check-workflow-yaml-keys / -timeouts / -permission-pairing clean. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Draft until the roll is proven. Do not merge on the reasoning below — merge it on the proof. A satellite that cannot publish is a delivery outage, which is exactly what #4583 was opened for this morning.
What this removes
#4583 added
actions/setup-pythontopublish-bakeon 2026-09-17 because the self-hosted ARC image shippedpython3withoutensurepip, sopublish-bake-bundles.shcould not build the venv it installs its pinned Azure SDKs into. Every satellite's publish step went red with the rest of the run green — MeshWeaver.Crm run 35199593887, MeshWeaver.Manufacturing run 35205340142. Its own comment says to delete it once the runner image bakespython3-venv.Why it is safe — both runners this job can land on
runs-on: ${{ vars.MW_RUNNER_DOCKER || 'ubuntu-latest' }}, so exactly two:python3 -m venvworksaks-silos-dind(every private repo)python3-venv. Its build asserts, as uid 1001:python3 -m venv: works as uid 1001, pip present inside the venv. Run against the pushed image itself, as uid 1001:/usr/bin/python3 -m venv→pip install azure-storage-file-share==12.26.0 azure-identity==1.25.3→ both import — this script's ownSDK_PINS, not a substituteubuntu-latest(fallback where the org variable is invisible)actions/runner-imagesimages/ubuntu/scripts/build/install-python.sh:apt-get install --no-install-recommends python3 python3-dev python3-pip python3-venvWhat it does NOT do
It does not delete the requirement — it states it where the step used to be. The next person to meet an
ensurepipfailure should learn there that this is the image's job, not this workflow's, rather than find a blank and re-add a step that hides the requirement.Merge condition
ci-runners-apply.ymlhas rolled@sha256:acdbefbc…onto both sets;/usr/bin/python3builds a venv whose pip installs these exact pins, on a real runner;Then mark ready. Until all three, the interim step stays: it costs ~0 s on a hosted runner and a few seconds on ours, which is nothing against a fleet that cannot deliver.
🤖 Generated with Claude Code