[yoavkatz]

GitHub moved the ubuntu-latest label to Ubuntu 26.04 on 2026-11-05. That broke five workflows at once on any run after the rollout.

main has not re-run CI since 2026-11-04, so the breakage is not yet visible there — but it will hit the next push to main and every pull request. It is already red on #1997.

Two failure modes, one cause

1. Python 3.8 and 3.9 are not on the 26.04 image, so actions/setup-python fails outright:

The version '3.9' with architecture 'x64' was not found for Ubuntu 26.04.

Hits quality (3.9), docs (3.8), consistency (3.9), hub (3.9), helm (3.9).

2. The 26.04 toolchain cannot build pytrec-eval. Jobs on Python 3.10 install Python fine, then fail building the C extension because a newer GCC rejects the vendored trec_eval sources:

error: Failed to build `pytrec-eval==0.5`
trec_eval-9.0.8/form_prefs_counts.c:818:12: error: passing argument 4 of
'qsort' from incompatible pointer type [-Wincompatible-pointer-types]

Hits unittests, eager, performance, preparation and the other 3.10 jobs.

The fix

Pin every job to ubuntu-24.04. This restores the environment that was green on 2026-11-04 and fixes both modes together.

Verified against the actions/python-versions manifest:

Python	24.04	26.04
3.8	✅	❌
3.9	✅	❌
3.10	✅	✅

Why pin the image rather than bump the Python versions

pyproject.toml declares requires-python = ">=3.8". Moving the pins forward to satisfy the new image would quietly drop CI coverage for versions the package still claims to support. Dropping 3.8/3.9 should be a separate, deliberate decision — not a side effect of a runner rollout.

Notes for reviewers

• Each runs-on carries a short comment saying why it is pinned, so it does not get reverted to ubuntu-latest and reintroduce this. .github/workflows/README.md records both error signatures and how to check whether a newer image is usable.
• The vestigial OS: env var is updated alongside each runs-on so the two cannot drift apart and mislead a reader. Nothing references it (no env.OS or $OS anywhere in the repo), so that part is cosmetic.
• quality's failure message is misleading and cost me time: it prints "likely due to not using pre-commit hooks" on any failure, but setup-python failed before pre-commit ever ran. Noted in the README.
• All 13 workflow files parse, and every job is pinned (checked with a YAML load over jobs[*].runs-on).

No application code changes — .github/workflows only. The pinned label and Python availability are verified against the upstream manifest, but the pytrec-eval build can only be confirmed by CI on this PR.

Does not close an issue; this is the main CI regression blocking #1997.

🤖 Generated with Claude Code