Skip to content

Changelog

Subscribe to all Changelog posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

GitHub Enterprise Cloud standalone organizations paying by invoice may now update to an enterprise account via a self-service flow.

Organization owners may navigate to the organization's billing page and click "Upgrade to Enterprise Account" to begin. There are no changes to licensing agreement or payment terms. In the new enterprise account, every organization owner will be granted the enterprise owner role.

Enterprise accounts allow you to create new organizations, manage policies and users, and provide a single point to manage and view multiple organizations. Enterprise accounts also grant access to features like audit log streaming, enterprise verified domains, and enable cross-organization collaboration via internal repositories.

Learn more about upgrading to an enterprise account.

See more

We’ve improved the depth of CodeQL's analysis by adding support for more libraries and frameworks and increasing the coverage of our existing library and framework models. JavaScript analysis now supports most common templating languages, and Java now covers more than three times the endpoints of previous CodeQL versions. As a result, CodeQL can now detect even more potential sources of untrusted user data, steps through which that data flows, and potentially dangerous sinks in which this data could end up. This results in an overall improvement of the quality of the code scanning alerts.

We carefully choose and prioritize the libraries and frameworks supported by CodeQL based on their popularity and through user feedback. These improvements are now available to users of CodeQL code scanning on GitHub.com, and will also be available in the next release of GitHub Enterprise Server (3.3).

Java

We've improved coverage for the following libraries:

JavaScript

We've added support for the following templating languages:

Learn more about CodeQL and code scanning.

See more

Developers and security researchers using the CodeQL CLI and VS Code extension can now build databases and analyze code on machines powered by Apple Silicon (e.g. Apple M1).

In order to use the CodeQL CLI and/or the VS Code extension on Apple Silicon, please make sure to install the Xcode command-line developer tools and Rosetta 2.

For detailed instructions on how to set up the CLI on supported platforms, please refer to the CodeQL CLI guide.

Learn more about CodeQL and code scanning.

See more

You can now require that all changes to a protected branch are made using a pull request, but without requiring reviews. This can be useful when you want to use pull requests for tracking purposes or to simplify your continuous integration (CI) configuration, but don't want to gate merging on review.

Previously, you could create a branch protection rule that required pull requests with approving reviews before commits could be merged into a branch. When pull requests were required, approving reviews were also required. This didn’t meet the needs of users who wanted to require pull requests for tracking purposes or CI validation, but who didn’t want their ability to merge to be gated by approving reviews.

Now, requiring pull requests and requiring approving reviews are separate options of protecting a branch. For example, you can now require pull requests without requiring reviews, or with requiring approving reviews. This flexibility lets you choose what is best for you and your branches.

image

For more information, visit Managing a branch protection rule.

See more

Code scanning alerts now integrate with GitHub Issues task lists to make it easy to prioritize and track your alerts with all your development work.

You can use the task list feature in markdown to track a code scanning alert in an issue. When you add a code scanning alert to a task list in an issue, a "tracked in" pill will show on the corresponding alert page. The code scanning alerts page also shows which alerts are tracked in issues.

You can also create a new issue from a code scanning alert, which automatically adds the code scanning alert to a task list in the new issue.
Demo: tracking code scanning alerts in task lists

This feature has now shipped in beta for all users on GitHub.com.

Learn more about tracking code scanning alerts in Issues using task lists.

See more

We made three improvements to the repository invite experience, so you can start contributing faster:

  1. You will now see notifications for private repository invites, just as you already do for public repositories.
  2. For pending invites to public repositories, you will now notice a banner on the repository overview, indicating that there is a pending invite.
  3. When you navigate to a private repository you have been invited to, you will now see a prompt to accept the invite instead of a 404 error page.
See more

GitHub secret scanning helps protect users by searching repositories for known types of secrets. By flagging leaked secrets, our scans can prevent data leaks and prevent the fraudulent use of accidentally committed secrets.

