[FEAT]: Add Support for GitHub Enterprise Rulesets#3110
[FEAT]: Add Support for GitHub Enterprise Rulesets#3110Ravio1i wants to merge 33 commits intointegrations:mainfrom
Conversation
deiga
left a comment
There was a problem hiding this comment.
Initial pass. Not a complete review.
Please see if there are other parts of the PR where my comments might be applicable :)
|
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) |
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
I can check it out and see if I can adjust it ! 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. |
Similar to the the
|
|
The Importer is functionality to enable |
Oh nevermind, yes that I will most definitely add! I thought you were referring to the importer functionality in GitHub rulesets. Oops |
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! |
f5a34a3 to
dd26f68
Compare
stevehipwell
left a comment
There was a problem hiding this comment.
Thanks for the PR @Ravio1i.
github/util_rules.go
Outdated
There was a problem hiding this comment.
Please change the signature of this as the type isn't a bool.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
It needs fixing in this PR as before this PR a bool can represent the supported states.
There was a problem hiding this comment.
I addded RulesetLevel instad of the bool now
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": { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I'd hold off on this for now.
| }, | ||
| }, | ||
| }, | ||
| "rules": { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
I'd suggest opening an issue to discuss or creating a PR to demonstrate a POC.
… and remove initial schemaversion
…e actor_type validation
…rise ruleset resource
…se ruleset schema
…ise ruleset schema
…ag, push, and repository targets
…ort and conditions
…n conditions and rules
… for enterprise ruleset
…itions and improve import error handling
…pand/flatten functions
… data source and improve test checks
…rove import handling
…equirements for repository rulesets
…ons with property validation
…dateDiagFunc for improved error handling
…nter types for target and source
b3dfcdd to
21d8823
Compare
…nc with ConfigStateChecks using terraform-plugin-testing
…read function for improved type safety
… target attribute immutability
…ganization, and enterprise levels
…with shared HCL templates
Resolves #2666
Before the change?
No possibility to create or fetch rulesets at enterprise level
After the change?
Pull request checklist
Does this introduce a breaking change?
Please see our docs on breaking changes to help!
Notes
testAccGithubEnterpriseRuleset_required_workflows:Error running post-test destroy, there may be dangling resources forvulnerability-alerts`. The test still works but the vulnerabtily alert seems to be not finished in time. Happy to hear feedback about this