Rethinking the rollback function in the deployment workflow

[minkimcello]

In #3 we introduced a roll back step in the release workflow for when a new deployment of backstage is not successful. This will work fine in most cases but there will be a problem when we have two merge commits happen back-to-back and if the resulting image of both those pull requests are not healthy.

This problem will occur if the first deployment workflow is at the kubectl rollout status step (which lasts for 60 seconds for a bad deployment) and the second deployment workflow (running concurrently) runs helm upgrade --install min-backstage-chart.

The upgrade of the second workflow run will extend/prolong the kubectl rollout status step of the first workflow run.

At this point we'll have a chart history that looks like this:

good deployment 1
bad deployment 2 (first workflow run)
bad deployment 3 (second workflow run)

The failing result of the kubectl rollout status will rollback from bad deployment 3 to bad deployment 2 and the chart history will become:

good chart 1
bad deployment 2
bad deployment 3
bad deployment 2 (as 4)

We have the workflow configured to prevent parallel runs but the same problem persists if the first workflow gets past the helm upgrade --install min-backstage-chart step.