actions

Subscribe to all “actions” posts via RSS or follow GitHub Changelog on Twitter to stay updated on everything we ship.

~ cd github-changelog
~/github-changelog|main git log main
showing all changes successfully

OpenID Connect (OIDC) support in GitHub Actions enables secure cloud deployments using short-lived tokens that are automatically rotated for each deployment.

You can now use the enhanced OIDC support to configure the subject claim format within the OIDC tokens, by defining a customization template at either org or repo levels. Once the configuration is completed, the new OIDC tokens generated during each deployment will follow the custom format.

This enables organization & repository admins to standardize OIDC configuration across their cloud deployment workflows that suits their compliance & security needs.

Learn more about Security hardening your GitHub Workflows using OpenID Connect.

See more

We've made exciting design improvements to GitHub Actions to promote better discoverability and accessibility. The improvements include:

  • An improved navigation experience that makes it easier to search workflows and workflow runs.
  • Added structure to better represent the hierarchy between caller and called reusable workflows.
  • A better mobile experience that is more consistent and supports multiple viewports.

Workflow run

For questions or to share your feedback, visit the GitHub Actions community.

See more

GitHub now supports using the -latest image label on your larger hosted runners. With the -latest label developers can be sure that their workflows use the latest available GA image in GitHub Actions.
latestimagelabel

In general the -latest tag is used for the latest OS image version that is GA. You can find more information about the different image versions in our runner-images repository.

Interested in learning more about larger hosted runners? Read the announcement here or sign up for the beta here.

See more

To avoid untrusted logged data to use save-stateand set-output workflow commands without the intention of the workflow author we have introduced a new set of environment files to manage state and output.

Starting today runner version 2.298.2 will begin to warn you if you use the save-state or set-output commands via stdout. We are monitoring telemetry for the usage of these commands and plan to fully disable them on 31st May 2023. Starting 1st June 2023 workflows using save-state or set-output commands via stdout will fail with an error.

Patching your actions and workflows

If you are using self-hosted runners make sure they are updated to version 2.297.0 or greater.

Action authors who are using the toolkit should update the @actions/core package to v1.10.0 or greater to get the updated saveState and setOutput functions.

Action and workflow authors who are using save-state or set-output via stdout should update to use the new environment files.

Examples

A workflow using save-state or set-output like the following

- name: Save state
  run: echo "::save-state name={name}::{value}"

- name: Set output
  run: echo "::set-output name={name}::{value}"

should be updated to write to the new GITHUB_STATE and GITHUB_OUTPUT environment files:

- name: Save state
  run: echo "{name}={value}" >> $GITHUB_STATE

- name: Set output
  run: echo "{name}={value}" >> $GITHUB_OUTPUT
See more

Actions on GitHub Mobile

Actions are coming to GitHub Mobile! You can now view and manage your pull requests on the go.

Tapping on checks when viewing a pull request now leads to a vastly improved experience, including the ability to view a workflow-run, its jobs and even the logs of completed steps inside.

A run did not go as planned? No problem. GitHub Mobile now supports re-running single jobs, failed jobs as well as entire workflows directly from your mobile device. For checks that are already running, support for cancellation has been added as well.


Read more about GitHub Mobile and send us your feedback to help us improve.

See more

macOS 12 became generally available on GitHub-hosted runners in June 2022. Over the next 10 weeks, jobs using the macos-latest runner label will migrate from macOS 11 to 12. During migration, you can determine if your job has migrated by viewing the Runner Image 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 12 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 macOS 12, please let us know by creating an issue in the runner image repository.

See more

Actions runner support for Windows ARM hardware, is now in public beta . This provides teams with the capability to run self-hosted Windows workflows in a Windows ARM64 runtime.

There are some limitations of the current beta product to be aware of:

  • Windows ARM runners are currently using nodejs's "unofficial" win-arm64 builds
  • Some first party actions will not work until a win-arm64 version of that language is released:
    • setup-node
    • Some first party actions don't support the arm64 architecture:
    • setup-python -issue tracking it here

For additional information on how to set up a self-hosted Windows ARM64 runner, please refer to our documentation. If you have any feedback or questions for Actions self-hosted Windows ARM support, you can submit an issue in the runner repository.

See more

Additional information has been added to the payload of github.event for scheduled runs. Before this change, github.event for scheduled runs would only include the cron schedule. This change adds information about the repository, organization, and enterprise (when available).

