[BUG]: unable to add github apps to bypassers

[jamesgeddes]

Expected Behavior

should be able to add a github app (bot) to PR bypassers, as indicated by the docs;

pull_request_bypassers: (Optional) The list of actor Names/IDs that are allowed to bypass pull request requirements. Actor names must either begin with a "/" for users or the organization name followed by a "/" for teams.

Can add a GitHub app using the GUI, but not in Terraform. When a GitHub app is manually added to the PR bypassers in the GUI, it shows up in terraform as [org name]/[app username].

NB This was tested within a GitHub org using a github app that had been granted all permissions.

Actual Behavior

terraform apply returned the following error.

github_branch_protection.trunk_protection["test-trunk-protection"]: Modifying... [id=***]
github_branch_protection.trunk_protection["test-trunk-protection"]: Still modifying... [id=***, 10s elapsed]
github_branch_protection.trunk_protection["test-trunk-protection2"]: Still modifying... [id=***, 10s elapsed]

Error: Could not resolve to a node with the global id of ''

  with github_branch_protection.trunk_protection["test-trunk-protection2"],
  on github.tf line 38, in resource "github_branch_protection" "trunk_protection":
  38: resource "github_branch_protection" "trunk_protection" {


Error: Could not resolve to a node with the global id of ''

  with github_branch_protection.trunk_protection["test-trunk-protection"],
  on github.tf line 38, in resource "github_branch_protection" "trunk_protection":
  38: resource "github_branch_protection" "trunk_protection" {

fails when specifying github app as,

• [org name]/[app login] (the format returned by a terraform plan!)
• /[org name]/[app login]
• [app user id]
• /[app user login]
• /[app user login][bot]
• [app installation id]

Terraform Version

Terraform v1.8.0 GitHub provider v6.2.1

Affected Resource(s)

github_branch_protection

Terraform Configuration Files

resource "github_branch_protection" "trunk_protection" {
  pattern                         = "main"
  repository_id                   = "test-trunk-protection"
...
  required_pull_request_reviews {
    pull_request_bypassers = compact(concat(
      ["/jamesgeddes"],         # This human user works as expected.
    ))
  }
}

resource "github_branch_protection" "trunk_protection2" {
  pattern                         = "main"
  repository_id                   = "test-trunk-protection2"
...
  required_pull_request_reviews {
    pull_request_bypassers = compact(concat(
      ["/jamesgeddes"],         # This human user works as expected.
      ["geddesfamily/gedbot"],  # As soon as this GitHub app is added, Terraform returns the aforementioned error.
    ))
  }
}

Steps to Reproduce

1. run terraform plan and terraform apply with no pull_request_bypassers
2. manually add github app to github branch protection gui
3. terraform plan shows [org name]/[app username] to remove
4. add [org name]/[app username] to terraform pull_request_bypassers
5. run terraform plan - note github app is accepted
6. runterraform apply - note Error: Could not resolve to a node with the global id of '' error

Debug Output

No response

Panic Output

No response

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[carl-knutson]

fails when specifying github app as,

Also attempted the following with same results:

• /[node-id]
• [node-id]

[ivanmartos]

Still valid with provider version 6.2.2

[msharbaji]

Is there a plan to fix this issue?

[tobias-farrenkopf]

As a workaround you can provide the node-id which you can get from the rest api: https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28

[rtkwlf-hzzz]

As a workaround you can provide the node-id which you can get from the rest api: https://docs.github.com/en/rest/apps/apps?apiVersion=2022-11-28

hi @tobias-farrenkopf , we also encountered this issue recently, would you mind providing some details about how to use this workaround ....

we try

 pull_request_bypassers = ["A_ID"]

but it doesn't work. appreciat it in advance 🙏🙏

[Mabog10]

Hello, below solution works in my case:

github provider version: 6.3.1

1. Use data source providing your GitHub App name:

data "github_app" "this" {
  slug = "github_app_name"
}

2. Use "node_id" from data source in your code:

  required_pull_request_reviews = {
    pull_request_bypassers = [
      data.github_app.this.node_id
    ]
  }

[jamesgeddes]

Super! If this is intended functionality, then this has just become a request for documentation 😂

[Erwan-loot]

data "github_app" "this" { slug = "github_app_name" }

Doesn't work at all when your app is private

[Erwan-loot]

Can we know what exactly is the format expected for an app when you are not using github_app ? i've tried with the node_id, the id used by the ruleset, the slug name all prefixed by the org. Even worse if i add the app in UI and i apply with a change, the app doesn't appears in the terraform plan

[lloydmcl]

Can we know what exactly is the format expected for an app when you are not using github_app ? i've tried with the node_id, the id used by the ruleset, the slug name all prefixed by the org. Even worse if i add the app in UI and i apply with a change, the app doesn't appears in the terraform plan

I tried the following using github provider version 6.5.0:

Hello, below solution works in my case:

github provider version: 6.3.1

1. Use data source providing your GitHub App name:

data "github_app" "this" {
  slug = "github_app_name"
}

2. Use "node_id" from data source in your code:

  required_pull_request_reviews = {
    pull_request_bypassers = [
      data.github_app.this.node_id
    ]
  }

My GitHub app was private and it worked for me.

[cvegagimenez]

Hi @lloydmcl ,

what authentication method are you using against Github? I noticed that I can only add as a bypasser the same App I am using tho authenticate.

[brmb]

Experiencing the same issue after 1 year, would be nice to get this solved 😕

[stevehipwell]

Branch protection isn't deprecated (yet) but is referred to as legacy in the docs and UI, have you looked at switching over to using rulesets?

[cvegagimenez]

Hey @stevehipwell ,

we already planned to do so. In the meantime, we are dealing with ProtectedBranches.

[Sytten]

Ruleset doesn't support all the features of branch protection. Most of the time you need to use both. And with the lack of development at GitHub in the past year this is unlikely to change anytime soon.

[stevehipwell]

Ruleset doesn't support all the features of branch protection. Most of the time you need to use both. And with the lack of development at GitHub in the past year this is unlikely to change anytime soon.

@Sytten could you elaborate on what's missing?

[Sytten]

Very simple example @stevehipwell: GitHub Rulesets don’t have a "Dismiss stale reviews" option

[stevehipwell]

@Sytten I think you might be mistaken.

[Sytten]

Ha looks like it @stevehipwell , I swear I did check not that long ago. This was one of blockers we had to switching. Maybe it was just not supported in the terraform provider?

[stevehipwell]

@Sytten if you want I can look back at our history for when we switched over to rulesets as it's one of the foundational constraints we require and we were early adopters? The TF provider implementation hasn't always been perfect, which is partially down to the API, but neither was the branch protection implementation.

[deiga]

The only API limitation I currently know of that still requires using branch_protection: Deployment Environments configured on protected branches only consider branch_protection rules and not repo/org_ruleset.

There might of course be TF provider limitations, but we're working on those! It's my personal highest priority, since I want our ClickOps Org Rulesets into Terraform 😬

[stevehipwell]

@deiga deployment environments should explicitly call out the refs that can deploy to them, otherwise it's likely that there will be misconfiguration as it's perfectly valid to apply (different) rules to all repo refs. Take for example this repo, until recently there was a branch protection for all refs (*) so an environment protection using protected would have been useless.

[deiga]

@deiga deployment environments should explicitly call out the refs that can deploy to them, otherwise it's likely that there will be misconfiguration as it's perfectly valid to apply (different) rules to all repo refs. Take for example this repo, until recently there was a branch protection for all refs (*) so an environment protection using protected would have been useless.

That is a good point yeah. Especially when managing all of this via TF. We are still part way in ClickOps land, where the protected branches made more sense

[stevehipwell]

We originally had protected branches but as soon as it was viable (actually before as we used a lifecycle ignore to stop the provider erroring) we switched over to rulesets as we could configure these across a whole organization.