rules

Subscribe to all“rules”posts viaRSSor follow GitHub Changelog onTwitterto stay updated on everything we ship.

→ ~ cd github-changelog
→ ~/github-changelog|main git log main
showing all changes successfully

Repositories – Enterprise rules and custom properties updates

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Custom properties

Screenshot depicting new filter options available

There are new search and filtering options for custom properties now generally available to ensure you can easily find the right property.

  • Managed byallows you to limit your result by the organization or enterprise who manages the property.
  • Property typeallows you to limit your result by the available type of properties.
  • Textallows you to limit your result by the context of the property name or values.

Enterprise custom properties

Screenshot of custom property promotion screen

Enterprise custom propertiesas part of the currentpreviewcan now be promoted from an organization to an enterprise property. This ensures properties configured in one organization are available across all organizations in an enterprise.

Enterprise code rulesets

Screenshot of configuring enterprise workflow rule

Required workflows are now available as a new rule in theenterprise code rulespreview.This will allow you to target workflows across specific organizations and repositories with a single workflow file managed at the enterprise.

Note:GitHub Enterprise Cloud with data residencysupport for the enterprise workflow rule will be coming soon.

Join the discussion withinGitHub Community.

See more

Repositories: Ruleset history, import and export are generally available

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Screenshot of repository ruleset menu showing history and export.

  • Import and export makes it easy to share and reuse rulesets, including our collection ofruleset-recipesto help get you started.
  • Ruleset history allows administrators of GitHub Enterprise to easily track and rollback changes in the ruleset UI and API.

To learn more, check out theruleset documentation.You can also join ourcommunity discussions.

See more

Improved pull request merge experience enabled by default in public preview

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

The improved merge experience on the pull request pageannounced in Decemberwill be enabled by default over the next few days! The feature remains in public preview while we addressfeedback(keep it coming!) and make final improvements before making it generally available later this quarter.

Screenshot of the updated merge box page on the pull request page showing that 1 review is required, a list of status checks (some failing), and a message about not having any merge conflicts.

This improved experience, while still familiar, is designed to help you better understand the state of your pull request and get it merged faster. To learn more, see thepublic preview announcement.

Recent fixes

There have been numerous bugs fixed and feature gaps filled since the public preview launched last year. Here are some notable fixes:

  • Fixed:Enabling auto-merge, deleting branch (after merging), or restoring branch previously failed with an unexpected error message.
  • Fixed:In certain scenarios, the commit author email address shown when merging the pull request would not match the email address in the resulting merge (or squash) commit.
  • Fixed:GitHub Actions workflow runs could only be approved from the classic merge experience.
  • Fixed:Status check durations were missing.

We’ve also made various improvements, including natural ordering for status checks. For a more complete list, see therecently fixed section of this discussion.

How to turn it off

To switch back to the classic experience, click theSwitch back to the classic merge experiencejust below the merge experience on the Conversation page:

A screenshot showing how to switch back to the classic merge experience

If you want to return to the improved experience, clickTry the new merge experiencebelow the merge box on the pull request page:

A screenshot showing how to re-enable the improved merge experience

You can also toggle the experience via thefeature preview dialog.

How to provide feedback

We want to hear from you! To provide feedback, ask questions, and see a list of known issues, visit the GitHub Communityimproved merge box discussion.

See more

Pull request merge method rule – Public Preview

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Repository rules now allow you to enforce which merge methods are available when merging pull requests into a specified branch. The merge method rule is available for rulesets at the repository, organization and the enterprise level. Allowing you to choose between merge commit, squash, or rebase to ensure only the selected merge methods are allowed on the targeted branches across the user interface and APIs.

Screenshot of merge type rule selection

Learn more in thedocumentationand join the discussion withinGitHub Community.

See more

Enterprise repository properties, policies and rulesets – Public Preview

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

We are excited to announce the launch of new governance at scale features for enterprise accounts in public preview. This preview includesenterprise custom repository properties,enterprise repository policiesandenterprise rulesetsto help enterprise administrators manage more at greater scale.

Check out thisvideo on managing your repositories at scale across the enterpriseand learn more below.

Enterprise custom properties

Enterprise customers can now enrich repositories with metadata and govern protections for branches, pushes, and tags across your entire enterprise using repositorycustom propertiesandrulesets.

Enterprise custom properties screenshot
With custom properties available at the enterprise level, you can ensure consistent properties across organizations without manual synchronization and de-duplication. Enterprise and organization properties share a common namespace to prevent confusion when searching or targeting rulesets with properties.
To learn more about enterprise custom properties, head over to thedocs.

