Polygens
commented
3 years ago Closed kzw closed 4 months ago
Polygens
commented
3 years ago 
yuzujoe
commented
3 years ago https://github.com/terraform-providers/terraform-provider-github/issues/634 I'm suffering from a similar problem.
alk-rniveau
commented
3 years ago We have the same here:
terraform import 'module.scar.module.review.github_branch_protection.master-approved[0]' scar:master git:(master) ✗
module.scar.module.review.github_branch_protection.master-approved[0]: Importing from ID "scar:master"...
Error: Could not resolve to a node with the global id of 'scar'
majormoses
commented
3 years ago Are you able to replicate this with newly created resources or only existing? I had a number of these issues that only seemed to happen for a subset of the existing resources. Rather than importing/moving any resources I had to opt to delete and recreate the branch protections. Not sure if your mileage will vary.
great-qwerty
commented
3 years ago @majormoses the same happens with newly created resources as well:
module.github_repository.github_branch_protection.main: Creating...
enforce_admins: "" => "false"
pattern: "" => "master"
repository_id: "" => "test-repo"
require_signed_commits: "" => "false"
required_pull_request_reviews.#: "" => "1"
required_pull_request_reviews.0.required_approving_review_count: "" => "1"
required_status_checks.#: "" => "1"
required_status_checks.0.contexts.#: "" => "2"
required_status_checks.0.contexts.1584824872: "" => "ci/circleci"
required_status_checks.0.contexts.2007057319: "" => "ci/jenkins"
required_status_checks.0.strict: "" => "true"
Error: Error applying plan:
1 error(s) occurred:
* module.github_repository.github_branch_protection.main: 1 error(s) occurred:
* github_branch_protection.main: Could not resolve to a node with the global id of 'test-repo'
5obol
commented
3 years ago We suffer same problem, our github provider version is 4.1.0 and error we're seeing:
Error: Error applying plan:
1 error(s) occurred:
module.github_repository_1.bp: 1 error(s) occurred:
bp.main: Could not resolve to a node with the global id of 'github-repos'
Terraform does not automatically rollback in the face of errors. Instead, your Terraform state file has been partially updated with any resources that successfully completed. Please address the error above and apply again to incrementally change your infrastructure.
kchristensen
commented
3 years ago We're in the same boat. Currently on 3.1.0, but trying to go to anything newer (including the new 4.3.2) when running a plan or trying to import anything, I get:
Instance module.github_repository-whatever.github_branch_protection.additional_rules["master"]
data could not be decoded from the state: unsupported attribute "branch".Trying to run a state show, I see the same thing.
❯ _ENV=STUFF tf state show 'module.github_repository-whatever.github_branch_protection.additional_rules["master"]'
<SNIP>
Running command: terraform state show module.github_repository-whatever.github_branch_protection.additional_rules["master"]
unsupported attribute "branch"
# module.github_repository-whatever.github_branch_protection.additional_rules["master"]:
resource "github_branch_protection" "additional_rules" {Looking in the actual state, there is indeed a branch attribute:
"instances": [
{
"index_key": "master",
"schema_version": 0,
"attributes": {
"branch": "master",
"enforce_admins": false,
"etag": "W/\"REDACTED\"",
"id": "whatever:master",
"repository": "whatever",
"require_signed_commits": false,
"required_pull_request_reviews": [
{
"dismiss_stale_reviews": false,
"dismissal_teams": [],
"dismissal_users": [],
"include_admins": false,
"require_code_owner_reviews": true,
"required_approving_review_count": 1
}
],
"required_status_checks": [
{
"contexts": [
"continuous-integration/jenkins/pr-merge"
],
"include_admins": false,
"strict": false
}
],
"restrictions": []
},
"sensitive_attributes": [],
"private": "REDACTED",
"dependencies": [
"module.github_repository-whatever.github_repository.repository"
]
}
]What's the path forward here? I have hundreds of repositories, I really don't want to have to edit the state manually and remove this branch attribute if it has been deprecated. There's hundreds and hundreds of references that would need to be updated.
jcudit
commented
3 years ago 🤔 seems like we could introduce a new upgrader to https://github.com/integrations/terraform-provider-github/blob/master/github/migrate_github_branch_protection.go. We may also be able to re-add a computed branch attribute that does nothing but facilitate rolling forward. Open to either option, but feel we may need some back and forth to test that it all works correctly.
kchristensen
commented
3 years ago I'm in a position where we upgraded to Terraform 14, and the Github provider handoff meant I can't continue using 3.1.0, but I can't do anything on versions newer than 3.1.0 so I'm stuck manually making repository changes and having to reconcile them at some point when this gets fixed.
Some kind of upgrade process is much needed because we're managing 2-3 branch protection rules * hundreds of repositories and there's no real path forward for us.
kchristensen
commented
3 years ago Anyone have ANY workarounds for this? At this point I am willing to spend a couple hours massaging our state file manually if need be to get back to the point where I can interact with our Github organization at all.
majormoses
commented
3 years ago We finally saw this on a new resource:
module.my-repo.github_branch_protection.default[0]: Creating...
Error: Could not resolve to a node with the global id of '1111111'
on ../../../../modules/repository/branch_default.tf line 11, in resource "github_branch_protection" "default":
11: resource "github_branch_protection" "default" {
It's worth noting that we are using repository_id = github_repository.repo.node_id rather than the name, which as I understand it is desirable to eventually support repositories being safely renamed.
I agree it's not about old vs new resources even if that's where I saw it first. It does seem quite "random" but then consistently repeatable. I don't know much about graphql but I will try to see if I can find some time next week at work to use a local proxy to capture the API requests so we can see the full (redacted) payloads. I think the likely causes are an issue with the query we are writing or an infrastructure issue with Github that is missing some kind of required "index" on certain nodes is the graph.
majormoses
commented
3 years ago This actually seems related: https://github.blog/2021-02-10-new-global-id-format-coming-to-graphql/ I have opened a support ticket to confirm this might be and if so get some information on when it actually started rolling out.
jcudit
commented
3 years ago 😬 seems like we'd need to account for old and new formats, thanks for linking https://github.blog/2021-02-10-new-global-id-format-coming-to-graphql/.
Capturing the failure with a local proxy or leveraging TF_LOG=DEBUG (or TRACE) are good next steps here to get more information. Just to confirm, @majormoses are you experiencing this with version 3.1.0?
My next steps here are to get a test org provisioned using v3.1.0 and then iterate on a state upgrader this week. It seems like only github_branch_protection is blocking upgrades, but if anyone else can point out other resources to include, please let me know. Will keep an eye out for the different format as well and hopefully come up with separate fixes to what seems to be two intertwined bugs.
jcudit
commented
3 years ago 😕 I was able to upgrade from v3.1.0 to v4.0.1 with this configuration and create new resources / modify existing ones:
$ terraform version
Terraform v0.14.5
+ provider registry.terraform.io/hashicorp/github v4.0.1resource "github_repository" "terraformed" {
name = "terraformed"
description = "A repository created by Terraform"
}
resource "github_branch_protection" "terraformed" {
repository_id = github_repository.terraformed.node_id
pattern = "main"
enforce_admins = true
required_pull_request_reviews {
dismiss_stale_reviews = true
require_code_owner_reviews = false
}
required_status_checks {
strict = true
}
push_restrictions = [data.github_team.test.node_id]
}
data "github_team" "test" {
slug = "test-first"
}I did see similar error messaging to what has been posted in this thread when passing a slug into the push_restrictions array:
push_restrictions = [data.github_team.test.slug]
Error: Could not resolve to a node with the global id of 'test-first'
on main.tf line 6, in resource "github_branch_protection" "terraformed":
6: resource "github_branch_protection" "terraformed" {Any chance switching to .node_id helps anyone else's upgrade?
kchristensen
commented
3 years ago I've been using .node_id in my branch protection rules for some time now but I still run into the Instance module.github_repository-whatever.github_branch_protection.additional_rules["master"] data could not be decoded from the state: unsupported attribute "branch". when trying to move from 3.1.0 to current.
majormoses
commented
3 years ago seems like we'd need to account for old and new formats, thanks for linking https://github.blog/2021-02-10-new-global-id-format-coming-to-graphql/.
Capturing the failure with a local proxy or leveraging
TF_LOG=DEBUG(or TRACE) are good next steps here to get more information. Just to confirm, @majormoses are you experiencing this with version 3.1.0?My next steps here are to get a test org provisioned using v3.1.0 and then iterate on a state upgrader this week. It seems like only
github_branch_protectionis blocking upgrades, but if anyone else can point out other resources to include, please let me know. Will keep an eye out for the different format as well and hopefully come up with separate fixes to what seems to be two intertwined bugs.
Sorry I have not had time yet to dig further I am having these issues in some places but not others and we are on the latest version released as of last I commented. I will try to do some testing but I suspect based on some other issues I have seen that it might be another form of those bas64 decoding issues. The one repo I am currently able to replicate with is has a total of 5 chars (hs-ops) and I think that is somehow relevant but I will try to confirm that when I can.
majormoses
commented
3 years ago I tried pulling in 4.5 but I am not seeing any more actual debug context sadly. I will have to use the verbosity settings and/or proxy to try to dig more.
majormoses
commented
3 years ago majormoses
commented
3 years ago @jcudit any chance you can DM me and we can setup a debugging session to hack on this? This is getting more dangerous for my org, it's cropping up in more places than I realized. If I don't get a resolution shortly we are gonna have to do something like switching back to the non gql endpoint which will be very painful as we are using features that are not yet supported on rest. I have also committed some time from some devs on my team to try digging into it as well.
majormoses
commented
3 years ago @jcudit I have some great news! I am still running through the number of ones, so far all the issues are when we are specifying id rather than node_id. If we know the provider resource requires a node_id and not an id I think we should build some validation into it because this is a footgun that wasted a ton of time and the error messages were really not helpful. We had to rely on using a proxy (burp) to capture the requests.
jcudit
commented
3 years ago Agreed, this is one of the more painful issues that have come up as of late. Glad to see we may have identified a root cause and am open to adding validation to close this out so others do not need to experience this friction.
github-actions[bot]
commented
1 year ago 👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!
github-actions[bot]
commented
5 months ago 👋 Hey Friends, this issue has been automatically marked as stale because it has no recent activity. It will be closed if no further activity occurs. Please add the Status: Pinned label if you feel that this issue needs to remain open/active. Thank you for your contributions and help in keeping things tidy!
We have many resources managed with terraform 0.12.29 and provider 2.9.2.
Now we want to upgrade to at least 4.0.1 and even 4.1.0. But anything above 3.1.0 breaks
terraform planwith error message. I can reproduce this to one specificbranch_protectionresource which errors with the messageI have pruned the code and state so that only 2 resources remain and I am getting this error.
No error when I upgraded to just 3.1.0
Terraform Version
Also tried with terraform version 0.13.5 to no avail
Affected Resource(s)
Terraform Configuration Files
Debug Output
available upon request
Panic Output
Expected Behavior
No error.
Actual Behavior
Error.
Steps to Reproduce
terraform planImportant Factoids
No error for provider 3.1.0. I also get the above error when I use target on this resource
Before pruning code and state, I get no error when I plan with target on other resources.
I also get the following error on
state showI tried the same
terraform state showwith other resources and I get similar error.