Gitea now has two action runners, but there is one 4090. Until now, two PRs' e2e jobs could run at the same time and share the GPU.
Change: the e2e job joins a fixed concurrency group, nisse-e2e, with cancel-in-progress: false. A second PR's e2e waits for the first to finish. checks still runs on both runners in parallel, and a newer push still cancels its own PR's older run (the workflow-level group).
Caveat: a group holds one running job and one waiting job (GitHub's rule, which Gitea follows as far as I know). If three PRs reach e2e together, the third replaces the waiting one, which then shows as cancelled and needs a rerun. If that happens often, the fallback is a dedicated runner label for e2e.
Test:tests/ci/test_workflow.py checks that the group is the same for every PR and doesn't cancel.
Live check: to come once this merges, the next time two PRs reach e2e together. I'll confirm the second one waits.
Gitea now has two action runners, but there is one 4090. Until now, two PRs' e2e jobs could run at the same time and share the GPU.
**Change:** the `e2e` job joins a fixed concurrency group, `nisse-e2e`, with `cancel-in-progress: false`. A second PR's e2e waits for the first to finish. `checks` still runs on both runners in parallel, and a newer push still cancels its own PR's older run (the workflow-level group).
**Caveat:** a group holds one running job and one waiting job (GitHub's rule, which Gitea follows as far as I know). If three PRs reach e2e together, the third replaces the waiting one, which then shows as cancelled and needs a rerun. If that happens often, the fallback is a dedicated runner label for e2e.
**Test:** `tests/ci/test_workflow.py` checks that the group is the same for every PR and doesn't cancel.
**Live check:** to come once this merges, the next time two PRs reach e2e together. I'll confirm the second one waits.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk
Gitea now has two runners but there is one 4090. The e2e job joins one
concurrency group without cancel-in-progress, so a second PR's e2e waits
for the first. checks still run in parallel.
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Gitea now has two action runners, but there is one 4090. Until now, two PRs' e2e jobs could run at the same time and share the GPU.
Change: the
e2ejob joins a fixed concurrency group,nisse-e2e, withcancel-in-progress: false. A second PR's e2e waits for the first to finish.checksstill runs on both runners in parallel, and a newer push still cancels its own PR's older run (the workflow-level group).Caveat: a group holds one running job and one waiting job (GitHub's rule, which Gitea follows as far as I know). If three PRs reach e2e together, the third replaces the waiting one, which then shows as cancelled and needs a rerun. If that happens often, the fallback is a dedicated runner label for e2e.
Test:
tests/ci/test_workflow.pychecks that the group is the same for every PR and doesn't cancel.Live check: to come once this merges, the next time two PRs reach e2e together. I'll confirm the second one waits.
🤖 Generated with Claude Code
https://claude.ai/code/session_01J5Utyfzw7gF7UhjRDEtjTk