Repository navigation
Conversation
One author opening or pushing many pull requests could fill the runner queue and delay everyone else. Each PR-triggered workflow now uses a concurrency group keyed on the workflow and the actor, so an author has one run in progress per workflow while the rest wait in order (queue: max) rather than being cancelled. Pushes to main, scheduled runs and manual dispatches fall back to the run ID and are never held back. Signed-off-by: dhruv8sh <dhruv8sh@proton.me>
Group pull request runs by the PR author instead of the triggering actor, so a maintainer pushing to or updating contributors' branches does not pile those runs into the maintainer's queue. Bot-authored PRs fall back to the run ID so a Dependabot batch is not serialized. Give every job in the queued workflows a timeout of roughly three times its longest recent run, so a hung job cannot hold an author's queue for GitHub's six-hour default. Signed-off-by: dhruv8sh <dhruv8sh@proton.me>
prk-Jr
left a comment
There was a problem hiding this comment.
Summary
Reviewed all five changed workflows at 3d448f910c2c0445b979441452b29d401074d42d, including job dependencies, matrices, shared setup, triggers, permissions and concurrency policies. No blocking defects found; the implementation matches issue #1425. Author rather than actor grouping correctly handles maintainer updates, and all 18 job definitions have explicit timeouts.
Non-blocking observations
-
🤔 Workflow limits do not guarantee runner fairness — The concurrency block in
.github/workflows/test.yml:16–19admits one workflow run per author, but that run can launch eight jobs. Format and CodeQL can launch another eight simultaneously, alongside integration jobs. This substantially reduces burst multiplication, but still permits significant runner occupancy by one author. Measure contention after rollout before adding further serialization. -
📝 Clarify queue capacity and ordering — The repeated comments in the five workflows say queued runs are preserved and run in order. GitHub permits 100 pending runs per group, then cancels additional arrivals. FIFO follows when runs begin waiting on the concurrency group, rather than workflow dispatch order. Consider documenting those qualifications in the shared wording and PR description. See GitHub concurrency documentation. Apply manually: this clarification spans five workflow files.
-
🏕 Retain the policy verification script — The PR describes useful expression checks with
act, but the verification script is not included in the change. Keeping it in the repository would help catch drift across the five duplicated policies. Cover author versus actor, bots, non-PR events, group separation and timeout presence. Apply manually: retaining the script introduces a new file.
Suggested follow-up
Retain this author-level cap, then separately consider cancelling superseded runs within the same PR. That would reduce obsolete work while preserving the cap across different PRs. Any privileged cancellation workflow should manipulate Actions metadata without checking out or executing contributor code. Stale-run queueing is explicitly acknowledged in this PR and is not a blocker.
Validation
Local YAML/policy assertions passed for all five identical concurrency policies and all 18 job definitions; git diff --check passed. Local actionlint reported its outdated schema for queue and shell warnings on unchanged lines. Current GitHub documentation confirms queue: max is supported. Rust/JS suites were not rerun locally for this workflow-only change, and the reported live multi-PR experiment was not independently reproduced.
CI Status
- browser integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- integration tests: PASS
- CodeQL: PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- Analyze (actions): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- Analyze (javascript-typescript): PASS
- cargo test (axum native): PASS
- docs-proposal scripts: PASS
- format-docs: PASS (required)
- Analyze (rust): PASS
- prepare integration artifacts: PASS
- format-typescript: PASS (required)
- cargo test: PASS (required)
- CLAUDE.md symlink guard: PASS
- cargo fmt: PASS (required)
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- vitest: PASS
- cargo test (cross-adapter parity): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- PBS Terraform and Compose checks: PASS
- Analyze (javascript-typescript): PASS
- Analyze (python): PASS
ChristianPavilonis
left a comment
There was a problem hiding this comment.
Approved. Queuing PR CI runs per author and workflow, with bounded job timeouts and independent groups for bots and non-PR runs, is a focused improvement to shared runner fairness.
aram356
left a comment
There was a problem hiding this comment.
Summary
This adds a per-PR-author concurrency group with queue: max to the five PR-triggered workflows, and a timeout-minutes on every job. The timeouts hold up against the last 400 runs of each workflow and against the cold runs after the Rust 1.98.1 upgrade. Two things block: without superseded-run cancellation, the per-author queue delays required checks by hours and can hit the 100-pending cap, and nothing keeps the new invariants in place as open PRs land.
1 of the inline comments below carries a one-click GitHub
suggestion— use Commit suggestion to apply it as a commit on the PR branch. The remaining comments describe the fix in prose because the change touches multiple files or lines outside the diff and can't be auto-applied.
Blocking
🔧 wrench
- Per-author queue without superseded-run cancellation — see inline at
.github/workflows/test.yml:17 - Enforce the shared block and job timeouts — see inline at
.github/workflows/format.yml:58
Non-blocking
🤔 thinking
- Bot exemption covers the runs nobody waits on — see inline at
.github/workflows/test.yml:14
📝 note
- Windows axum leg from the module stack — see inline at
.github/workflows/test.yml:81
CI Status
- integration tests: PASS
- browser integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- CodeQL: PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- Analyze (python): PASS
- docs-proposal scripts: PASS
- Analyze (javascript-typescript): PASS (both runs)
- Analyze (rust): PASS
- vitest: PASS
- cargo fmt: PASS (required)
- cargo test (axum native): PASS
- CLAUDE.md symlink guard: PASS
- format-typescript: PASS (required)
- prepare integration artifacts: PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- format-docs: PASS (required)
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- cargo test (cross-adapter parity): PASS
- PBS Terraform and Compose checks: PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo test: PASS (required)
- Analyze (actions): PASS
A workflow-level group per pull request now cancels a run when a newer push arrives, so stale runs no longer hold an author's queue or count toward GitHub's 100-pending cap. The per-author queue moves to each job's own concurrency block with queue: max, keyed on the matrix for matrix jobs so their legs do not queue behind each other. Bot-authored PRs and non-PR events still key on the run ID. The shared comment now states the FIFO ordering and the 100-pending limit. Signed-off-by: dhruv8sh <dhruv8sh@proton.me>
The required cargo fmt job now fails when a PR-triggered workflow lacks the per-PR cancellation block from test.yml, or when a job lacks timeout-minutes or a per-author queue keyed on pull_request.user.login with queue: max. Matrix jobs must also include the matrix in their group. Jobs that call a reusable workflow are skipped. The step uses the runner image's yq. Signed-off-by: dhruv8sh <dhruv8sh@proton.me>
aram356
left a comment
There was a problem hiding this comment.
Summary
Round 2 at 5068110d2. Both round-1 blockers are fixed: each workflow now cancels a PR's superseded run, each job queues per author, and the guard enforces both. A job-level replay of the 372 Run Tests PR runs from Oct 21 to 30, using uncontended job durations, shows the effect. For the stacked-PR author, the latest push's cargo test wait drops from p50 547 / max 1199 min under the round-1 design to p50 170 / max 393 min. prk-Jr's max falls from 266 to 8 min, job-hours fall from 275 to 239, and nothing is cancelled at the 100-pending cap. What blocks now is mechanical: the required cargo fmt check fails, the description still describes round 1, and the live check is open.
2 of the inline comments below carry a one-click GitHub
suggestion— use Commit suggestion (or Add suggestion to batch) to apply them as commits on the PR branch. The remaining findings describe the fix in prose because the change touches lines outside the diff or the PR description.
Blocking
🔧 wrench
- The required
cargo fmtcheck fails — see Cross-cutting below - The PR description still describes round 1 — see Cross-cutting below
❓ question
- Live check of cancelling a run whose jobs wait in a job-level queue — see inline at
.github/workflows/test.yml:20
Non-blocking
♻️ refactor
- The guard accepts three copy-paste mistakes — see inline at
.github/workflows/format.yml:124
🤔 thinking
- The bot exemption is now the largest load source — see inline at
.github/workflows/test.yml:28
⛏ nitpick
- 104-column comment line in all five workflows — see inline at
.github/workflows/test.yml:17
Cross-cutting / body-level findings
-
🔧 The required
cargo fmtcheck fails. The guard works as designed: the latest main merge brought incheck-ci-node-pin(from #1257,format.yml) andlint-domains(from #1254,test.yml) without the new blocks (job log). Those lines are outside the diff, so there's no suggestion. Add these after each job'sruns-on:, then merge main again (2 behind, and main requires up-to-date branches):check-ci-node-pin: name: CI Node pin guard runs-on: ubuntu-latest timeout-minutes: 5 concurrency: group: ${{ github.workflow }}-check-ci-node-pin-${{ github.event_name == 'pull_request' && github.event.pull_request.user.type != 'Bot' && github.event.pull_request.user.login || github.run_id }} queue: max
lint-domains: ... name: ts dev lint domains (changed lines) if: github.event_name == 'pull_request' runs-on: ubuntu-latest timeout-minutes: 10 concurrency: group: ${{ github.workflow }}-lint-domains-${{ github.event_name == 'pull_request' && github.event.pull_request.user.type != 'Bot' && github.event.pull_request.user.login || github.run_id }} queue: max
The timeouts follow the description's rule: the slowest recent runs were 0.3 min (52 runs) and 2.4 min (54 runs). Verified on a local merge with current main plus these blocks and both suggestions: the guard passes locally and in Docker, the Node pin checker reports 26 jobs OK and its tests pass 30/30, and the setup-rust guard passes.
-
🔧 The PR description still describes round 1. The summary and YAML snippet show
cancel-in-progress: falseand a workflow-level per-author group. "Known trade-offs" says cancelling superseded runs is left for a follow-up. The Changes table has no row for the guard or the per-job blocks, and the test plan's live run andactchecks cover the old design. Please rewrite it for the current design and add the live-check result. -
📝 Merge order. After this lands, the guard fails
cargo fmton rebase for #1107 (trace-runtime-tests; approved and behind main), #1433 (worker-auction-deadlines.yml), #1435 (release.yml), #1345 (inspector.yml) and draft #1460 (publisher-registration). Ten more already conflict with this PR in.github: the #1347 to #1423 stack, #1424, #1449, #917, #1002 and #1053. That's the guard doing its job, but those authors will want a heads-up. For #1435, the guard forces test.yml's block onto a workflow that also runs on tag pushes and has its ownbinary-attestations-${{ github.ref }}group. Tag pushes key on the run ID, so releases won't queue, but it's worth confirming that's intended. -
🏕 AGENTS.md. The CI Gates list names the standalone guards (10, 12 and 13). One line saying every PR-triggered workflow needs test.yml's workflow-level block and every job needs a timeout and a per-author queue would tell agents before the guard fails their run.
CI Status
- cargo fmt: FAIL (required)
- cargo test: PASS (required)
- format-typescript: PASS (required)
- format-docs: PASS (required)
- integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- browser integration tests: PASS
- prepare integration artifacts: PASS
- CodeQL: PASS
- Analyze (actions): PASS
- Analyze (javascript-typescript): PASS (both runs)
- Analyze (python): PASS
- Analyze (rust): PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- cargo test (cross-adapter parity): PASS
- cargo test (axum native): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- HTML EOF runtime (Fastly): PASS
- ts dev lint domains (changed lines): PASS
- CI Node pin guard: PASS
- CLAUDE.md symlink guard: PASS
- docs-proposal scripts: PASS
- vitest: PASS
- PBS Terraform and Compose checks: PASS
| # PRs and non-PR events key on the run ID and never wait on a queue. | ||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
❓ question — In the earlier thread you planned to confirm in your throwaway repo that cancelling a superseded run also drops its jobs still waiting in a job-level queue, and to report back before merge. This PR can't show it yet: the three rework commits went up in one push, so its own history has no cancelled run. Could you post the result here? A run link is enough.
There was a problem hiding this comment.
I haven't run the throwaway-repo check, and I won't before merge. Let's confirm it from the first superseded PR runs after merge. If cancelling a run leaves its queued jobs behind, I'll open a follow-up to move cancellation to the job-level groups.
|
@dhruv8sh please resolve comments after addressing feedback |
aram356
left a comment
There was a problem hiding this comment.
Summary
Round 3 at 32523f184. The round-2 asks mostly landed: check-ci-node-pin and lint-domains have their blocks, the guard is now scripts/check-ci-concurrency.sh with tests and checks the exact group shape (all three round-2 gaps now fail), AGENTS.md has gate 14, and the comment is rewrapped. I re-probed the script with 23 fixtures, ran it under bash 3.2, bash 5.2 with yq 4.54.1, and mutated it against its tests. What blocks: the guard fails on the merge ref, it no longer sits on a required check, the yq download is unverified, and the description and the live-check question from round 2 are still open.
3 of the inline comments below carry a one-click GitHub
suggestion— use Commit suggestion (or Add suggestion to batch for several at once) to apply them as commits on the PR branch. The remaining findings describe the fix in prose because the change touches lines outside the diff, repository settings, or the PR description.
Blocking
🔧 wrench
- The guard fails on the merge ref (
trace-runtime-testsfrom #1107) — see Cross-cutting below - The guard no longer runs on a required check — see inline at
.github/workflows/format.yml:97 - The yq download is not verified — see inline at
.github/workflows/format.yml:73 - The PR description is still the round-1 text — see Cross-cutting below
❓ question
- The live check from round 2 is still open — see Cross-cutting below
Non-blocking
♻️ refactor
- The timeout check rejects expression timeouts — see inline at
scripts/check-ci-concurrency.sh:146 - Six of the script's checks have no test — see inline at
scripts/check-ci-concurrency.test.mjs:233
🌱 seedling
- The matrix check accepts partial keying — see inline at
scripts/check-ci-concurrency.sh:73
Cross-cutting / body-level findings
-
🔧 The guard fails on the merge ref. #1107 landed on main with a
trace-runtime-testsjob that has a timeout but no per-author block, soCI Node pin guardfails on this PR's merge ref (job log). The branch is also 5 behind main, and main requires up-to-date branches. Merge main (it merges cleanly) and add this after that job'stimeout-minutes: 45inintegration-tests.yml:concurrency: group: ${{ github.workflow }}-trace-runtime-tests-${{ github.event_name == 'pull_request' && github.event.pull_request.user.type != 'Bot' && github.event.pull_request.user.login || github.run_id }} queue: max
Verified on a local merge with current main plus this block and all three suggestions: the guard exits 0 locally and in Docker (bash 5.2, yq 4.54.1), the concurrency tests pass 11/11, the Node pin tests pass 30/30 and it reports 27 jobs OK, the setup-rust guard passes, the YAML parses, and actionlint reports nothing new.
-
🔧 The PR description is still the round-1 text. It shows
cancel-in-progress: falseand a workflow-level per-author group, says cancelling superseded runs is left for a follow-up, and its Changes table, timeouts table and test plan predate both reworks. It now also leaves outscripts/check-ci-concurrency.shand its tests, AGENTS.md gate 14 and the scripts/README.md row. -
❓ The live check is still open. The round-2 question at
.github/workflows/test.yml:19(does cancelling a superseded run also drop its jobs waiting in a job-level queue?) has no reply yet.
CI Status
- cargo fmt: PASS (required)
- cargo test: PASS (required)
- format-docs: PASS (required)
- format-typescript: PASS (required)
- CI Node pin guard: FAIL (runs the concurrency guard; see above)
- CLAUDE.md symlink guard: PASS
- docs-proposal scripts: PASS
- ts dev lint domains (changed lines): PASS
- vitest: PASS
- cargo test (axum native): PASS
- cargo test (cross-adapter parity): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- HTML EOF runtime (Fastly): PASS
- prepare integration artifacts: PASS
- integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- browser integration tests: PASS
- trace runtime and browser acceptance: PASS
- PBS Terraform and Compose checks: PASS
- CodeQL: PASS
- Analyze (actions): PASS
- Analyze (javascript-typescript): PASS (both runs)
- Analyze (python): PASS
- Analyze (rust): PASS
…currency # Conflicts: # AGENTS.md
Move the yq install and concurrency guard steps into format-rust so a required check enforces them, and pin the yq download by SHA-256. The guard now accepts expression timeouts, requires every matrix dimension in a matrix job's group, and drops an unreachable reusable-job skip. Add tests for the previously uncovered checks.
|
Round 3 is addressed in 03f24f9 (merge of main) and d79392a:
@prk-Jr, your round-1 notes are covered: the shared comment now states the start order and the 100-pending limit, and the policy check is kept in the repo as |
aram356
left a comment
There was a problem hiding this comment.
Summary
Round 4 at 7fc939589. Every round-3 ask landed: the guard runs in the required cargo fmt job again (CI's log shows the yq checksum OK, 13/13 tests and a clean guard run on ubuntu-26.04), trace-runtime-tests and worker-deadlines carry their blocks, the script accepts expression timeouts and requires every matrix dimension, and AGENTS.md gate 16 is in place. I re-ran 26 fixtures and 14 mutants against the script, plus macOS bash 3.2, bash 5.2 with yq 4.54.1 in Docker, shellcheck and prettier; all behave as intended, and only one real test gap remains (inline). What still blocks is outside the workflow code: the PR description, and the live-check question from round 2.
1 of the inline comments below carries a one-click GitHub
suggestion— use Commit suggestion to apply it as a commit on the PR branch. The remaining findings are about the PR description, an open thread and other PRs, so they have no suggestion.
Blocking
🔧 wrench
- The PR description is still the round-1 text — see Cross-cutting below
❓ question
- The live check from round 2 is still unanswered — see Cross-cutting below
Non-blocking
⛏ nitpick
- The matrix check's
include/excludefilter has no test — see inline atscripts/check-ci-concurrency.test.mjs:356
Cross-cutting / body-level findings
-
🔧 The PR description is still the round-1 text. This is the third time it has come up. It still shows
cancel-in-progress: falsewith a workflow-level per-author group, and says cancelling superseded runs is "left for a follow-up". The Changes table, the timeouts table and the test plan predate both reworks, and it leaves outscripts/check-ci-concurrency.shand its tests, AGENTS.md gate 16, the scripts/README.md row, and the blocks ontrace-runtime-testsandworker-auction-deadlines.yml. Please rewrite it for the current design. -
❓ The live check is still unanswered. The question at
.github/workflows/test.yml:19(does cancelling a superseded run also drop its jobs waiting in a job-level queue?) has had no reply for two rounds, and this PR's own history still has no cancelled run, since each push finished before the next. If the throwaway-repo check isn't possible, please say so in that thread; it can then be confirmed from the first burst of superseded runs after merge. -
📝 Merge order. With the guard on a required check, these open PRs will turn
cargo fmtred once they rebase onto this one: #1435 and #1449 (each adds arelease-scriptsjob toformat.ymlwithout a timeout or per-author queue) and draft #1460 (publisher-registrationinintegration-tests.yml). #1499, #1424, the #1345 to #1423 module stack, #917, #1002 and #1053 already conflict with this PR in.github. That's the guard doing its job, but those authors will want a heads-up.
CI Status
- cargo fmt: PASS (required)
- cargo test: PASS (required)
- format-docs: PASS (required)
- format-typescript: PASS (required)
- CI Node pin guard: PASS
- CLAUDE.md symlink guard: PASS
- docs-proposal scripts: PASS
- ts dev lint domains (changed lines): PASS
- vitest: PASS
- cargo test (axum native): PASS
- cargo test (cross-adapter parity): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- HTML EOF runtime (Fastly): PASS
- worker-deadlines (cloudflare): PASS
- worker-deadlines (spin): PASS
- prepare integration artifacts: PASS
- integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- browser integration tests: PASS
- trace runtime and browser acceptance: PASS
- PBS Terraform and Compose checks: PASS
- CodeQL: PASS
- Analyze (actions): PASS
- Analyze (javascript-typescript): PASS (both runs)
- Analyze (python): PASS
- Analyze (rust): PASS
Co-authored-by: AG <132480+aram356@users.noreply.github.com>
aram356
left a comment
There was a problem hiding this comment.
Summary
Round 5 at 7c3aaf78f. Since round 4 the include/exclude test landed byte-for-byte as suggested (14/14, prettier-clean), and every other file in the PR is unchanged from the version I verified in round 4. The workflow code is done. What blocks: the PR now conflicts with main, and the description and the round-2 live-check question are still open.
Blocking
🔧 wrench
- The PR conflicts with main — see Cross-cutting below
- The PR description is still the round-1 text — see Cross-cutting below
❓ question
- The live check from round 2 is still unanswered — see Cross-cutting below
Cross-cutting / body-level findings
-
🔧 The PR conflicts with main. #917 landed after your last merge and added an
env:block tobrowser-testsdirectly aftertimeout-minutes: 15, where this PR adds that job'sconcurrency:block. Merge main and keep both:runs-on: ubuntu-24.04 timeout-minutes: 15 concurrency: group: ${{ github.workflow }}-browser-tests-${{ github.event_name == 'pull_request' && github.event.pull_request.user.type != 'Bot' && github.event.pull_request.user.login || github.run_id }} queue: max env: VICEROY_CONFIG_GENERATOR_PATH: ${{ github.workspace }}/target/debug/generate-viceroy-config
Verified on a local merge resolved this way: the concurrency guard exits 0 and its tests pass 14/14, the Node pin guard passes 30/30 and reports 28 jobs OK, and the setup-rust guard passes. GitHub does not run
pull_requestworkflows while a PR conflicts, so CI re-runs only after the merge. -
🔧 The PR description is still the round-1 text. This is the fourth round it has come up. It still shows
cancel-in-progress: falsewith a workflow-level per-author group and says cancelling superseded runs is "left for a follow-up". The Changes table, timeouts table and test plan predate both reworks, and it leaves outscripts/check-ci-concurrency.shand its tests, AGENTS.md gate 16, the scripts/README.md row, and the blocks ontrace-runtime-testsandworker-auction-deadlines.yml. Please rewrite it for the current design. -
❓ The live check is still unanswered. The question at
.github/workflows/test.yml:19(does cancelling a superseded run also drop its jobs waiting in a job-level queue?) has had no reply for three rounds. If the throwaway-repo check isn't possible, please say so in that thread, and it can be confirmed from the first burst of superseded runs after merge.
CI Status
All 30 checks passed at 7c3aaf78f (run before #917 landed); they will not re-run until the conflict is resolved.
- cargo fmt: PASS (required)
- cargo test: PASS (required)
- format-docs: PASS (required)
- format-typescript: PASS (required)
- CI Node pin guard: PASS
- CLAUDE.md symlink guard: PASS
- docs-proposal scripts: PASS
- ts dev lint domains (changed lines): PASS
- vitest: PASS
- cargo test (axum native): PASS
- cargo test (cross-adapter parity): PASS
- cargo test (ts CLI, native) (ubuntu-latest): PASS
- cargo test (ts CLI, native) (macos-latest): PASS
- cargo check (cloudflare native + wasm32-unknown-unknown): PASS
- cargo check/build/test (spin native + wasm32-wasip1): PASS
- HTML EOF runtime (Fastly): PASS
- worker-deadlines (cloudflare): PASS
- worker-deadlines (spin): PASS
- prepare integration artifacts: PASS
- integration tests: PASS
- integration tests (Fastly EC lifecycle): PASS
- browser integration tests: PASS
- trace runtime and browser acceptance: PASS
- PBS Terraform and Compose checks: PASS
- CodeQL: PASS
- Analyze (actions): PASS
- Analyze (javascript-typescript): PASS (both runs)
- Analyze (python): PASS
- Analyze (rust): PASS
aram356
left a comment
There was a problem hiding this comment.
Summary
Round 6 at 7c3aaf78f, unchanged since round 5. Main has since landed #1435 and #1504, so the merge now needs more than round 5's one-file fix. The updated recipe is below and replaces round 5's. The description and the live-check question are still open.
Blocking
🔧 wrench
- Merging main now takes four fixes — see Cross-cutting below
- The PR description is still the round-1 text — see Cross-cutting below
❓ question
- The live check from round 2 is still unanswered — see Cross-cutting below
Cross-cutting / body-level findings
-
🔧 Merging main now takes four fixes. Main is at
598a85170, and the PR conflicts in three files plus needs one new block:-
.github/workflows/integration-tests.yml: inbrowser-tests, keep both this PR'sconcurrency:block and #917'senv:block, as in round 5. -
AGENTS.md: #1435 took gate 16 ("Release producer checks"), so the CI concurrency policy guard becomes gate 17. -
scripts/README.md: #1504 widened the table's middle column. Take main's table, add thecheck-ci-concurrency.shrow aftercheck-ci-node-pin.mjs, and realign withdocs/node_modules/.bin/prettier --config docs/.prettierrc --write scripts/README.md. -
.github/workflows/format.yml: #1435's newrelease-scriptsjob has no timeout or per-author queue, so the guard fails on it after the merge. Its slowest of 14 recent runs took 25 seconds, so the 10-minute floor applies:release-scripts: name: release scripts runs-on: ubuntu-latest timeout-minutes: 10 concurrency: group: ${{ github.workflow }}-release-scripts-${{ github.event_name == 'pull_request' && github.event.pull_request.user.type != 'Bot' && github.event.pull_request.user.login || github.run_id }} queue: max
release.ymlfrom #1435 now triggers only on tag pushes, so the guard rightly skips it.Verified on a local merge with all four fixes: the concurrency guard exits 0 and its tests pass 14/14, the Node pin guard passes 30/30 and reports 34 jobs in 10 workflows OK, #1435's release producer tests pass 27/27, the setup-rust guard passes, and prettier and
git diff --checkare clean. CI won't re-run until the conflicts are resolved. -
-
🔧 The PR description is still the round-1 text. This is the fifth round it has come up. It still shows
cancel-in-progress: falsewith a workflow-level per-author group and says cancelling superseded runs is "left for a follow-up". The Changes table, timeouts table and test plan predate both reworks, and it leaves outscripts/check-ci-concurrency.shand its tests, the AGENTS.md gate, the scripts/README.md row, and the blocks ontrace-runtime-tests,worker-auction-deadlines.ymland nowrelease-scripts. Please rewrite it for the current design. -
❓ The live check is still unanswered. The question at
.github/workflows/test.yml:19(does cancelling a superseded run also drop its jobs waiting in a job-level queue?) has had no reply for four rounds. If the throwaway-repo check isn't possible, please say so in that thread, and it can be confirmed from the first burst of superseded runs after merge.
CI Status
All 30 checks passed at 7c3aaf78f (run before #917, #1435 and #1504 landed); they will not re-run until the conflicts are resolved.
Keep the browser-tests concurrency block alongside the new env block, renumber the concurrency guard to AGENTS.md gate 17, add its row to the widened scripts/README.md table, and give the new release-scripts job a timeout and per-author queue so the guard passes. Signed-off-by: dhruv8sh <dhruv8sh@proton.me>
|
Merged main at e9f09e6, using the four fixes from round 6:
Checked locally: the concurrency guard exits 0 and its tests pass 14/14. The Node pin guard passes 30/30, with 34 jobs in 10 workflows OK. Release producer tests pass 27/27. Prettier, I've rewritten the PR description for the current design. |
Summary
Two concurrency layers apply to pull request CI:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}withcancel-in-progress: true. A new push cancels the older runs for the same PR.timeout-minutesand a group of the form<workflow>-<job>-<author login>withqueue: max. Each author runs one copy of a given job at a time, and the rest wait in a queue. Matrix jobs add their matrix values to the group. Bots and non-PR events key ongithub.run_id, so they never share a queue.The timeouts free a queue when a job hangs. GitHub mostly runs queued jobs in the order they started waiting, but it doesn't guarantee FIFO. A queue holds up to 100 pending jobs.
Changes
.github/workflows/test.yml,format.yml,integration-tests.yml,codeql.yml,pbs-example.yml,worker-auction-deadlines.ymltrace-runtime-testsandrelease-scripts)scripts/check-ci-concurrency.shscripts/check-ci-concurrency.test.mjs.github/workflows/format.ymlAGENTS.mdscripts/README.mdcheck-ci-concurrency.shrowWorkflows triggered only by tags or dispatch, such as
release.yml, are out of scope, and the guard skips them.Test plan
scripts/check-ci-concurrency.shexits 0, andnode --test scripts/check-ci-concurrency.test.mjspasses 14/14cargo fmt --checkare cleanCloses #1425