Add content for "Repository Rules" [GA] (#39268)
Co-authored-by: Patrick Knight <patrick-knight@github.com> Co-authored-by: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com>
This commit is contained in:
Sam Browning
@@ -113,7 +113,7 @@ If you're running Bitbucket Data Center in cluster mode with multiple notes, you
|
||||
|
||||
### `Repository rule violations found` error
|
||||
|
||||
If you receive a `Repository rule violations found` error, such as `GH013: Repository rule violations found for refs/heads/main`, data in the origin repository conflicts with rulesets (public beta) configured on the destination organization. For more information, see "[AUTOTITLE]({% ifversion repo-rules %}{% else %}/enterprise-cloud@latest{% endif %}/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
|
||||
If you receive a `Repository rule violations found` error, such as `GH013: Repository rule violations found for refs/heads/main`, data in the origin repository conflicts with rulesets configured on the destination organization. For more information, see "[AUTOTITLE]({% ifversion repo-rules %}{% else %}/enterprise-cloud@latest{% endif %}/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
|
||||
|
||||
You can temporarily disable your rulesets during your migration, or you can use bypass mode or the bypass list to exempt your migration from configured rules. For more information, see "[AUTOTITLE]({% ifversion repo-rules-enterprise %}{% else %}/enterprise-cloud@latest{% endif %}/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization)."
|
||||
|
||||
|
||||
@@ -9,8 +9,6 @@ topics:
|
||||
shortTitle: Manage rulesets
|
||||
---
|
||||
|
||||
{% data reusables.repositories.rulesets-public-beta %}
|
||||
|
||||
## About managing rulesets for an organization
|
||||
|
||||
You can create rulesets in your organization to control how users can interact with repositories in your organization. You can control things like who can push commits to a certain branch and how the commits must be formatted, or who can delete or rename a tag. You can also prevent people from renaming repositories.
|
||||
@@ -19,7 +17,7 @@ When you create a ruleset for an organization, you use `fnmatch` syntax to defin
|
||||
|
||||
{% data reusables.repositories.ruleset-bypass %}
|
||||
|
||||
You can use the REST API to manage rulesets. For more information, see "[AUTOTITLE](/rest/orgs/rules)."
|
||||
You can use the REST and GraphQL APIs to manage rulesets. For more information, see "[AUTOTITLE](/rest/orgs/rules)" and "[AUTOTITLE](/graphql/reference/mutations#createrepositoryruleset)."
|
||||
|
||||
If a repository is targeted by a ruleset created at organization level, only owners of the organization can edit this ruleset. However, people with admin access to the repository, or with a custom role including the "edit repository rules" permission, can create additional rulesets at the repository level. The rules in these rulesets will be aggregated with the rules defined at organization level. The result is that creating a new ruleset can make the rules targeting a branch or tag more restrictive, but never less restrictive. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
|
||||
|
||||
@@ -37,11 +35,22 @@ Forks do not inherit rulesets from their upstream repositories. However, forks o
|
||||
{% data reusables.repositories.create-ruleset-step %}
|
||||
{% data reusables.repositories.rulesets-general-step %}
|
||||
{% data reusables.repositories.rulesets-bypass-step %}
|
||||
1. In the "Target repositories" section, select **Add a target** to add repositories. You can include all repositories in your organization, or you can use `fnmatch` syntax to include or exclude repository names based on a pattern. For more information, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
|
||||
1. In the "Target repositories" section, select {% octicon "goal" aria-hidden="true" %} **Target: REPOSITORIES**, then click:
|
||||
- **All repositories** to target all repositories in the organization,
|
||||
- **Dynamic list of repositories** to target a dynamically updated list of repositories based on their names, or
|
||||
- **Select repositories** to target a static list of repositories that you manually select.
|
||||
1. If you chose to target a dynamic list of repositories, in the "Targeting criteria" section:
|
||||
- Select **Add a target** {% octicon "triangle-down" aria-hidden="true" %}, then click **Include by pattern** or **Exclude by pattern**.
|
||||
- In the modal dialog that appears, enter a repository naming pattern using `fnmatch` syntax, then click **Add Inclusion pattern** or **Add Exclusion pattern**. For more information on `fnmatch` syntax, see "[Using `fnmatch` syntax](#using-fnmatch-syntax)."
|
||||
- Optionally, on the ruleset configuration page, select **Prevent renaming of target repositories**.
|
||||
|
||||
You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern `*cat*`, then specifically exclude a repository matching the pattern `not-a-cat`.
|
||||
{% note %}
|
||||
|
||||
Optionally, to prevent users from renaming any of the targeted repositories, select **Prevent renaming of target repositories**.
|
||||
**Note:** You can add multiple targeting criteria to the same ruleset. For example, you could include any repositories matching the pattern `*cat*`, then specifically exclude a repository matching the pattern `not-a-cat`.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
1. If you chose to target a static list of select repositories, in the "Targeting criteria" section, select {% octicon "repo" aria-hidden="true" %} **Select repositories**, then search for the name of each repository you would like to target. Select each repository from the search results.
|
||||
{% data reusables.repositories.rulesets-target-branches %}
|
||||
{% data reusables.repositories.rulesets-protections-step %}
|
||||
{% data reusables.repositories.rulesets-metadata-step %}
|
||||
|
||||
@@ -146,7 +146,8 @@ Some of the features listed below are limited to organizations using {% data var
|
||||
| Manage the default branch name (see "[AUTOTITLE](/organizations/managing-organization-settings/managing-the-default-branch-name-for-repositories-in-your-organization)") | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} |
|
||||
| Manage default labels (see "[AUTOTITLE](/organizations/managing-organization-settings/managing-default-labels-for-repositories-in-your-organization)") | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} |{% ifversion ghec %}
|
||||
| Enable team synchronization (see "[AUTOTITLE](/organizations/managing-saml-single-sign-on-for-your-organization/managing-team-synchronization-for-your-organization)") | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} |{% endif %}
|
||||
| Manage pull request reviews in the organization (see "[AUTOTITLE](/organizations/managing-organization-settings/managing-pull-request-reviews-in-your-organization)") | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} |
|
||||
| Manage pull request reviews in the organization (see "[AUTOTITLE](/organizations/managing-organization-settings/managing-pull-request-reviews-in-your-organization)") | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} |{% ifversion repo-rules-enterprise %}
|
||||
| Manage organization-level rulesets (see "[AUTOTITLE](/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization)") | {% octicon "check" aria-label="Yes" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} | {% octicon "x" aria-label="No" %} |{% endif %}
|
||||
|
||||
{% endrowheaders %}
|
||||
|
||||
|
||||
@@ -15,7 +15,7 @@ topics:
|
||||
- Pull requests
|
||||
children:
|
||||
- /about-status-checks
|
||||
- /troubleshooting-required-status-checks
|
||||
- /working-with-pre-receive-hooks
|
||||
shortTitle: Code quality features
|
||||
---
|
||||
|
||||
|
||||
@@ -124,7 +124,7 @@ You can set up required status checks to either be "loose" or "strict." The type
|
||||
| **Loose** | The **Require branches to be up to date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
|
||||
| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
|
||||
|
||||
For troubleshooting information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks)."
|
||||
For troubleshooting information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks)."
|
||||
|
||||
### Require conversation resolution before merging
|
||||
|
||||
|
||||
@@ -18,7 +18,5 @@ topics:
|
||||
children:
|
||||
- /about-protected-branches
|
||||
- /managing-a-branch-protection-rule
|
||||
- /troubleshooting-required-status-checks
|
||||
shortTitle: Manage protected branches
|
||||
---
|
||||
|
||||
|
||||
@@ -10,8 +10,6 @@ topics:
|
||||
shortTitle: About rulesets
|
||||
---
|
||||
|
||||
{% data reusables.repositories.rulesets-public-beta %}
|
||||
|
||||
## About rulesets
|
||||
|
||||
A ruleset is a named list of rules that applies to a repository{% ifversion repo-rules-enterprise %}, or to multiple repositories in an organization{% endif %}. You can create rulesets to control how people can interact with selected branches and tags in a repository. You can control things like who can push commits to a certain branch{% ifversion repo-rules-enterprise %} and how the commits must be formatted{% endif %}, or who can delete or rename a tag. For example, you could set up a ruleset for your repository's `feature` branch that requires signed commits and blocks force pushes for all users except repository administrators.
|
||||
|
||||
@@ -10,8 +10,6 @@ topics:
|
||||
shortTitle: Available rules
|
||||
---
|
||||
|
||||
{% data reusables.repositories.rulesets-public-beta %}
|
||||
|
||||
You can create rulesets to control how users can interact with selected branches and tags in a repository. When you create a ruleset, you can choose to enable or disable the rules described in the following sections.
|
||||
|
||||
When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
|
||||
@@ -118,7 +116,7 @@ You can think of required status checks as being either "loose" or "strict." The
|
||||
| **Loose** | The **Require branches to be up to date before merging** checkbox is **not** checked. | The branch **does not** have to be up to date with the base branch before merging. | You'll have fewer required builds, as you won't need to bring the head branch up to date after other collaborators merge pull requests. Status checks may fail after you merge your branch if there are incompatible changes with the base branch. |
|
||||
| **Disabled** | The **Require status checks to pass before merging** checkbox is **not** checked. | The branch has no merge restrictions. | If required status checks aren't enabled, collaborators can merge the branch at any time, regardless of whether it is up to date with the base branch. This increases the possibility of incompatible changes.
|
||||
|
||||
For troubleshooting information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks)."
|
||||
For troubleshooting information, see "[AUTOTITLE](/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks)."
|
||||
|
||||
## Block force pushes
|
||||
|
||||
@@ -136,36 +134,23 @@ If a site administrator has blocked force pushes to the default branch only, you
|
||||
|
||||
## Metadata restrictions
|
||||
|
||||
{% note %}
|
||||
|
||||
**Notes:**
|
||||
|
||||
- Adding restrictions for commit metadata may impact the experience of people contributing to your repository.
|
||||
- Metadata restrictions are intended to increase consistency between commits in your repository. They are not intended to replace security measures such as requiring code review via pull requests.
|
||||
|
||||
{% endnote %}
|
||||
{% data reusables.repositories.rulesets-metadata-restrictions-notes %}
|
||||
|
||||
Organizations on a {% data variables.product.prodname_enterprise %} plan can access additional rules to control how commit metadata must be formatted. You can use literal strings or regular expression syntax to define a pattern that the commit metadata must conform to. For example, you can require that commit messages contain a {% data variables.product.company_short %} issue number, or that the committer or author has an email address ending in `@octoorg.com`. You can also control the format of new branch names and tag names. For a selection of useful regular expressions for commit metadata, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#using-regular-expressions-for-commit-metadata)."
|
||||
|
||||
If a contributor tries to update a branch or tag with a commit that doesn't meet your requirements, the contributor will see an error telling them what was wrong with their commit. This error can appear both in the command line, when the user pushes, and on {% data variables.product.prodname_dotcom_the_website %}, when the user tries to make a commit or merge a pull request. Commits are immutable in Git: once a contributor has created a commit, they cannot edit the commit's metadata, so they may need to perform a rebase to rewrite their commit history with new commits before they can successfully contribute their work to the repository.
|
||||
|
||||
Metadata restrictions are useful for enforcing consistency between the commits in a branch's history. This can be useful for enforcing adherence to best practices, such as the [Conventional Commits](https://www.conventionalcommits.org/) specification, or for integrating with tooling that relies on commit metadata. For example, it is easier to run scripts based on the contents of a commit message if each message conforms to a predictable format. {% ifversion ghes %}You may want to use metadata restrictions as an alternative for setting up custom pre-receive hook scripts. For more information, see "[AUTOTITLE
|
||||
Metadata restrictions are useful for enforcing consistency between the commits in a branch's history. This can be useful for enforcing adherence to best practices, such as the [Conventional Commits](https://www.conventionalcommits.org/) specification, or for integrating with tooling that relies on commit metadata. For example, it is easier to run scripts based on the contents of a commit message if each message conforms to a predictable format. {% ifversion ghes %}You may want to use metadata restrictions as an alternative for setting up custom pre-receive hook scripts. For more information, see "[AUTOTITLE]
|
||||
(/admin/policies/enforcing-policy-with-pre-receive-hooks/about-pre-receive-hooks)."{% endif %}
|
||||
|
||||
### Important considerations for metadata restrictions
|
||||
|
||||
Metadata restrictions block "ref updates." If a contributor pushes work that includes a commit that doesn't meet the requirements, the push is not rejected, but the branch or tag they are targeting is not updated. Technically, the commits still enter your repository: the commits will be "retrievable" (you can navigate to them in your repository), but not "reachable" (they are not connected to the history of a branch or tag). If the contributor's push also includes work on other branches or tags, with commits that meet the requirements of those branches or tags, then those references will be successfully updated.
|
||||
|
||||
Metadata restrictions can increase friction for people contributing to a repository. Generally, if you impose metadata restrictions, you should do so on a limited set of branches to avoid impacting contributors' daily work. For example, instead of requiring consistent commit messages on any topic branch that a contributor might work on, you should require consistent commit messages on `main`, then require pull requests and squash merges into `main`. Contributors will only have to think about the restrictions when they merge a pull request into `main`, not for every commit they make. You can also configure the default message for the squash merge to use the required format. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/configuring-commit-squashing-for-pull-requests)."
|
||||
Metadata restrictions can increase friction for people contributing to a repository. Generally, if you impose metadata restrictions, you should do so on a limited set of branches to avoid impacting contributors' daily work. For example, instead of requiring consistent commit messages on any topic branch that a contributor might work on, you should require consistent commit messages on `main` only, then require pull requests into `main`.
|
||||
|
||||
When you add metadata restrictions to an existing branch or tag, the rules are enforced for new commits pushed to the branch or tag from that point forward, but they are not enforced against the existing history of the branch or tag. However, if you create a new branch or tag that is targeted by a metadata restriction, the rules are enforced against its entire history.
|
||||
If you use squash merges, you should be aware that metadata restrictions are evaluated before the merge, so all commits on the pull request must meet the requirements.
|
||||
|
||||
To understand more about how metadata restrictions work, consider the following example. In this example, you are adding a restriction to ensure that every commit message starts with an issue number. The following points outline some of the effects of adding this restriction.
|
||||
|
||||
- You add the restriction to a ruleset targeting your `main` branch. You can add the restriction without changing the existing history of the branch, even if the history contains commits that do not meet the new requirement. However, from now on, new commits pushed to `main` will need to meet the new requirement.
|
||||
- You have an existing branch pushed to the repository, called `new-feature`. The commits that exist in the `new-feature` branch, but not in `main`, will be evaluated if you try to merge the branch into `main`. To merge the branch, you may need to use a squash merge with an appropriate commit message.
|
||||
- You update the ruleset targeting `main` so that any branches that match the pattern `release-*` are also targeted. Then, you try to create a new branch from `main`, called `release-3.2`. You won't be able to create this new branch, because for the creation of the new branch the metadata requirement is evaluated against the entire commit history of `main`.
|
||||
|
||||
These considerations may or may not pose a problem, depending on how you expect contributors to work in your repository and who has bypass permissions in the ruleset.
|
||||
When you add metadata restrictions to an existing branch or tag, the rules are enforced for new commits pushed to the branch or tag from that point forward, but they are not enforced against the existing history of the branch or tag.
|
||||
|
||||
{% endif %}
|
||||
|
||||
@@ -10,11 +10,9 @@ topics:
|
||||
shortTitle: Manage a ruleset
|
||||
---
|
||||
|
||||
{% data reusables.repositories.rulesets-public-beta %}
|
||||
|
||||
You can create rulesets to control how users can interact with selected branches and tags in a repository. When you create a ruleset, you can allow certain users to bypass the rules in the ruleset. This can be users with certain permissions, specific teams, or {% data variables.product.prodname_github_apps %}. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets)."
|
||||
|
||||
You can use the REST API to manage rulesets. For more information, see "[AUTOTITLE](/rest/repos/rules)".
|
||||
You can use the REST and GraphQL APIs to manage rulesets. For more information, see "[AUTOTITLE](/rest/repos/rules)" and "[AUTOTITLE](/graphql/reference/mutations#createrepositoryruleset)."
|
||||
|
||||
{% data reusables.repositories.rulesets-sudo-mode %}
|
||||
|
||||
|
||||
@@ -9,8 +9,6 @@ topics:
|
||||
shortTitle: Troubleshooting
|
||||
---
|
||||
|
||||
{% data reusables.repositories.rulesets-public-beta %}
|
||||
|
||||
If you cannot perform an action in a repository and want to know why, you can view the active rulesets targeting the branch or tag you're working with. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository#viewing-rulesets-for-a-repository)."
|
||||
|
||||
Depending on which rules are active, you may need to edit your commit history locally before you can push your commits to the remote branch. For example, if a branch requires commits to be signed, you can update your signing settings, then use an interactive rebase on your local branch to rewrite your Git history with signed commits. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#require-signed-commits)" and "[AUTOTITLE](/get-started/using-git/using-git-rebase-on-the-command-line)."
|
||||
|
||||
@@ -28,9 +28,9 @@ Until you add an image, repository links expand to show basic information about
|
||||
|
||||
{% data reusables.repositories.navigate-to-repo %}
|
||||
{% data reusables.repositories.sidebar-settings %}
|
||||
1. Under "Social preview," click **Edit**
|
||||
1. Under "Social preview", click **Edit**.
|
||||
- To add a new image, click **Upload an image...**.
|
||||
- To remove an image, click **Remove image**
|
||||
- To remove an image, click **Remove image**.
|
||||
|
||||
|
||||
|
||||
|
||||
@@ -14,10 +14,4 @@ autogenerated: rest
|
||||
allowTitleToDifferFromFilename: true
|
||||
---
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Rulesets are in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
<!-- Content after this section is automatically generated -->
|
||||
|
||||
@@ -13,10 +13,4 @@ autogenerated: rest
|
||||
allowTitleToDifferFromFilename: true
|
||||
---
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Rulesets are in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
<!-- Content after this section is automatically generated -->
|
||||
|
||||
@@ -3,4 +3,4 @@
|
||||
# Feature flag for enterprise-only features (metadata restrictions, setting rulesets at org level, ruleset insights)
|
||||
versions:
|
||||
ghec: '*'
|
||||
ghes: '>3.9'
|
||||
ghes: '>3.10'
|
||||
|
||||
@@ -3,4 +3,4 @@
|
||||
versions:
|
||||
fpt: '*'
|
||||
ghec: '*'
|
||||
ghes: '>3.9'
|
||||
ghes: '>3.10'
|
||||
|
||||
@@ -1,3 +1,5 @@
|
||||
Because {% data variables.product.company_short %} uses the `File::FNM_PATHNAME` flag for the `File.fnmatch` syntax, the `*` wildcard does not match directory separators (`/`). For example, `qa/*` will match all branches beginning with `qa/` and containing a single slash, but will not match `qa/foo/bar`. You can include any number of slashes after `qa` with `qa/**/*`, which would match, for example, `qa/foo/bar/foobar/hello-world`. You can also extend the `qa` string with `qa**/**/*` to make the rule more inclusive.
|
||||
|
||||
For more information about syntax options, see the [fnmatch documentation](https://ruby-doc.org/core-2.5.1/File.html#method-c-fnmatch).
|
||||
|
||||
{% data reusables.repositories.rulesets-unsupported-fnmatch-syntax %}
|
||||
@@ -1,7 +1,9 @@
|
||||
1. Optionally, in the "Bypass list" section, add teams or {% data variables.product.prodname_github_apps %} to give them bypass permission for the ruleset.
|
||||
1. Optionally, to grant bypass permissions for the ruleset, in the "Bypass list" section, click {% octicon "plus" aria-hidden="true" %} **Add bypass**.
|
||||
- In the "Add bypass" modal dialog that appears, search for the role, team, or app you would like to grant bypass permissions, then select the role, team, or app from the "Suggestions" section and click **Add Selected**.
|
||||
- The following are eligible for bypass access:
|
||||
- Repository or organization owners.
|
||||
- The maintain or write role, or custom repository roles based on the write role.
|
||||
- Teams.
|
||||
- {% data variables.product.prodname_github_apps %}.
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** The bypass list is independent of the bypass mode. The teams and apps you add will be able to bypass the ruleset even if you set "Bypass mode" to "Not permitted."
|
||||
|
||||
{% endnote %}
|
||||
Optionally, to grant bypass to an actor without allowing them to push directly to a repository, select **Always** {% octicon "triangle-down" aria-hidden="true" %}, then click **For pull requests only**. That actor is now required to open a pull request to make changes to a repository, creating a clear digital trail with their changes. The actor can then choose to bypass any branch protections and merge that pull request.
|
||||
|
||||
@@ -1,4 +1,3 @@
|
||||
1. In the "General" section:
|
||||
- Type a name for the ruleset.
|
||||
- Select the enforcement status. You must set the status to **Active** if you want the ruleset to be enforced. {% ifversion repo-rules-enterprise %}Alternatively, if you set the status to **Evaluate**, the ruleset will not be enforced, but you will be able to monitor which actions would or would not violate rules on the "Rule Insights" page. For more information, see "[Viewing insights for rulesets](#viewing-insights-for-rulesets)."{% endif %}
|
||||
- If you want repository or organization owners to be able to bypass the rules in the ruleset, change the selection in the dropdown menu under "Bypass mode."
|
||||
|
||||
@@ -0,0 +1,8 @@
|
||||
{% note %}
|
||||
|
||||
**Notes:**
|
||||
- Adding metadata restrictions can impact the experience of people contributing to your repository. Before you enact a ruleset with metadata restrictions, you can select the "Evaluate" enforcement status for your ruleset to test the effects of any metadata restrictions without impacting contributors. For more information on metadata restrictions, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#important-considerations-for-metadata-restrictions)."
|
||||
- Metadata restrictions are intended to increase consistency between commits in your repository. They are not intended to replace security measures such as requiring code review via pull requests.
|
||||
- If you squash merge a branch, all commits on that branch must meet any metadata requirements for the base branch.
|
||||
|
||||
{% endnote %}
|
||||
@@ -2,11 +2,7 @@
|
||||
|
||||
|
||||
|
||||
{% note %}
|
||||
|
||||
**Note:** Adding metadata restrictions can impact the experience of people contributing to your repository. Before you add metadata restrictions to a ruleset, make sure you understand their potential consequences. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets#important-considerations-for-metadata-restrictions)."
|
||||
|
||||
{% endnote %}
|
||||
{% indented_data_reference reusables.repositories.rulesets-metadata-restrictions-notes spaces=3 %}
|
||||
|
||||
1. If you're adding a metadata restriction, configure the settings for the metadata restriction rule, then click **Add**. You can add multiple restrictions to the same ruleset.
|
||||
|
||||
|
||||
@@ -1 +1,9 @@
|
||||
1. In the "Branch protections" or "Tag protections" section, select the rules you want to include in the ruleset. When you select a rule, you may be able to enter additional settings for the rule. For more information on the rules, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets)."
|
||||
|
||||
{% note %}
|
||||
|
||||
**Notes:** If you select **Require status checks before merging**, in the "Additional settings" section:
|
||||
- You can enter the name of each status check you would like to require. To finish adding the status check as a requirement, you must click {% octicon "plus" aria-label="Add selected status checks" %}.
|
||||
- If you select **Require branches to be up to date before merging**, you must define a check for the protection to take effect.
|
||||
|
||||
{% endnote %}
|
||||
|
||||
@@ -1,5 +0,0 @@
|
||||
{% note %}
|
||||
|
||||
**Note:** Rulesets are in public beta and subject to change.
|
||||
|
||||
{% endnote %}
|
||||
@@ -0,0 +1,5 @@
|
||||
{% note %}
|
||||
|
||||
**Note:** Although {% data variables.product.prodname_dotcom %} supports `File::FNM_PATHNAME` in `fnmatch` syntax, `File::FNM_EXTGLOB` is not supported.
|
||||
|
||||
{% endnote %}
|
||||
Reference in New Issue
Block a user