terraform-provider-github
terraform-provider-github copied to clipboard
[BUG]: Resource `github_organization_ruleset ` knows nothing about attribute `required_workflows` after creation of the Rule(s)
Expected Behaviour
Terraform state has information about an attribute required_workflows of the github_organization_rulesett resource.
Actual Behaviour
State DOES NOT include information about required_workflows attribute of github_organization_ruleset resource.
Terraform Version
Terraform v1.7.0 on linux_amd64
GH Provider registry.terraform.io/integrations/github v5.45.0
Affected Resource(s)
- github_organization_ruleset
Terraform Configuration Files
resource "github_organization_ruleset" "required-workflow-depricated-actions" {
name = "Required workflow for Deprecated Actions"
target = "branch"
enforcement = "evaluate"
conditions {
ref_name {
include = ["~DEFAULT_BRANCH"]
exclude = []
}
repository_name {
include = [
"test-repo"
]
exclude = []
}
}
rules {
required_workflows {
required_workflow {
repository_id = 123456 # change to real repo_id or use "data"
path = ".github/workflows/deprecated_actions.yaml"
ref = "master"
}
}
}
}
Steps to Reproduce
terraform apply
terraform plan
terraform state show 'github_organization_ruleset.required-workflow-depricated-actions'
output of plan (tries to add required_workflow again)
~ resource "github_organization_ruleset" "required-workflow-depricated-actions" {
id = "CENSORED"
name = "Required workflow for Deprecated Actions"
# (5 unchanged attributes hidden)
~ rules {
# (6 unchanged attributes hidden)
+ required_workflows {
+ required_workflow {
+ path = ".github/workflows/deprecated_actions.yaml"
+ ref = "master"
+ repository_id = CENSORED
}
}
}
# (1 unchanged block hidden)
}
output of state (empty rules object)
# github_organization_ruleset.required-workflow-depricated-actions:
resource "github_organization_ruleset" "required-workflow-depricated-actions" {
enforcement = "evaluate"
etag = "CENSORED"
id = "CENSORED"
name = "Required workflow for Deprecated Actions"
node_id = "CENSORED"
ruleset_id = CENSORED
target = "branch"
conditions {
repository_id = []
ref_name {
exclude = []
include = [
"~DEFAULT_BRANCH",
]
}
repository_name {
exclude = []
include = [
"test-repo"
]
protected = false
}
}
rules {
}
}
Debug Output
No response
Panic Output
No response
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Hey @ViacheslavKudinov, I'll try looking into this within the next couple of days, it's likely an issue with how the object is serialized. Thanks for bringing this up 🙂
Thank you @o-sama, it will be great if you could fix it quickly.
Is not reproducible on v6.0.1.
@ViacheslavKudinov feel free to close the issue if this has been fixed!
Thanks for the fix.
Hey @kfcampbell , @o-sama , @ViacheslavKudinov We are experiencing this same issue with a newer provider version. We just updated to 6.2.1 from 5.42.0 and then finally imported (to terraform state) an existing ruleset which had required_workflows. We wondered why the generated config did not include the required_workflows block but we added it manually according to provider docs. The apply of that plan worked fine but new plans afterwards show changes to the resource same way as @ViacheslavKudinov posted in this issue. required_workflows attribute for this org ruleset resource is null in the state.
Edit: We are using terraform_version: "1.7.5"
Hm,
i've just tested it again and plan doesn't show any drift.
terraform state show also shows required_workflows object same as it was applied.
Provider is v.6.2.1, terraform cli 1.7.5.
Interesting! Did you create is a new ruleset or import an existing one? Let me test creating a new ruleset from scratch and see if that works.
I didn't create or import anything new. I have Rule created by resource and I run plan/apply over the same IaC.
If it is about import or creation of a new resource, then maybe exactly this scenario needs more testing.
My initial issue i reported was that plan/apply was always trying to "add" object required_workflows (even after it was applied by previous run).
Now i don't see exactly this issue anymore.
Okay. We are still experiencing this issue. @kfcampbell should this issue be re-opened or should I create a new one?
We are using: "terraform_version": "1.7.5" integrations/version: "6.2.1"
Code that we are using. (And this code is applied!):
resource "github_organization_ruleset" "test_require_workflows_to_pass" {
enforcement = "disabled"
name = "Test version of Require workflows to pass for default and release branches"
target = "branch"
bypass_actors {
actor_id = <number>
actor_type = "Integration"
bypass_mode = "always"
}
conditions {
repository_id = [<number>]
ref_name {
exclude = []
include = ["~DEFAULT_BRANCH"]
}
}
rules {
required_workflows {
required_workflow {
repository_id = module.devops_workflows_repository.repository_id
path = ".github/workflows/check_pr_title.yaml"
ref = "main"
}
}
}
}
and terraform plan with no changes to this resource code:
# github_organization_ruleset.test_require_workflows_to_pass will be updated in-place
~ resource "github_organization_ruleset" "test_require_workflows_to_pass" {
id = "<number>"
name = "Test version of Require workflows to pass for default and release branches"
# (5 unchanged attributes hidden)
~ rules {
+ creation = false
+ deletion = false
+ non_fast_forward = false
+ required_linear_history = false
+ required_signatures = false
+ update = false
+ required_workflows {
+ required_workflow {
+ path = ".github/workflows/check_pr_title.yaml"
+ ref = "main"
+ repository_id = <number>
}
}
}
# (2 unchanged blocks hidden)
}
terraform state shows null for this resource's required_workflows block ("required_workflows": null)
I'll re-open then. P.S. as i've created resource by v5.45.0, then re-applied by 6.0.1 and now we are on 6.2.1, it is not to get the "fresh" resource as you do.
Apologies for ghosting this. I've been going through a rough period with the baby and just last week the company I work at announced it is being dissolved. On the bright side that means I should have more free time now to contribute so I should be more consistent 🤣, I'll try to work on this in the next couple of days and hopefully figure out where this is going wrong
Ran it using the TF and provider versions you mentioned @anttijman, the state is stored as follows with the same rule you've defined: "required_workflows": [],.
I now have a direction on where this is going wrong and will try to get a fix out tonight :)
Once @kfcampbell or @nickfloyd have a chance to review this should be good to go :)