Public preview feedback: Enterprise repository properties, policies and rulesets

[patrick-knight]

Thanks for exploring enterprise properties, policies and rulesets! We are excited to introduce a host of new features to help you better govern your enterprise as part of this public preview. If you’re here to share feedback on the merge method rule you’re in the right spot!

Enterprise custom repository properties

Create properties at the enterprise level that become available across all organizations. Providing you a way to share properties across all orgs without having to synchronize properties and deal with duplication, so you have a central place to control all enterprise-wide properties. The creation experience is nearly the same as repo properties at the org, where you create a property with a name and a type, but enterprise properties do not have the set value experience which is done per organization.

To learn more about enterprise custom properties, head over to the docs.

Planned enhancements for general availability

• Enterprise owners will be able to filter and search for properties across all organizations.
• Enterprise owners will be able to promote an organization owned custom properties to the enterprise.

Known limitations

• There is a shared namespace across repository properties so properties created by an organization or enterprise must be uniquely named.
• Enterprise properties are not available on the enterprise security overview.

Enterprise repository policies

An easy way across your enterprise to say certain types of repositories, based on custom properties, can’t be transferred, or deleted or have its visibility changed in a granular way. Policies can also apply to organizations and enterprise managed user repositories.

To learn more about enterprise repository policies, head over to the docs.

Planned enhancements for general availability

• Policies to manage forking and archiving of repositories.

Known limitations

• Policies for enterprise managed users will apply to all of those repositories, with no additional granularity.

Enterprise code rulesets

Create branch, tag and push rules at the enterprise, that include rule insights and push rule delegated bypasses.

Planned enhancements for general availability

• Support for the “require workflows to pass before merging” rule

Known issues

• Bypass list is limited to built-in roles and deploy keys
• The following branch rules are not available at the enterprise level:
  • Require deployments to succeed
  • Require merge queue
  • Require status checks to pass
  • Require workflows to pass before merging

Feedback

We want to hear from you! Add your comments, questions, likes and dislikes below. 🔽

[chrisreddington]

Looking for a quick overview and hands-on demo? Check out our video on GitHub's YouTube Channel

[IAmHughes]

Hey @patrick-knight

Thanks for the discussion around this. We find this to be a very exciting feature to track; however, the "200 values per property" limit is quite limiting for our use case. We want to identify repositories by the business service they support. We have over 2,000 business services and 100,000 repositories. If the property was business-service and the value was the specific service itself, we'd hit our 200 limit and require 10 properties be labeled incrementally such as, business-service1, business-service2, etc. to allow for the total number of values, resulting in a poor UX.

Is this 200 limit in place as a rough rate limit attempt while in preview or due to actual performance issues? I understand for use cases such as environment, for example, there's no need for a long list; but our use case would require multiple thousand values. A potential workaround we were considering before custom properties was to look at repository labels instead; however, these are less ideal.

[patrick-knight]

The limit is the same as what exists for organization owned properties. This was an implementation choice based on UX constraints as well as platform scalability, but we continue to evaluate the data and feedback around the existing limits.

Out of curiosity what's the current location that business-service is tracked today outside GitHub?

[IAmHughes]

The limit is the same as what exists for organization owned properties. This was an implementation choice based on UX constraints as well as platform scalability, but we continue to evaluate the data and feedback around the existing limits.

I understand the limit is the same on an org level and enterprise level, but we'd still want to see the limit increased.

I know GitHub has a lot of opportunity when it comes to UX in terms of pagination, but it can't be any worse than other areas of the application with large pagination and no filters 😛 - Understood though and I appreciate you want the UX to be a good experience as well.

For scalability, I can understand that being a potential limiting factor as well, though I hope this can be increased/optimized by y'all for the use case I described. I can't imagine looking up a key with 1000 possible values is a very large compute lift over 200 possible values, but I don't know the full data structure y'all went with of course and won't pretend to 😄

Out of curiosity what's the current location that business-service is tracked today outside GitHub?

It's managed in a few places right now (we're actually trying to centralize this data as well for a single source of truth that could then be mapped to GitHub) including an internal tool, a system built on the open source backstage project, and some in AzureAD/EntraID as well, though again it's a bit of a work in progress on standardization we're doing as well.

Another thought on justifying the additional limit would be that the billing team has found a way to not limit (or at least I don't see one listed in the Docs for cost-centers. Enterprises may have hundreds of cost centers, so I'm curious what their limit is (if one exists and isn't documented) or maybe how they're handling the UX of more than 200? Just a thought on another approach to it 👍