Auto-deploy latest proposed plan

We’d love it if there was a halfway between autodeploy being on or off, where tracked runs would autodeploy only if the latest proposed plan for that stack had an identical plan to the tracked run plan.

Our workflow for terraform changes is fairly standard. People make changes, open an MR in Gitlab, and then solicit review. Spacelift comments on the MR with a proposed plan for each stack affected by the change. At the point of approval, we consider both the code change and the proposed plans to have been “approved” - and would be happy for the proposed plan to be automatically applied.

However this currently isn’t possible. We only have the choice between no autodeploy (at which point there is another gate in the tracked run) or autodeploy on (at which point if the environment has drifted for any reason we may apply inadvertant changes that did not show in the proposed plan on the MR)

Ideally we’d be able to select an option that would:

• Have proposed plans work identically to how they currently work

• When an MR is approved and merge, the tracked run it triggers can reference the previous proopsed run

• If the changes in that proposed run match the changes in the tracked run, autodeploy, otherwise hit the standard manual approval gate when autodeploy is off

In terms of implementation, I think it could work a few different ways:

• Have proposed plans save their plans as an artifact of the run, similarly to how tracked runs do when planning. At the point the tracked run is created if this option is turned on rather than running a plan phase go straight to apply with the latest propsed plan artifact. If this applies successfully then we’re done. If it doesn’t, fall back to running a “normal” tracked run, going into the plan phase and then sitting at the manul approval gate

• Have proposed plans save some kind of hash of the plan that captures the changes it would intend to make. At the tracked run stage grab the hash of the last proposed run, then generate a new plan like you would normally in a tracked run, also taking the hash. Compare the two hashes and if they match automatically approve the run. If not go to the manual approval gate

• A variation of the above, just provide a tracked run with access to the last proposed run. This way users can replicate this behaviour with an approval policy, essentially implementing the plan comparison step above in the policy itself