Enterprise rulesets

Enterprise rulesets screenshot

Enterprise-level rulesets enforce consistent code governance rules to ensure thorough reviews of critical repositories with pull requests, and protect important locations from unauthorized pushes. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.

Enterprise repository policy

We are also introducing repository policies, which allow you to effectively manage repository lifecycle events such as deletions and visibility from the enterprise level. Enterprise administrators can target enterprise polices over repositories in organizations, as well as repositories homed under personal namespaces for any company usingenterprise managed users.

Enterprise repository policy screenshot
Repository policies extend the ruleset framework to help you govern repositories beyond the code itself. These policies manage lifecycle events, enhancing the security, compliance and resilience of your repositories. You can enable repository policies per organization, and the preview launches with five policies:
– Restrict visibility
– Restrict creations
– Restrict deletions
– Restrict transfers
– Restrict names

To learn more about enterprise repository policy, head over to thedocs.

Feedback

To ask questions or share feedback, join our discussion in theGitHub Community.

See more

Improved pull request merge experience now in public preview

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

To help you better understand the state of your pull request and get it merged faster, the merge experience on the pull request page has been improved! This experience is currently in public preview.

Screen shot of the updated merge box page on the pull request page showing that 1 review is required, a list of status checks (some failing), and a message about not having any merge conflicts.

What’s new

We’ve maintained the familiar look of the existing merge experience while incorporating several usability improvements:

  • Checks grouped by status:checks are now grouped by status with failing checks prioritized at the top of the list, making it easier to identify issues that need attention
  • Checks ordered alphabetically:status checks are now ordered alphabetically to make it easier to find a specific check
  • Commit metadata validation:errors from failing commit metadata rules (like non-compliant commit messages) can now be corrected and retried
  • Improved accessibility:consistent keyboard navigation, focus management, and landmarks help make the experience more accessible to everyone

For a more completelist of changesvisit the feedback discussion.

Try it out

This improved experience is rolling out gradually and is turned off by default. Once it becomes available to you, aTry the new merge experiencelink will appear below the merge box on the pull request page:

Image

Click it to switch to the improved experience. A link is also available for easily switching back to the existing experience. You can also toggle the experience via thefeature preview dialog.

Known issues

As this experience is in public preview, you may run into some bugs and missing features (let us know when you do). Some of the known issues include:

  • Actions workflows requiring approval cannot be approved currently
  • Changing the commit author email when merging is not currently supported

For a more complete list ofknown issuesvisit the feedback discussion.

Feedback

We want to hear from you! To provide feedback, ask questions, and see a list of known issues, visit the GitHub Communityimproved merge box discussion!

See more

Updates to repository enterprise policy, ruleset and custom properties

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Recent improvements to enterprise repository policy, rulesets, and custom properties now ensure a more consistent, intuitive experience, making it easier for you to navigate and accomplish your tasks efficiently.

  • Enterprise repository policy page has been renamed to “Member privileges” to align the page title with the current URL path, API endpoints and the correspondingorganization setting.

Screenshot of member privileges

  • Repository rulesetsnow support enterprise owners as a bypass actor, ensuring your most privileged roles across your enterprise can bypass rulesets.

Screenshot of ruleset bypass with enterprise owners

Screenshot of additional repository property section

We want to hear from you

Questions or suggestions? Join the conversation in thecommunity discussion.

See more

Push Rules are now generally available, and updates to custom properties

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

You can now restrict pushes into your private and internal repositories and their forks, withpush rules– a new type ofruleset.Push rules enable you to limit updates to sensitive files like actions workflows, and help to enforce code hygiene by keeping unwanted objects out of your repositories.

In addition, organization owners can now allow repository property values to be set when repositories are created. This ensures appropriate rules are enforced from the moment of creation and improves discoverability of new repositories.

Push Rules

Organization and repository owners can now configure rules that govern what changes can be pushed to their repository, by attributes of the files changed – including their paths, extensions and sizes.

Screenshot showing the list of new push rules with options configured

Available push rules

  • Restrict file paths
    • This rule allows you to define files or file paths that cannot be pushed to. An example of when you might use this is if you wanted to limit changes to your Actions workflows in.github/workflows/**/*
  • Restrict file path length
    • You can limit the path length of folder and file names.
  • Restrict file extensions
    • You can keep binaries out of your repositories using this rule. By adding a list of extensions, you can excludeexejarand more from entering the repository.
  • Restrict file size
    • Limit the size of files allowed to be pushed. Note: currentGitHub limitsare still enforced.

