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
Every python-package.ymlpush-event run for ~1 week is conclusion: failure with 0 jobs (startup_failure — the run never launches a single job). Sampled run IDs (all event: push, total_count jobs = 0):
0 jobs + failure = startup_failure, not a test failure. The workflow YAML is valid (yaml.safe_load OK; the fromJson(... && ... || ...) matrix expression evaluates fine on push → full 3-OS × 3-py matrix).
Pattern (push full-matrix fails to start, ubuntu-only PR runs are fine) points to Actions runner availability / spending-limit on the macOS (10×) + Windows (2×) minutes, i.e. an account/billing condition — not a code defect.
Evidence it is not the code
Local full fast suite on development HEAD (35c2b9c) is green:
So the rolling PR #224 code is healthy; the red X is infra.
What's needed (operator-only)
Confirm whether GitHub Actions spending limit / included-minutes is exhausted for macOS/Windows on this account, or whether hosted macOS/Windows runners are otherwise unavailable.
development35c2b9c adds concurrency: cancel-in-progress to python-package.yml so superseded pushes/PR-syncs stop stacking redundant full-matrix runs — reduces minute burn but does not fix the underlying startup_failure (which is the operator decision above).
Filed by the CHILmesh hour-02 rotation follow-on (maintenance track). Not auto-fixable — undoing the deliberate macOS/Windows matrix is an operator call, and the root cause is billing/runner availability.
Problem
Every
python-package.ymlpush-event run for ~1 week isconclusion: failurewith 0 jobs (startup_failure — the run never launches a single job). Sampled run IDs (allevent: push,total_countjobs = 0):Diagnosis
failure= startup_failure, not a test failure. The workflow YAML is valid (yaml.safe_loadOK; thefromJson(... && ... || ...)matrix expression evaluates fine on push → full 3-OS × 3-py matrix).macos-latest+windows-latest(added deliberately per Windows portability: encoding/newline on file I/O + Windows CI runner #121/CI runtime optimization: measure + xdist safety + macOS profiling #122); the PR leg is ubuntu-only and theworkflow-conformanceruns succeed.Evidence it is not the code
Local full fast suite on
developmentHEAD (35c2b9c) is green:So the rolling PR #224 code is healthy; the red X is infra.
What's needed (operator-only)
workflow_dispatch/ scheduled / release-gated) lane so routine pushes get a green ubuntu signal and cross-platform coverage runs deliberately. Option (b) preserves the Windows portability: encoding/newline on file I/O + Windows CI runner #121/CI runtime optimization: measure + xdist safety + macOS profiling #122 intent without burning minutes on every push.Already mitigated (this session)
development35c2b9caddsconcurrency: cancel-in-progresstopython-package.ymlso superseded pushes/PR-syncs stop stacking redundant full-matrix runs — reduces minute burn but does not fix the underlying startup_failure (which is the operator decision above).Filed by the CHILmesh hour-02 rotation follow-on (maintenance track). Not auto-fixable — undoing the deliberate macOS/Windows matrix is an operator call, and the root cause is billing/runner availability.
[repo: CHILmesh · session: 2026-06-20T06Z-rotation · refs: #121, #122, #224]