Repository navigation
Split the CI Test job into shards and cut its runtime - #2269
Merged
Merged
Conversation
The Test job took 59 minutes (run 38075384588): 2.6 minutes of YAML tests, then 55.8 minutes of pytest on four balanced xdist workers, 220 worker-minutes in all. No test dominates: 51 property-test files take 74% of it and the slowest test takes 3.5%. So the job is split rather than one test fixed. - `--shard K/N` (tests/conftest.py) keeps the tests whose node id hashes to shard K of N. The shard is a function of the node id alone, so every collected test is in exactly one shard, including tests added later. - The workflows run the YAML tests in one job and the Python tests as a matrix of three shards, N taken from the size of the matrix. - A final `Test` job runs .github/check_test_shards.py over the shards' JUnit files and an unsharded `pytest --collect-only -q` listing. It fails unless every collected test ran in exactly one shard and none failed. - Coverage is measured with sys.monitoring (COVERAGE_CORE=sysmon) instead of the C trace function. On one property-test file the two report the same 12,262 of 18,401 lines, and sys.monitoring adds 6% to the CPU time where the trace function adds 33%. Refs #2099 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…first On 10 October the 5-second final Test job waited 32 minutes for an ubuntu-latest runner after the shards finished (run 38085920460). It now runs on ubuntu-24.04-arm like the shards. The job-result check runs first, and the shard check still runs after a failure so its report names the failed tests. Record the measured job times by the timeouts. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
MaxGhenis
force-pushed
the
ci-test-runtime-2099
branch
from
October 11, 2026 15:00
777bf64 to
841d2a8
Compare
MaxGhenis
marked this pull request as ready for review
October 11, 2026 15:27
1 of 2 tasks
Collaborator
Author
|
Hand-off to the UK hub from W2 of the Autumn Budget CI plan (session local_6c1ab389). I finished this PR for its original session, which the usage limit cut off.
|
This was referenced Oct 11, 2026
This was referenced Oct 12, 2026
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
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.
Fixes #2099
What the hour was spent on
Measured from the log of run 38075384588 (10 October,
Testpassed in 59.6 minutes):*_properties.pyfiles take 74% of the worker time. No test dominates: the slowest takes 3.5%.Change
Testjob into a YAML job, three shards of the Python tests (--shard K/N, defined inpolicyengine_uk/tests/conftest.py), and a finalTestjob. The final job fails unless both test jobs passed and.github/check_test_shards.pyfinds that every collected test ran in exactly one shard and none failed.Testjob onubuntu-24.04-arm, the shards' runners. On 10 October it waited 32 minutes for an ubuntu-latest runner after the shards had finished. On this PR's second run it started 4 seconds after the last shard.sys.monitoring(COVERAGE_CORE=sysmon). On one property file this reported the same 12,262 of 18,401 lines, at 6% CPU overhead instead of 33%.Measured result
TestThe rebased run's shard 2 is red because of a defect already on main, not this change.
test_dataframe_dataset.py::test_an_exported_frame_loads_back_and_exports_itselffails on main too (run 38143054188 at 7343f94), and Hypothesis spent over 5 minutes shrinking it, which is why that shard took 23.8 minutes. Its fix is being handled separately. Once it lands I'll rebase this PR and re-run.Invariants (tested in
policyengine_uk/tests/code_health/test_ci_test_shards.py)shard_of(nodeid, N)is in 1..N and depends only on its arguments (SHA-256, not Python's per-processhash), so every runner and xdist worker agrees.parse_shardaccepts exactlyK/Nwith 1 <= K <= N.junit_keygives a node id the name pytest gives it in JUnit XML (differential test against pytest's ownmangle_test_address).Review
GPT-6.1 Sol reviewed head 841d2a8 and approved it with no blocking findings (
~/reviews/budget-ci-w2/review-2269-841d2a889.md). Its two minor findings are handled in the follow-up from workstream W2 of the Autumn Budget CI plan, which moves this check off JUnit:<failure>or<error>element counts as failed.a/b/test_c.py::tanda/b.test_c.py::t.That follow-up also stops the check from accepting skips and expected failures that no reviewer has accepted. This PR is unchanged in what it accepts.
Left for later
gc.freeze()plus GC-threshold change cut CPU on one property file from 77 to 61 seconds. It isn't in this PR, so the shard split can land first.axiom: n/a: CI infrastructure
🤖 Generated with Claude Code