Repository navigation
fix(publish-bake): a python with venv + pip, so the self-hosted lane can publish - #4583
Merged
Merged
Conversation
…can publish publish-bake-bundles.sh builds a venv and installs its pinned Azure SDKs into it — deliberately, so a satellite whose ref is newer than its pin cannot end up running a script whose dependency nobody installed. The ARC runner image ships python3 3.12 WITHOUT ensurepip/venv, so from the moment every private repo moved to the self-hosted sets (2026-09-17) the publish step died with The virtual environment was not created successfully because ensurepip is not available. ... apt install python3.12-venv and no satellite could publish: MeshWeaver.Crm run 35199593887 and MeshWeaver.Manufacturing run 35205340142 failed there with every other job in the run green — a delivery outage that only shows up on a run that actually has something to bake, which is why the migration's own proofs did not catch it. `actions/setup-python` brings an interpreter WITH pip on any runner, so the script's venv works hosted or self-hosted; on a hosted runner the tool cache already carries it. The durable fix is to bake python3-venv into the runner image, and the comment says to delete this step when that lands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
🟢 Approval recommended
The workflow change addresses the self-hosted runner dependency issue without unresolved blocking concerns.
Pull request overview
Updates the reusable publish-bake workflow to provision Python 3.12 with venv and pip on self-hosted runners before publishing bundles.
Changes:
- Adds
actions/setup-python@v7. - Runs setup only when publication is required.
- Preserves pinned Azure SDK validation.
File summaries
| File | Description |
|---|---|
.github/workflows/node-repo-publish-bake.yml |
Provisions Python for the publish script. |
Review details
- Files reviewed: 1/1 changed files
- Comments generated: 0
- Review effort level: Lite
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
Contributor
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The outage
publish-bake-bundles.shbuilds a venv and pip-installs its pinned Azure SDKs into it — on purpose, so a satellite whose ref is newer than its pin cannot run a script whose dependency nobody installed (see the script's own header).The ARC runner image ships
python33.12 withoutensurepip/venv. So from the moment every private repo's jobs moved toaks-silos*this morning, the publish step died with:No satellite could publish. Evidence — the publish job failed while every other job in the same run was green:
publish-bake / Bake + publish NodeType assemblies to portal storagepublish-bakeisskippedwhenever a run has nothing to bake, which is why the migration's own proofs did not catch this: it only fires on a run that actually publishes.The fix
actions/setup-pythonbrings its own interpreter with pip on any runner — hosted or ours — so the script's venv works everywhere. On a hosted runner the tool cache already carries it, so it costs nothing there. Notsudo apt-get install python3-venv: that needs root and the archive, and would be the only thing standing between the fleet and a failed publication.The durable fix is baking
python3-venvinto the runner image (Systemorph/Memexdeployments/aks/ci-runners/runner-image/Dockerfile); the step's comment says to delete it when that lands. The script asserts its own pins afterwards (sdk-check), so a wrong interpreter is red here rather than a later "unreadable".Checks
check-workflow-yaml-keys,check-workflow-timeouts,check-reusable-workflow-runnersandcheck-workflow-shellall pass--self-testand clean over the edited tree.🤖 Generated with Claude Code