Use GitHub Action's concurrency support to avoid simultaneous deployments
rasmuslund opened this issue · 5 comments
What can we improve?
Instead of using SQS and a Lambda to avoid concurrent deploys, you should be using the concurrency support in GitHub Actions, which handles exactly that.
From the docs:
When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. Any previously pending job or workflow in the concurrency group will be canceled
Read about concurrency in the docs.
Version
latest
Suggested Changes
No response
Thanks a lot for your input. That's indeed an interesting idea because it uses a native GitHub feature instead of custom code. We'll look into this.
@rasmuslund We've now discussed this in some more detail. While the native GitHub Actions feature has the advantage of being much simpler both in terms of architecture and regarding actual usage (due to fewer moving parts) it has the slight downside that it'll trigger a build for each commit (even if that build is then cancelled by a subsequent commit) whereas the SQS / Lambda will only trigger another build for the latest subsequent commit.
Nonetheless, using the GitHub Actions concurrency feature probably is the more easily accessible approach in most cases. We'll add a paragraph to the book with a link to the relevant section in the GitHub documentation to make readers aware of this alternative.
Thanks again for your feedback and this useful suggestion!
it has the slight downside that it'll trigger a build for each commit
Actually, reading the docs again with a fresh mind, this doesn't seem to be the case:
When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. Any previously pending job or workflow in the concurrency group will be canceled. To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.
It seems that this is doing exactly what our Lambda is doing. Either this feature didn't exist when we wrote about it, or we missed it :). Thanks @rasmuslund for the feedback, we'll surely pick it up in the next version of the book.
it has the slight downside that it'll trigger a build for each commit
Actually, reading the docs again with a fresh mind, this doesn't seem to be the case:
When a concurrent job or workflow is queued, if another job or workflow using the same concurrency group in the repository is in progress, the queued job or workflow will be pending. Any previously pending job or workflow in the concurrency group will be canceled. To also cancel any currently running job or workflow in the same concurrency group, specify cancel-in-progress: true.
It seems that this is doing exactly what our Lambda is doing. Either this feature didn't exist when we wrote about it, or we missed it :). Thanks @rasmuslund for the feedback, we'll surely pick it up in the next version of the book.
@thombergs as a recommendation I'd say:
If you prefer this new approach for any reason and use it in the book, try to leave the lambda one as a side note or as an alternative.
I have personally found it very useful with some decoupled repositories which communicate (via deployment triggers) using the lambda approach. (I have an application repo -- the actual app code -- which triggers by using github actions the sqs event and the lambda executes the actual ecs stack update in another "deployer" repo by calling that other repor actions API ... just the same you described in the book)
The latest version of the ebook now contains some more information about this feature.