From 2b3e6d8fb4879590b945440c47f8408e6239e12a Mon Sep 17 00:00:00 2001 From: Sam Browning <106113886+sabrowning1@users.noreply.github.com> Date: Mon, 24 Jul 2023 11:57:59 -0400 Subject: [PATCH] Add content for "Repository Rules" [GA] (#39268) Co-authored-by: Patrick Knight Co-authored-by: Isaac Brown <101839405+isaacmbrown@users.noreply.github.com> --- ...gration-with-github-enterprise-importer.md | 2 +- ...s-for-repositories-in-your-organization.md | 21 ++++++++++----- .../roles-in-an-organization.md | 3 ++- .../index.md | 2 +- .../troubleshooting-required-status-checks.md | 0 .../about-protected-branches.md | 2 +- .../managing-protected-branches/index.md | 2 -- .../managing-rulesets/about-rulesets.md | 2 -- .../available-rules-for-rulesets.md | 27 +++++-------------- .../managing-rulesets-for-a-repository.md | 4 +-- .../troubleshooting-rules.md | 2 -- ...g-your-repositorys-social-media-preview.md | 4 +-- content/rest/orgs/rules.md | 6 ----- content/rest/repos/rules.md | 6 ----- data/features/repo-rules-enterprise.yml | 2 +- data/features/repo-rules.yml | 2 +- data/reusables/repositories/about-fnmatch.md | 2 ++ .../repositories/rulesets-bypass-step.md | 14 +++++----- .../repositories/rulesets-fnmatch.md | 2 +- .../repositories/rulesets-general-step.md | 1 - .../rulesets-metadata-restrictions-notes.md | 8 ++++++ .../repositories/rulesets-metadata-step.md | 6 +---- .../repositories/rulesets-protections-step.md | 8 ++++++ .../repositories/rulesets-public-beta.md | 5 ---- .../rulesets-unsupported-fnmatch-syntax.md | 5 ++++ 25 files changed, 64 insertions(+), 74 deletions(-) rename content/{repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches => pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features}/troubleshooting-required-status-checks.md (100%) create mode 100644 data/reusables/repositories/rulesets-metadata-restrictions-notes.md delete mode 100644 data/reusables/repositories/rulesets-public-beta.md create mode 100644 data/reusables/repositories/rulesets-unsupported-fnmatch-syntax.md diff --git a/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer.md b/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer.md index 9ca54b1ca9..814f897a70 100644 --- a/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer.md +++ b/content/migrations/using-github-enterprise-importer/completing-your-migration-with-github-enterprise-importer/troubleshooting-your-migration-with-github-enterprise-importer.md @@ -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)." diff --git a/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md b/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md index 9a2c5e6087..8aed4d112b 100644 --- a/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md +++ b/content/organizations/managing-organization-settings/managing-rulesets-for-repositories-in-your-organization.md @@ -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 %} diff --git a/content/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization.md b/content/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization.md index 139bae6765..f51cfa7f4c 100644 --- a/content/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization.md +++ b/content/organizations/managing-peoples-access-to-your-organization-with-roles/roles-in-an-organization.md @@ -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 %} diff --git a/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/index.md b/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/index.md index 5f3aec478b..d709212866 100644 --- a/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/index.md +++ b/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/index.md @@ -15,7 +15,7 @@ topics: - Pull requests children: - /about-status-checks + - /troubleshooting-required-status-checks - /working-with-pre-receive-hooks shortTitle: Code quality features --- - diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks.md b/content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks.md similarity index 100% rename from content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/troubleshooting-required-status-checks.md rename to content/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/troubleshooting-required-status-checks.md diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md index d849972651..e1cc1a9221 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches.md @@ -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 diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/index.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/index.md index 4badb74c6c..703b6dff48 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/index.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/index.md @@ -18,7 +18,5 @@ topics: children: - /about-protected-branches - /managing-a-branch-protection-rule - - /troubleshooting-required-status-checks shortTitle: Manage protected branches --- - diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md index 16a1e593df..a927008036 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/about-rulesets.md @@ -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. diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md index 4cbfdfb991..bb526623bd 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/available-rules-for-rulesets.md @@ -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 %} diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md index 729733663d..960a0607f8 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository.md @@ -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 %} diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md index dc2b4e2a18..1868bc51c2 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/troubleshooting-rules.md @@ -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)." diff --git a/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview.md b/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview.md index 0c09a52d91..cada58fad7 100644 --- a/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview.md +++ b/content/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/customizing-your-repositorys-social-media-preview.md @@ -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**. ![Screenshot of the "Social Preview" section. The "Edit" button is highlighted with an orange outline, and a dropdown displays the options for uploading or removing an image.](/assets/images/help/repository/social-preview.png) diff --git a/content/rest/orgs/rules.md b/content/rest/orgs/rules.md index daa6e51d0a..1cf916535c 100644 --- a/content/rest/orgs/rules.md +++ b/content/rest/orgs/rules.md @@ -14,10 +14,4 @@ autogenerated: rest allowTitleToDifferFromFilename: true --- -{% note %} - -**Note:** Rulesets are in public beta and subject to change. - -{% endnote %} - diff --git a/content/rest/repos/rules.md b/content/rest/repos/rules.md index fcdcc119b3..45998224ce 100644 --- a/content/rest/repos/rules.md +++ b/content/rest/repos/rules.md @@ -13,10 +13,4 @@ autogenerated: rest allowTitleToDifferFromFilename: true --- -{% note %} - -**Note:** Rulesets are in public beta and subject to change. - -{% endnote %} - diff --git a/data/features/repo-rules-enterprise.yml b/data/features/repo-rules-enterprise.yml index 7c11fabb65..9b5002e574 100644 --- a/data/features/repo-rules-enterprise.yml +++ b/data/features/repo-rules-enterprise.yml @@ -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' diff --git a/data/features/repo-rules.yml b/data/features/repo-rules.yml index 535b65c5b8..80d70ae9b4 100644 --- a/data/features/repo-rules.yml +++ b/data/features/repo-rules.yml @@ -3,4 +3,4 @@ versions: fpt: '*' ghec: '*' - ghes: '>3.9' + ghes: '>3.10' diff --git a/data/reusables/repositories/about-fnmatch.md b/data/reusables/repositories/about-fnmatch.md index bd3f0a7f91..10d36c3308 100644 --- a/data/reusables/repositories/about-fnmatch.md +++ b/data/reusables/repositories/about-fnmatch.md @@ -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 %} \ No newline at end of file diff --git a/data/reusables/repositories/rulesets-bypass-step.md b/data/reusables/repositories/rulesets-bypass-step.md index 802c4cc7b4..84236f3421 100644 --- a/data/reusables/repositories/rulesets-bypass-step.md +++ b/data/reusables/repositories/rulesets-bypass-step.md @@ -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. diff --git a/data/reusables/repositories/rulesets-fnmatch.md b/data/reusables/repositories/rulesets-fnmatch.md index ff4b799a8b..1582a0ee32 100644 --- a/data/reusables/repositories/rulesets-fnmatch.md +++ b/data/reusables/repositories/rulesets-fnmatch.md @@ -1,3 +1,3 @@ You can use `fnmatch` syntax to define patterns to target the names of {% ifversion repo-rules-enterprise %}branches, tags, and repositories{% else %}branches and tags{% endif %} when you create a ruleset. -You can use the `*` wildcard to match any string of characters. {% data reusables.repositories.about-fnmatch %} +You can use the `*` wildcard to match any string of characters. {% data reusables.repositories.about-fnmatch %} \ No newline at end of file diff --git a/data/reusables/repositories/rulesets-general-step.md b/data/reusables/repositories/rulesets-general-step.md index 5b558c47aa..70153c2b67 100644 --- a/data/reusables/repositories/rulesets-general-step.md +++ b/data/reusables/repositories/rulesets-general-step.md @@ -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." diff --git a/data/reusables/repositories/rulesets-metadata-restrictions-notes.md b/data/reusables/repositories/rulesets-metadata-restrictions-notes.md new file mode 100644 index 0000000000..b0ef0c36de --- /dev/null +++ b/data/reusables/repositories/rulesets-metadata-restrictions-notes.md @@ -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 %} \ No newline at end of file diff --git a/data/reusables/repositories/rulesets-metadata-step.md b/data/reusables/repositories/rulesets-metadata-step.md index a3e618da42..99375ed266 100644 --- a/data/reusables/repositories/rulesets-metadata-step.md +++ b/data/reusables/repositories/rulesets-metadata-step.md @@ -2,11 +2,7 @@ ![Screenshot of the "Metadata restriction" section. To the right of the header, a plus icon is highlighted with an orange outline.](/assets/images/help/repository/add-metadata-restriction.png) - {% 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. diff --git a/data/reusables/repositories/rulesets-protections-step.md b/data/reusables/repositories/rulesets-protections-step.md index 373d4840f3..de93bbefb3 100644 --- a/data/reusables/repositories/rulesets-protections-step.md +++ b/data/reusables/repositories/rulesets-protections-step.md @@ -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 %} diff --git a/data/reusables/repositories/rulesets-public-beta.md b/data/reusables/repositories/rulesets-public-beta.md deleted file mode 100644 index aae4b4a250..0000000000 --- a/data/reusables/repositories/rulesets-public-beta.md +++ /dev/null @@ -1,5 +0,0 @@ -{% note %} - -**Note:** Rulesets are in public beta and subject to change. - -{% endnote %} diff --git a/data/reusables/repositories/rulesets-unsupported-fnmatch-syntax.md b/data/reusables/repositories/rulesets-unsupported-fnmatch-syntax.md new file mode 100644 index 0000000000..3a56e5e601 --- /dev/null +++ b/data/reusables/repositories/rulesets-unsupported-fnmatch-syntax.md @@ -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 %} \ No newline at end of file