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.