Announcing important changes to what it means for a pull request to be 'approved'.
If you use pull requests with protected branches, there are some important security improvements rolling out now that may impact your workflow:
Note: You may see some older approvals dismissed as we rollout these changes.
Read on to learn more about the specific changes:
User-created merges must have the same contents as the system-created merge.
Previously, it was possible for users to make unreviewed changes to a protected branch, by creating the merge commit locally and pushing it to the server. The merge would be accepted, so long as the parents commits were set correctly.
Going forward, manually creating the merge commit for a pull request and pushing it directly to a protected branch will only succeed if the contents of the merge exactly match the system-generated merge for the pull request. This new check will be enforced on branches where the branch protections mentioned earlier are enabled.
Pull request approvals will become stale if the merge base changes
A pull request approval will be marked as stale when the merge base changes after a review is submitted.
The merge base of a pull request is the closest common ancestor of both the target and source branches for that pull request. It is often (but not always) the commit where a user has branched off the mainline development and started working on a topic branch:
When "dismiss stale approvals" is enabled, the review will be dismissed and needs a re-approval. If branch protection rules specify that every push needs to be reviewed by a second contributor, a change in the merge base will require fresh approvals.
Merge bases changing under a pull request will preserve approvals in most situations where no new changes are introduced.
Pull requests no longer combine approvals.
Previously it was possible for a branch protected by "required pull request review" to be merged without an approved PR. This was possible because approvals were gathered across multiple independent pull requests if the feature branches pointed to the same commit as well as targeting the same branch.
We appreciate your feedback in GitHub's public feedback discussions.
You can now create single-use self-hosted runners without time-limited registration tokens using the REST API.
When a runner registers using this API it will only be allowed to run a single job before being automatically removed from the repository, organization, or enterprise. This enables you to improve the security of your self-hosted runner infrastructure by limiting the exposure of long lived credentials.
Today, we're extending CodeQL code scanning support to Swift! Developers working on Swift libraries and apps on Apple platforms can now benefit from our best-in-class code security analysis. We currently identify issues such as path injection, unsafe web view fetches, numerous cryptographic misuses and other types of unsafe evaluation or processing of unsanitized user-controlled data. During this beta, we’ll gradually increase our coverage of distinct weaknesses.
Swift joins our existing supported languages (C/C++, Java/Kotlin, JS/TS, Python, Ruby, C#, and Go), which in sum run nearly 400 checks on your code, all while keeping false positive rates low and precision high.
Set up code scanning on your Swift repositories today and receive actionable security alerts right on your pull requests. Read more about our supported Swift versions and platforms here.
Swift support is available starting with CodeQL version 2.13.3. GitHub.com users are automatically updated, while GitHub Enterprise Server users can update using these guidelines. Security researchers can set up the CodeQL CLI and VS Code extension by following these instructions.
This is just the start for Swift support in GitHub Advanced Security, keep an eye on the main GitHub blog for further announcements. If you have any feedback or questions about the Swift beta, consider joining our community in the #codeql-swift-beta channel in the GitHub Security Lab Slack. Thanks to all Swift community members who have participated in the private beta.