Skip to content

Conversation

@Moser-ss
Copy link
Contributor

@Moser-ss Moser-ss commented Aug 20, 2024

Resolves #2137
Introduces the support to use repository_property to target repositories in the ruleset

The changes were manually tested against a GitHub Organization with an enterprise plan.
It is not possible to add properties with the source system because the lib version doesn't allow that. It is necessary to update to version v65


Before the change?

  • Cannot target ruleset using repository_property

After the change?

  • The ruleset can use the repository_property under the conditions block

Pull request checklist

  • 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

@Moser-ss Moser-ss marked this pull request as draft August 20, 2024 18:57
@Moser-ss Moser-ss marked this pull request as ready for review August 20, 2024 22:58
@Moser-ss Moser-ss force-pushed the Support-repository_property-for-github_organization_ruleset branch from bb62d7a to 40c5111 Compare August 28, 2024 13:17
@Moser-ss Moser-ss changed the title Support repository property for GitHub organization ruleset feat : Support repository property for GitHub organization ruleset Sep 3, 2024
@Moser-ss
Copy link
Contributor Author

Moser-ss commented Sep 7, 2024

@kfcampbell, could you take a quick look to see if I need to improve anything in this PR

Copy link
Contributor

@kfcampbell kfcampbell left a comment

Choose a reason for hiding this comment

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

Thanks! Have you looked at expanding the tests in github/resource_github_organization_ruleset_test.go to cover this usecase yet?

@Moser-ss
Copy link
Contributor Author

A test case was added, I hope the change was not to ugly

@Moser-ss
Copy link
Contributor Author

Moser-ss commented Oct 5, 2024

@kfcampbell can I do anything to speed up the review of this PR?

Comment on lines +138 to +144
Elem: &schema.Schema{
Type: schema.TypeString,
},
Copy link

@PaarthShah PaarthShah Oct 16, 2024

Choose a reason for hiding this comment

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

Does this handle properties with boolean values? From a json export which shows the use of string "false" and "true" I assume it does

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I manualy tested the solution and can handle boelean custom_properties using strings

@stevehipwell
Copy link
Collaborator

@Moser-ss I think you need to update the docs to reflect these changes?

@Moser-ss
Copy link
Contributor Author

Moser-ss commented Nov 9, 2024

@stevehipwell Docs updated, thanks for catching that.

@wrighbr
Copy link

wrighbr commented Nov 14, 2024

@PaarthShah @kfcampbell Would you have an estimate on when this PR might be reviewed and merged?

@PaarthShah
Copy link

@PaarthShah @kfcampbell Would you have an estimate on when this PR might be reviewed and merged?

@wrighbr No idea, I'm not a maintainer 😅

@alexymantha
Copy link

alexymantha commented Dec 16, 2024

We also need this feature. It's been stale for a little while, anything we can do to get this merged?

@daniddelrio
Copy link

+1 on this PR. Would be great if this can get merged soon

@ChrisStatham
Copy link

@kfcampbell If you have a chance to review this feature it would be appreciated thanks!

@aditya-nair1
Copy link

aditya-nair1 commented Jan 7, 2025

@kfcampbell +1, thanks!

@vimc9
Copy link

vimc9 commented Jan 7, 2025

@kfcampbell would be grateful for your review here 🚀 🚀 🚀

@tayven-bigelow
Copy link

@kfcampbell - Any chance of getting a review / approval of this PR?

@graham1228
Copy link

➕ 1️⃣ on getting this merged. Would love to migrate our bash scripts to TF, but need this functionality.

@lfraile
Copy link

lfraile commented Apr 7, 2025

+1 On desperately needing this PR to get approved :(

@tayven-bigelow
Copy link

@kfcampbell - Is there any chance we could get this merged?
Is there something missing or any sort of directive as to why it hasn't been approved?

@stevehipwell
Copy link
Collaborator

@tayven-bigelow check out the commit history for this repo, I don't think GitHub are providing engineering resources here at the moment.

@loksonarius
Copy link

tyvm for setting up this PR, I really hope it merges in soon 🙏

@Maksym-Perehinets
Copy link

hi, is there any chance to get this one merged?
+1

@deiga
Copy link
Collaborator

deiga commented Nov 18, 2025

Hey there 👋

We're looking into getting this into a mergeable state :)

This PR will need to wait until #2891 is merged as the ruleset resources in the SDK have changed.

@Moser-ss Could you try rebasing and retargeting this branch to go-github-v68?

@Moser-ss Moser-ss force-pushed the Support-repository_property-for-github_organization_ruleset branch from d30875f to 16c81f2 Compare November 18, 2025 16:04
@Moser-ss
Copy link
Contributor Author

@deiga, I already removed the conflicts by rebasing the branch with the main branch. But do you prefer that I rebase the branch using the branch go-github-v68

@deiga
Copy link
Collaborator

deiga commented Nov 18, 2025

@Moser-ss nice! I think, you could try it locally, to see if anything breaks or needs changes.
If no, then you can leave it as is. With changes needed it could be better to rebase on that branch to be prepared for the changes needed

@stevehipwell
Copy link
Collaborator

@deiga @Moser-ss given that #2891 is using v77.0.0 that'd be the version to target, but I don't think there is much value in doing this independently of #2891 as the code will be modified as part of this work.

@nickfloyd nickfloyd moved this from Backlog to BLOCKED in Terraform Provider Nov 20, 2025
@nickfloyd nickfloyd added this to the v7.0.0 Release milestone Nov 20, 2025
@Moser-ss
Copy link
Contributor Author

Moser-ss commented Dec 5, 2025

@stevehipwell I tried to rebase my branch using the branch go-github-v68, but it starts to be a mess, because I have already made changes from the main branch that are not present in the go-github-v68, in particular the function flattenRules

So, do I wait for the changes of go-github-v68 to be in the main branch, or do I redo all my changes in a new branch from the branch go-github-v68

@stevehipwell
Copy link
Collaborator

@Moser-ss I'd hold off working on this until that branch (currently targeting v77) has been merged. I also know we're considering re-working the ruleset code for the v7 provider release.

@Moser-ss Moser-ss force-pushed the Support-repository_property-for-github_organization_ruleset branch from 46a7499 to 18674a6 Compare December 5, 2025 10:32
@Moser-ss
Copy link
Contributor Author

Moser-ss commented Dec 5, 2025

@stevehipwell Ok, if you need to spread the work with more people, you can count on me

@deiga
Copy link
Collaborator

deiga commented Jan 17, 2026

@Moser-ss This can now be rebased and finalized! We managed to upgrade the SDK without a major release :)

Refactor expandConditions to reduce complexity
Refactor logic to reduce the  cognitive complexity and add logic to handle the repository_property field
Flatten conditions for repository_property and fix schemas
Add test case when ruleset use repository_property
Refactor repository property conditions to make them optional
Flatten update Target parameters to allow the detection of changes when remote resource is updated
Update documentation
  - Add ValidateFunc to include.source field for consistency with exclude
  - Update docs to mention repository_property as third targeting option
  - Fix missing space in documentation
@Moser-ss Moser-ss force-pushed the Support-repository_property-for-github_organization_ruleset branch from 18674a6 to 0888d58 Compare January 18, 2026 16:34
@Moser-ss
Copy link
Contributor Author

@deiga I just rebase with main branch

Comment on lines 122 to 123
ExactlyOneOf: []string{"conditions.0.repository_id", "conditions.0.repository_name"},
AtLeastOneOf: []string{"conditions.0.repository_id", "conditions.0.repository_name"},
Copy link
Collaborator

Choose a reason for hiding this comment

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

issue: This isn't going to work as push rulesets don't work with any of these 😬

I have a PR almost ready to build the validation logic for rulesets which you can leverage: https://github.com/integrations/terraform-provider-github/pull/2958/changes#diff-89635a4e1dcb5319cdc31ace60e4b5854c13f237e5325009e4d9897288f9d3a0

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I pushed a change that I hope matches the style of the validation we want to implement with CustomizeDiff.
I tested with my testing organization

@github-project-automation github-project-automation bot moved this from 👀 In review to 🏗 In progress in 🧰 Octokit Active Jan 18, 2026
@stevehipwell
Copy link
Collaborator

@Moser-ss I'm going to prioritise getting #2958 merged in before looking at other ruleset PRs, but as soon as that's in I'll revisit this.

@deiga deiga added the Type: Feature New feature or request label Jan 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Type: Feature New feature or request

Projects

Status: BLOCKED

Development

Successfully merging this pull request may close these issues.

[FEAT]: Support targeting dynamic list by properties in organizational rulesets