Repository environment creation fails on private Teams repos

[AnitaErnszt]

This is related to the discussion on the integrations/terraform-provider-github#1262

In June GitHub made the environments and environment protection rules generally available, however, the wait_timer and reviewers remains limited to enterprise.

Many developers would like to make use of this great new feature, but the bug in the Terraform provider currently proves to be a blocker.
The provider uses the go-github Go library under the hood and makes the following call:

_, _, err := client.Repositories.CreateUpdateEnvironment(ctx, owner, repoName, escapedEnvName, &updateData)

where the &updateData is a github.CreateUpdateEnvironment struct.

Looking at the code it seems that instead of sending nil value for wait_timer it defaults to 0.

// CreateUpdateEnvironment represents the fields required for the create/update operation
// following the Create/Update release example.
// See https://github.com/google/go-github/issues/992 for more information.
// Removed omitempty here as the API expects null values for reviewers and deployment_branch_policy to clear them.
type CreateUpdateEnvironment struct {
	WaitTimer              *int            `json:"wait_timer"`
	Reviewers              []*EnvReviewers `json:"reviewers"`
	DeploymentBranchPolicy *BranchPolicy   `json:"deployment_branch_policy"`
}

This is causing the issue for us, as the API doesn't expect this parameter and returns 422.

I understand why the omitempty was removed, so I'm looking at what alternative solutions are possible to ensure environments fully work regardless of the payment plan.

[gmlewis]

Please read #2467 and see if that answers your questions.

[AnitaErnszt]

@gmlewis It seems unrelated to me.

I'm very new to go-github and go in general, so I could be wrong.

My core issue is that the API is expecting different objects from Enterprise and Teams customers.
Above code is correct for Enterprise. Adding omitempty would make it work for Teams, but would introduce bug for enterprise customers.

[gmlewis]

OK, thanks, @AnitaErnszt - so would it help to split it into two separate endpoints?

[gmlewis]

I suppose another option might be to add a flag that alters its behavior.

Thoughts?

[AnitaErnszt]

@gmlewis do you mean creating separate endpoints based on pricing plan (one for teams/pro where wait_timer is not sent, and one for enterprise where wait_timer defaults to 0 if not set)?

I'm still checking in the TF provider if it's possible to access the pricing plan to decide which endpoint to call.

If not, we might have to call the enterprise endpoint first, and if it returns 422 make an attempt to call the teams endpoint. However, in this case, would it not be better to make a retry attempt here, rather than downstream?

[gmlewis]

Hi @AnitaErnszt - honestly, I don't know what the best answer is. I also no longer have access to GitHub Enterprise, so it makes it very challenging to experiment and further investigate.

Maybe others who also use GitHub Enterprise might be able to comment?