-
Notifications
You must be signed in to change notification settings - Fork 9.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Add a new flag terraform init -lockfile=readonly
to suppress updating .terraform.lock.hcl
#27506
Comments
Fixes hashicorp#27506 Add a new flag `-lockfile=readonly` to `terraform init`. It would be useful to allow us to suppress dependency lockfile changes explicitly. The type of the `-lockfile` flag is string rather than bool, leaving room for future extensions to other behavior variants. The readonly mode suppresses lockfile changes, but should verify checksums against the information already recorded. It should conflict with the `-upgrade` flag. Note: In the original use-case described in hashicorp#27506, I would like to suppress adding zh hashes, but a test code here suppresses adding h1 hashes because it's easy for testing.
We have a similar case, where we use https://github.com/renovatebot/renovate/ to update providers (it may eventually update the lockfiles, but for now, we Would a flag to ignore the lockfile when |
Fixes hashicorp#27506 Add a new flag `-lockfile=readonly` to `terraform init`. It would be useful to allow us to suppress dependency lockfile changes explicitly. The type of the `-lockfile` flag is string rather than bool, leaving room for future extensions to other behavior variants. The readonly mode suppresses lockfile changes, but should verify checksums against the information already recorded. It should conflict with the `-upgrade` flag. Note: In the original use-case described in hashicorp#27506, I would like to suppress adding zh hashes, but a test code here suppresses adding h1 hashes because it's easy for testing.
We would also like to not use the lockfile - I also don't see why we should complicate anything as we use absolute locking already as Hashicorp strongly recommends. And, to make this work also with Terraform Cloud, it'd be great to ignore the new behaviour with an environment variable. |
We also
... Because it encourages engineers to commit the file and break the deployments. |
One other point (could make a new feature request) is that requiring I think, across the board, this feature was rolled out a bit hastily, and seems to have been (to the point of the previous post) a bit over-sold. |
Fixes hashicorp#27506 Add a new flag `-lockfile=readonly` to `terraform init`. It would be useful to allow us to suppress dependency lockfile changes explicitly. The type of the `-lockfile` flag is string rather than bool, leaving room for future extensions to other behavior variants. The readonly mode suppresses lockfile changes, but should verify checksums against the information already recorded. It should conflict with the `-upgrade` flag. Note: In the original use-case described in hashicorp#27506, I would like to suppress adding zh hashes, but a test code here suppresses adding h1 hashes because it's easy for testing.
Fixes #27506 Add a new flag `-lockfile=readonly` to `terraform init`. It would be useful to allow us to suppress dependency lockfile changes explicitly. The type of the `-lockfile` flag is string rather than bool, leaving room for future extensions to other behavior variants. The readonly mode suppresses lockfile changes, but should verify checksums against the information already recorded. It should conflict with the `-upgrade` flag. Note: In the original use-case described in #27506, I would like to suppress adding zh hashes, but a test code here suppresses adding h1 hashes because it's easy for testing. Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>
Fixes #27506 Add a new flag `-lockfile=readonly` to `terraform init`. It would be useful to allow us to suppress dependency lockfile changes explicitly. The type of the `-lockfile` flag is string rather than bool, leaving room for future extensions to other behavior variants. The readonly mode suppresses lockfile changes, but should verify checksums against the information already recorded. It should conflict with the `-upgrade` flag. Note: In the original use-case described in #27506, I would like to suppress adding zh hashes, but a test code here suppresses adding h1 hashes because it's easy for testing. Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>
Fixes hashicorp#27506 Add a new flag `-lockfile=readonly` to `terraform init`. It would be useful to allow us to suppress dependency lockfile changes explicitly. The type of the `-lockfile` flag is string rather than bool, leaving room for future extensions to other behavior variants. The readonly mode suppresses lockfile changes, but should verify checksums against the information already recorded. It should conflict with the `-upgrade` flag. Note: In the original use-case described in hashicorp#27506, I would like to suppress adding zh hashes, but a test code here suppresses adding h1 hashes because it's easy for testing. Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further. |
This feature request was originally proposed in #27264 (comment) . To clarify the scope, I'll split it to a new issue.
Current Terraform Version
Use-cases
I have 200+ root modules and I'm automating a provider version up workflow in CI with tfupdate, which updates all version constraints in Terraform configurations recursively. My laptop is macOS and CI is Linux, so I want to pre-populate hash values for all platforms I need in the workflow to avoid a checksum mismatch error.
I'm looking for an efficient way to maintain
.terraform.lock.hcl
for multiple root modules and platforms environments.To use it on multiple platforms, a lock file should be generated in advance with the
terraform providers lock
command. In addition, I use a local filesystem mirror and cache to avoid redundant duplicate downloads. In such case, only h1 hashes are recorded in.terraform.lock.hcl
.However, the state of the mirror and cache depends on environments in which the terraform command is executed and the current implementation of the
terraform init
command will add zh hashes if neither the mirror nor the cache exists.Since
.terraform.lock.hcl
is intended to commit to a VCS such as Git, the unnecessary change is not desirable. It would be great if we could suppress the lock file change.For more details, see #27264
Attempted Solutions
The lock file contains only h1 hashes.
terraform init
The zh hashes were added to the lock file.
Of course, we can discard the change by using
git checkout .terraform.lock.hcl
, but obviously it's not the best solution.Proposal
Add a new flag
terraform init -lockfile=readonly
to suppress updating.terraform.lock.hcl
.See the comment below for detailed behavior considerations
#27264 (comment)
References
This feature request was originally proposed as a partial workaround for #27264 (comment)
It was inspired by the discussion in #27241 (comment)
So, it may be also useful for the read-only filesystem.
The text was updated successfully, but these errors were encountered: