Draft: Allow developers to use the Terraform template out of the box
What does this MR do and why?
The Terraform state lock can only be acquired by Maintainers
. However, the Terraform state itself can be read by Developers
, too.
In a scenario where you want Developers
to be able to contribute IaC changes in a Merge Request it is important that the MR pipeline can plan
the change. Prior to the change in this MR that is not possible because gitlab-terraform plan
locks the state (so does terraform plan
).
According to a Terraform Maintainer terraform plan
only locks the state, because the underlying remote state store may write to the state and because there is a risk that a terraform apply
writes to the state while plan
reads it which would corrupt the state.
The first point is (AFAIK) not the case for the GitLab-managed Terraform state. The second risk with the concurrent apply
is one, thought when only the pipeline writes to the state it's not a risk, because the jobs all use the same resource_group
and thus have a lock on the GitLab pipeline job level. The risk applies when someone pushed to the state outside of the pipeline while the pipeline is running.
The impact of this is that the terraform plan
fails - the state isn't harmed.
IMHO: it's a sensible default to NOT lock the state during a plan in the Terraform template to allow for the aforementioned use case out of the box. The risks are mostly mitigated and the impact if the risk occurs is rather low.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.