Implements what was agreed in Discussion #655: every commit on dev gets a full CI result, and pull requests never wait behind dev runs on the R620.
Changes
Before
After
dev concurrency group
one group for the branch (github.ref); a newer push replaced the waiting run (#656)
one group per commit (github.sha), never cancelled
Runner for dev pushes
sisyphus-ci (the four self-hosted runners on the R620)
ubuntu-26.04 (GitHub-hosted)
Runner for this repo's own PRs
sisyphus-ci
sisyphus-ci (unchanged)
Runner for fork and Dependabot PRs
ubuntu-26.04
ubuntu-26.04 (unchanged)
The runs-on expression of test, realimages and rehearsal is inverted, so sisyphus-ci is chosen only for this repository's own pull requests and every other event falls back to hosted. The steps already handle both kinds of runner (runner.environment == 'github-hosted'), since fork PRs run these jobs on hosted runners today.
docs/development.md describes the new dev behaviour, and the comments in ci.yml say why.
Cost and trade-offs
Cost: none. Standard hosted runners are free on a public repository.
Speed:dev runs are slower on hosted runners, but nothing waits on them.
Capacity:dev runs share the org's 20 concurrent hosted jobs with the PR jobs that already run hosted (scope, lint, packaging). A burst of merges queues there, not on the R620.
Testing
actionlint passes.
This PR's own run checks that PR routing is unchanged. The first dev push after merging will show the hosted route and the per-commit group.
## Summary
Implements what was agreed in [Discussion #655](https://git.echelonts.net/Sisyphus/Sisyphus/issues/655): every commit on `dev` gets a full CI result, and pull requests never wait behind `dev` runs on the R620.
## Changes
| | Before | After |
|---|---|---|
| `dev` concurrency group | one group for the branch (`github.ref`); a newer push replaced the waiting run (#656) | one group per commit (`github.sha`), never cancelled |
| Runner for `dev` pushes | `sisyphus-ci` (the four self-hosted runners on the R620) | `ubuntu-26.04` (GitHub-hosted) |
| Runner for this repo's own PRs | `sisyphus-ci` | `sisyphus-ci` (unchanged) |
| Runner for fork and Dependabot PRs | `ubuntu-26.04` | `ubuntu-26.04` (unchanged) |
The `runs-on` expression of `test`, `realimages` and `rehearsal` is inverted, so `sisyphus-ci` is chosen only for this repository's own pull requests and every other event falls back to hosted. The steps already handle both kinds of runner (`runner.environment == 'github-hosted'`), since fork PRs run these jobs on hosted runners today.
`docs/development.md` describes the new `dev` behaviour, and the comments in `ci.yml` say why.
## Cost and trade-offs
- **Cost:** none. Standard hosted runners are free on a public repository.
- **Speed:** `dev` runs are slower on hosted runners, but nothing waits on them.
- **Capacity:** `dev` runs share the org's 20 concurrent hosted jobs with the PR jobs that already run hosted (scope, lint, packaging). A burst of merges queues there, not on the R620.
## Testing
- `actionlint` passes.
- This PR's own run checks that PR routing is unchanged. The first `dev` push after merging will show the hosted route and the per-commit group.
The routing reads right to me. The runs-on expression is now an allow-list (sisyphus-ci only for this repo's own non-Dependabot PRs), which is safer than the old deny-list, and grouping push concurrency by github.sha gives each dev commit its own uncancelled run, which is what Austin asked for. The docs match.
One thing to watch on the first dev runs, not a blocker. realimages on a hosted runner builds every real image cold: no Docker layer cache carries over, unlike on the R620. That set includes Chronos-Bolt's ~4 GB image, and with #712 the ~5.7 GB TimesFM image as well. That is likely more than a standard hosted runner's free disk, and it could also push the job towards its 90-minute timeout. Fork PRs have been taking this route all along, but I don't think one has actually run realimages on a hosted runner recently. If the first dev run fails on disk space or time, freeing disk at the start of the job (the usual rm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghc step) or pruning images between tests would probably be enough.
The routing reads right to me. The `runs-on` expression is now an allow-list (`sisyphus-ci` only for this repo's own non-Dependabot PRs), which is safer than the old deny-list, and grouping push concurrency by `github.sha` gives each dev commit its own uncancelled run, which is what Austin asked for. The docs match.
One thing to watch on the first dev runs, not a blocker. `realimages` on a hosted runner builds every real image cold: no Docker layer cache carries over, unlike on the R620. That set includes Chronos-Bolt's ~4 GB image, and with #712 the ~5.7 GB TimesFM image as well. That is likely more than a standard hosted runner's free disk, and it could also push the job towards its 90-minute timeout. Fork PRs have been taking this route all along, but I don't think one has actually run `realimages` on a hosted runner recently. If the first dev run fails on disk space or time, freeing disk at the start of the job (the usual `rm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghc` step) or pruning images between tests would probably be enough.
The first post-merge dev run has now completed realimages on ubuntu-26.04 successfully (11m20s), with no disk-space or timeout failure. The hosted route is still finishing its remaining test/desktop/package jobs. /cc @rvnminers-A-and-N
The first post-merge `dev` run has now completed `realimages` on `ubuntu-26.04` successfully (11m20s), with no disk-space or timeout failure. The hosted route is still finishing its remaining test/desktop/package jobs. /cc @rvnminers-A-and-N
Thanks, that settles my worry about disk space and the time limit on hosted runners. 11m20s for a cold realimages build is faster than it takes on the R620.
Thanks, that settles my worry about disk space and the time limit on hosted runners. 11m20s for a cold `realimages` build is faster than it takes on the R620.
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.
rvnminers-A-and-N
Summary
Implements what was agreed in Discussion #655: every commit on
devgets a full CI result, and pull requests never wait behinddevruns on the R620.Changes
devconcurrency groupgithub.ref); a newer push replaced the waiting run (#656)github.sha), never cancelleddevpushessisyphus-ci(the four self-hosted runners on the R620)ubuntu-26.04(GitHub-hosted)sisyphus-cisisyphus-ci(unchanged)ubuntu-26.04ubuntu-26.04(unchanged)The
runs-onexpression oftest,realimagesandrehearsalis inverted, sosisyphus-ciis chosen only for this repository's own pull requests and every other event falls back to hosted. The steps already handle both kinds of runner (runner.environment == 'github-hosted'), since fork PRs run these jobs on hosted runners today.docs/development.mddescribes the newdevbehaviour, and the comments inci.ymlsay why.Cost and trade-offs
devruns are slower on hosted runners, but nothing waits on them.devruns share the org's 20 concurrent hosted jobs with the PR jobs that already run hosted (scope, lint, packaging). A burst of merges queues there, not on the R620.Testing
actionlintpasses.devpush after merging will show the hosted route and the per-commit group.The routing reads right to me. The
runs-onexpression is now an allow-list (sisyphus-cionly for this repo's own non-Dependabot PRs), which is safer than the old deny-list, and grouping push concurrency bygithub.shagives each dev commit its own uncancelled run, which is what Austin asked for. The docs match.One thing to watch on the first dev runs, not a blocker.
realimageson a hosted runner builds every real image cold: no Docker layer cache carries over, unlike on the R620. That set includes Chronos-Bolt's ~4 GB image, and with #712 the ~5.7 GB TimesFM image as well. That is likely more than a standard hosted runner's free disk, and it could also push the job towards its 90-minute timeout. Fork PRs have been taking this route all along, but I don't think one has actually runrealimageson a hosted runner recently. If the first dev run fails on disk space or time, freeing disk at the start of the job (the usualrm -rf /usr/share/dotnet /usr/local/lib/android /opt/ghcstep) or pruning images between tests would probably be enough.The first post-merge
devrun has now completedrealimagesonubuntu-26.04successfully (11m20s), with no disk-space or timeout failure. The hosted route is still finishing its remaining test/desktop/package jobs. /cc @rvnminers-A-and-NThanks, that settles my worry about disk space and the time limit on hosted runners. 11m20s for a cold
realimagesbuild is faster than it takes on the R620.