-
-
Notifications
You must be signed in to change notification settings - Fork 114
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
Documentation: Compare with native concurrency
key
#76
Comments
That looks really cool - appears to be nice for cases where you want to cancel previous of same workflow - plus obviously for things where you are interested in making sure multiple jobs don't run in parallel But it does not handle other-workflow cancel or the new (super useful) all_but_latest feature here |
Very cool! Looks like its still in beta and subject to change though. https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#concurrency |
Yep, it also seems to not work as expected right now: |
Trying to implement the
implementation in workflow for context:
What is wrong with my implementation at the job level? |
Also mentioned here #133 (comment) |
GitHub has announced that workflows "now support a
concurrency
key at both the workflow and job level that will ensure that only a single run or job is in progress". The syntax documentation has already been updated:I'm wondering if it would be helpful to document in the readme what the differences are and which implementation might be more useful depending on use cases. I think this will be helpful for anyone currently using this action and thinking about switching but even for new users. Any thoughts?
The text was updated successfully, but these errors were encountered: