-
-
Notifications
You must be signed in to change notification settings - Fork 23
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
doesn't seems to do what it should #12
Comments
Can you provide an MRE? I’m guessing your concurrency group is defined with cancel-in-progress set to true. |
Hi ben-z, thanks for answering.
|
Can you indent the code properly in your message? I’d use triple backticks. I see that the branch argument is set to main. Is that intentional? This will use the main branch as the branch to store locks. Usually, we use a separate, empty branch. |
code was indented properly. |
Oh I see, you said
You probably want to not use a concurrency group if you want to have the same workflow protected by a mutex. Just removing the concurrency line should result in what you want. |
Thanks ben-z , it seems to lock a job in the workflow when concurrency group is commented out. |
Ah yep, the mutex works at a job-level and not at a workflow-level. This is mainly because there's no easy way to achieve RAII at a workflow level. It could be possible, but it'd require some investigation. |
I've tried using this action in my workflow which consists of multiple jobs.
when more than 2 workflows are triggered , the second one gets canceled by GitHub.
it doesn't seem to work or I'm missing something.
The text was updated successfully, but these errors were encountered: