actions

You now have more control over when your self-hosted runners perform software updates. If you specify the --disableupdate flag to the runner then it will not try to perform an automatic software update if a newer version of the runner is available. This allows you to update the self-hosted runner on your own schedule, and is especially convenient if your self-hosted runner is in a container.

For compatibility with the GitHub Actions service, you will need to manually update your runner within 30 days of a new runner version being available. For instructions on how to install the latest runner version, please see the installation instructions for the latest release in the runner repo.

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

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.

Previously, when running a job that requires a self-hosted runner, GitHub Actions would look for self-hosted runners in the repository, organization, and enterprise, in that order.

We are changing that behavior so that the first available matching runner at any level will run the job in all cases. This allows jobs to be sent to self-hosted runners much faster, especially for organizations and enterprises with lots of self-hosted runners.

Learn more in the documentation

Getting started with GitHub Actions just got easier! Now, when you want to create an Actions workflow in the Actions tab of your repository, the workflow recommendations will be based on repository analysis that detects elements, such as programming language, build tools, frameworks, and package managers.

For example, if a repository contains a Node.js application that has been containerized, then the repository analysis will prioritize showing you container and Node related workflows.

We have also extended recommendations to the deployment category.
and added search and filters to help you find the right workflow that matches your unique requirements.

Learn more about this GitHub Actions improvement.

In the latest update to our GitHub-hosted runners virtual environments, Node.js 16 has become the default version of node and npm 8 has become the default version of npm.

To select the version of Node.js that you use for your projects, we encourage you to use the setup-node action.

For questions, visit the GitHub Actions community

To see what's next for Actions, visit our public roadmap

Reusable workflows are now generally available. Reusable workflows help you reduce duplication by enabling you to reuse an entire workflow as if it were an action. A number of improvements have been made since the beta was released in October:

• You can utilize outputs to pass data from reusable workflows to other jobs in the caller workflow
• You can pass environment secrets to reusable workflows
• The audit log includes information about which reusable workflows are used

Learn more about reusing workflows.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

You can now run workflows for Python projects faster on GitHub Actions by enabling dependency caching on the setup-python action. setup-python supports caching for both pip and pipenv projects.

The following example enables caching for a Python project with pip:

steps:
- uses: actions/checkout@v2
- uses: actions/setup-python@v2
  with:
    python-version: '3.9'
    cache: 'pip'
- run: pip install -r requirements.txt
- run: pip test

For additional examples, visit the setup-python repository.

Windows Server 2022 with Visual Studio 2022 is now generally available on GitHub-hosted runners. To use it now, simply add runs-on: windows-2022 in your workflow file. Otherwise, our recommendation is to use windows-latest, which currently utilizes Windows 2019 but will begin running on Windows 2022 in the near future. This will ensure your workflows are always using a recent OS and removes the need to constantly update workflow files with image versions.

jobs:
  build:
    runs-on: windows-2022
    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.

Read more on available runner images and beta images terms of use in our documentation.