terraform-provider-local: Error: Failed to install provider v2.2.0

Terraform CLI and Provider Versions

Terraform CLI: 1.0.11 Provider: hashicorp/local v2.2.0

Terraform Configuration

n/a

Expected Behavior

When running terraform init it downloads the provider.

Actual Behavior

When running terraform init it throws an error message.

╷
│ Error: Failed to install provider
│ 
│ Error while installing hashicorp/local v2.2.0: archive has incorrect checksum zh:507776b1e1901fdd6450a88298fc87a27a508e0c01405c7e8e8f2037d5963afe (expected
│ zh:f427480d3ec953434eccf21544b0b2be63595634e4e79a53575ceb892f22230d)
╵

Steps to Reproduce

  1. terraform init

How much impact is this issue causing?

Medium

Logs

No response

Additional Information

No response

Code of Conduct

  • I agree to follow this project’s Code of Conduct

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 72
  • Comments: 26 (2 by maintainers)

Most upvoted comments

Hi folks 👋 Thank you for reporting this and apologies for the unexpected 2.2.0 release issue. A new 2.2.1 release has been published to releases.hashicorp.com and the public Terraform Registry. Can you confirm that the new release is working as expected?

Quickfix is locking it to v2.1.0

local = {
  source = "hashicorp/local"
  version = "= 2.1.0"
}

@spliskamatyshak please share where! My attempts so far have not been effective.

I had a versions.tf with another provider defined. I added it in our module that ultimately calls the registry module. If you don’t have versions specified, you should be able to just add it.

terraform {
  required_version = ">= 1.0"
  required_providers {
    local = {
      source = "hashicorp/local"
      version = "2.1.0"
    }
  }
}

It is still failing for me with a job launched after the “Checksum has been updated” comment.

I think it hasn’t been published yet due to CDN distributions https://registry.terraform.io/providers/hashicorp/local/latest

It is still failing for me with a job launched after the “Checksum has been updated” comment.

Apologies folks, there was an issue with our release automation when I prepared 2.2.0, this caused binary and checksums being built against 2 different consecutive commits.

Closing.

This needs to be escalated. All of our deployments that use registry modules with local included are failing.

Well this shows me I need to use lockfiles! If only the m1 mac issues requiring manually patched providers didn’t make things complicated using both arm/x86 deployment architectures!