feat(pytest-matrix): let a caller choose its runner, defaulting to today's pool - #25
Closed
ywatanabe1989 wants to merge 1 commit into
Closed
feat(pytest-matrix): let a caller choose its runner, defaulting to today's pool#25ywatanabe1989 wants to merge 1 commit into
ywatanabe1989 wants to merge 1 commit into
Conversation
…day's pool Operator ruling 2026-07-31: GitHub-hosted runners are the DEFAULT CHOICE for new work. Most scitex repositories are public, so hosted minutes are free and the cost objection that justified blanket self-hosting mostly does not apply. Self-hosted stays for jobs where our own machines are genuinely faster -- long builds, GPU, large data -- chosen because it wins, not by policy. BACKWARD COMPATIBLE BY CONSTRUCTION. The new `runs_on` input defaults to '["self-hosted","Linux","X64","spartan-cpu"]', byte-identical to the value that was hardcoded, so all 28 callers keep exactly today's behaviour. Only a repo that passes the input moves. WHY A CALLER WANTS OUT TODAY. Every runner on the Spartan lease inherits one mutable ~/.runner-toolcache on GPFS, so runners contend for a single directory. Jobs fail BOTH reading it (`uv: No such file` -> exit 127) and writing it (ENOENT during copyfile INTO the cache) -- one bug seen from opposite ends. Measured on scitex-cards 2026-07-31: seven failures across five pull requests in one afternoon, four differently-named runners, every one cleared by a plain rerun. This workflow's own comments already describe the hazard, and #24 records that the per-runner fix "cannot fire". The durable fix is still a per-runner AGENT_TOOLSDIRECTORY in the supervisor. This input is not that fix; it is an escape hatch for callers that cannot absorb random reruns while that work is pending. THE FORK GUARD NEEDED A REAL FIX, NOT A TEST UPDATE. Parameterising `runs-on` made the guard's selector stop recognising this job: it matched the literal label "self-hosted", and an expression is not that string. The job silently left the guarded set, so the fork guard would have become unenforced AND untested in the same moment -- the suite would have stayed green while the protection disappeared. The tests caught it. _may_run_self_hosted now answers YES for an expression-valued `runs-on`, because such a job CAN resolve to self-hosted and its default here does. Erring towards guarded is the only safe direction: a false yes costs one harmless step on a hosted runner, a false no removes a security boundary quietly. 74 passed, up from 72.
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
1 participant
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.
feat(pytest-matrix): let a caller choose its runner, defaulting to today's pool
Operator ruling 2026-07-31: GitHub-hosted runners are the DEFAULT CHOICE for
new work. Most scitex repositories are public, so hosted minutes are free and
the cost objection that justified blanket self-hosting mostly does not apply.
Self-hosted stays for jobs where our own machines are genuinely faster -- long
builds, GPU, large data -- chosen because it wins, not by policy.
BACKWARD COMPATIBLE BY CONSTRUCTION. The new
runs_oninput defaults to'["self-hosted","Linux","X64","spartan-cpu"]', byte-identical to the value that
was hardcoded, so all 28 callers keep exactly today's behaviour. Only a repo
that passes the input moves.
WHY A CALLER WANTS OUT TODAY. Every runner on the Spartan lease inherits one
mutable ~/.runner-toolcache on GPFS, so runners contend for a single directory.
Jobs fail BOTH reading it (
uv: No such file-> exit 127) and writing it(ENOENT during copyfile INTO the cache) -- one bug seen from opposite ends.
Measured on scitex-cards 2026-07-31: seven failures across five pull requests
in one afternoon, four differently-named runners, every one cleared by a plain
rerun. This workflow's own comments already describe the hazard, and #24 records
that the per-runner fix "cannot fire".
The durable fix is still a per-runner AGENT_TOOLSDIRECTORY in the supervisor.
This input is not that fix; it is an escape hatch for callers that cannot
absorb random reruns while that work is pending.
THE FORK GUARD NEEDED A REAL FIX, NOT A TEST UPDATE. Parameterising
runs-onmade the guard's selector stop recognising this job: it matched the literal
label "self-hosted", and an expression is not that string. The job silently left
the guarded set, so the fork guard would have become unenforced AND untested in
the same moment -- the suite would have stayed green while the protection
disappeared. The tests caught it.
_may_run_self_hosted now answers YES for an expression-valued
runs-on, becausesuch a job CAN resolve to self-hosted and its default here does. Erring towards
guarded is the only safe direction: a false yes costs one harmless step on a
hosted runner, a false no removes a security boundary quietly.
74 passed, up from 72.