GitHub Community
Support Enterprise Teams as CODEOWNERS #210450
Replies: 3 comments 1 reply
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Current Technical Limitation CODEOWNER status Direct repository permissions / team assignment Project boards, secret teams, or nested team structures This limitation exists because the CODEOWNERS parser is designed at the Organization scope. For a team to act as a code owner, it must explicitly exist within the repository's host organization and hold explicit write access to that specific repository. Since Enterprise Teams span across multiple organizations, GitHub's branch protection engine cannot currently evaluate cross-org write permissions or auto-request reviews from them. Current Workarounds Organization-Level Team Mapping: Create organization-level teams within each child org and link them to your IdP (Okta, Entra ID, etc.) via Team Sync. This maintains centralized membership control while providing an @org/team-name handle that CODEOWNERS and branch rulesets can consume. Rulesets + Custom Status Checks: Instead of relying on native CODEOWNERS evaluation, use Repository Rulesets combined with an internal GitHub Action (e.g., using actions/github-script) to validate pull request reviewers against Enterprise Team API endpoints before permitting merges. If this answer clarifies the architectural reasoning and provides a viable workaround, please mark it as the accepted answer! |
|
The core of this post is the last line which is centric about understanding the direction for support with this feature; when I asked "Is there aims to support enterprise teams in the future as CODEOWNER targets?" I omitted asking for work-arounds intentionally as none of them use Enterprise Teams in conjunction with built-in Github functionality. You've pulled out some facts and then in some cases fabricated them, CODEOWNER status is not supported, project boards don't support enterprise teams but direct repository permissions absolutely are supported. I feel like this is a point worth calling out because documentation in this space is sparse and inaccurate details in responses like this can mislead people trying to understand the feature. On a side note, I believe this is an LLM generated response and checking other discussions of which you have participated in can see you've forgotten to drop out the LLM-provided subtext. If so, I’d encourage engaging directly rather than posting automated summaries, because they can add noise to the discussion. Happy to keep the discussion focused on the actual intent. |
|
Current Technical Limitation CODEOWNER status Direct repository permissions / team assignment Project boards, secret teams, or nested team structures This limitation exists because the CODEOWNERS parser is designed at the Organization scope. For a team to act as a code owner, it must explicitly exist within the repository's host organization and hold explicit write access to that specific repository. Since Enterprise Teams span across multiple organizations, GitHub's branch protection engine cannot currently evaluate cross-org write permissions or auto-request reviews from them. Current Workarounds Organization-Level Team Mapping: Create organization-level teams within each child org and link them to your IdP (Okta, Entra ID, etc.) via Team Sync. This maintains centralized membership control while providing an @org/team-name handle that CODEOWNERS and branch rulesets can consume. Rulesets + Custom Status Checks: Instead of relying on native CODEOWNERS evaluation, use Repository Rulesets combined with an internal GitHub Action (e.g., using actions/github-script) to validate pull request reviewers against Enterprise Team API endpoints before permitting merges. If this answer clarifies the architectural reasoning and provides a viable workaround, please mark it as the accepted answer! |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
🏷️ Discussion Type
Product Feedback
Body
The addition of enterprise teams allows us to group individuals from the enterprise and cascade down into organisations for better control of teams which is a welcomed addition for enterprises which may span across multiple organisations.
Whilst documented that enterprise teams cannot be used as CODEOWNERS, this is a bit of a confusing gap as it means controls such as requiring a specific CODEOWNER review cannot be paired with the ruleset controls such as requiring specific CODEOWNERS to take part in pull requests.
The documentation for this and lack of signals otherwise currently implies this is intentional design choice. Is there aims to support enterprise teams in the future as CODEOWNER targets?
All reactions