Skip to content

Comments

[FEAT]: Add Support for GitHub Enterprise Rulesets#3110

Open
Ravio1i wants to merge 33 commits intointegrations:mainfrom
siemens:feat/enterprise-rulesets
Open

[FEAT]: Add Support for GitHub Enterprise Rulesets#3110
Ravio1i wants to merge 33 commits intointegrations:mainfrom
siemens:feat/enterprise-rulesets

Conversation

@Ravio1i
Copy link

@Ravio1i Ravio1i commented Jan 22, 2026

Resolves #2666


Before the change?

No possibility to create or fetch rulesets at enterprise level

After the change?

  • Create rulesets with resource
  • Fetch rulesets with datasource

Pull request checklist

  • Schema migrations have been created if needed (example)
  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been reviewed and added / updated if needed (for bug fixes / features)

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

  • Yes
  • No

Notes

  • Tested with own GitHub Enterprise Cloud Instance
  • Currently there is a race condition in the test testAccGithubEnterpriseRuleset_required_workflows: Error running post-test destroy, there may be dangling resources for vulnerability-alerts`. The test still works but the vulnerabtily alert seems to be not finished in time. Happy to hear feedback about this

@github-actions github-actions bot added the Type: Feature New feature or request label Jan 22, 2026
Copy link
Collaborator

@deiga deiga left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Initial pass. Not a complete review.

Please see if there are other parts of the PR where my comments might be applicable :)

@Ravio1i Ravio1i changed the title [FEAT]: Add Support for GitHub Enterprise Rulesets #3108 [FEAT]: Add Support for GitHub Enterprise Rulesets Jan 23, 2026
@deiga
Copy link
Collaborator

deiga commented Jan 23, 2026

You're doing good work!

I'm wondering if there are patterns from #2958 you should be copying here (for example the conditions and rules validation)

@Ravio1i
Copy link
Author

Ravio1i commented Jan 23, 2026

You're doing good work!

Thanks! although I wasted a lot of time today being utterly confused of what is actually implemented and exposed in the API/golang sdk. E.g there are parts in the go sdk, which indicate that a ruleset can use the new repository_properties, organization_properties or merge_queue, but the actual API of the Enterprise Cloud is not supporting it 🔥

I'm wondering if there are patterns from #2958 you should be copying here (for example the conditions and rules validation)

I can check it out and see if I can adjust it !

#3110 (comment)

For the importer feature: I left it out intentionally as I was under the impression it is a feature used only in UI. Not sure who actually would use it with terraform/tofu to import json in hcl.

@Ravio1i
Copy link
Author

Ravio1i commented Jan 23, 2026

I'm wondering if there are patterns from #2958 you should be copying here (for example the conditions and rules validation)

Similar to the the CustomizeDiff in #2958 I've added the util_ruleset_enterprise_validation.go to validate that:

  • ref_name is required for branch/tag, but forbidden for push/repository
  • creation, deletion, update, required_linear_history, required_signatures, pull_request, required_status_checks,
    non_fast_forward, commit_message_pattern, commit_author_email_pattern, committer_email_pattern, branch_name_pattern,
    tag_name_pattern, required_workflows, required_code_scanning, copilot_code_review rules are only valid for branch/tag
    targets
  • file_path_restriction, max_file_size, max_file_path_length, file_extension_restriction rules are only valid for push
    target
  • repository_creation, repository_deletion, repository_transfer, repository_name, repository_visibility rules are only
    valid for repository target

@deiga
Copy link
Collaborator

deiga commented Jan 23, 2026

The Importer is functionality to enable terraform import or the import block inside the config, so that existing resources can be added to state

@Ravio1i
Copy link
Author

Ravio1i commented Jan 23, 2026

The Importer is functionality to enable terraform import or the import block inside the config, so that existing resources can be added to state

Oh nevermind, yes that I will most definitely add!

I thought you were referring to the importer functionality in GitHub rulesets. Oops

@Ravio1i
Copy link
Author

Ravio1i commented Jan 26, 2026

The Importer is functionality to enable terraform import or the import block inside the config, so that existing resources can be added to state

7dd2b13

Added the importer functionality + test

TF_CLI_CONFIG_FILE=../dev.tfrc terraform import github_enterprise_ruleset.imported siemens:440187
github_enterprise_ruleset.imported: Importing from ID "siemens:440187"...
github_enterprise_ruleset.imported: Import prepared!
  Prepared github_enterprise_ruleset for import
github_enterprise_ruleset.imported: Refreshing state... [id=440187]

Import successful!

@Ravio1i Ravio1i force-pushed the feat/enterprise-rulesets branch 2 times, most recently from f5a34a3 to dd26f68 Compare February 6, 2026 07:28
@deiga deiga added this to the v6.12.0 Release milestone Feb 16, 2026
@deiga deiga requested a review from stevehipwell February 16, 2026 12:39
Copy link
Collaborator

@stevehipwell stevehipwell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR @Ravio1i.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please change the signature of this as the type isn't a bool.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The org bool parameter on expandConditions/flattenConditions/expandRules/flattenRules is a shared utility across all three resource types (repo, org, enterprise). It controls whether org-level fields (like organization_name, organization_id, repository_property) are included.

I agree, changing this to a more descriptive type (e.g. an enum like RulesetLevel) would be a good improvement but affects all three resource files and their tests. Should this be done as a separate refactoring PR to keep the scope of this PR focused?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It needs fixing in this PR as before this PR a bool can represent the supported states.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I addded RulesetLevel instad of the bool now

2a59f50

Please check if this is how you would do it or you want to handle it differently :)

Computed: true,
Description: "GitHub ID for the ruleset.",
},
"conditions": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion: What if we split conditions into target_organizations and target_repositories or some similar naming? Similar to what it is like in the UI.

This could make the code for handling and validating these simpler and it could make the config UX clearer too.

@stevehipwell @nickfloyd thoughts?

Image

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd hold off on this for now.

},
},
},
"rules": {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discussion:
On the shoulders of https://github.com/integrations/terraform-provider-github/pull/3110/changes#r2827158611: What if we split the rules into separate lists based on which target they work with?

That would enable us to remove the rules validation for "is this target allowed to set this rule" and replace it with simpler built-in validators.
It would make the UX for our users nicer since they don't have to trial-and-error the rules.

@stevehipwell @nickfloyd thoughts?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest opening an issue to discuss or creating a PR to demonstrate a POC.

@Ravio1i Ravio1i force-pushed the feat/enterprise-rulesets branch from b3dfcdd to 21d8823 Compare February 20, 2026 14:12
…nc with ConfigStateChecks using terraform-plugin-testing
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FEAT]: Add Support for GitHub Enterprise Rulesets

3 participants