actions

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.

You can now specify input types for manually triggered workflows allowing you to provide a better experience to users of your workflow. In addition to the default string type, we now support choice, boolean, and environment.

name: Mixed inputs

on:
  workflow_dispatch:
    inputs:
      name:
        type: choice
        description: Who to greet
        options: 
        - monalisa
        - cschleiden
      message:
        required: true
      use-emoji:
        type: boolean
        description: Include 🎉🤣 emojis
      environment:
        type: environment

jobs:
  greet:
    runs-on: ubuntu-latest

    steps:
    - name: Send greeting
      run: echo "${{ github.event.inputs.message }} ${{ fromJSON('["", "🥳"]')[github.event.inputs.use-emoji == 'true'] }} ${{ github.event.inputs.name }}"

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

Actions written in YAML, also known as composite actions, now support if conditionals. This lets you prevent specific steps from executing unless a condition has been met. Like steps defined in workflows, you can use any supported context and expression to create a conditional.

Learn more about actions written in YAML.

For questions, visit the GitHub Actions community

As part of our ongoing efforts to keep GitHub-hosted runners updated and secure, the Windows 2016 virtual environment will be removed from GitHub Actions on March 15, 2022. We recommend you change jobs using runs-on: windows-2016 to use runs-on: windows-latest which will ensure you're always running on the latest version of Windows Server.

If you need to pin your job to a specific version of Windows Server, you can see the full list of supported versions and instructions here: supported-runners-and-hardware-resources

To raise awareness of the upcoming removal, we will temporarily fail jobs using Windows 2016 for two short 'brownout' periods. Builds that are scheduled to run during the brownout periods will fail. The brownouts are scheduled for the following dates and times:

• December 1, 2021 4:00pm UTC – 10:00pm UTC
• February 7, 2022 4:00pm UTC – 10:00pm UTC

Once deprecated, the Windows 2016 image is now excluded from the service level agreement and warranty therefore it is recommended that you move to a supported version of Windows before March 15, 2022.

You can learn more about our software and image guidelines for GitHub-hosted runners in the virtual environment repository. Please contact support if you experience any issues due to this change.

Now available in public beta, you can reuse entire workflows as if they were an action. Instead of copying and pasting workflow definitions across repositories, you can now reference an existing workflow with a single line of configuration.

Reusing workflows are great for reducing configuration. Here’s a few examples:

• Create a workflow for building your homegrown framework so your users can quickly setup CI
• Create a workflow to deploy to production, and reference it from each repository of your microservice application
• Create a workflow to roll up end-of-sprint metrics, and encourage every team to add it to their repository

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

macOS Big Sur (11) became generally available on GitHub-hosted runners in August 2021. Over the next 8 weeks, jobs using the macos-latest runner label will migrate from Catalina (10.15) to Big Sur (11). 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.

Start using GitHub Actions to build and publish apps for the Apple ecosystem by updating your jobs to include runs-on: macos-latest

jobs:
  build:
    runs-on: macos-latest
     steps:
      - uses: actions/checkout@v2
      - name: Build
        run: swift build
      - name: Run tests
        run: swift test

The macOS 11 Big Sur runner image has different tools and tool versions than macOS 10.15 Catalina. See the full list of changed software.

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

GitHub Actions now supports ephemeral (i.e. single job) self-hosted runners and a new workflow_job webhook to make autoscaling your runners easier. After a job is run, ephemeral runners are automatically unregistered from the service, allowing you to do any required post-job management.

Ephemeral runners are a good choice for self-managed environments where you need each job to run on a clean image. A runner is configured as ephemeral by adding the optional --ephemeral parameter during configuration. Learn more about registering ephemeral runners.

Example ephemeral runner registration:

$ ./config.sh --url https://github.com/octo-org --token example-token --ephemeral

Combine ephemeral runners with the new workflow_job webhook to automatically scale your self-hosted runners in response to your Actions job requests, including the runner labels from the runs-on: key from your workflow. Learn more about the workflow_job webhook and how to use it to autoscale your self-hosted runners.

Get started with automating the configuration of your self-hosted runners by following this automation guide in the runner repo.

GitHub Actions now has an updated management experience for your self-hosted runners that makes it easier to manage runner groups and see the status of your runners. New Runners and Runner groups pages give you flexibility to get a summary view of your runners, or deep dive into a specific runner to edit it or see what job it may be currently running. You'll find both of these experiences in the Actions settings page of your repository or organization.

Similarly, a new Runner groups page gives you a cleaner view of all the runner groups you've created, and how many runners are included in each one.

Learn more about self-hosting your runners for GitHub Actions.
Learn more about managing access to your runners with runner groups.

You can now use setup-node action to cache dependencies for projects with monorepo and pnpm package manager. Use the optional cache-dependency-path field to specify the path to dependency file(s).

steps:
- uses: actions/checkout@v2
- uses: actions/setup-node@v2
  with:
    node-version: 14
    cache: npm
    cache-dependency-path: 'sub-project/package-lock.json'

For questions, visit the setup-node repository and GitHub Actions community.