Warning about bidirectional Unicode text

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.

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