Push rules are available on GitHub Team plans for private repositories, and coverage extends to not just the repository, but also all forks of that repository. Additionally, GitHub Enterprise Cloud customers can set push rules on internal repositories and across organizations with custom repository properties. You can also access rule insights to see how push rules are applied across your repositories.

Additional details

  • Delegated bypassfor push rules, currently in beta, allows your development teams to stay compliant with internal policies and keep a clean git history. Developers can easily request exceptions to push rules, that are reviewed and audited all within GitHub.
  • To ensure best performance push rules are designed to handle up to 1000 reference updates for branches and tags per push.

For more information, see thePush Rule documentationand to get started you can visit theruleset-recipesrepositoryto import an example push ruleset.

Custom properties

Organization owners can now allow their users to set custom properties duringrepository creation.Previously, this was only available to repository administrators or those with permissions to edit custom repository properties. By selectingAllow repository actors to set this propertyfor your custom property, you can ensure repositories have properties attached from the start.

Screenshot of new repo being set up with a custom repository property

We want to hear from you

Questions or suggestions? Join the conversation in thecommunity discussion.

See more

Repository updates July 31st 2024

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

We’re excited to bring an updated repository list view experience and the ruleset merge queue rule to general availability, as well as an update to the status check and workflow rules.

Finding repositories in your organization is now easier

With the introduction ofcustom propertiesearlier this year we wanted to make it easier to find repositories across your organization. With the new organization repository view and advanced filtering you find repositories based on common parameters like visibility and language, but also custom properties, size, license and a host of additional values.

Screenshot of repository list view filtered by visibility, archived status and a custom property showing a list of 64 repositories.

Repository Rules updates

Repository ruleset merge queue rule is now generally available

In addition to being able to manage your merge queue via rules, you can now see all the pull requests that merged in the same group along with the checks needed for the queue with rule insights.

Screenshot of repository rule merge queue options with default configurations.

Learn more about merge queues in ourdocumentationand repository rulesREST API

Avoid required status checks and required workflows when creating branches

Applying status check and actions workflow rules to newly created branches has been a point of friction in rulesets. When creating a new branch will fail unless you add bypass actors or create an intermediate unprotected branch. To alleviate this friction there is a new option available prevent checks and workflows from running on new branches.

Screenshot of require status check rule with the new "Do not require status checks on creation" option enabled

Learn more aboutstatus check rulesandrequired workflows rulesin our documentation.

Join the discussion withinGitHub Community.

See more

Repository updates June 12th 2024

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

We’re excited to introduce enhancements tocustom propertiesas well as updates to thepush rule public beta.

Custom properties updates!

New property types

  • Multi selectallows a repo to have more than one value for a property defined. Now a repository can have a property that defines a compliance requirement with values for FedRamp and SOC2, for example.
  • True/Falseallows you to set whether a given property is true or false for a given repository.

repository properties with multi select

Target rulesets by repository visibility and more

In addition to targeting repositories with the custom properties you’ve created, we’ve now extended property targeting to include the ability to target by:
–Visibility:public, private, or internal
–Fork:true, false
–Language:select primaryrepository language.

System property targeting in a ruleset screenshot

Learn more in thecustom properties documentation

What do you think? Start a discussion withinGitHub Community.

Push rule delegated bypass public beta!

We are expanding on thepush rule public betawith a new delegated bypass flow.

Previously to bypass push rules you had to be on the bypass list to push restricted content. Now with delegated bypass, contributors can propose bypassing a push rule and members of the bypass list can review those bypass requests to allow or deny the content.

Learn more about push rule delegated bypass in therepository rules documentationand join the push rule discussion in theGitHub Community.

Delegated bypass screenshot

See more

Sunset Notice – Tag Protections

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

EDIT: Monday December 2nd, 2024

GitHub Enterprise Server Timeline changing sunset to GHES 3.17 as the final version instead of 3.16.

Starting today, we will begin work towards the sunset oftag protections,with a full deprecation planned for August 30, 2024.See below for a full sunset timeline. You can migrate existing tag protections with theimport to ruleset feature.

Welaunched repository rules last yearto meet the needs of tag protection rules, while also scaling support to provide new functionalities like org-wide rules, granular restrictions for creating, reading, and updating events, and a more granular bypass model that does not require repository administrator permissions. As we such, we will sunsettag protectionsin favor of our ongoing investment in the repository rulesets platform.

