Using modules requires hashicorp/github

[Anton-Shutik]

Hi there,

The issue is that it installs hashicorp/github dependency if using terraform module

Terraform Version

Terraform v0.14.6

Affected Resource(s)

• modules

Terraform Configuration Files

providers.tf:

terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = "~> 4.4.0"
    }
  }
  required_version = ">= 0.12"
}

provider github {
  token         = ""
  organization  = ""
}

Expected Behavior

terraform init
terraform providers

Providers required by configuration:
.
└── provider[registry.terraform.io/integrations/github] ~> 4.4.0

Actual Behavior

terraform init
terraform providers

Providers required by configuration:
.
├── provider[registry.terraform.io/integrations/github] ~> 4.4.0
└── module.github
    └── provider[registry.terraform.io/hashicorp/github]

Steps to Reproduce

main.tf

module "github" {
    source  = "./modules"

}

and run terraform init & terraform providers

[thekbb]

I'm seeing the same - with terraform 13.5, I cannot replace the references with:

terraform state replace-provider hashicorp/github integrations/github

[tibbes]

@Anton-Shutik, I can only reproduce this if none of the .tf files in the github directory have a required_providers section that refers to integrations/github (either because there is no required_providers section at all, or it uses the old terraform syntax of github = "X.Y.Z"). This makes the module implicitly refer to hashicorp/github.

The Terraform documentation mentions in a note the following:

Note: Only provider configurations are inherited by child modules, not provider source or version requirements. Each module must declare its own provider requirements. This is especially important for non-HashiCorp providers.

Can you try adding a section like the following to a file in the github module directory?

terraform {
  required_providers {
    github = {
      source  = "integrations/github"
      version = ">= 4.4.0" // or whatever version range you wish
    }
  }
}

[bleachbyte]

Bumping this, as we're running into a similar issue and can demonstrate it in a different way:

Our original config that made this come up:

1. versions.tf file in a top directory, referencing a specific version number for integrations/github (and not hashicorp/github)
2. a .terraform.lock.hcl file, with hashes for integrations/github at the version specified in versions.tf
3. In terraform/modules:

• a directory, my_module, whose main.tf contains a data source, data "github_ip_ranges" "ips"

3. In terraform/myapp/module:

• in main.tf, a data source data "github_ip_ranges" "ips"
• in module.tf, a module resource whose source is ../modules/my_module
• .terraform.lock.hcl andversions.tf, symlinked from the top-directory files

With this config, running init would cause Terraform to look for both integrations/github AND hashicorp/github -- despite the fact that the latter is not referenced anywhere in our codebase (it's also not in any local cache/plugin-cache directories, at least not before init runs and pulls it down):

Initializing provider plugins...
- Reusing previous version of integrations/github from the dependency lock file
- Finding latest version of hashicorp/github...
[...deletia...]
- Using previously-installed integrations/github v4.19.1
- Installing hashicorp/github v4.19.2...
- Installed hashicorp/github v4.19.2 (signed by HashiCorp)

Neither versions.tf nor .terraform.lock.hcl references hashicorp/github, and we run Terraform commands with -lockfile=readonly so that the same lock file can be used across our directories, so init complains that it can't update said lock file:

│ Warning: Additional provider information from registry
│ 
│ The remote registry returned warnings for registry.terraform.io/hashicorp/github:
│ - For users on Terraform 0.13 or greater, this provider has moved to integrations/github.
│   Please update your source in required_providers.
│

│
│ Error: Provider dependency changes detected
│ 
│ Changes to the required provider dependencies were detected, but the lock file is read-only.
│ To use and record these requirements, run "terraform init" without the "-lockfile=readonly"
│ flag.

This turned out to be because we had two (conflicting, apparently) data.github_ip_ranges.ips sources:

• module.main.data.github_ip_ranges.ips
• module.main.module.my_module.data.github_ip_ranges.ips

We updated my_module to use a variable -- instead of its own data.github_ip_ranges.ips source -- and then passed in the main-level data.github_ip_ranges.ips value into my_module via that variable. As soon as this change was put in place, subsequent init operations only downloaded integrations/github, and hashicorp/github was no longer sought out.

In tree form:

Problematic config:

terraform/
├── myapp
│ ├── myenv
│ │ ├── env-vars.sh
│ │ └── main.tf # <--- data.github_ip_ranges.ips declared
│ └── module
│   ├── main.tf # <--- module.myapp_module declared (source: ../modules/my_module)
│   ├── .terraform.lock.hcl -> ../../.terraform.lock.hcl
│   └── versions.tf         -> ../../versions.tf
├── modules
│   └── my_module
│     └── main.tf # <--- data.github_ip_ranges.ips declared
├── .terraform.lock.hcl
└── versions.tf

Fixed:

terraform/
├── myapp
│ ├── myenv
│ │ ├── env-vars.sh
│ │ └── main.tf # <--- data.github_ip_ranges.ips declared, passed to local.github_ips
│ └── module
│   ├── main.tf # <--- module.myapp_module declared, var.github_ip_range = local.github_ips
│   ├── .terraform.lock.hcl -> ../../.terraform.lock.hcl
│   └── versions.tf         -> ../../versions.tf
├── modules
│   └── my_module
│     └── main.tf # <--- contains variable "github_ip_range"
├── .terraform.lock.hcl
└── versions.tf

[github-actions]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!

[github-actions]

👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!