diff --git a/content/admin/data-residency/network-details-for-ghecom.md b/content/admin/data-residency/network-details-for-ghecom.md index d1ca9fcd6451..b7e3aff5f82c 100644 --- a/content/admin/data-residency/network-details-for-ghecom.md +++ b/content/admin/data-residency/network-details-for-ghecom.md @@ -177,13 +177,43 @@ Japan region: ### Domains for Azure private networking +#### Required for all regions + * `*..ghe.com` * `.ghe.com` * `github.com` * `*.githubusercontent.com` -* `*.blob.core.windows.net` +* `*.blob.core.windows.net` (can be further restricted by region, see below) * `*.web.core.windows.net` +#### EU + +`*.blob.core.windows.net` can be replaced with: +* `prodsdc01resultssa0.blob.core.windows.net` +* `prodsdc01resultssa1.blob.core.windows.net` +* `prodsdc01resultssa2.blob.core.windows.net` +* `prodsdc01resultssa3.blob.core.windows.net` +* `prodweu01resultssa0.blob.core.windows.net` +* `prodweu01resultssa1.blob.core.windows.net` +* `prodweu01resultssa2.blob.core.windows.net` +* `prodweu01resultssa3.blob.core.windows.net` + +#### Australia + +`*.blob.core.windows.net` can be replaced with: +* `prodae01resultssa0.blob.core.windows.net` +* `prodae01resultssa1.blob.core.windows.net` +* `prodae01resultssa2.blob.core.windows.net` +* `prodae01resultssa3.blob.core.windows.net` + +#### Japan + +`*.blob.core.windows.net` can be replaced with: +* `prodjpw01resultssa0.blob.core.windows.net` +* `prodjpw01resultssa1.blob.core.windows.net` +* `prodjpw01resultssa2.blob.core.windows.net` +* `prodjpw01resultssa3.blob.core.windows.net` + ## IP ranges for {% data variables.product.prodname_importer_proper_name %} If you're running a migration to your enterprise with {% data variables.product.prodname_importer_proper_name %}, you may need to add certain ranges to an IP allow list. See [AUTOTITLE](/migrations/using-github-enterprise-importer/migrating-between-github-products/managing-access-for-a-migration-between-github-products#configuring-ip-allow-lists-for-migrations). diff --git a/content/code-security/concepts/code-scanning/index.md b/content/code-security/concepts/code-scanning/index.md index 2620e78e8208..a1de0ceae8a1 100644 --- a/content/code-security/concepts/code-scanning/index.md +++ b/content/code-security/concepts/code-scanning/index.md @@ -15,7 +15,7 @@ contentType: concepts children: - /about-code-scanning - /about-code-scanning-alerts - - /evaluating-default-setup-for-code-scanning + - /setup-types - /about-integration-with-code-scanning - /codeql --- diff --git a/content/code-security/concepts/code-scanning/setup-types.md b/content/code-security/concepts/code-scanning/setup-types.md new file mode 100644 index 000000000000..8933b15ed48c --- /dev/null +++ b/content/code-security/concepts/code-scanning/setup-types.md @@ -0,0 +1,67 @@ +--- +title: About setup types for code scanning +shortTitle: Setup types +intro: Depending on your needs, {% data variables.product.github %} offers a default or advanced setup for code scanning. +topics: + - Code Security + - Code scanning +versions: + fpt: '*' + ghes: '*' + ghec: '*' +contentType: concepts +--- + +## About default setup + +Default setup for {% data variables.product.prodname_code_scanning %} is the quickest, easiest, most low-maintenance way to enable {% data variables.product.prodname_code_scanning %} for your repository. Based on the code in your repository, default setup will automatically create a custom {% data variables.product.prodname_code_scanning %} configuration. After enabling default setup, the code written in {% data variables.product.prodname_codeql %}-supported languages in your repository will be scanned: + +* On each push to the repository's default branch, or any protected branch. For more information on protected branches, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). +* When creating or committing to a pull request based against the repository's default branch, or any protected branch, excluding pull requests from forks. +* On a weekly schedule. + +If you need more granular control over your {% data variables.product.prodname_code_scanning %} configuration, you should instead configure advanced setup. + +### Supported languages + +{% data reusables.code-scanning.default-setup-pre-enablement-explanation %} + +If the code in a repository changes to include any {% data variables.product.prodname_codeql %}-supported languages, {% data variables.product.prodname_dotcom %} will automatically update the {% data variables.product.prodname_code_scanning %} configuration to include the new language. If {% data variables.product.prodname_code_scanning %} fails with the new configuration, {% data variables.product.prodname_dotcom %} will resume the previous configuration automatically so the repository does not lose {% data variables.product.prodname_code_scanning %} coverage. + +### Available runners + +You can use default setup for all {% data variables.product.prodname_codeql %}-supported languages on self-hosted runners or {% data variables.product.prodname_dotcom %}-hosted runners. + +You can assign self-hosted runners for default setup by giving the runners {% ifversion code-scanning-default-setup-customize-labels %}the default `code-scanning` label, or you can optionally give them custom labels so that individual repositories can use different runners.{% else %}the `code-scanning` label.{% endif %} + +{% ifversion code-scanning-default-setup-customize-labels %} + +Unless you have a specific use case, we recommend that you only assign runners with the default `code-scanning` label. However, you may want to use custom labels to: + +* Assign more powerful self-hosted runners to critical repositories for faster {% data variables.product.prodname_code_scanning %} analysis. +* Run your {% data variables.product.prodname_code_scanning %} analyses on a particular platform (for example, macOS). +* Have granular control over the workload for your {% data variables.product.prodname_dotcom %}-hosted runners and self-hosted runners. + +{% endif %} + +## About advanced setup + +Advanced setup for {% data variables.product.prodname_code_scanning %} is helpful when you need to customize your {% data variables.product.prodname_code_scanning %}. By creating and editing a workflow file, you can define how to build compiled languages, choose which queries to run, select the languages to scan, use a matrix build, and more. You also have access to all the options for controlling workflows, for example: changing the scan schedule, defining workflow triggers, specifying specialist runners to use. + +{% ifversion fpt or ghec %} +You can also configure {% data variables.product.prodname_code_scanning %} with third-party tools. + +{% else %} +Your site administrator can also make third-party actions available to users for {% data variables.product.prodname_code_scanning %}, by setting up {% data variables.product.prodname_github_connect %}. For more information, see [AUTOTITLE](/admin/code-security/managing-github-advanced-security-for-your-enterprise/configuring-code-scanning-for-your-appliance#configuring-github-connect-to-sync-github-actions). +{% endif %} + +{% data reusables.code-scanning.about-multiple-configurations-link %} + +## Next steps + +You can enable default setup for a single repository, multiple repositories, or all repositories in an organization at the same time. + +* For a single repository, see [AUTOTITLE](/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning). +* For bulk enablement, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning-at-scale). + +To configure advanced setup instead, see [AUTOTITLE](/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning). diff --git a/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning.md b/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning.md index 705b99ab5eec..7d02d61d902b 100644 --- a/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning.md +++ b/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-advanced-setup-for-code-scanning.md @@ -23,23 +23,11 @@ contentType: how-tos {% data reusables.code-scanning.enterprise-enable-code-scanning-actions %} -## About advanced setup for {% data variables.product.prodname_code_scanning %} - -Advanced setup for {% data variables.product.prodname_code_scanning %} is helpful when you need to customize your {% data variables.product.prodname_code_scanning %}. By creating and editing a workflow file, you can define how to build compiled languages, choose which queries to run, select the languages to scan, use a matrix build, and more. You also have access to all the options for controlling workflows, for example: changing the scan schedule, defining workflow triggers, specifying specialist runners to use. For more information about {% data variables.product.prodname_actions %} workflows, see [AUTOTITLE](/actions/using-workflows/about-workflows). - -{% ifversion fpt or ghec %} -You can also configure {% data variables.product.prodname_code_scanning %} with third-party tools. For more information, see [Configuring {% data variables.product.prodname_code_scanning %} using third-party actions](#configuring-code-scanning-using-third-party-actions). - -{% else %} -Your site administrator can also make third-party actions available to users for {% data variables.product.prodname_code_scanning %}, by setting up {% data variables.product.prodname_github_connect %}. For more information, see [AUTOTITLE](/admin/code-security/managing-github-advanced-security-for-your-enterprise/configuring-code-scanning-for-your-appliance#configuring-github-connect-to-sync-github-actions). -{% endif %} - -{% data reusables.code-scanning.about-multiple-configurations-link %} {% data reusables.code-scanning.codeql-action-version-ghes %} -If you do not need a highly customizable {% data variables.product.prodname_code_scanning %} configuration, consider using default setup for {% data variables.product.prodname_code_scanning %}. For more information on eligibility for default setup, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning#requirements-for-using-default-setup). +If you do not need a highly customizable {% data variables.product.prodname_code_scanning %} configuration, consider using default setup for {% data variables.product.prodname_code_scanning %}. For more information, see [AUTOTITLE](/code-security/concepts/code-scanning/setup-types). -### Prerequisites +## Prerequisites Your repository is eligible for advanced setup if it meets these requirements. * It uses {% data variables.product.prodname_codeql %}-supported languages or you plan to generate code scanning results with a third-party tool. diff --git a/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning.md b/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning.md index abda1f3f0dfd..9034f06113f4 100644 --- a/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning.md +++ b/content/code-security/how-tos/scan-code-for-vulnerabilities/configure-code-scanning/configuring-default-setup-for-code-scanning.md @@ -27,40 +27,14 @@ versions: contentType: how-tos --- -## About default setup +We recommend that you start using {% data variables.product.prodname_code_scanning %} with default setup. After you've initially configured default setup, you can evaluate {% data variables.product.prodname_code_scanning %} to see how it's working for you and customize it to better meet your needs. For more information, see [AUTOTITLE](/code-security/concepts/code-scanning/setup-types). -Default setup for {% data variables.product.prodname_code_scanning %} is the quickest, easiest, most low-maintenance way to enable {% data variables.product.prodname_code_scanning %} for your repository. Based on the code in your repository, default setup will automatically create a custom {% data variables.product.prodname_code_scanning %} configuration. After enabling default setup, the code written in {% data variables.product.prodname_codeql %}-supported languages in your repository will be scanned: -* On each push to the repository's default branch, or any protected branch. For more information on protected branches, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). -* When creating or committing to a pull request based against the repository's default branch, or any protected branch, excluding pull requests from forks. -* On a weekly schedule. - -> [!NOTE] -> If no pushes and pull requests have occurred in a repository with default setup enabled for 6 months, the weekly schedule will be disabled to save your {% data variables.product.prodname_actions %} minutes. - -You can also enable default setup for multiple or all repositories in an organization at the same time. For information on bulk enablement, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/configuring-default-setup-for-code-scanning-at-scale). - -If you need more granular control over your {% data variables.product.prodname_code_scanning %} configuration, you should instead configure advanced setup. For more information, see [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning). - -### Requirements for using default setup +## Prerequisites Your repository is eligible for default setup for {% data variables.product.prodname_code_scanning %} if: {% data reusables.code-scanning.require-actions-ghcs %} -{% data reusables.code-scanning.default-setup-pre-enablement-explanation %} - -You can use default setup for all {% data variables.product.prodname_codeql %}-supported languages for self-hosted runners or {% data variables.product.prodname_dotcom %}-hosted runners. See [Assigning labels to runners](#assigning-labels-to-runners), later in this article. - -Default setup uses the `none` build mode for {% data variables.code-scanning.no_build_support %} and uses the `autobuild` build mode for other compiled languages. You should configure your self-hosted runners to make sure they can run all the necessary commands for C/C++, C#, and Swift analysis. Analysis of JavaScript/TypeScript, Go, Ruby, Python, and Kotlin code does not currently require special configuration. - -### Customizing default setup - -We recommend that you start using {% data variables.product.prodname_code_scanning %} with default setup. After you've initially configured default setup, you can evaluate {% data variables.product.prodname_code_scanning %} to see how it's working for you. If you find that something isn't working as you expect, you can customize default setup to better meet your needs. For more information, see [AUTOTITLE](/code-security/code-scanning/enabling-code-scanning/evaluating-default-setup-for-code-scanning). - -### About adding new languages to your default setup - -If the code in a repository changes to include any {% data variables.product.prodname_codeql %}-supported languages, {% data variables.product.prodname_dotcom %} will automatically update the {% data variables.product.prodname_code_scanning %} configuration to include the new language. If {% data variables.product.prodname_code_scanning %} fails with the new configuration, {% data variables.product.prodname_dotcom %} will resume the previous configuration automatically so the repository does not lose {% data variables.product.prodname_code_scanning %} coverage. - ## Configuring default setup for a repository > [!NOTE] @@ -99,24 +73,31 @@ If the code in a repository changes to include any {% data variables.product.pro 1. Optionally, to view your default setup configuration after enablement, select {% octicon "kebab-horizontal" aria-label="Menu" %}, then click **{% octicon "gear" aria-hidden="true" aria-label="gear" %} View {% data variables.product.prodname_codeql %} configuration**. -## Assigning labels to runners +> [!NOTE] +> If no pushes and pull requests have occurred in a repository with default setup enabled for 6 months, the weekly schedule will be disabled to save your {% data variables.product.prodname_actions %} minutes. ->[!NOTE]{% data variables.product.prodname_code_scanning_caps %} sees assigned runners when default setup is enabled. If a runner is assigned to a repository that is already running default setup, you must disable and re-enable default setup to start using the runner. If you add a runner and want to start using it, you can change the configuration manually without needing to disable and re-enable default setup. +{% ifversion fpt or ghec %} -You can also assign self-hosted runners{% ifversion code-scanning-default-setup-customize-labels %} with the default `code-scanning` label, or you can optionally give them custom labels so that individual repositories can use different runners.{% else %}with the `code-scanning` label.{% endif %} For information about assigning labels to self-hosted runners, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners). +## Running default setup on self-hosted or {% data variables.actions.hosted_runners %} -{% ifversion code-scanning-default-setup-customize-labels %} +You can use default setup for all {% data variables.product.prodname_codeql %}-supported languages on self-hosted runners or {% data variables.product.prodname_dotcom %}-hosted runners. -Specifying custom labels for self-hosted runners is optional. Unless you have a specific use case, we recommend that you only assign runners with the default `code-scanning` label. For example, you may want to: +{% else %} -* Assign more powerful self-hosted runners to critical repositories for faster {% data variables.product.prodname_code_scanning %} analysis. -* Run your {% data variables.product.prodname_code_scanning %} analyses on a particular platform (for example, macOS). -* Have granular control over the workload for your {% data variables.product.prodname_dotcom %}-hosted runners and self-hosted runners. +## Assigning runners for default setup -Once you've assigned custom labels to self-hosted runners, your repositories can use those runners for {% data variables.product.prodname_code_scanning %} default setup. For more information, see [Configuring default setup for a repository](#configuring-default-setup-for-a-repository), earlier in this article. +{% endif %} -You can also use {% data variables.product.prodname_security_configurations %} to assign labels to self-hosted runners for {% data variables.product.prodname_code_scanning %}. See [AUTOTITLE](/code-security/securing-your-organization/meeting-your-specific-security-needs-with-custom-security-configurations/creating-a-custom-security-configuration#creating-a-custom-security-configuration). +>[!NOTE]{% data variables.product.prodname_code_scanning_caps %} sees assigned runners when default setup is enabled. If a runner is assigned to a repository that is already running default setup, you must disable and re-enable default setup to start using the runner. If you add a runner and want to start using it, you can change the configuration manually without needing to disable and re-enable default setup. +### Assigning labels to self-hosted runners + +To assign a self-hosted runner for default setup, you can use {% ifversion code-scanning-default-setup-customize-labels %}the default `code-scanning` label, or you can optionally give them custom labels so that individual repositories can use different runners.{% else %}the `code-scanning` label.{% endif %} For information about assigning labels to self-hosted runners, see [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/using-labels-with-self-hosted-runners). + +Once you've assigned custom labels to self-hosted runners, your repositories can use those runners for {% data variables.product.prodname_code_scanning %} default setup. + +{% ifversion security-configurations %} +You can also use {% data variables.product.prodname_security_configurations %} to assign labels to self-hosted runners for {% data variables.product.prodname_code_scanning %}. See [AUTOTITLE](/code-security/securing-your-organization/meeting-your-specific-security-needs-with-custom-security-configurations/creating-a-custom-security-configuration#creating-a-custom-security-configuration). {% endif %} {% ifversion fpt or ghec %} @@ -127,6 +108,10 @@ To assign a {% data variables.actions.hosted_runner %}, name the runner `code-sc {% endif %} +### Ensuring build support + +Default setup uses the `none` build mode for {% data variables.code-scanning.no_build_support %} and uses the `autobuild` build mode for other compiled languages. You should configure your self-hosted runners to make sure they can run all the necessary commands for C/C++, C#, and Swift analysis. Analysis of JavaScript/TypeScript, Go, Ruby, Python, and Kotlin code does not currently require special configuration. + ## Next steps After your configuration runs successfully at least once, you can start examining and resolving {% data variables.product.prodname_code_scanning %} alerts. For more information on {% data variables.product.prodname_code_scanning %} alerts, see [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/about-code-scanning-alerts) and [AUTOTITLE](/code-security/code-scanning/managing-code-scanning-alerts/assessing-code-scanning-alerts-for-your-repository). diff --git a/content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-default-setup-for-code-scanning-at-scale.md b/content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-default-setup-for-code-scanning-at-scale.md index 3dd099397d5b..541a90dab296 100644 --- a/content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-default-setup-for-code-scanning-at-scale.md +++ b/content/code-security/how-tos/secure-at-scale/configure-organization-security/configure-specific-tools/configuring-default-setup-for-code-scanning-at-scale.md @@ -18,37 +18,9 @@ versions: contentType: how-tos --- -## About configuring default setup at scale +With default setup for {% data variables.product.prodname_code_scanning %}, you can quickly secure code in repositories across your organization. For more information, see [AUTOTITLE](/code-security/concepts/code-scanning/setup-types). -With default setup for {% data variables.product.prodname_code_scanning %}, you can quickly secure code in repositories across your organization. - -You can enable {% data variables.product.prodname_code_scanning %} for all repositories in your organization that are eligible for default setup. After enabling default setup, the code written in {% data variables.product.prodname_codeql %}-supported languages in repositories in the organization will be scanned: - -* On each push to the repository's default branch, or any protected branch. For more information on protected branches, see [AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches). -* When creating or committing to a pull request based against the repository's default branch, or any protected branch, excluding pull requests from forks. -* On a weekly schedule. - -For more information, see [Configuring default setup for all eligible repositories in an organization](#configuring-default-setup-for-all-eligible-repositories-in-an-organization). - -{% ifversion pre-security-configurations %} - -You can also use security overview to find a set of repositories in your organization and enable or disable default setup for all of them at the same time. For more information, see [Configuring default setup for a subset of repositories in an organization](#configuring-default-setup-for-a-subset-of-repositories-in-an-organization). - -{% endif %} - -For repositories that are not eligible for default setup, you can configure advanced setup at the repository level, or at the organization level using a script. For more information, see [AUTOTITLE](/code-security/code-scanning/creating-an-advanced-setup-for-code-scanning/configuring-advanced-setup-for-code-scanning-with-codeql-at-scale). - - - - -### Eligible repositories for {% data variables.product.prodname_codeql %} default setup at scale - -A repository must meet all the following criteria to be eligible for default setup, otherwise you need to use advanced setup. - -* Advanced setup for {% data variables.product.prodname_code_scanning %} is not already enabled. -{% data reusables.code-scanning.require-actions-ghcs %} - -{% data reusables.code-scanning.default-setup-pre-enablement-explanation %} +For repositories that are not suitable for default setup, you can configure advanced setup at the repository level, or at the organization level using a script. {% ifversion pre-security-configurations %} @@ -57,23 +29,18 @@ A repository must meet all the following criteria to be eligible for default set {% endif %} -### About adding languages to an existing default setup configuration +## Prerequisites -If the code in a repository changes to include a {% data variables.product.prodname_codeql %}-supported language, {% data variables.product.prodname_dotcom %} will automatically update the {% data variables.product.prodname_code_scanning %} configuration to include the new language. If {% data variables.product.prodname_code_scanning %} fails with the new configuration, {% data variables.product.prodname_dotcom %} will resume the previous configuration automatically so the repository does not lose {% data variables.product.prodname_code_scanning %} coverage. +A repository must meet all the following criteria to be eligible for default setup: -{% ifversion org-private-registry %} - -### Providing default setup access to private registries - -When a repository uses code stored in a private registry, default setup needs access to the registry to work effectively. For more information, see [AUTOTITLE](/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries). - -{% endif %} +* Advanced setup for {% data variables.product.prodname_code_scanning %} is not already enabled. +{% data reusables.code-scanning.require-actions-ghcs %} ## Configuring default setup for all eligible repositories in an organization {% ifversion security-configurations %} You can enable default setup for all eligible repositories in your organization. For more information, see [AUTOTITLE](/code-security/securing-your-organization/introduction-to-securing-your-organization-at-scale/about-enabling-security-features-at-scale). {% else %} -Through the "{% data variables.product.UI_advanced_security %}" page of your organization's settings, you can enable default setup for all eligible repositories in your organization. For more information on repository eligibility, see [Eligible repositories for {% data variables.product.prodname_codeql %} default setup at scale](#eligible-repositories-default-setup). +Through the "{% data variables.product.UI_advanced_security %}" page of your organization's settings, you can enable default setup for all eligible repositories in your organization. {% data reusables.profile.access_org %} {% data reusables.profile.org_settings %} @@ -104,7 +71,7 @@ You can filter for specific repositories you would like to configure default set {% ifversion pre-security-configurations %} -Through security overview for your organization, you can find eligible repositories for default setup, then enable default setup across each of those repositories simultaneously. For more information on repository eligibility, see [Eligible repositories for {% data variables.product.prodname_codeql %} default setup at scale](#eligible-repositories-default-setup). +Through security overview for your organization, you can find eligible repositories for default setup, then enable default setup across each of those repositories simultaneously. ### Finding repositories that are eligible for default setup @@ -156,6 +123,14 @@ You can select all of the displayed repositories, or a subset of them, and enabl {% endif %} +{% ifversion org-private-registry %} + +## Providing default setup access to private registries + +When a repository uses code stored in a private registry, default setup needs access to the registry to work effectively. For more information, see [AUTOTITLE](/code-security/securing-your-organization/enabling-security-features-in-your-organization/giving-org-access-private-registries). + +{% endif %} + {% ifversion ghes or ghec %} ## Configuring merge protection for all repositories in an organization diff --git a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/managing-pull-requests-for-dependency-updates.md b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/managing-pull-requests-for-dependency-updates.md index 4895fad310f0..7a67b39ae56b 100644 --- a/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/managing-pull-requests-for-dependency-updates.md +++ b/content/code-security/how-tos/secure-your-supply-chain/manage-your-dependency-security/managing-pull-requests-for-dependency-updates.md @@ -24,18 +24,6 @@ contentType: how-tos {% data reusables.dependabot.enterprise-enable-dependabot %} -## About {% data variables.product.prodname_dependabot %} pull requests - -{% data reusables.dependabot.pull-request-introduction %} - -When {% data variables.product.prodname_dependabot %} raises a pull request, you're notified by your chosen method for the repository. Each pull request contains detailed information about the proposed change, taken from the package manager. These pull requests follow the normal checks and tests defined in your repository. -{% ifversion fpt or ghec %}In addition, where enough information is available, you'll see a compatibility score. This may also help you decide whether or not to merge the change. For information about this score, see [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates).{% endif %} - -If you have many dependencies to manage, you may want to customize the configuration for each package manager so that pull requests have specific assignees and labels. You may also want to group sets of dependencies together, so that multiple dependencies are updated in a single pull request. For more information, see [AUTOTITLE](/code-security/dependabot/dependabot-version-updates/customizing-dependabot-prs) and [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/configuring-dependabot-security-updates#grouping-dependabot-updates-into-a-single-pull-request). - -> [!NOTE] -> If you don't interact with {% data variables.product.prodname_dependabot %} pull requests for a repository during a 90-day time period, {% data variables.product.prodname_dependabot %} considers your repository as inactive, and will automatically pause {% data variables.product.prodname_dependabot_updates %}. For more information about inactivity criteria, see [AUTOTITLE](/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates#about-automatic-deactivation-of-dependabot-updates) and [AUTOTITLE](/code-security/dependabot/dependabot-security-updates/about-dependabot-security-updates#about-automatic-deactivation-of-dependabot-updates). - ## Viewing {% data variables.product.prodname_dependabot %} pull requests {% data reusables.repositories.navigate-to-repo %} @@ -54,44 +42,10 @@ By default, {% data variables.product.prodname_dependabot %} will stop rebasing ## Managing {% data variables.product.prodname_dependabot %} pull requests with comment commands -{% data variables.product.prodname_dependabot %} responds to simple commands in comments. Each pull request contains details of the commands you can use to process the pull request (for example: to merge, squash, reopen, close, or rebase the pull request) under the "{% data variables.product.prodname_dependabot %} commands and options" section. The aim is to make it as easy as possible for you to triage these automatically generated pull requests. - -You can use any of the following commands on a {% data variables.product.prodname_dependabot %} pull request. - -| Command | Description | -| --- | --- | -| `@dependabot cancel merge` | Cancels a previously requested merge. | -| `@dependabot close` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from recreating that pull request. You can achieve the same result by closing the pull request manually. | -| `@dependabot ignore this dependency` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this dependency (unless you reopen the pull request or upgrade to the suggested version yourself). | -| `@dependabot ignore this major version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this major version (unless you reopen the pull request or upgrade to this major version yourself). | -| `@dependabot ignore this minor version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this minor version (unless you reopen the pull request or upgrade to this minor version yourself). | -| `@dependabot ignore this patch version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this patch version (unless you reopen the pull request or upgrade to this patch version yourself). | -| `@dependabot merge` | Merges the pull request once your CI tests have passed. | -| `@dependabot rebase` | Rebases the pull request. | -| `@dependabot recreate` | Recreates the pull request, overwriting any edits that have been made to the pull request. | -| `@dependabot reopen` | Reopens the pull request if the pull request is closed. | -| `@dependabot show DEPENDENCY_NAME ignore conditions` | Retrieves information on the ignore conditions for the specified dependency, and comments on the pull request with a table that displays all ignore conditions for the dependency. For example, `@dependabot show express ignore conditions` would find all `ignore` conditions stored for the Express dependency, and comment on the pull request with that information. | -| `@dependabot squash and merge` | Squashes and merges the pull request once your CI tests have passed. | +You can use comment commands on {% data variables.product.prodname_dependabot %} pull requests to manage and customize your dependency updates. For details, see [AUTOTITLE](/code-security/reference/supply-chain-security/dependabot-pull-request-comment-commands). {% data variables.product.prodname_dependabot %} will react with a "thumbs up" emoji to acknowledge the command, and may respond with a comment on the pull request. While {% data variables.product.prodname_dependabot %} usually responds quickly, some commands may take several minutes to complete if {% data variables.product.prodname_dependabot %} is busy processing other updates or commands. If you run any of the commands for ignoring dependencies or versions, {% data variables.product.prodname_dependabot %} stores the preferences for the repository centrally. While this is a quick solution, for repositories with more than one contributor it is better to explicitly define the dependencies and versions to ignore in the configuration file. This makes it easy for all contributors to see why a particular dependency isn't being updated automatically. For more information, see [AUTOTITLE](/code-security/dependabot/working-with-dependabot/dependabot-options-reference#ignore--). - -### Managing {% data variables.product.prodname_dependabot %} pull requests for grouped updates with comment commands - -In {% data variables.product.prodname_dependabot %} pull requests for grouped version updates and security updates, you can use comment commands to ignore and un-ignore updates for specific dependencies and versions. You can use any of the following commands to manage ignore conditions for grouped updates. - -| Command | Description | -| --- | --- | -| `@dependabot ignore DEPENDENCY_NAME` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency. | -| `@dependabot ignore DEPENDENCY_NAME major version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency's major version. | -| `@dependabot ignore DEPENDENCY_NAME minor version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency's minor version. | -| `@dependabot ignore DEPENDENCY_NAME patch version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency's patch version. | -| `@dependabot unignore *` | Closes the current pull request, clears all `ignore` conditions stored for all dependencies in the group, then opens a new pull request. | -| `@dependabot unignore DEPENDENCY_NAME` | Closes the current pull request, clears all `ignore` conditions stored for the dependency, then opens a new pull request that includes available updates for the specified dependency. For example, `@dependabot unignore lodash` would open a new pull request that includes updates for the Lodash dependency. | -| `@dependabot unignore DEPENDENCY_NAME IGNORE_CONDITION` | Closes the current pull request, clears the stored `ignore` condition, then opens a new pull request that includes available updates for the specified ignore condition. For example, `@dependabot unignore express [< 1.9, > 1.8.0]` would open a new pull request that includes updates for Express between versions 1.8.0 and 1.9.0. | - -> [!TIP] -> When you want to un-ignore a specific ignore condition, use the `@dependabot show DEPENDENCY_NAME ignore conditions` command to quickly check what ignore conditions a dependency currently has. diff --git a/content/code-security/reference/supply-chain-security/dependabot-pull-request-comment-commands.md b/content/code-security/reference/supply-chain-security/dependabot-pull-request-comment-commands.md new file mode 100644 index 000000000000..2fc985ed6242 --- /dev/null +++ b/content/code-security/reference/supply-chain-security/dependabot-pull-request-comment-commands.md @@ -0,0 +1,55 @@ +--- +title: Dependabot pull request comment commands +intro: '{% data variables.product.prodname_dependabot %} responds to commands in comments on its pull requests, making it easy to triage and manage dependency updates.' +allowTitleToDifferFromFilename: true +versions: + fpt: '*' + ghec: '*' + ghes: '*' +topics: + - Dependabot + - Version updates + - Repositories + - Dependencies + - Pull requests +shortTitle: Dependabot PR comment commands +contentType: reference +--- + +{% data variables.product.prodname_dependabot %} responds to simple commands in comments. Each pull request contains details of the commands you can use to process the pull request (for example: to merge, squash, reopen, close, or rebase the pull request) under the "{% data variables.product.prodname_dependabot %} commands and options" section. The aim is to make it as easy as possible for you to triage these automatically generated pull requests. + +## Commands for {% data variables.product.prodname_dependabot %} pull requests + +You can use any of the following commands on a {% data variables.product.prodname_dependabot %} pull request. + +| Command | Description | +| --- | --- | +| `@dependabot cancel merge` | Cancels a previously requested merge. | +| `@dependabot close` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from recreating that pull request. You can achieve the same result by closing the pull request manually. | +| `@dependabot ignore this dependency` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this dependency (unless you reopen the pull request or upgrade to the suggested version yourself). | +| `@dependabot ignore this major version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this major version (unless you reopen the pull request or upgrade to this major version yourself). | +| `@dependabot ignore this minor version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this minor version (unless you reopen the pull request or upgrade to this minor version yourself). | +| `@dependabot ignore this patch version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from creating any more pull requests for this patch version (unless you reopen the pull request or upgrade to this patch version yourself). | +| `@dependabot merge` | Merges the pull request once your CI tests have passed. | +| `@dependabot rebase` | Rebases the pull request. | +| `@dependabot recreate` | Recreates the pull request, overwriting any edits that have been made to the pull request. | +| `@dependabot reopen` | Reopens the pull request if the pull request is closed. | +| `@dependabot show DEPENDENCY_NAME ignore conditions` | Retrieves information on the ignore conditions for the specified dependency, and comments on the pull request with a table that displays all ignore conditions for the dependency. For example, `@dependabot show express ignore conditions` would find all `ignore` conditions stored for the Express dependency, and comment on the pull request with that information. | +| `@dependabot squash and merge` | Squashes and merges the pull request once your CI tests have passed. | + +## Commands for grouped version updates + +In {% data variables.product.prodname_dependabot %} pull requests for grouped version updates and security updates, you can use comment commands to ignore and un-ignore updates for specific dependencies and versions. You can use any of the following commands to manage ignore conditions for grouped updates. + +| Command | Description | +| --- | --- | +| `@dependabot ignore DEPENDENCY_NAME` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency. | +| `@dependabot ignore DEPENDENCY_NAME major version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency's major version. | +| `@dependabot ignore DEPENDENCY_NAME minor version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency's minor version. | +| `@dependabot ignore DEPENDENCY_NAME patch version` | Closes the pull request and prevents {% data variables.product.prodname_dependabot %} from updating this dependency's patch version. | +| `@dependabot unignore *` | Closes the current pull request, clears all `ignore` conditions stored for all dependencies in the group, then opens a new pull request. | +| `@dependabot unignore DEPENDENCY_NAME` | Closes the current pull request, clears all `ignore` conditions stored for the dependency, then opens a new pull request that includes available updates for the specified dependency. For example, `@dependabot unignore lodash` would open a new pull request that includes updates for the Lodash dependency. | +| `@dependabot unignore DEPENDENCY_NAME IGNORE_CONDITION` | Closes the current pull request, clears the stored `ignore` condition, then opens a new pull request that includes available updates for the specified ignore condition. For example, `@dependabot unignore express [< 1.9, > 1.8.0]` would open a new pull request that includes updates for Express between versions 1.8.0 and 1.9.0. | + +> [!TIP] +> When you want to un-ignore a specific ignore condition, use the `@dependabot show DEPENDENCY_NAME ignore conditions` command to quickly check what ignore conditions a dependency currently has. diff --git a/content/code-security/reference/supply-chain-security/index.md b/content/code-security/reference/supply-chain-security/index.md index 148c135d4618..ae76a0c1db82 100644 --- a/content/code-security/reference/supply-chain-security/index.md +++ b/content/code-security/reference/supply-chain-security/index.md @@ -18,6 +18,7 @@ topics: contentType: reference children: - /dependabot-options-reference + - /dependabot-pull-request-comment-commands - /supported-ecosystems-and-repositories - /dependency-graph-supported-package-ecosystems redirect_from: diff --git a/content/code-security/concepts/code-scanning/evaluating-default-setup-for-code-scanning.md b/content/code-security/tutorials/customize-code-scanning/evaluating-default-setup-for-code-scanning.md similarity index 99% rename from content/code-security/concepts/code-scanning/evaluating-default-setup-for-code-scanning.md rename to content/code-security/tutorials/customize-code-scanning/evaluating-default-setup-for-code-scanning.md index f0da7b96cca4..d96885f910e4 100644 --- a/content/code-security/concepts/code-scanning/evaluating-default-setup-for-code-scanning.md +++ b/content/code-security/tutorials/customize-code-scanning/evaluating-default-setup-for-code-scanning.md @@ -1,6 +1,6 @@ --- title: Evaluating default setup for code scanning -shortTitle: Evaluate code scanning +shortTitle: Evaluate default setup intro: Learn how to assess how code scanning is working for you, and how you can customize your setup to best meet your needs. permissions: '{% data reusables.permissions.security-repo-enable %}' topics: diff --git a/content/code-security/tutorials/customize-code-scanning/index.md b/content/code-security/tutorials/customize-code-scanning/index.md index 17a12f1d3a79..59a94bbb8609 100644 --- a/content/code-security/tutorials/customize-code-scanning/index.md +++ b/content/code-security/tutorials/customize-code-scanning/index.md @@ -11,6 +11,7 @@ topics: - CodeQL contentType: tutorials children: + - /evaluating-default-setup-for-code-scanning - /preparing-your-code-for-codeql-analysis - /analyzing-your-code-with-codeql-queries - /uploading-codeql-analysis-results-to-github