You can import existing tag protection rules today with the existingmigration feature.If no action is taken before the sunset date, GitHub will migrate all existing tag protections into a corresponding ruleset.

When are changes happening?

GitHub.com Timeline

  • May 30: Repositories without tag protection rules will no longer be able to add new protection rules via the GitHub.com UI
  • July 24 through August 14: A series of API brownouts will be run, see below for additional details on dates and times.
  • August 30, 2024: All tag protection rules will be migrated to a new tag ruleset. All REST and GraphQL API endpoints will be deprecated

GitHub.com API Timeline

  • May 30: API responses will include a deprecation notice
  • July 24: 1 hour API brownout
  • August 7: 8 hour API brownout
  • August 14: 24 hour API brownout
  • August 30: The tag protection rule API will begin responding with NULL data
  • The tag protection rules API will be deprecated in the next calendar version

GitHub Enterprise Server Timeline

  • Version 3.14: Tag protection rules will be marked for deprecation with an in-product banner and API responses will include a deprecation notice
  • Version 3.15: No changes will be made
  • Version 3.16: No changes will be made
  • Version 3.17: Tag protection rules will be migrated to a ruleset and the tag protection rule feature will no longer be available

Join the discussion withinGitHub Community.

See more

Repository Updates April 30th, 2024

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Repository Updates April 30th, 2024

  • Deploy keys are now supported as a bypass actor inrepository rules,allowing additional granularity for your automations. Previously for deploy keys to bypass a ruleset the Repository Administrator role was required.

  • Webhooks and GitHub Actions will no longer be run for any push that includes over 5000 branches. Clients will now receive the following warning indicating they have reached this limit.remote: warning: No webhooks or actions will be performed for this push as it updates more than 5000 branches.

Join the discussion withinGitHub Community.

See more

Code scanning now allows configuring rulesets to prevent pull requests from being merged (beta)

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

The code scanning option forrepository rulesis now available in public beta. Code scanning users can now create a dedicated code scanning rule to block pull request merges, instead of relying on status checks.
Making it easier than ever to prevent new vulnerabilities from being introduced into your code base.

code scanning rule

Configuring code scanning merge protection with rulesets can be done at the repository or organization levels and for repositories configured with either default setup or advanced setup. Additionally you can also use the REST API to set merge protection withrulesets.

You can use rulesets to prevent pull requests from being merged when one of the following conditions is met:
– A required tool found a code scanning alert of a severity that is defined in a ruleset.
– A required code scanning tool’s analysis is still in progress.
– A required code scanning tool is not configured for the repository.

Note:Merge protection with rulesets is not related to status checks. If the code scanning rule is configured for the repository in parallel with an alert threshold and the merge protection rule for the code scanning check run, the two functionalities will work simultaneously. For more information about status checks, seeabout status checks.

This beta is now available on GitHub.com and will be available on GHES 3.14. The organisation wide rules is only available for GitHub enterprise. For more information, seeConfiguring merge protection for all repositories in an organization.

We look forward to your feedback on the code scanning option for repository rulesin the GitHub community.

See more

Push rules public beta

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Say goodbye to unwanted files cluttering your repos, like*.jaror*.so.And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉

A glimpse of push rules in action

You can now enable a new type of ruleset that allows you to control pushes to repositories based on file extensions, file path lengths, file and folder paths and file sizes. Push rules don’t require any branch targeting as they apply to every push to the repository, and also apply to all forks of the repo to ensure all pushes to therepository networkare protected.

Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.

Learn more aboutpush rulesin our documentation and join thecommunity discussionto leave feedback.

See more

Repository Rules – configure merge queue rule – public beta

html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"

Configuring mergequeuein your reporulesets is nowavailablein public beta!

Screenshot showing the configuration of merge queue inside a ruleset

Merge queue & rule insights

Until now, rule insights would only list one pull request as merged even when multiple pull requests were merged by the queue at the same time. Also in this beta, each pull request in a merge queue will have an individual record in rule insights, linked to the actor that added the pull request to the merge queue.

Example screenshot showing rules insights and all PRs from a queue

Within the additional data of a rule insight dialog you can now see all the pull requests that merged in the same group along with the checks needed for the queue.

Example screenshot of details of a queue in rule insights

Limitations

  • The merge queue rule cannot be configured via an API. This feature will be available in the near future.
  • Merge Queue for branch protections and repository rules do not support wildcard patterns
  • Not supported in organization rulesets.
  • Multiple merge queues configured against a single branch will prevent merging.

Join the discussion withinGitHub Community.

See more
View more changes