-
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
.terraform.lock.hcl contains hashes for manifest.json files. #33599
Comments
Hi @sodul, Terraform does not make any assumptions about what the filenames in your SHA256SUMS file might mean, or try to guess which ones are really packages and which ones aren't. Instead, Terraform expects that you will only include valid package checksums in that file, and exclude everything else. Given that, I'm now wondering how you have ended up with a manifest file listed in your package checksums. Were you following some documentation that suggested you should do that? If so, I think we should correct that documentation so that the generated checksums file will be correct, rather than changing Terraform's behavior. The filenames listed in the checksums file are not meaningful to Terraform and to start making assumptions about how they are named now would be a potential breaking change for existing published providers that might use different filenames (since the specific filenames chosen have been, so far, only a private detail chosen by the provider package build process). |
@apparentlymart we do not have any custom logic for the checksum, we just call I think the issue is that for the Hashicorp providers the We have noticed this pattern with official Hashicorp providers, third party providers do not have that issue. BTW, since we only care about a limited number of platforms it would be quite nice if |
Ahh, sorry for the misunderstanding. I thought you were reporting that a provider you created was being treated in this way, but I see now that you were referring to In that case, I think the problem here is that the release process for the official providers seems to be incorrectly including the manifest file in the set of files it considers when calculating the Thanks for reporting this, and sorry for the misunderstanding! I do also acknowledge your addendum about only recording a subset of the checksums. Let's keep that a separate concern because it would require changing the provider registry protocol to explicitly distinguish between checksums for each target platform, rather than just reporting them all together with no indication of which is which. (While as humans we can infer that the filename containing The existing issue #27264 is already covering an improvement to the checksum management that would require changing the registry protocol -- to be able to return more than just |
I have filed hashicorp/ghaction-terraform-provider-release#81 at the request of the team that takes care of releasing our providers, or setting the conventions for releasing them to be more specific. |
Terraform Version
Terraform Configuration Files
not relevant, pretty much any workspace that includes hashicorp providers.
Debug Output
not relevant
Expected Behavior
The
.terraform.lock.hcl
file should only contain hashes of actual providers binaries.Actual Behavior
The
zh:
hash for the manifest.json files are included.In this case the last hash is from https://github.com/hashicorp/terraform-provider-consul/releases/download/v2.18.0/terraform-provider-consul_2.18.0_SHA256SUMS
Steps to Reproduce
terraform init
Additional Context
This is not a very serious bug, but the fact is that the lock is referencing hash of files are not invalid. We noticed that while reviewing an update of our providers and that for hashicorp providers there was one
zh:
line that remained constant, but not for third party providers.Something that
terraform
could do when parsing the SHA256SUM files is to filter out the non zip files. If it turns out that the manifest.json checksum are actually intentionally provided and used, then ignore this report.References
No response
The text was updated successfully, but these errors were encountered: