Repository navigation
Expire pull request artifacts sooner and cancel superseded runs - #623
Conversation
A pull request build is worth downloading while the pull request is open and not much after it, and a second push to a branch starts a full matrix build beside the one already running rather than replacing it. * Keep what a pull request uploads for a week, and everything master and the tags upload for the 90 days they are kept now * Group runs by pull request so a push replaces the run in flight, and fall back to the run id everywhere else, which gives master and tag builds a group each and leaves them to finish
4bc9ff9 to
8241fd6
Compare
|
Screenshot differs: emulatorApi=arm64 with 4 screenshot(s) |
|
|
||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }} | ||
| cancel-in-progress: true |
There was a problem hiding this comment.
@goneng
Everything comes with an disadvantage. With this I can't test stuff in parallel, so it serialize the observations in CI
There was a problem hiding this comment.
@hannesa2 , Fair point, and it was my suggestion, so let me offer a way out...
Since 13 Sep the rule has cancelled four runs on your screenshot PRs
(#658, #661, #681), including one this morning, so it is costing you
observations rather than just theory.
Two options, your pick:
-
A per-PR opt out, so the PRs where you compare artifacts keep every run:
concurrency: group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }} cancel-in-progress: ${{ !contains(github.event.pull_request.labels.*.name, 'keep-runs') }}
Put the
keep-runslabel on before you push and nothing is cancelled there.
(The expression is read when the run is created, so labeling mid-run does not
rescue a run already going.) -
Drop the three lines.
What CI: Expire PR artifacts sooner and cancel superseded CI runs #615 was really about was retention-days on the artifacts, and that stays either way.
Cancelling mostly buys queue slots.
Say which you prefer and I will open the PR. Gating on draft instead would not
help, since all my PRs start as drafts.
There was a problem hiding this comment.
Option 1 sounds good
On it!
Cancelling a superseded run throws away the artifacts it would have uploaded, which is the very thing the screenshot experiments in gitx#658, gitx#661 and gitx#681 exist to look at, and it makes each variant wait for the running build before it can start. Raised by hannesa2 on gitx#623. - Read cancel-in-progress from the pull request's labels, so that a pull request labelled keep-runs runs every push to completion - Leave every other pull request cancelling as it does now, and master and tag builds untouched, since their group is keyed per run
Closes #615, as agreed there.
Retention. The four
upload-artifactsteps set nothing, so everythingfalls back to the 90 day default and a pull request build (~21 MB across
dmg and zip per arch) is kept as long as a release. They now keep a
pull request's uploads for a week and leave master and tag uploads at 90:
The same line is on all four steps, including the two screenshot ones
that only run on pull requests today, so the value stays right if those
conditions ever change.
Concurrency. A second push to a branch starts another full matrix
build beside the one already running. Grouping by pull request number
replaces it instead:
The fallback is what keeps master and tag builds safe: off a pull request
github.event.pull_request.numberis empty, so each run falls back to itsown run id, gets a group to itself and is never cancelled by a later one.
Test plan
this workflow, so its artifacts should expire in 7 days rather than 90
a superseded run then shows as cancelled, which is the point of it