We have a very simple project, setup in AWS and deployed with github actions. It consists of:

1) An API that runs on lambda.

2) An ECS Fargate task that is instantiated by the lambda.

Everything is working great and as intended, except for our approach with CICD pipelines.

Currently, for the ECS container, a build is made when a PR is made. It is then deployed to the dev environment in AWS. Once we are happy to promote the build, we approve and merge the PR.

This triggers a workflow that simply promotes the image to the higher environments, stg and prd, by changing the tag on the image. So it starts with a "dev" tag so the dev environment knows to pick it up when the fargate task is called, then the workflow will add "stg" or "prd" tags to the same image in the same ECR to promote the image. This ensures that it is built once and the same image that is tested and approved is used in prd.

However, this results in the following:

1) Feature branch A is made, and commit A is created before pull request A is also made to build image A.

2) At the same time, feature branch B is made (off of the same main branch), with commit B and pull request B is created to build image B.

3) Pull request A is merged, and image A, with commit A, is promoted to prod. Nice!

4) Pull request B is merged, and image B, with commit B, is promoted to prod. Nice! Except, commit A is not there, because feature branch B branched off of main before commit A was merged in.

Hope that explains the problem, thus far this is a small project and not an issue, but it will be a problem as we start to scale up the complexity. What should we be doing here? Am I missing an obvious pattern? It feels like ensuring the build once pattern has resulted in this.