Skip to content

The GitHub Enterprise Server 3.9 Release Candidate is available

The GitHub Enterprise Server 3.9 release candidate is here

GitHub Enterprise Server 3.9 brings new capabilities to help companies create and ship secure software, more often. Here are a few highlights:

  • Autoscaling with self-hosted runners – Actions administrators can configure auto scaling self-hosted actions runners using the actions runner controller and runner scale sets.
  • The Projects public beta has seen numerous improvements – We're continuing to add more functionality to Projects in GitHub Enterprise Server, to make planning and tracking your work in GitHub even more effective.
  • REST API now has versioning – API releases will be named with the date on which they are released (for example, 2021-04-01). Users will pick what version they want to use on a request-by-request basis, and each version will be supported for two years.
  • Establishing semantic conventions for logging – As part of GitHub's gradual migration to internal semantic conventions for OpenTelemetry, we have updated many of the field names in our logging statements. This makes it clearer what each statement is referencing and allows you to troubleshoot problems quicker.

This release also includes an upgrade from MySQL 5.7 to 8, which will increase I/O utilization. Please read this page for more details on this increase and how to mitigate it if you see an unacceptable degradation of performance on your instance.

Release Candidates are a way for you to try the latest features at the earliest time, and they help us gather feedback early to ensure the release works in your environment. They should be tested on non-production environments. Read more about the release candidate process.

Read more about GitHub Enterprise Server 3.9 in the release notes, or download the release candidate now. If you have any feedback or questions, please contact our Support team.

Security enhancements to required approvals on pull requests

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:

  • Merge commits created locally and pushed to a protected branch will be rejected if the contents differ from the system-created merge.
  • The branch protection for dismissing stale reviews now dismisses approvals whenever a merge base changes after a review.
  • A pull request approval now only counts towards the pull request it was submitted against.

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:

228341522-a954ade3-a4e2-4703-8920-8c3220e2ff0d

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.

See more
View all changes