You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Layer 2 assumes an ambient pip, so runner: self-hosted fails on a clean Linux box #145
maxigame switched CI on with runner: self-hosted, pointing at the org's Hetzner runners
(Debian, Linux/X64, registered at org level). The layer2 job died in Install pinned tools:
/usr/bin/python3: No module named pip
detect on the same box was fine, so this is Layer 2's bootstrap specifically.
and then bootstraps pipx for semgrep the same way. Its own comment says "PyYAML is already
present on the standard runner images" — true of ubuntu-latest, not of a self-hosted box. Debian's
minimal python3 ships neither pip nor PyYAML, so all three branches fail and the job stops
before installing anything.
Why it is worth fixing here rather than in each consumer
The runner input exists precisely so a private repo that runs out of hosted minutes keeps its gate
("when the quota runs out an ubuntu-latest job does not run slowly — it does not start at all, and
the gate goes dark"). A self-hosted box is the least likely place to have an ambient pip, so the one
input that points at self-hosted hardware is the one that walks into this.
It is also close to the failure this repo already learned from — maxi-editor#85, where semgrep's
installer assumed an ambient python with pip and the gate went red on every PR while scanning
nothing. Same assumption, one layer up. Here it failed loudly, which is the good version.
Suggestions
Bootstrap pip rather than assuming it — python3 -m ensurepip --upgrade before the pip calls
covers a stock Debian/Ubuntu python3 without needing root or apt.
Or fail with the fix in the message. If an ambient pip is a documented requirement of runner:, the error should say apt install python3-pip python3-yaml rather than surfacing
Python's own line — a consumer reading "No module named pip" inside a security scan has to go
and find this workflow's source to learn what it wanted.
Either way, worth stating the self-hosted prerequisites next to the runner input, the way the
platform table already states the supported OS/arch.
Workaround in the consumer meanwhile
maxigame moved its security job back to ubuntu-latest and left a comment naming the apt line
that flips it back, so it is a one-line change once this lands.
Activity