Repository navigation
ci: split the lifecycle-model job into 8 shares that start all their runs at once - #328
Conversation
The model of #324 has about twice the states of main's. On its head the four shares took 38, 40, 46 and 48 min of the 50 min timeout, and a share cannot be shorter than its longest run.
|
@codex review |
|
@codex security review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Codex Review: Didn't find any major issues. Keep them coming! Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
…runs at once A timeout raise alone leaves #324's 48 min share at the merge queue's 60 min limit. check.sh waits for each batch of CHECK_JOBS runs, so a share took the sum of its longest runs. With 8 shares and CHECK_JOBS 12, every share starts all its runs at once and takes about as long as its longest run. The job timeout goes to 45 min.
ThomasK33
changed the title
|
@codex review |
|
@codex security review |
|
Codex Review: Didn't find any major issues. 🚀 Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
…share times On the model of #324 the 8 shares took 15 to 43 min. The 43 min share holds only the longest run, which TLC checks with 1 worker, so no share split makes it shorter, and 45 min left too little room.
|
@codex review |
|
@codex security review |
|
Codex Review: Didn't find any major issues. More of your lovely PRs please. Reviewed commit: ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
If Codex has suggestions, it will comment; otherwise it will react with 👍. Codex can also answer questions or update the PR. Try commenting "@codex address that feedback". |
🛡️ Codex Security ReviewSecurity review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
Why
#324 roughly doubles the lifecycle model (summed over all runs, about 2.1 times the states of main's). On #324's head
60006876, the fourlifecycle-modelshares took 48, 40, 38 and 46 min (shares 1 to 4). The merge queue waits at most 60 min for checks, so those shares plus the install sit at its edge.Raising the timeout alone does not help:
check.shstartsCHECK_JOBSruns at a time and waits for all of them before it starts the next ones, so a share took about the sum of the longest runs of its batches.What changed
.github/workflows/ci.yml, joblifecycle-model:CHECK_SHARD: <i>/8).check.shalready takes any<i>/<n>.CHECK_JOBS: '12', so each share starts all its runs at once. With the model of fix: on Windows, stop a late host after a failed create in more cases, and name the session in text mode #324, a share has 10 to 12 runs, and at most 2 of them are long, so they share the runner's 4 vCPUs. A share then takes about as long as its longest run.timeout-minutes: 55instead of 50. The longest share holds only the longest run,mutant-ReconcileSkipsTerminal(88.7 million distinct states), which TLC checks with 1 worker. That share took 43 min, so no split of the runs makes it shorter. A follow-up PR after fix: on Windows, stop a late host after a failed create in more cases, and name the session in text mode #324 will give the long runs more TLC workers to lower that floor.quality-gatesstill needslifecycle-model, which waits for every share. The required checks arequality-gates,quality-gates-macosandpr-title, so the new share names change no required check.SKILL.mdof the lifecycle skill still says that CI runs the check "in four shares". #324 edits that same line, so the follow-up PR after #324 updates it.Behavior changes
None for CLI or JSON users. This PR does not change
coverage.json, so its own CI skips the TLC runs.Validation
600068767cdd569989da2970ab50d9847998cb1c:lifecycle-model (1/4)12:50:37 to 13:38:53 UTC,(2/4)12:50:38 to 13:30:45,(3/4)12:50:37 to 13:28:58,(4/4)12:50:37 to 13:36:31.a3e6590f) into fix: on Windows, stop a late host after a failed create in more cases, and name the session in text mode #324's head (aa556964). Share 1 took 36 min 47 s (it holdscurrentandcurrent-unseen), share 2 15 min 14 s, share 3 34 min 40 s, share 4 34 min 26 s, share 5 43 min 25 s (mutant-ReconcileSkipsTerminalalone), share 6 23 min 7 s, share 7 25 min 29 s and share 8 22 min 35 s. The whole CI run finished in about 44 min. Every share passed. In share 1, the TLC step took 36 min 13 s, and setup and install took 30 s.oxfmt --check .github/workflows/ci.ymlpasses.Refs #324, #302
Generated with
xum• Model:anthropic:claude-opus-5-5• Thinking:xhigh