-
Notifications
You must be signed in to change notification settings - Fork 914
[MAINT] Fix github_organization_ruleset and github_repository_ruleset with push target
#2958
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
stevehipwell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this change likely wants to wait for the SDK upgrade as a lot of this area is modified in future versions.
FYI the error behaviours previously seen should have been mitigated by #2705 so if there is an error the provider should handle it gracefully.
0531db8 to
9dd2965
Compare
1bdfa45 to
efd67ae
Compare
github_organization_ruleset with push targetgithub_organization_ruleset with push target
52d95d4 to
6782aab
Compare
stevehipwell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be possible to either de-scope this PR or open a new PR with the smallest number of changes possible to fix the outstanding bugs?
| }, | ||
| "bypass_actors": { | ||
| Type: schema.TypeList, | ||
| Type: schema.TypeList, // TODO: These are returned from GH API sorted by actor_id, we might want to investigate if we want to include sorting |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should sort the returned values based on the inputs which would stop churn.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That sounds sensible, need to investigate where the best place for the sorting is
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@stevehipwell after some investigation, it seems that schema.TypeSet would be the correct way to implement unsorted. What do you think?
|
@stevehipwell Yes, I agree. I've done that already in this PR: #2976 But I can't switch the base of this PR to point to that :) |
github_organization_ruleset with push targetgithub_organization_ruleset and github_repository_ruleset with push target
10baa83 to
1fe74fc
Compare
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
… to org rulesets will never be a thing Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
…re empty lists by default Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
…_id` Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
…s.context` is not empty Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
This turns out to be failing as there is a bug in our implementation! Unit tests and fix coming up Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
…esponse Signed-off-by: Timo Sand <[email protected]>
As they differ from `branch` and `tag` rules Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
…ved` repos to be private This allows even EMU users to run these tests Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
…` and `rules` Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
Signed-off-by: Timo Sand <[email protected]>
1fe74fc to
2a2277a
Compare
Signed-off-by: Timo Sand <[email protected]>
…anything Signed-off-by: Timo Sand <[email protected]>
stevehipwell
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some review comments, mainly about the code structure.
| @@ -0,0 +1,157 @@ | |||
| package github | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why we need this new file instead of using the util_rules.go file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I felt that util_rules.go is already getting too long to reason about nicely. But if this is an anti-pattern I can move these there
| CustomizeDiff: customdiff.All( | ||
| validateConditionsFieldBasedOnTarget, | ||
| validateOrganizationRulesetRules, | ||
| ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should use separate function here as we're writing our own logic, that pattern is only really useful when we're composing. Could you take a look at how I've structured the schema and done this in #3069?
| return []*schema.ResourceData{d}, nil | ||
| } | ||
|
|
||
| func validateConditionsFieldBasedOnTarget(ctx context.Context, d *schema.ResourceDiff, meta any) error { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this is scoped to the organization ruleset then the name should reflect that, otherwise it should probably be in the util_rules.go file (idiomatically I'd expect this to be called util_ruleset.go).
| } | ||
| `, resourceName, randomID) | ||
|
|
||
| check := resource.ComposeTestCheckFunc( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we please inline these instead of creating a separate var, this makes the code so much harder to read.
| resource.TestCheckResourceAttr( | ||
| fmt.Sprintf("github_organization_ruleset.%s", resourceName), | ||
| "name", | ||
| fmt.Sprintf("test-push-%s", randomID), | ||
| ), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| resource.TestCheckResourceAttr( | |
| fmt.Sprintf("github_organization_ruleset.%s", resourceName), | |
| "name", | |
| fmt.Sprintf("test-push-%s", randomID), | |
| ), | |
| resource.TestCheckResourceAttr(fmt.Sprintf("github_organization_ruleset.%s", resourceName), "name", fmt.Sprintf("test-push-%s", randomID)), |
Please can these be made a single line, it's the idiomatic Go pattern (no introducing line breaks) and makes the code much easier to read.
Resolves #2929, #2467
Before the change?
ref_namewould cause the provider to Panic asref_nameis a required fieldruleswhich weren't valid forpushrulesetsAfter the change?
pushrulesets to an organizationref_nameshould no longer be needed to be set forpushtargetconditions&targetvalidation logic should ensure correct fields are populatedPull request checklist
Schema migrations have been created if needed (example)Does this introduce a breaking change?
Please see our docs on breaking changes to help!