provider block for github shows as invalid for an empty app_auth block

[scott-doyland-burrows]

Extension Version

v2.82.2

VS Code Version

Version: 1.82.2 (user setup)
Commit: abd2f3db4bdb28f9e95536dfa84d8479f1eb312d
Date: 2023-09-14T05:55:25.390Z
Electron: 25.8.1
ElectronBuildId: 23779380
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.19044

Operating System

Windows 10 using WSL

Terraform Version

Terraform v1.6.1 on linux_amd64

Steps to Reproduce

Create a provider block as per the terraform configuration below and it shows an invalid app_auth block:

However, the app_auth block shown is valid - it can be empty as the values required can be passed in as environment variables.

Terraform works fine with the code as shown, and terraform fmt shows no issues.

Expected Behavior

The app_auth block should show as valid.

Actual Behavior

Terraform Configuration

terraform {
  cloud {
  }

  required_providers {
    github = {
      source = "integrations/github"
    }
  }
}

provider "github" {
  alias = "some-alias"
  owner = "some-owner"

  app_auth {}
}

Project Structure

N/A

Gist

No response

Anything Else?

No response

Workarounds

No response

References

No response

Help Wanted

• I'm interested in contributing a fix myself

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[radeksimko]

Hey @scott-doyland-burrows
Thanks for finding another bug and describing it in detail. It's greatly appreciated.

I was able to reproduce it.

It looks like this is an interesting edge case of how the schema, as codified in https://github.com/integrations/terraform-provider-github/blob/4a5ab5f5b08813c52cbf2f7b917aabd7fda623cd/github/provider.go#L69-L97 gets interpreted.

As per the linked LOC, the fields under the app_auth block are indeed considered required. We'll have to look into how this is handled inside of Terraform Core and why. I recall that providers were more recently discouraged from using blocks, in favour of attributes of complex types and I assume this edge case may be one of the reasons but I don't have all the details.

Either way the validation should reflect the behaviour of Terraform Core/CLI.

[dbanck]

After debugging this and looking into the schema, it turns out everything might be working as expected.

If a resources uses the github provider, you end up with validation errors in Terraform

terraform {
  required_providers {
    github = {
      source = "integrations/github"
    }
  }
}

provider "github" {
  alias = "some-alias"
  owner = "some-owner"

  app_auth {}
}

resource "github_actions_environment_secret" "name" {
  provider = github.some-alias

  environment = "value"
  repository  = "value"
  secret_name = "value"
}

Running terraform validate will produce the same validation errors, we're currently reporting inside the editor.

❯ terraform validate
╷
│ Error: Missing required argument
│ 
│   on main.tf line 13, in provider "github":
│   13:   app_auth {}
│ 
│ The argument "pem_file" is required, but no definition was found.
╵
╷
│ Error: Missing required argument
│ 
│   on main.tf line 13, in provider "github":
│   13:   app_auth {}
│ 
│ The argument "id" is required, but no definition was found.
╵
╷
│ Error: Missing required argument
│ 
│   on main.tf line 13, in provider "github":
│   13:   app_auth {}
│ 
│ The argument "installation_id" is required, but no definition was found.
╵

So the question we can discuss here is: Do we want to suppress errors for unused providers?

@scott-doyland-burrows Are you using the provider anywhere in your configuration? If not, would you be able to get rid of the provider block?

[scott-doyland-burrows]

I am not sure what you mean by:

Are you using the provider anywhere in your configuration? If not, would you be able to get rid of the provider block?

I am using the provider as below:

If I set the following - which is what I want to do, as the app_auth {} block will obtain it's values from environment variables:

terraform {

  required_providers {
    github = {
      source  = "integrations/github"
      version = "5.40.0"
    }
  }
}

provider "github" {
  owner = "scott-doyland-02"

  app_auth {}
}

resource "github_team_members" "members" {
  team_id = "scott-team01"

  members {
    username = "scott-doyland-burrows"
    role     = "maintainer"
  }
}

If I do NOT set environment variables for the following, then terraform validate will have errors.

GITHUB_APP_ID
GITHUB_APP_INSTALLATION_ID
GITHUB_APP_PEM_FILE

I set the above environment variables then terraform validate works.

However, vscode still shows the errors.

Does the vscode extension actually use the github provider itself to see what is/isn't required? If so then I guess it is working as designed from a provider point of view, but it is then impossible for vscode to behave as we would want. vscode doesn't know I have the environment variables set.

[dbanck]

Thank you for the additional context, @scott-doyland-burrows. The provider alias had me confused.

I can reproduce the behavior and we will look into solutions. But you're right that it might be difficult, because inside VS Code we don't know about most environment variables.

[radeksimko]

Thanks for the report, I have opened #1616 to describe the problem in a more general way and added some context. It is something we will likely have to address soon as it's obviously wrong/misleading.

I also filed hashicorp/terraform-ls#1481 which relates to the other problem we ran into while trying to reproduce the problem earlier.

For now I'm going to close this issue but feel free to subscribe to either of the two new issues.

[github-actions]

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.