Skip to content

fix(publish-bake): a python with venv + pip, so the self-hosted lane can publish #4583

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
rbuergi merged 1 commit into from
Sep 17, 2026
Merged

fix(publish-bake): a python with venv + pip, so the self-hosted lane can publish #4583

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 21 additions & 0 deletions .github/workflows/node-repo-publish-bake.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1780,6 +1780,27 @@ jobs:
"$BAKE_CARRY_TARGET"
"${{ steps.identity.outputs.identity }}"
"${{ inputs.bake-source }}"
# 🚨 A PYTHON WITH `venv` + `pip`, because publish-bake-bundles.sh builds its own venv and
# installs its PINNED Azure SDKs into it (the script owns that install on purpose — see its
# header: a workflow-side install would leave a satellite whose ref is newer than its pin
# running a script whose dependency nobody installed). The self-hosted ARC image ships
# python3 3.12 WITHOUT ensurepip/venv, so from the moment every private repo's jobs moved to
# `aks-silos*` (2026-09-17) this 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 both failed here while every other job in the run was green. `setup-python`
# brings 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. Not `sudo apt-get install python3-venv`: that needs root and the archive, and would
# silently be the only thing standing between the fleet and a failed publication.
# Delete this step when the runner image bakes python3-venv (Systemorph/Memex
# deployments/aks/ci-runners/runner-image/Dockerfile) — the script asserts its own pins
# afterwards (`sdk-check`), so a wrong interpreter is RED here, never a later "unreadable".
- name: Python with venv + pip for the publish script
if: steps.scope.outputs.scope != 'none'
uses: actions/setup-python@v7
with:
python-version: "3.12"
- name: Publish bundles to every portal target
id: publish
if: steps.scope.outputs.scope != 'none'
Expand Down
Loading