-
-
Notifications
You must be signed in to change notification settings - Fork 2.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add "concurrency" to GitHub Actions #6621
Conversation
…ed in favor of new runs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm good with this, we just added this to the CI at work.
We have something similar with Travis CI:
And AppVeyor:
The key difference is already-running builds are not cancelled for Travis (and not configurable) or AppVeyor (configurable but we haven't done so).
We can allow already-running builds to continue with GHA using cancel-in-progress: true
or omitting it.
But I'm tempted to let it cancel, we have a pretty big CI matrix nowadays.
concurrency: | ||
group: ${{ github.workflow }}-${{ github.ref }} | ||
cancel-in-progress: true | ||
|
||
jobs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concurrency: | |
group: ${{ github.workflow }}-${{ github.ref }} | |
cancel-in-progress: true | |
jobs: | |
jobs: |
I don't think this is necessary, as stale only runs once a day.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This and tidelift.yml
can also be triggered manually via workflow_dispatch:
, so potentially could have more than one in the queue at once.
But I've no strong opinion either way.
concurrency: | ||
group: ${{ github.workflow }}-${{ github.ref }} | ||
cancel-in-progress: true | ||
|
||
jobs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concurrency: | |
group: ${{ github.workflow }}-${{ github.ref }} | |
cancel-in-progress: true | |
jobs: | |
jobs: |
I don't think this is necessary, as Tidelift Align only runs once a day.
concurrency: | ||
group: ${{ github.workflow }}-${{ github.ref }} | ||
cancel-in-progress: true | ||
|
||
jobs: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
concurrency: | |
group: ${{ github.workflow }}-${{ github.ref }} | |
cancel-in-progress: true | |
jobs: | |
jobs: |
Feel free to give thoughts on this, but... I kind of don't want to cancel the release drafter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It doesn't really matter as it only takes about 15s, but it's safe to cancel as we only need it to run once:
when it runs it looks at the current state of merged PRs and overwrites the previous draft.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Although two different runs from two different merges will have different ${{ github.ref }}
so won't be cancellable.
However, manual triggers via workflow_dispatch
could have the same ref
. Again, no strong opinion either way for this.
This will cancel outdated jobs in favor of new jobs. So if you push some changes, and then push some more changes while the first changes are still being tested, the first tests will be cancelled in favor of the new tests.
Also if you reset to the previous commit and force push that, it will actually un-cancel the previously cancelled tests for that commit.
https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#concurrency
https://docs.github.com/en/actions/learn-github-actions/contexts#github-context