Skip to content

Layer 2 assumes an ambient pip, so runner: self-hosted fails on a clean Linux box #145

Open

Description

@maximalcode

What happened

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.

Why it happens

The step tries, in order:

python3 -c 'import yaml' \
  || python3 -m pip install --quiet 'pyyaml==6.0.3' \
  || python3 -m pip install --quiet --break-system-packages 'pyyaml==6.0.3'

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

  1. 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.
  2. 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.
  3. 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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions