-
Notifications
You must be signed in to change notification settings - Fork 904
chore: Deprecate duplicate org team role resources #2933
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
Merged
stevehipwell
merged 3 commits into
integrations:main
from
stevehipwell:org-role-team-assignment-deprecation
Nov 26, 2025
+20
−8
Merged
Changes from all commits
Commits
Show all changes
3 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
question: Do we have a naming convention for these kinds of resources? I personally think that
github_organization_role_team_assignmentis clearer thangithub_organization_role_team, especially since GitHub uses the "Role assignment" terminologyAnd a second note: The docs for https://registry.terraform.io/providers/integrations/github/latest/docs/resources/organization_role_team_assignment are more verbose and user-friendly than https://registry.terraform.io/providers/integrations/github/latest/docs/resources/organization_role_team
So, if we want to deprecate
github_organization_role_team_assignmentcan we copy over the docs from it? :)Uh oh!
There was an error while loading. Please reload this page.
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.
Naming for the resources and data is a good thing to have.
There is for example another thing which may need to be addressed as well due to naming.
The data and resource for organization custom properties are named in plural
properties, but neither data not resource works with more than a single property.The resource organization_custom_properties and data organization_custom_properties
It means it most likely needs to be done depreciation of these "plurals" and introducing of "singulars" with
propertyin the names.It could be that "singular" named resources should be introduced in
v6and "plurals" removed inv7.I saw @mroyme done naming of repsource with singular property in their fork, which is more correct if it adds only a single custom property.
PS Added the issue #2936
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.
@deiga the resource
github_organization_role_teamwas implemented with all of the other related resources and data sources using consistent naming and implementation patterns.I also don't agree that the assignment suffix is necessarily an improvement to the name, it adds additional characters to parse and fit on a single line. In this context the point is consistency with all of the other related resources. If you want to discuss changing the naming conventions I think that's a separate issue.
@ViacheslavKudinov I agree with your points on pluralization and duplication of context in names. I'm not sure which way you're arguing here but in this context my interpretation of your logic would be that the assignment suffix isn't required as the context is already complete.
Uh oh!
There was an error while loading. Please reload this page.
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 have no strong opinion about this concrete resource, tbh.
PS At the same time as it was introduced Enterprise Roles and (Custom) Enterprise Role can be assigned to Enterprise team(s), it would be great if we use same "naming" for those as well to keep consistency, when we introduce new data/resources.
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.
FYI the PR (#2487) was opened almost a year ago, long before enterprise roles were a thing.
Uh oh!
There was an error while loading. Please reload this page.
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 thanks for sharing.
Now it looks like (from my perspective) is better to deprecate
organization_role_team_assignment, exactly what PR addresses (it was introduced a little bit more than a month ago in v6.7.0.As it (
organization_role_team_assignment) was added "recently" may need less changes for provider consumers instead oforganization_role_team, which is present for almost one year.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.
@ViacheslavKudinov they were all introduced in the same release, the PR freeze left everything backed up which meant that overlapping PRs got merged. The
organization_role_teamresource is part of a set of 11 resources or data sources whileorganization_role_team_assignmentwas in a PR on it's own.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 thank you for sharing the context.
I totally fine with this PR as I got better understanding. Have no any concern.