Skip to content

Refresh CI scheduling estimates after runtime improvements #37

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft
284km wants to merge 2 commits into
base: main
Choose a base branch
from
Draft

Refresh CI scheduling estimates after runtime improvements #37

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
ccc2bd1
Refresh CI scheduling estimates after runtime improvements
284km Nov 7, 2026
8dfc245
Correct the post-merge memory-limit file count
284km Nov 7, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions unittest/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -280,6 +280,16 @@ Reference and compiler builds take only a few minutes; this change targets the
larger repeated-job overhead without introducing native-runtime cache validity
or ABI dependencies.

The checked-in estimates now come from the [post-merge run on 2026-11-07](https://github.com/284km/mere-ruby/actions/runs/42361097257)
at `278a46c`, after the runtime fixes. All 758 files were collected from eight
shards. The observed execution totals ranged from 708.0 to 1,383.5 seconds per
shard with the previous weights. Replaying the same observations with refreshed
weights gives 959.8–960.6 seconds per shard. A four-worker replay falls from
2,298.3 to 1,920.4 seconds (16.4%); this excludes setup, queueing and future

@284km 284km Nov 7, 2026

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Positive: The replay qualification is accurate. Using the production partitioner and four-worker scheduling model reproduces 2,298.315 → 1,920.384 seconds (16.444%). The adjacent resource-limit and incomplete-file counts also match the source report, so balanced scheduling is not presented as complete Ruby conformance or a measured end-to-end speedup.

runtime variation and is not an observed end-to-end speedup. The report has no
WALL_LIMIT files, but 22 MEMORY_LIMIT files and 166 incomplete or zero-test files
remain. Successful collection is not Ruby conformance.

Successful collection writes `timings.json` into `unittest-report`, using the
observed per-file supervisor durations and exact source/compiler/Ruby refs.
To refresh the checked-in estimates, inspect a completed full report, copy that
Expand Down
Loading
Loading