From c624097e7075dafcd750022b2f543c929331d130 Mon Sep 17 00:00:00 2001 From: Felicity Chapman Date: Tue, 9 May 2023 11:37:57 +0100 Subject: [PATCH 1/2] Add note about merge_group for code scanning users (#36815) Co-authored-by: Sarita Iyer <66540150+saritai@users.noreply.github.com> --- .../customizing-code-scanning.md | 10 ++++++++++ .../managing-a-merge-queue.md | 6 ++++++ 2 files changed, 16 insertions(+) diff --git a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning.md b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning.md index 323be7208b..8d627a9794 100644 --- a/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning.md +++ b/content/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning.md @@ -87,6 +87,16 @@ If you scan pull requests, then the results appear as alerts in a pull request c Using the `pull_request` trigger, configured to scan the pull request's merge commit rather than the head commit, will produce more efficient and accurate results than scanning the head of the branch on each push. However, if you use a CI/CD system that cannot be configured to trigger on pull requests, you can still use the `on:push` trigger and {% data variables.product.prodname_code_scanning %} will map the results to open pull requests on the branch and add the alerts as annotations on the pull request. For more information, see "[AUTOTITLE](/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors/customizing-code-scanning#scanning-on-push)." +{% ifversion fpt or ghec %} + +{% note %} + +**Note:** If your repository is configured with a merge queue, you need to include the `merge_group` event as an additional trigger for {% data variables.product.prodname_code_scanning %}. This will ensure that pull requests are also scanned when they are added to a merge queue. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue)." + +{% endnote %} + +{% endif %} + ### Avoiding unnecessary scans of pull requests You might want to avoid a code scan being triggered on specific pull requests targeted against the default branch, irrespective of which files have been changed. You can configure this by specifying `on:pull_request:paths-ignore` or `on:pull_request:paths` in the {% data variables.product.prodname_code_scanning %} workflow. For example, if the only changes in a pull request are to files with the file extensions `.md` or `.txt` you can use the following `paths-ignore` array. diff --git a/content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md b/content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md index 00771c5c88..9fb2e81cb2 100644 --- a/content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md +++ b/content/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-a-merge-queue.md @@ -40,6 +40,12 @@ For information about merge methods, see "[AUTOTITLE](/pull-requests/collaborati You can use the `merge_group` event to trigger your {% data variables.product.prodname_actions %} workflow when a pull request is added to a merge queue. Note that this is a different event from the `pull_request` and `push` events. +{% note %} + +**Note:** If your repository uses {% data variables.product.prodname_actions %} to perform required checks on pull requests in your repository, you need to update the workflows to include the `merge_group` event as an additional trigger. Otherwise, status checks will not be triggered when you add a pull request to a merge queue. The merge will fail as the required status check will not be reported. + +{% endnote %} + A workflow that reports a check which is required by the target branch's protections would look like this: ```yaml From 3770a8bedcb4408500fc04aff800e0240a343213 Mon Sep 17 00:00:00 2001 From: Pantelis <85220850+Pantelis-Santorinios@users.noreply.github.com> Date: Tue, 9 May 2023 12:37:57 +0200 Subject: [PATCH 2/2] Update github-privacy-statement.md (#36845)