Git.io no longer accepts new URLs

Git.io is a URL shortening website that GitHub created in 2011 for redirecting to GitHub domains like github.com and github.io. What began as an experiment was only lightly documented and thus not heavily used.

Today, git.io is increasingly being used for malicious purposes. At GitHub, we want to end that activity, focus on building great developer tools, and cede URL shortening to companies and teams who provide it as a core offering. There are many URL shortening services available today that have more capabilities than git.io.

For these reasons, we have disallowed new link creation on git.io. Existing URLs will continue to be accessible, but we encourage using one of the many URL shortening services that are available, instead of git.io, as we will be deprecating the tool in the future. This allows us to concentrate on what we’re able to make and keep great.

GitHub Actions: Jobs running on `windows-latest` are now running on Windows Server 2022.

Windows Server 2022 became generally available on GitHub-hosted runners in November 2021. Over the next 8 weeks, jobs using the windows-latest runner label will migrate from Windows Server 2019 to Windows Server 2022. During migration, you can determine if your job has migrated by viewing the Virtual Environment information in the Set up job step of your logs.

Use GitHub Actions to build your apps with the latest Visual Studio 2022 by updating your workflows to include runs-on: windows-latest

jobs:
  build:
    runs-on: windows-latest
    steps:
      - uses: actions/checkout@v2
      - uses: actions/setup-dotnet@v1
      - name: Build
        run: dotnet build
      - name: Run tests
        run: dotnet test

The Windows Server 2022 runner image has different tools and tool versions than Windows Server 2019. See the full list of changed software.

If you spot any issues with your workflows when using Windows Server 2022, please let us know by creating an issue in the virtual-environments repository.

See more

Codespaces now offers organization policies to restrict machine types

Currently, Codespaces users in organizations in Team and Enterprise Cloud plans can use any machine type, from 2-core to 16-core (or even 32-core). We've heard from many organization administrators that they want the ability to restrict which machine sizes repositories in their organization should have access to as a means of cost control, and have implemented a new Codespaces policy feature to allow admins this level of control.

Organization admins can now visit their organization's settings page and create Codespaces policies to restrict which machine types repositories in their organization can use. For instance, an admin can restrict certain repositories to only access 2-core and 4-core machines, while granting other, more compute intensive repositories, access to 16-core machines.

In the future, the Codespaces policy feature will be expanded to include additional constraints, including setting a maximum idle timeout, restricting which port forwarding settings are allowed, and more. We'd love your feedback on other constraints you're interested in.

For more information, see "Restricting access to machine types".

See more
View all changes