1

First of all I am aware of the accepted answer for the following question:

Should .terraform.lock.hcl be included in the .gitignore file?

That's why I version the lock file. But (maybe because I don't fully understand the answer) I fail to infer from it how to deal with the lock file across branches representing different stages / environments.

Let me explain.

The project repo has three branches: dev, test, prod

Those branches correspond to three different GCP projects representing respective environments. Branch dev is deployed to project dev etc. The deployment workflow then is to merge branches from dev to test to prod.

But if the lock file represents the terraform state then wouldn't merging a lock file from dev to test and from test to prod be introducing a mismatch or conflict of actual state of the environment and the state encoded in the lock file? Because the branch of test then holds the state of dev and so on.

Raffael
  • 19,547
  • 15
  • 82
  • 160
  • 1
    The `.terraform.lock.hcl` is used to keep track of provider version. If you specify this version in your provider block, then I guess you don't have to commit it? The state itself is handled by the state file. – Mornor Dec 10 '21 at 10:59
  • I don't specify the provider version in the the provider block. that would mean merging the lock file across environments is recommended and no problem, right? – Raffael Dec 10 '21 at 11:05
  • But really it would be better to have good specifications for version range requirements for providers and modules in your config. If you cannot enforce these best practices, then you will need to backup to using that lock file. However, it does not need to be merged between workspaces, because it should be tied to a specific state. – Matthew Schuchard Dec 10 '21 at 13:39

0 Answers0