We have partnered with Meta to scan for their access tokens and help keep our mutual users secure. Our scan currently covers Facebook user access tokens and page access tokens. These tokens provide permissions to APIs that read, write, or modify the data belonging to a Facebook user or page.

We'll forward access tokens found in public repositories to Meta. Meta will then automatically invalidate tokens that have a valid session and notify app developers.

We continue to welcome new partners for public repo secret scanning. GitHub Advanced Security customers can also scan their private repositories for leaked secrets.

See more

The GitHub Enterprise Server 3.3 Release Candidate is available. This release contains a broad range of features and enhancements across the platform including GitHub Actions, Security, and a host of helpful productivity improvements.

Read the blog post to discover the highlights in this release, or dive into the full GitHub Enterprise Server 3.3 release notes.

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.

Download it today.

See more

GitHub recently introduced the ability to set an expiration date when creating or regenerating a personal access token (PAT). For a PAT that is authorized to access an organization protected by SAML single sign-on (SSO), the expiration date of that PAT is now available via the GET /orgs/{org}/credential-authorizations API.

Organization administrators can use the following gh command to see the expiration dates of all PATs that are authorized to access their org by authenticating with a PAT that has the read:org scope:

gh api --paginate /orgs/:org/credential-authorizations --jq='.[] | [.authorized_credential_expires_at]'

Learn more about authorizing a personal access token for use with SAML single sign-on.

See more

A warning is now displayed when a file's contents include bidirectional Unicode text. Such text can be interpreted or compiled differently than it appears in a user interface. For example, hidden, bidirectional Unicode characters can be used to swap segments of text in a file. This can cause code to appear one way and be interpreted or compiled another way.

image

This security issue is the topic of the Common Vulnerabilities and Exposures (CVE) publication: CVE-2021-42574. If your use of bidirectional Unicode characters is intentional and not malformed, you can ignore the warning.

To review a file for which this warning is displayed, open it in an editor that will display the hidden, bidirectional Unicode characters, like Visual Studio Code which highlights the characters by default. Then, verify that the characters are necessary and not disguising text that will be interpreted or compiled differently than it appears.

For more information, refer to Trojan Source: Invisible Source Code Vulnerabilities.

See more

Pull Request Merge Queue is now available in limited beta. Learn more about the feature and how to request early access.

Why a merge queue?

Maintaining high velocity and keeping your main branch green can be a challenge today. Many repositories try to do this by requiring all pull requests be up to date with the main branch before merging. This ensures the main branch is never updated to a commit that has not passed all required status checks, but forces developers to update (or rebase) their pull request branches multiple times and then wait for status checks to complete before trying to merge again. On some projects, status checks can take 30 or more minutes and if another pull request gets merged during this time, the process starts over (for everyone). This can have a significant impact on the overall velocity of the team and make it harder for developers to move onto their next task.

Merge Queue provides the benefits of requiring pull request branches to be up to date before merging, but without requiring developers to go through this process.

How it works

Merge Queue works by validating different combinations of pull requests identified as “ready to merge” in parallel so that pull requests can merge efficiently and without the typical delays that exist between merges today.

GIF of merge queue demo

Once a pull request has been approved and has passed all required status checks, a user with write access in the repository can queue the pull request to be merged. The pull request branch does not need to be up to date with the base branch before being queued. The merge queue then creates a temporary branch that includes the pull request and any non-failing pull requests ahead of it in the queue. This branch is based on the latest version of the base branch and is what the history of the base branch will look like if it passes all required status checks. Assuming it does pass these checks, the base branch is fast-forwarded and the pull request is marked as merged.

Early access

Merge Queue is currently available in limited beta. This gives us the opportunity to better understand your requirements as we improve the quality and capability of the feature. In the first phase of this beta, access to the feature is limited to a select number of organizations that meet certain requirements like having a consistently high volume of changes from multiple users being merged each day.

Organization admins can request early access for their organization by joining the waitlist: https://github.com/features/merge-queue/signup. You will need to provide the name of a repository in this organization that you plan on using merge queue on, but you will have the opportunity to test the feature on other repositories during the beta. We will contact you prior to onboarding to work through the details.

