integrations / terraform-provider-github

Terraform GitHub provider
https://www.terraform.io/docs/providers/github/
MIT License
887 stars 730 forks source link

[BUG]: existing repository_webhook removed from state if token doesn't have hook permissions #2132

Open avidspartan1 opened 7 months ago

avidspartan1 commented 7 months ago

Context

We're working with a GitHub Enterprise instance and use the GITHUB_TOKEN environment variable to pass credentials to the provider.

Expected Behavior

After a GitHub webhook has been created by one developer's token in repository X, another developer without permissions to manage hooks in repo X attempts a terraform apply.

The expected behavior is for the hook to remain in Terraform state or for an error message to display, indicating the user doesn't have access to read hooks in repository X.

Actual Behavior

During the apply, the webhook is removed from state even though it already exists. I think this is because the GitHub provider removes it from state if it receives a 404 from the API call.

A 404 is received from the API call when:

  1. The user has permissions to manage hooks, but the hook doesn't exist
  2. The user doesn't have permissions to manage hooks, but the hook exists

In the latter case, the hook is still removed from state.

Terraform Version

Terraform v1.5.7 on linux_amd64 + provider registry.terraform.io/integrations/github v5.45.0

Affected Resource(s)

Terraform Configuration Files

No response

Steps to Reproduce

Apply twice with two different tokens - one with the necessary scopes and one with no scopes at all.

Debug Output

No response

Panic Output

No response

Code of Conduct

jrsherry commented 7 months ago

Seeing the same thing. During an apply with a permissive GITHUB_TOKEN belonging to a user that doesn't have access to repository hooks, the apply fails w/ a 404 and removes the hook from state. In order to prevent this, the workaround is to have the repository hook resource depend_on a repository_hooks data source for the same repository. This way the 404 is discovered during the 'init' phase and it doesn't have a chance to rewrite state during the failed apply. For some reason the provider is swallowing the 404 when it's assessing if it should create the webhook during the init phase and defaulting to 'create' when it should just exit.

Aransh commented 3 months ago

Have this issue too, great to know what is the cause though, following

jean-mercier-hivebrite commented 4 days ago

We have also the problem any new on this issue ?