Reusable workflows can now be called from a matrix and other reusable workflows.
You can now nest up to 4 levels of reusable workflows giving you greater flexibility and better code reuse. Calling a reusable workflow from a matrix allows you to create richer parameterized builds and deployments.
Learn more about nesting reusable workflows.
Learn more about using reusable workflows with the matrix strategy..
For questions and feedback, visit the GitHub Actions community.
This feature is available to repositories enrolled in the Pull Request Merge Queue beta.
A new webhook event and GitHub Actions workflow trigger (merge_group) makes it easier to run required status checks on merge groups created by merge queue. A merge group includes the changes from one or more pull requests and must pass the status checks required by the target branch.
A merge_group webhook event, which currently has one supported action (checks_requested), is sent after a merge group is created and informs receivers, including GitHub Actions, when status checks are needed on the merge group. The event payload includes head_sha, the commit SHA that should be validated and have status reported on using check runs or commit statuses. For GitHub Actions, status is reported automatically at the conclusion of jobs in the triggered workflow.
To trigger a GitHub Actions workflow for a merge group, the merge_group trigger should be used. The following example triggers on individual pull requests and merge groups targeting the main branch:
# Trigger this workflow on individual pull requests and merge groups that target the `main` branch
on:
pull_request:
branches: [ main ]
merge_group:
branches: [ main ]A push event is still sent when a merge group branch is created, and will trigger a GitHub Actions workflow. However, unlike a merge_group event, a push event does not include the target branch of the merge group.
Learn more about using merge queue.
Learn more about the new GitHub Actions merge_group workflow trigger and the merge_group webhook event.
GitHub Pages now builds with GitHub Actions by default across all repositories.
For more details, see this blog post.
Ubuntu 22.04 is now generally available on GitHub-hosted runners. To use it now, simply add runs-on: ubuntu-22.04 in your workflow file. Otherwise, our recommendation is to use ubuntu-latest, which currently utilizes Ubuntu 20.04 but will begin running on Ubuntu 22.04 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: ubuntu-22.04
steps:
- uses: actions/checkout@v2
- uses: actions/setup-dotnet@v1
- name: Build
run: dotnet build
- name: Run tests
run: dotnet testThe Ubuntu 22.04 runner image has different tools and tool versions than Ubuntu 20.04.
Read more on available runner images and beta images terms of use in our documentation.
The Ubuntu 18.04 Actions runner image started our deprecation process on 8/8/22 and will be fully unsupported by 12/1/22. To raise awareness of the upcoming removal, jobs using Ubuntu 18.04 will temporarily fail during scheduled time periods defined below:
What you need to do
Workflows using the ubuntu-18.04 YAML workflow label should be updated to ubuntu-20.04, ubuntu-22.04, or ubuntu-latest. You can always get up-to-date information on our tools by reading about the software in GitHub Actions virtual environments. Please contact GitHub Support.
*update: we extended the deprecation schedule until April 2023 with updated dates for brownouts.
Actions runner support for Apple silicon hardware, such as the M1 chip, is now generally available. This provides teams with the capability to run self-hosted macOS workflows in a macOS ARM64 runtime. Now the Actions runner supports M1 and the ARM64 runtime meaning developers can run it on their own M1 or M2 hardware.
Based on initial testing, there are currently two issues to be aware of:
setup-python. The fix for that can be tracked here.For additional information on how to set up a self-hosted macOS ARM64 runner, please refer to our documentation. If you have any feedback or questions for Actions self-hosted Apple silicon support, you can submit an issue in the runner repository.
The repository that houses the images installed on GitHub-hosted runners has been renamed from actions/virtual-environments to actions/runner-images. These images are maintained by GitHub and used by GitHub Actions.
If you have forked this repository you will not be affected by this change.
All git clone, git fetch, or git push operations targeting the previous location will continue to function as if made on the new location. However, to reduce confusion, you should update any existing local clones to point to the new repository URL.
For more information and updates you can visit the newly improved runner images repository.
Previously we retained self-hosted GitHub Action runners in the GitHub Actions UI for 30 days after they were last seen to connect. With the growth in the use of ephemeral runners and the scale of use of self-hosted, this is becoming hard for users to manage. As a result, we are making the following changes to the time we retain offline runners for.
A non-ephemeral self-hosted Actions runner is automatically removed from GitHub if we have not seen it connect to GitHub for more than 14 days.
An ephemeral self-hosted Actions runner is automatically removed from GitHub if we have not seen it connect to GitHub for more than one day.
Learn more about self-hosted runners in GitHub Actions
You can now manage Actions cache from your terminal by installing the new GitHub CLI extension for Actions cache:
gh extension install actions/gh-actions-cache This extension is built on top of GitHub APIs for cache management and enables you to get:
Learn more about dependency caching to speed up your Actions workflows.
The macOS 10.15 Actions runner image started our deprecation process on 5/31/22 and will be fully unsupported by 8/30/22. To raise awareness of the upcoming removal, jobs using macOS 10.15 will temporarily fail during scheduled time periods defined below:
What you need to do
Workflows using the macos-10.15 YAML workflow label should be updated to macos-11, macos-12, or macos-latest. You can always get up-to-date information on our tools by reading about the software in GitHub Actions virtual environments. Please contact GitHub Support if you run into any problems or need help.
Starting next week, workflow re-runs in GitHub Actions will use the initial run’s actor for privilege evaluation. The actor who triggered the re-run will continue to be displayed in the UI, and can be accessed in a workflow via the triggering_actor field in the github context.
Currently, the privileges (e.g. – secrets, permissions) of a run are derived from the triggering actor. This poses a challenge in situations where the actor triggering a re-run is different than the original executing actor. The upcoming change will differentiate the initial executing actor from the triggering actor, enabling the stable execution of re-runs.
For more details see Re-running workflows and jobs.
For questions, visit the GitHub Actions community.
To see what’s next for Actions, visit our public roadmap.
You can now get more transparency and control over dependency caching in your actions workflows.
Actions users who use actions/cache to make jobs faster on GitHub Actions can now use our cache list and delete APIs to:
Learn more about Managing caching dependencies to speed up workflows.
The macOS 12 Actions runner image is now generally available. Start using GitHub Actions to build and publish apps for the Apple ecosystem with the latest version of Xcode by updating your jobs to include runs-on: macos-12
jobs:
build:
runs-on: macos-12
steps:
- uses: actions/checkout@v2
- name: Build
run: swift build
- name: Run tests
run: swift testThe macOS 12 Actions runner image has different tools and tool versions than macOS 11. See the full list of changed software.
If you spot any issues with your workflows when using the image, please let us know by creating an issue in the virtual-environments repository.
Workflows triggered by workflow_dispatch and workflow_call can now access their inputs using the inputs context.
Previously workflow_dispatch inputs were in the event payload. This made it difficult for workflow authors who wanted to have one workflow that was both reusable and manually triggered. Now a workflow author can write a single workflow triggered by workflow_dispatch and workflow_call and use the inputs context to access the input values.
For workflows triggered by workflow_dispatch inputs are still available in the github.event.inputs context to maintain compatibility.
Using the inputs context in GitHub Actions
You can now enable debug logging when you re-run jobs in a GitHub Actions workflow run. This gives you additional information about the job's execution and its environment which can help you diagnose failures.
To enable debug logging, select "Enable debug logging" in the re-run dialog.
You can also enable debug logging using the API or the command-line client.
For more details see
Re-running workflows and jobs.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.