Early access will expand to more organizations over the coming months.

Learn more

For the latest updates on this feature, see the public roadmap issue and #merge-queue posts in the GitHub Changelog.

To learn more about configuring and using the feature once it is available to you, start with “Adding a pull request to the merge queue“.

See more

GitHub Codespaces allows teams and organizations to spin-up developer environments directly from a browser or through Visual Studio Code, without the hassle of setting up a brand new environment tailored to a specific repository.

We've been hard at work since our general availability announcement in August making Codespaces the best way for you to develop software, which is why we're so happy to announce several new features at GitHub Universe 2021.

We know that many developers use the gh CLI to speed up or fully automate daily tasks, and we've received dozens of requests to add Codespaces support to the CLI. As of today, the gh codespace (or gh cs for those saving keystrokes) command now allows developers to manage their codespaces from the GitHub CLI. In addition to codespace creation, listing, and starting/stopping, users can forward ports, set port visibility, SSH into their codespaces, and copy files to/from their codespaces.

# Create a new codespace via the CLI
gh codespace create --repo monalisa/octocat --branch main

We're especially excited about ssh access, as it allows developers who prefer to use editors like vim and emacs to more easily develop in Codespaces. Just gh cs ssh into your codespace and launch your editor of choice; we'll set up the environment and grab all your dotfiles so you're ready to develop in seconds.

# SSH into the codespace created above
gh codespace ssh -c monalisa-monalisa-octocat-1337h4x0r

Complimenting the CLI, we are also launching an API in beta. The API provides control plane operations around a user's codespaces including creating, starting/stopping, listing available machine types, and setting user secrets. These APIs will allow developers to build Codespaces integrations into their favorite editors and tools, as well as allow for additional automation around Codespaces.

# Stop a running codespace via the API
curl https://api.github.com/user/codespaces/monalisa-monalisa-octocat-1337h4x0r/stop \
  -H "Authorization: token <Personal Access Token>" \
  -X POST

We also know that security and privacy are critical, and we've gotten a lot of feedback on providing additional visibility options for forwarded ports beyond public and private. Today we're launching a third option: org visible ports, which are accessible to any user in the organization the codespace has been created in. This is great for securely collaborating with your teammates on new and exciting features in your codespaces.

# Make port 80 visible to all users in an org
gh codespace ports visibility 80:org -c monalisa-monalisa-octocat-1337h4x0r

Continuing with security improvements, we have also heard from developers having difficulty launching codespaces from devcontainers stored in private container registries. To make this easier, we are offering streamlined access to containers stored in the GitHub Container Registry; you no longer have to provide a Personal Access Token (PAT).

Speaking of devcontainers, we know that there's a wide gap between using a predefined devcontainer and building a custom devcontainer. To help make that transition a little easier, we're launching the ability to extend devcontainers with features, which include shells, package managers, programming languages, and other common tools. For example, adding Terraform to a supported base image is as easy as adding the following to your devcontainer.json.

"features": {
  "terraform": "latest"
}

If you have any feedback about these features, or Codespaces in general, we'd love to hear from you!

Learn more about all our newly released features:

See more

Organizations using GitHub Enterprise Cloud now have more granular control over the repository access permissions they can grant to users, with custom repository roles – now available in Beta.

A custom repository role is created by an organization owner, and is available across all repositories in that organization. Each role can be given a custom name, and a description. It can be configured from a set of over 40 fine grained permissions. Once created, repository admins can assign a custom role to any user, team or outside collaborator in their repository.

Custom repository roles can be created, viewed, edited and deleted via the new Repository roles tab in Organization settings.

Screenshot 2021-10-25 at 12 59 46 PM

Custom repository roles are also fully supported in the GitHub REST APIs. The Organizations API can be used to list all custom repository roles in an organization, and the existing APIs for granting repository access to individuals and teams have been extended to support custom repository roles.

To get started with custom repository roles, read the docs.

See more