For questions, visit the GitHub Actions community.

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

See more

Node 12 has been out of support since April 2022, as a result we have started the deprecation process of Node 12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023. We will monitor the progress of the migration and listen to the community for how things are going before we define a final date.
To raise awareness of the upcoming change, we are adding a warning into workflows which contain Actions running on Node 12. This will come into effect starting on September 27th.

What you need to do
For Actions maintainers: Update your actions to run on Node 16 instead of Node 12 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node 16 (Using versions for Actions)

See more

Customers will now be able to use the GITHUB_TOKEN with workflow_dispatch and repository_dispatch events to trigger workflows. Prior to this change, events triggered by GITHUB_TOKEN would not create a new workflow run. This was done to prevent the accidental trigger of endless workflows. This update makes an exception for workflow_dispatch and repository_dispatch events since they are explicit calls made by the customer and not likely to end up in a loop.

name: Create Workflow Dispatch

on:
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Workflow
        uses: actions/github-script@v6
        with:
          script: |
            github.rest.actions.createWorkflowDispatch({
              owner: context.repo.owner,
              repo: context.repo.repo,
              workflow_id: 'test.yml',
              ref: 'main',
            })

For more details see
Triggering a workflow from a workflow.

For questions, visit the GitHub Actions community.

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

See more

Today, we are announcing the public beta of larger GitHub hosted runners for GitHub Actions for Team and Enterprise plans 🎉 🎉

The new larger runners provide new capabilities for Team and Enterprise GitHub Action users:

  • Linux and Windows machines up to 64 cores
  • Fixed IP ranges to provide access to runners via allow list services
  • Admin control over access to larger runners and concurrency

Larger machine sizes

Developers will be able to make use of machine sizes up to 64 cores on demand to run their workflows, billed by the job minute.

image

Fixed IP ranges

Setup a fixed IP range for your machines by simply ticking a check box, this provides an IP range that can be allow listed in internal systems and in GitHub’s allow list to keep using Actions while making your GitHub environment more secure.

image

Admin control

Admin’s can choose who can have access to larger machine sizes and at what concurrency, providing guard rails on spending
image

Larger machine pricing

Larger runners are charged for in both private and public repos and do not consume included minutes.
To learn more about the larger runner per job minute pricing, check out the updated pricing docs

To learn more about using the new larger runners, check out our docs

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

See more

OpenID Connect (OIDC) support in GitHub Actions is now enhanced to support secure cloud deployments at scale.

Org & repo admins can use the new OIDC API support to:

  • enable a standard OIDC configuration across their cloud deployment workflows by customizing the subject claim format.
  • ensure additional compliance & security for their OIDC based deployments by appending the issuer url with their enterprise slug
  • configure advanced OIDC policies by using the additional OIDC token claims like repository_id and repo_visibility.

Learn more about Security hardening your GitHub Workflows using OpenID Connect.

See more

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.

See more

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.

See more

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 test

The 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.

See more

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:

  • October 3, 12:00 UTC – October 3, 14:00 UTC
  • October 18, 14:00 UTC – October 18, 16:00 UTC
  • November 15, 18:00 UTC – November 15, 20:00 UTC
  • November 30, 20:00 UTC – November 30, 22:00 UTC
  • December 15, 20:00 UTC – December 16 00:00 UTC
  • January 5, 10.00 UTC – January 5, 14.00 UTC
  • January 13, 12.00 UTC – January 13, 16.00 UTC
  • January 18, 14.00 UTC – January 18, 18.00 UTC
  • January 24, 16.00 UTC – January 24, 20.00 UTC
  • February 7, 16.00 UTC – February 7, 22.00 UTC
  • February 21, 10.00 UTC – February 21, 22.00 UTC
  • March 6, 00.00 UTC – March 7, 00.00 UTC
  • March 13, 00.00 UTC – March 14, 00.00 UTC
  • March 21, 00.00 UTC – March 22, 00.00 UTC
  • March 28, 00.00 UTC – March 29, 00.00 UTC

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.

See more

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:

  • macOS ARM64 does not support node12. Therefore, the runner will automatically use node16 to execute any javascript Action written for node12.
  • All actions provided by GitHub are compatible with the runner except for a known issue with 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.

See more

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.

See more