pull-requests

Need to roll back a change to a ruleset? How about easily moving your ruleset around?

With today’s public beta you now have new tools to manage your ruleset.

Import and Export

Rulesets are now easier to share and reuse, with the ability to import and export rulesets as JSON files. Giving you the ability to share rules across repositories and organizations or to share your favorite rules with the community. Which is what we’re doing. The ruleset-recipes repository is home to a collection of pre-baked rulesets covering a number of popular scenarios ready for you to use.

History

If you are a repository or organization administrator of GitHub Enterprise cloud, we’re adding a history experience so you can track changes and revert rulesets. Now, it’s easy in the ruleset UI to see who changed a ruleset, when it happened, and what changed. Then, quickly get back to a known good state.

Only changes made to a ruleset after the public beta are included in ruleset history.

Click here to learn more. If you have feedback, please share and let us know in our community discussion.

Starting today, organization administrators can create custom properties to enrich repositories with valuable information. Using these properties, you can dynamically target repository rules to apply protections on just your production repositories or to a business unit or any other way you want to classify your repositories.

Only organization administrators can configure custom properties; you can be confident knowing that they are not accidentally removed by a repository administrator, ensuring your branch and tag rules are consistently applied. Property values can also be automatically applied with default values at repository creation, ensuring every new repository is classified, and its first commit is protected.

Today, organization administrators can only use custom properties for dynamically targeting rulesets. But soon, you can use properties to filter and search in an updated repository list and other experiences across GitHub.

Learn more about managing custom properties for your organization and managing rulesets for your organization.

Head over to community discussions for feedback

Repository rule insights now make finding more details about how someone merged specific code into your repos even easier.

🔍 Filter by status

If you want only to see bypassed rules, you can now filter rule insight by the status of the results.

No more scrolling through and sorting through all the insight activity to find that one bypass situation. You can now filter by All Statuses, Pass, Fail, and Bypass.

👀 Clamoring for more insight into your rule insights?

Well, now you have access to way more information, including who ✅ approved and ❌ denied a pull request. As well as having access to the results of all required status checks and deployment status states right in rule insights.

👩‍💻 REST API Endpoint

Want to look for ruleset failures for a specific app programmatically?
With the new REST endpoint, you can now view and query rule insights via your favorite API tools.

Repository Endpoint

All repo insight activity

–  GET http://api.github.com/repos/{owner}/{repo}/rulesets/rule-suites

Specific insight rule suite for a repository ruleset
–  GET http://api.github.com/repos/{owner}/{repo}/rulesets/rule-suites/{rule _suite_id}

Organization Endpoint

All org insight activity
–  GET http://api.github.com/orgs/{org}/rulesets/rule-suites

Specific insight rule suite for an organization ruleset
–  GET http://api.github.com/orgs/{org}/rulesets/rule-suites/{rule_suite_id}

Click here to learn more. If you have feedback, please share and let us know in our feedback discussion.

Repository rules are now generally available on GitHub.com.

Repository rules allow you to easily govern protections for branches and tags on your repositories. Repository collaborators also gain access to see what rules are in place via the Web, git client, and the GitHub CLI.

For GitHub Enterprise Cloud customer, you gain the ability to enforce branch and tag protections across repositories in your organization. As well as insights on rule enforcement, evaluation mode to test rules before enforcing them and governance around commit messages.

Check out the blog post to learn more about repository rules. And if you have feedback, please share and let us know in our feedback discussion.

We are introducing a number of enhancements, bug fixes and a breaking API change to repository rules.

1. UI Updates
* Added a repository picker to target select repositories for organization rulesets.
* Improvements to rule violations in the WebUI and git client.

2. Ruleset Bypass updates

• Bypass can be limited to pull request exemptions only.
• Single UI for bypass, collapsing bypass mode, and bypass list into one experience.
• Support for using repository roles as a bypass type
• Integrations (bots/apps) are now bypassable at the org.
  

3. API Enhancements

• Add fields for created and updated date
• Permission changes so all repo contributors can query the API for relevant rules enforced on branches.

4. Bug fixes

• Linear merge history could block bypass
• Branches could not always be created when using commit metadata rules
• Tag protections were failing for apps

5. API Changes

• GraphQL changes will be delayed by 24-72 hours.
• Breaking Change Remove bypass_mode from the Ruleset object and input
• Breaking Change Add bypass_mode as a required field for bypass actors to indicate if an actor can “always” bypass a ruleset or can only bypass for a “pull_request”
• Breaking Change for GraphQL Change bypass_actor_ids to a new bypass_actors object on the create and update mutations that can accept repository roles and organization admins
• Add repository_role_database_id, repository_role_name, and organization_admin fields to RepositoryRulesetBypassActor to indicate when the bypass actor is a role or org admin bypass
• “get rules for a branch” REST API endpoint now returns ruleset source info for each rule.
• “get a repo ruleset” REST API endpoint now has a current_user_can_bypass field that indicates whether the user making the request can bypass the ruleset.
• source field for rulesets returned via the REST API will now properly contain the repo in owner/name syntax when the ruleset is configured on a repository, rather than just the repository’s name.

We want to hear from you on how we can improve repository rules! Join the conversation in the repository rules public beta discussion.