On Tue, 22 Feb 2022 07:05:40 GMT, Aleksey Shipilev <sh...@openjdk.org> wrote:

> Since last year, GHA allows concurrency control over GHA runs:
>  
> https://github.blog/changelog/2021-04-19-github-actions-limit-workflow-run-or-job-concurrency/
>  
> https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
> 
> Our GHA workflows trigger on every PR update, sometimes doing multiple runs 
> per PR. This is seldom useful and wastes resources with our very large jobs. 
> For example, one can push a commit, quickly realize there is a mistake, push 
> another commit, and this would do *two* GHA runs, both taking many hours.
> 
> I think we can say that only one run per branch is good, and all 
> running/pending runs should be cancelled when a new run starts.
> 
> Additional testing:
>  - [x] Verified queued run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on new commit
>  - [x] Verified in-progress run gets cancelled on merge
>  - [x] Verified in-progress run gets cancelled on rebase + force-push

I realized that we would be better off specializing by workflow name as well. 
While we only have one workflow in the upstream repo, others might have more 
than one referenced by the same concurrency key. To avoid surprises, we can 
should also mix in `github.workflow`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/7570

Reply via email to