-
Notifications
You must be signed in to change notification settings - Fork 776
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
error when creating repositories in orgs where projects are disabled #99
Comments
From what I read here
|
So looking at the code and the upstream library we do not set any defaults and the github api docs something is wrong but I can't seem to figure out where its going wrong yet. |
I am beginning to suspect the issue may be on github's side. Running this through charles proxy this is what I see:
Which confirms that the payload being sent to github looks correct. |
Docs updated per #98 (thanks for the PR!), going to close this as I think that's all we can do at this point. |
@paultyng even though there is nothing we can do at the moment I think it should remain open for tracking purposes as other users may find themselves affected. When searching for answers people often only look at open vs closed issues and leaving it open can avoid wasting their time as I already put in the effort to validate that its an API issue. |
I can appreciate the desire to make the discoverability of the problem good for newcomers to the provider, but we do not leave open issues for every caveat or gotcha we call out in docs. Now that it is documented on the provider website I don't think keeping this open is useful unless there is an upstream issue to track somewhere or some other actionable tasks left. I did verify it will still come up in a Google search closed or open and the TF error message output from GitHub's API explains what the conflict is on their side. If we can do something down the road I'm happy to reopen it at that point. |
I think you are misunderstanding this, this is broken on GitHub's side, I have finally got confirmation today from GitHub that they agree its broken on their end and are not sure why. We do not call that out in our docs, we only documented that its an option not that it essentially does not matter what you pass it will always fail if your org disables projects. I respect your decision to keep it closed as there is no action item (other than me pinging github support every week until we have a resolution) and I will keep updating here as I get more information from the GitHub api team when they deliver a fix so then when someone googles it they can find the issue and be up to date. |
my team ran into this issue in Github Enterprise 2.14. Our work around was to manually enable projects at the org level, apply the change (in our case it was adding checks to a branch) and then disable projects again. Interestingly repo level changes were applied with no problem (disabled merge commits, rebase merges, and projects). It was only adding the checks to the branch that failed. |
I pulled in 1.1.0 and am now seeing issues where on create terraform fails and then a re-run works as intended. I am not yet sure if this is an upstream api issue yet but wanted to report it here first.
Terraform Version
Affected Resource(s)
Please list the resources as a list:
Config
Plan Output
Apply Output
Expected Behavior
As we are setting
has_projects
as false I would expect it to successfully create the repository without any project enabled.Actual Behavior
Steps to Reproduce
terraform plan
with some minimal snippets from my exampleterraform apply
which fails with issueterraform plan
terraform apply
and it worksImportant Factoids
References
Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:
has_projects
option #98The text was updated successfully, but these errors were encountered: