minute 0: r101-graph merges to master, triggers emp v2, which puts a message on the release queue
and triggers stacks which triggers stacker-runner
minute 2: russell merges PR on stacks to change env var on r101-api, which triggers stacker-runner
minute 5: r101-pipes merges to master, which triggers empv2, which puts another message on the release
queue and triggers stacks which triggers stacker-runner.
stacker-runner always uses the latest master docker image, which might not reflect the latest merge to stacks master.
If there is a message in the queue, we just run that specific apps stack. We have two messages in the queue so the next
two stacker-runner executions will be single stack runs, even though there was an env var merge in between.
Because the minute 2 and minute 5 releases switched places, the stacks docker image
is not in the proper state when the releases are reordered.
Build stacks docker image in codebuild again.
Cons: will add 90 seconds to every release.
Build something (a lambda which gets a github webhook?) to post a message to the
SQS release queue whenever a PR is merged to stacks master, or a commit is added to stacks master.
Cons: Adds even more complexity
Compare the stack's docker image creation date to the SQS release queue message sent timestamp.
If the release message timestamp is greater than the docker image timestamp, skip the message.
Cons: might have edge cases