terraform-provider-github
                                
                                 terraform-provider-github copied to clipboard
                                
                                    terraform-provider-github copied to clipboard
                            
                            
                            
                        [BUG]: 5.43 upgrade failing due to signoff issues
Expected Behavior
Just got the 5.43 upgrade and I'm seeing failures like:
Error: PATCH https://api.github.com/repos/***: 422 Commit signoff is enforced by the organization and cannot be disabled []
I assume this is somehow due to https://github.com/integrations/terraform-provider-github/pull/2007/files. I've tried manually adding web_commit_signoff_required but this still seems to fail:
 # module.***.github_repository.repo will be updated in-place
  ~ resource "github_repository" "repo" {
      + web_commit_signoff_required = true
        # (35 unchanged attributes hidden)
    }
Is this related to something else or is there something else I should be doing here? Thank you.
Actual Behavior
Doesn't fail / backwards compatible.
Terraform Version
1.2.6, 5.43
Affected Resource(s)
- github_repository (I think)
Terraform Configuration Files
No response
Steps to Reproduce
No response
Debug Output
No response
Panic Output
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
I know it's not a fix, but ignoring that field might be a workaround for now?
resource "github_repository" "repo" {
  lifecycle {
    ignore_changes = [
      web_commit_signoff_required
    ]
  }
}
I know it's not a fix, but ignoring that field might be a workaround for now?
resource "github_repository" "repo" { lifecycle { ignore_changes = [ web_commit_signoff_required ] } }
Unfortunately, this does not seem to help either. The error also occurs on a completely new deployment, as soon as the repository resource is applied.
I know it's not a fix, but ignoring that field might be a workaround for now?
resource "github_repository" "repo" { lifecycle { ignore_changes = [ web_commit_signoff_required ] } }Unfortunately, this does not seem to help either. The error also occurs on a completely new deployment, as soon as the repository resource is applied.
I was still facing the same issue, so I had to remove the commit signoff from the org and I'm setting to true only on the repos now, its working so far.
Same here... 😕 with version 6.0.0 Only for initial creation I think.
Same here, using pulumi/github
@iwahbe FYI
We've been running into this issue today as well, but I haven't changed the web_commit_signoff_required parameter at all (I'm updating the setting of advanced_security to true). I am, however, getting the 422 error listed by the OP.
I've forked the provider, and thrown a debugger on it, and have been able to tell the following:
- The web_commit_signoff_requiredparameter is sent by the provider for any change to the repository. This should be harmless / inert, except that:
- The GitHub API throws the 422 error when the setting is not changing, from true/enabledand the provider sendsweb_commit_signoff_required=true,- This appears to be happening consistently, when the setting for the organizationis enabled/set totrue(which overrides therepository'ssetting on GitHub).
 
- This appears to be happening consistently, when the setting for the 
I've modified the provider locally, with a bit of a hack, that sets the web_commit_signoff_required to Nil (if the setting wasn't changed), before we send the request to the github module/API. It resolved the issue for us.
        // There's a bug in the GitHub 2022-11-28 version, that throws a 422 error
	// whenever the `web_commit_signoff_required` is set to true, even when it 
	// is already true.
	if !d.HasChange("web_commit_signoff_required") && d.Get("web_commit_signoff_required").(bool) {
		// remove the field from the request
		repoReq.WebCommitSignoffRequired = nil
	}
Inserted into: resource_github_repository.go:resourceGithubRepositoryUpdate:763
Unless the GitHub API is fixed (I'd say this is a bug on their end), maybe this could be the workaround.
I'm currently facing the same issue with the latest version 6.2.1
Edit: I was able to bypass this issue by downgrading to the version 5.37