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.
Learn more in the documentation and join the discussion within GitHub Community.
We are excited to announce the launch of new governance at scale features for enterprise accounts in public preview. This preview includes enterprise custom repository properties, enterprise repository policies and enterprise rulesets to help enterprise administrators manage more at greater scale.
Check out this video on managing your repositories at scale across the enterprise and learn more below.
Enterprise customers can now enrich repositories with metadata and govern protections for branches, pushes, and tags across your entire enterprise using repository custom properties and rulesets.
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 the docs.
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.
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 using enterprise managed users.
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 the docs.
To ask questions or share feedback, join our discussion in the GitHub Community.
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.
We’ve maintained the familiar look of the existing merge experience while incorporating several usability improvements:
For a more complete list of changes visit the feedback discussion.
This improved experience is rolling out gradually and is turned off by default. Once it becomes available to you, a Try the new merge experience link will appear below the merge box on the pull request page:
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 the feature preview dialog.
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:
For a more complete list of known issues visit the feedback discussion.
We want to hear from you! To provide feedback, ask questions, and see a list of known issues, visit the GitHub Community improved merge box discussion!
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.
Questions or suggestions? Join the conversation in the community discussion.
You can now restrict pushes into your private and internal repositories and their forks, with push rules – a new type of ruleset. 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.
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.
Restrict file paths
.github/workflows/**/* Restrict file path length
Restrict file extensions
exe jar and more from entering the repository.Restrict file size
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.
For more information, see the Push Rule documentation and to get started you can visit the ruleset-recipes repository to import an example push ruleset.
Organization owners can now allow their users to set custom properties during repository creation. Previously, this was only available to repository administrators or those with permissions to edit custom repository properties. By selecting Allow repository actors to set this property for your custom property, you can ensure repositories have properties attached from the start.
Questions or suggestions? Join the conversation in the community discussion.
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.
With the introduction of custom properties earlier 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.
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.
Learn more about merge queues in our documentation and repository rules REST API
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.
Learn more about status check rules and required workflows rules in our documentation.
Join the discussion within GitHub Community.
We’re excited to introduce enhancements to custom properties as well as updates to the push rule public beta.
Multi select allows 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/False allows you to set whether a given property is true or false for a given repository.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 primary repository language.
Learn more in the custom properties documentation
What do you think? Start a discussion within GitHub Community.
We are expanding on the push rule public beta with 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 the repository rules documentation and join the push rule discussion in the GitHub Community.
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 of tag protections, with a full deprecation planned for August 30, 2024. See below for a full sunset timeline. You can migrate existing tag protections with the import to ruleset feature.
We launched repository rules last year to 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 sunset tag protections in favor of our ongoing investment in the repository rulesets platform.
You can import existing tag protection rules today with the existing migration 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
GitHub.com API Timeline
GitHub Enterprise Server Timeline
Join the discussion within GitHub Community.
Repository Updates April 30th, 2024
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 within GitHub Community.
The code scanning option for repository rules is 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.
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 with rulesets.
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, see about 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, see Configuring merge protection for all repositories in an organization.
We look forward to your feedback on the code scanning option for repository rules in the GitHub community.
Say goodbye to unwanted files cluttering your repos, like *.jar or *.so. And limit who can make updates to sensitive files like your Actions workflows with the public beta of push rules. 🎉
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 the repository network are protected.
Push rules are now available for private and internal repositories for GitHub Teams, and across organizations for GitHub Enterprise Cloud.
Learn more about push rules in our documentation and join the community discussion to leave feedback.
Configuring merge queue in your repo rulesets is now available in public beta!
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.
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.
Join the discussion within GitHub Community.
We’re excited to announce the general availability of Repository Custom Properties, a major enhancement to how repositories are managed and classified across GitHub organizations.
Properties offer a flexible way to add meaningful metadata to your repositories that simplifies repository classification, enhances discoverability, and seamlessly integrates with rulesets.
Check out this video from our own Jon Peck for a walk through of a common scenario.
Starting today the new repositories list view moves to public beta.
Repository Rules now support adding Dependabot to bypass lists. This enables you to let Dependabot merge changes to a repository’s protected branch.
Learn more about managing custom properties for your organization and managing rulesets for your organization.
Auto-triage rules are a powerful tool to help you reduce false positives and alert fatigue substantially, while better managing your alerts at scale. We've heard your feedback, which is helping us improve throughout this beta period.
Starting today, you can now create Dependabot auto-triage rules using CVE IDs or GHSA IDs to target subsets of alerts.
Let us know what you think by providing feedback — we’re listening!
Auto-triage rules are a powerful tool to help you reduce alert and pull request fatigue substantially, while better managing your alerts at scale.
Starting today, you can define your own rules to control and enforce Dependabot behaviors across organizations and individual repositories.
Auto-triage rules are defined by alert targeting criteria, the behaviors you'd like Dependabot to automatically perform for these alerts, as well as how you want the rule to be enabled or enforced across your organization.
Alerts can be targeted based on metadata related to the advisory, dependency, and how it's used. For this public beta, currently supported attributes at the organization level are: severity, scope, package-name, cwe, and ecosystem. At the repository level, you can also target specific manifest files.
For any existing or future alerts that match a custom rule, Dependabot will perform the selected behavior accordingly. You can proactively filter out false positives, snooze alerts until patch release, choose which alerts open Dependabot security updates, and – as rules apply to both future and current alerts – manage existing alerts in bulk.
This feature is free for open source (all public repositories) and available for use in private repositories through GitHub Advanced Security.
At GitHub, we’ve been thinking deeply about how to responsibly address long-running issues around alert fatigue and false positives. Rather than over-indexing on one criterion like reachability or dependency scope, we believe that a responsibly-designed solution should be able to detect and reason on a rich set of complex, contextual alert metadata.
That’s why, moving forward, we’re releasing a series of ships powered by a flexible and powerful alert rules engine. Our first ship – Dependabot presets – leveraged our rules engine with GitHub-curated vulnerability patterns and has helped millions of repositories filter out false positive alerts. Today’s ship exposes our rules engine at the organization and repository levels, so you can create and enforce custom rules, too.
From your organization or repository settings page, admins and security managers can navigate to Code security and analysis settings. Under Dependabot, select Dependabot rules to add or modify your own custom rules or modify GitHub presets.
At the organization level, rules can be set with the following states.
| State | Description |
|---|---|
Enabled |
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Any individual repository can choose to disable the rule. |
Enforced |
This rule will be enabled across all eligible repositories in your organization. It will be on by default (new repositories are included). Individual repositories cannot override this setting. |
Disabled |
This rule will be disabled and hidden across your organization. |
At the repository level, rules can be set to enabled or disabled if they're not enforced.
Rules can be created across the following attributes:
| Attribute | Description |
|---|---|
severity |
Alert severity, based on CVSS base score, across the following values: low, medium, high, and critical. |
scope |
Scope of the dependency: development (devDependency) or runtime (production). |
package-name |
Packages, listed by package name. |
cwe |
CWEs, listed by CWE ID. |
ecosystem |
Ecosystems, listed by ecosystem name. |
manifest |
Manifest files, listed by manifest path. |
Note: manifest is only available at the repository level.
You can use the alert criteria (above) to indicate which alerts Dependabot will attempt to open pull requests to resolve. To use auto-triage rules with Dependabot updates, you must disable Dependabot's option to always open pull requests to resolve all open alerts from the repository Code security and analysis settings.
Similar to Dependabot pull request rules, you can control how Dependabot filters out false postives (with dismiss indefinitely) or snoozes alerts (with dismiss until patch).
At the time of public beta, you can create 20 rules per organization and 10 rules for each repository. Want more? Let us know!
Auto-dismissal activity is shown in webhooks, REST, GraphQL, and the audit log for Dependabot alerts. Alerts are dismissed without a notification or new pull request and appear as a special timeline event. As these alerts are closed, you’ll still be able to review any auto-dismissed alerts with the resolution:auto-dismissed filter.
Auto-triage rules are free for open source repositories. Anyone who can enable Dependabot alerts for a public repository will be able to create custom rules for it. Customers of GitHub Advanced Security can create and manage custom rules across private repositories and at the organization level.
Like any manually dismissed alert, you can reopen an auto-dismissed alert from the alert list view or details page. This specific alert won’t be auto-dismissed again (by any other auto-dismiss rule).
Dependabot recognizes and immediately responds to any changes to metadata which void auto-dismissal logic. For example, if you change the dependency scope and the alert no longer meets the criteria to be auto-dismissed, the alert will automatically reopen.
Let us know what you think by providing feedback — we’re listening!