Perspective on why terraform plan is run with -lock=false and has no ability to manipulate the option

[ojintoad]

Howdy 👋

I am curious to understand why this PR seemed to introduce a forced "-lock=false" option to Terraform plan without any option to override?

#121

Documentation I am reading that doesn't mention lock options:

https://github.com/dflook/terraform-github-actions/tree/403978dff9a8123caa0d2fc0d25171e289543d38/terraform-plan

I have not actually hit an issue which is why I chose a discussion. My context was I was attempting to verify the introduction of an s3 state lock mechanism and assumed that plan would lock since that's the default for terraform. It appears I'll need another method, which is reasonable.

I do see locking on plan is sort of a debated topic within the Terraform community and while documentation does not recommend disabling it, it appears to be a contextual choice:

hashicorp/terraform#28130
https://discuss.hashicorp.com/t/why-does-a-plan-lock-the-state-file/3520/10

I did search for previous issues/discussion and went to the blame to see if it had anything. I don't see anyone mentioning this. If I missed something my bad. This is truly an ask for perspective. I am learning terraform and am curious of your take given the expertise here.

Thank you!

[dflook]

Hi @ojintoad.

The dflook/terraform-plan (and dflook/terraform-check) actions run terraform plan with -lock=false because they do not write to the state. But the dflook/terraform-apply action does modify the state file, so it runs terraform plan with the state lock enabled (it will then run terraform apply, again with a state lock). So they both run terraform plan, the difference is if the github action as a whole could modify the state file.

Think of the plan action as creating a speculative plan - what would happen if this change was applied right now? If we locked the state while we did this, then:

1. Other plan (or apply) actions would have to wait for us to finish, even though it won't change what they do since the state won't be modified.
2. The plan would have to wait for any in progress apply to finish, which could actually change what the resulting plan is!

The second point sounds like a reason to lock the state, but at the time we review/apply the plan it could still easily be out of date due to the nature of concurrent CI jobs and asychronous PRs.

These actions were specifically designed to work well with busy repos that have multiple open PRs, that may not be merged in any kind of predictable order, and have plans that take quite a while to run.

When the terraform-apply action runs, it will generate a new plan (using a state lock) and compare it to the plan from the terraform-plan action - if they are the same then it will be applied. If the plan has changed then it will abort by default. One reason the plan could have changed is another apply operation changed something - but locking the state file for the original plan doesn't prevent that.

[ojintoad]

@dflook That all makes sense. Having an answer on the record for the motivation helps. If we ever run into any functional issues with this we'll report but given no one else seems to have reported any, it seems unlikely we will either. Thanks for the response!