Use Case
Currently, the deploy.yml action triggers on any pushes to the main branch, and writes to the staging bucket.
The promote.yml action triggers on new tags pushed to main, and copies the contents of the staging bucket to the production bucket.
When a new commit with a release tag is made, both of these actions trigger at the same time, and promote.yml usually completes before deploy.yml can build and write to the staging bucket. This causes a race condition where the release made in the production bucket is one version out of date.
Solution
Chain the deploy.yml and promote.yml actions together, possibly by making them part of the same action, to prevent the race condition.
Alternatives
Please describe any alternatives you've considered, even if you've dismissed them
Use Case
Currently, the
deploy.ymlaction triggers on any pushes to themainbranch, and writes to the staging bucket.The
promote.ymlaction triggers on new tags pushed tomain, and copies the contents of the staging bucket to the production bucket.When a new commit with a release tag is made, both of these actions trigger at the same time, and
promote.ymlusually completes beforedeploy.ymlcan build and write to the staging bucket. This causes a race condition where the release made in the production bucket is one version out of date.Solution
Chain the
deploy.ymlandpromote.ymlactions together, possibly by making them part of the same action, to prevent the race condition.Alternatives
Please describe any alternatives you've considered, even if you've dismissed them