added concurrency group to prevent concurrent workflow executions#141
added concurrency group to prevent concurrent workflow executions#141zlowen wants to merge 1 commit into
Conversation
| # Will queue 1 PENDING workflow run. New incoming runs cancel & replace the pending run | ||
| concurrency: | ||
| group: ${{ github.workflow }}-${{ github.ref }} | ||
| queue: single |
There was a problem hiding this comment.
There are two options for functionality:
single (default): At most one job or workflow run can be pending in the concurrency group. When a new job or workflow run is queued, any existing pending job or workflow run in the same group is canceled and replaced.
max: Up to 100 jobs or workflow runs can be pending in the concurrency group. When the queue is full, any additional jobs or workflow runs are canceled. (non configurable. 100 count is baked in)
To me it makes sense to use single. That way if a dev is makes multiple commits in quick succession the workflow will only use the most recent. I don't think we would need the intermediate builds. Open to hear others' thoughts on this.
flufflycthu1u
left a comment
flufflycthu1u
left a comment
There was a problem hiding this comment.
Looks good to me. I do think we could probably use queue: max for prod since we only really trigger it via cron job, but I'm ambivalent on actually making that change.
2 participants
Added a concurrency group to the Prod and Dev workflows. Building the key as a composite of
workflow+refallows each branch/tag to maintain it's own concurrency.Tested functionality with Dev and the workflows queue properly
