Improved pull request file filtering

Code scanning runs analysis tools that scan your code on the triggers defined in your .yml Actions workflow file. The default CodeQL workflow analyzes your code each time you push a change to the default branch and when you raise a pull request against the default branch.

We have made some improvements for users who are not able to run analyses using the default on:pull_request GitHub Actions trigger). These changes will make it easier to use code scanning for users of other CI/CD platforms, as well as users who can only use the on:push triggers in Actions.

Scanning pull requests (using GitHub Actions)

If you use GitHub Actions, we recommend that you configure code scanning to analyse all pull requests using the on:pull_request trigger in the Actions workflow (default). Developers will see code scanning results right in their pull requests, alongside the code review by their colleagues.

The pull_request trigger also produces the most accurate results: alerts shown on the pull request are identified by comparing the results for the pull request merge commit against the target branch baseline. This best reflects the future state of the code after the pull request has been merged.

Scanning code on every push (using GitHub Actions)

You can also scan your code using the on:push triggers, which will perform a scan each time you push code to a branch (regardless of whether there is a pull request).

Previously, alerts identified in on:push workflows would not show up on any pull request. However, our recent changes have improved this. When an on:push scan returns results that we can map to a pull request, we will flag up these alerts on the PR. The alerts shown on the PR are those identified by comparing the existing analysis of the head of the branch to the analysis for the target branch that you are merging against. Note that if the pull request's merge commit is not used, alerts can be less accurate when compared to the approach that uses on:pull_request triggers.

This is a less cost effective way to use code scanning because your code will be analysed each time you push to the branch, even before a pull request is opened.

If you scan both on:push and on:pull_request, we will choose to show the results from the merge analysis.

Scanning on push (or for every commit) using other CI/CD systems

Some other CI/CD systems can exclusively be configured to trigger a pipeline when code is pushed to a branch, or even exclusively for every commit. This is a less cost effective way to run code scanning, but with our recent improvements we will now provide alerts in developers' pull requests using this approach. Whenever such an analysis pipeline is triggered and results are uploaded to the SARIF API, code scanning will try to match the analysis results to an open pull request. If an open pull request is found, the results will be published as described above.

How do I update my Actions workflow to use the pull_request trigger?

1. If you are setting up code scanning for the first time, use the default CodeQL analysis workflow which will scan the merge commit on pull request.

2. If you have setup code scanning to scan on push and would like to update it to scan on the pull request, update your .yml workflow file to look like this:

on:
  push:
    branches: [ main ]
  pull_request:
    # The branches below must be a subset of the branches above
    branches: [ main ]

You will still need to analyze your default branch on:push because it provides the base analysis for the comparison.

3. If you have setup code scanning to scan the head commit on pull request and would like to update it to scan the merge commit, delete the following lines from your .yml workflow file:

    - run: git checkout HEAD^2
      if: ${{ github.event_name == 'pull_request' }}

Read more about setting up code scanning using Actions.