Derrick Stolee <derrickstolee@xxxxxxxxxx> writes: > On 11/3/22 9:34 AM, Johannes Schindelin via GitGitGadget wrote: >> From: Johannes Schindelin <johannes.schindelin@xxxxxx> >> >> Whenever a branch is pushed to a repository which has GitHub Actions >> enabled, a bunch of new workflow runs are started. >> >> We sometimes see contributors push multiple branch updates in rapid >> succession, which in conjunction with the impressive time swallowed by >> even just a single CI build frequently leads to many queued-up runs. >> >> This is particularly problematic in the case of Pull Requests where a >> single contributor can easily (inadvertently) prevent timely builds for >> other contributors. > > As someone who is both the cause and the victim of this, I > thank you for finding a way to reduce wasted CPU time. This > patch looks good to me, though I'll need to trust the docs > and your testing to be sure it will work. We will definitely > see it in place as it merges into 'next' and 'main'. When I see breakages of 'seen' only at the CI, perhaps because it manifests only on macOS, I manually "bisected" by pushing various combinations of topics merged on top of 'master' and pushing the result out as 'seen' only to the GitHub repository, and not having to wait one to finish before pushing out another was a really nice feature. Of course, I could wait before pushing another out, but after seeing the last one close to successful completion in a few minutes and being able to push out the next one was a great timesaver, not only for the "few minutes", but for the countless minutes because I will have to concentrate on more than just a "few minutes" on another task if I have to switch to another task in order to wait for just a "few minutes" before pushing the trial merge out. So, that is the only concern I have with this change, but in general, not running jobs whose results are clearly not needed is a good idea. It just is "clearly" is hard to determine automatically.
