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 :)