[BUG]: Updating GitHub Pages Fails in GHES

[sstrullmyer]

Expected Behavior

Hello,

I have been encountering an issue making modifications to the pages block of github_repository resources in GitHub Enterprise Server (3.10.3).

I am able to initially create a github_repository resource with a pages block, such as this:

resource "github_repository" "main" {
  name = "terraform-provider-github-pages-test"

  pages {
    build_type = "legacy"
    source {
      branch = "main"
      path   = "/"
    }
  }
}

I expect that changing an argument, such as build_type, would result in the GitHub repository's configuration successfully being modified in GHES. An example valid, new Terraform configuration could be

resource "github_repository" "main" {
  name = "terraform-provider-github-pages-test"

  pages {
    build_type = "workflow"
    source {
      branch = "main"
      path   = "/"
    }
  }
}

Actual Behavior

The Terraform provider attempts to update the GitHub Pages configuration, but fails with a 400 error:

│ Error: PUT https://<base_url>/api/v3/repos/SStrullmyer/terraform-provider-github-pages-test/pages: 400 Custom domains are not available for GitHub Pages []
│
│   with github_repository.main,
│   on main.tf line 1, in resource "github_repository" "main":
│    1: resource "github_repository" "main" {

This results in the desired configuration not being effected. This is doubly problematic, as the tfstate associated with this block appears to be prematurely updated, anticipating a successful PUT; coupled with #1913, this can lead to additional challenges.

I've tested calling the /api/v3/repos/.../pages endpoint directly (outside of Terraform contexts), and can confirm that a PUT request that includes any cname entry, including empty strings and null, results in the same 400 error message.

I suspect all that would be required here would be to not provide the cname argument to the */pages endpoint if the GITHUB_BASE_URL indicates the target is a GHES instance. If this path (or another) is amenable, I'd be happy to pursue a PR for it.

Terraform Version

Terraform v1.6.6 on windows_amd64 + provider registry.terraform.io/integrations/github v5.43.0

Affected Resource(s)

• github_repository

Terraform Configuration Files

resource "github_repository" "main" {
  name = "terraform-provider-github-pages-test"

  pages {
    build_type = "legacy"
    source {
      branch = "main"
      path   = "/"
    }
  }
}

Steps to Reproduce

• Run terraform apply on the above Terraform configuration file targeting a GitHub Enterprise Server instance via GITHUB_BASE_URL (or equivalent provider configuration)
• Change build_type to "workflow"
• Run terraform apply

Debug Output

[DEBUG] provider.terraform-provider-github_v5.43.0.exe: PUT /api/v3/repos/SStrullmyer/terraform-provider-github-pages-test/pages HTTP/1.1
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: User-Agent: go-github/v55.0.0
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: Content-Length: 39
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: Accept: application/vnd.github.v3+json,application/vnd.github.stone-crop-preview+json
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: Content-Type: application/json
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: X-Github-Api-Version: 2022-11-28
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: Accept-Encoding: gzip
[DEBUG] provider.terraform-provider-github_v5.43.0.exe
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: {
[DEBUG] provider.terraform-provider-github_v5.43.0.exe:  "cname": null,
[DEBUG] provider.terraform-provider-github_v5.43.0.exe:  "build_type": "workflow"
[DEBUG] provider.terraform-provider-github_v5.43.0.exe: }

Panic Output

No response

Code of Conduct

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

[Sam13]

Same issue here with GHES v3.13.2.

Any better workarounds than ignoring the pages configuration in the repository resource?

I suspect all that would be required here would be to not provide the cname argument to the */pages endpoint if the GITHUB_BASE_URL indicates the target is a GHES instance. If this path (or another) is amenable, I'd be happy to pursue a PR for it.

@sstrullmyer Yes please