Skip to content

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

We are excited to announce that organizations within an enterprise can now create network configurations indepndently of their enterprise for Azure private networking. Azure private networking is a powerful feature that allows you to run your Actions workflows on GitHub-hosted runners connected to your Azure virtual network, without compromising on security or performance. Previously, only enterprises and organizations associated with team plans could create network configurations. This caused a bottleneck for administrators who have been delegated the responsibility for managing network configurations.

Moving forward, enterprise administrators can enable this feature by navigating to the “Hosted compute networking” section of their enterprise policies and selecting “Enabled”. Once this setting has been saved, all organizations associated with the enterprise will be able to create their own network configurations.

To start using Azure private networking for Actions, follow this guide to walk you through configuring Azure resources and creating an Actions network configuration. For additional information, check out our docs here. Please note that Azure private networking is available for GitHub Enterprise Cloud & Team plans.

See more

Today, GitHub announced the public beta of ArmⓇ-based Linux and Windows hosted runners for GitHub Actions.
This new addition to our suite of hosted runners provides power, performance & sustainability improvements for all your Actions jobs. Developers can now take advantage of Arm-based hardware hosted by GitHub to build and deploy their release assets anywhere Arm architecture is used. These runners are priced at 37% less than our x64 Linux and Windows runners.

The Arm64 runners are fully managed by GitHub with an image built by Arm containing all the tools needed for developers to get started. To view the list of installed software, give feedback, or to report issues with the image, head to the new partner runner images repository.

Arm runners are available to customers on our Team and Enterprise Cloud plans. We expect to begin offering Arm runners for open source and personal accounts by the end of the year.

Get Started

Customers can begin using these runners today by creating an Arm runner in their organization/enterprise, then updating the runs-on syntax in their Actions workflow file to call that runner name.
More information on how to set up Arm-hosted runners can be found in our public documentation.
To learn more about hosted runner per minute rates, see our rate table.

We’re eager to hear your feedback on these runners, share your thoughts on our GitHub Community Discussion.

See more

GitHub Actions has recently made changes to the available macOS runner images and the GitHub meta API. Below is a summary of the changes and possible impact to your use of GitHub-hosted macOS runners:

macOS latest migration

GitHub announced in April 2024 the general availability of macOS 14. As of today, we have completed the migration and all macos-latest workflows now use macOS 14.

macOS 11 deprecation and removal

In January 2024, GitHub announced the deprecation of macOS 11 and the removal of the runner image by June 2024. The macOS 11 runner image will be removed on 6/28/2024. We recommend updating workflows to use macos-14, macos-13, macos-12, or macos-latest. Reminder emails will be sent to those who have used the macOS 11 runner image in the past 30 days. Jobs using macOS 11 will temporarily fail during scheduled time periods to raise awareness of the upcoming removal. The schedule can be found below:

  • June 17 2024, 8:00 AM – 2:00 PM EST
  • June 19 2024, 12:00 PM – 6:00 PM EST
  • June 24 2024, 3:00 AM – 9:00 PM EST
  • June 26 2024, 8:00 AM – 2:00 PM EST

macOS runner IP ranges

Developers and teams have requested that Actions separate macOS runner IP ranges from the rest of Actions so they can allow list them. As of today, developers can isolate macOS runners from the rest of Actions in the GitHub API by using the actions_macos object. The IP addresses may change periodically due to new hardware being brought online or maintenance being performed. To ensure that developers have the most up-to-date information, the IP addresses are refreshed every Monday at 12:30 PM EST.

You can always get up-to-date information on our tools by reading about the software in the runner images repository. For more information on how to use the GitHub API, please see our docs. If you run into any problems or need help, please contact GitHub Support.

See more

Following on from our announcement of the end of Node16 support we have a new timeline for Node16 end of life in Actions.

On June 30th 2024, we will change the default from Node16 to Node20.
To opt out of this and continue using Node16 while it is still available in the runner, you can choose to set ACTIONS_ALLOW_USE_UNSECURE_NODE_VERSION=true

We will then continue to monitor Node16 usage and will communicate a timeline for the removal of Node16 at the start of October, based on the volume of continued use. This means that customers who use the environment variable to continue to use Node16 now have until October to complete their migrations.

Join the discussion within GitHub Community.

See more

Updating our announcement we made on the 16th of April, we have a new timeline for the removal of multi-labels for larger runners.

Brownouts will now be run on the 29th of May between 18:00 and 20:00 UTC, during this time multi label larger runner jobs will fail to start. Customers will then no longer be able to use multiple labels or target non-name labels on larger runners after the 17th of June.

To prepare for this change and avoid any disruption, please ensure the runs-on: references only the runner name in your workflows prior to the dates above.

Join the discussion within GitHub Community.

See more

We are happy to announce the beta release of the Ubuntu 24.04 image for GitHub Actions hosted runners. To start using this in your Actions workflows, update your workflow file to include runs-on: ubuntu-24.04

jobs:
  build:
    runs-on: ubuntu-24.04
     steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm install -g bats
      - run: bats -v

Some users may notice differences in workflows as the Ubuntu 22.04 image has different tools and tool versions, see the full list of changed software.

If you spot any issues with your workflows when using Ubuntu-24.04, or if you have feedback on the software installed on the image, please let us know by creating an issue in the runner-images repository.

While the runner image is in beta, you may experience longer queue times during peak usage hours.

See more

Azure private networking was made generally available in April 2024 with 11 available regions. GitHub Actions has expanded the number of supported regions to 17, with the following new additions:

  • Germany West Central
  • Sweden Central
  • North Central US
  • South Central US
  • West US 3
  • Japan East

Azure private networking is available for GitHub Enterprise Cloud & Team plans. For the entire list of supported regions, see our documentation. If your desired region is not currently available, please use this form to submit a region request.

To start using Azure private networking for Actions, follow this guide to walk you through configuring Azure resources and creating an Actions network configuration.

See more

Previously, developers who used private registries to host their packages on internal networks could not use Dependabot to update the versions of those packages in their code.

With this change, users can choose to run Dependabot pull request jobs on their private networks with self-hosted GitHub Actions runners, allowing Dependabot to access on-premises private registries and update those packages.

A prerequisite for enabling self-hosted runners includes enabling GitHub Actions for the repositories of interest. It’s important to note that running Dependabot does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone.

To get started, check out our documentation on managing self-hosted runners with Dependabot Updates.

If you’re interested in learning more about what it means to run Dependabot as a GitHub Actions workflow, check out our changelog and FAQ or Dependabot on Actions documentation.

See more

Create a tamper-proof papertrail for anything you build on Actions

Artifact Attestations lets you sign builds in GitHub Actions, capturing provenance information about the artifact and making it verifiable from anywhere. There are no keys or PKI to manage, and verification happens with the GitHub CLI tool. The solution is based on Sigstore, an open source project that simplifies signing for software artifacts.

To add provenance to a GitHub Actions workflow, you just need to invoke the new attest-build-provenance Action with the path to an artifact. Here’s a simple example:

permissions:
  id-token: write
  contents: read
  attestations: write

#
# (build your artifact)
#

- name: Generate artifact attestation
  uses: actions/attest-build-provenance@v1
  with:
    subject-path: 'PATH/TO/ARTIFACT'

Then verify it with the CLI tool:

gh attestation verify PATH/TO/ARTIFACT -o myorganization

To learn more check out the blog and join the discussion in the GitHub Community.

See more

We recently shipped several changes to improve the Actions user experience. These changes include adding backscroll to the Actions streaming logs and workflow pinning.

Actions streaming logs with backscroll is now generally available. Previously, an Actions job that was actively running would only stream the logs generated after the page was loaded. Logs emitted prior to the page loading would only be available after the job completed. This made it challenging to monitor the progress of jobs as they were running, particularly those that could take a long time to complete. Customers will now be able to visit the logs of a running job and immediately get the previous 1,000 log lines emitted. This will give you immediate context into the run’s progress and status.

We have also made it easier to navigate within the Actions tab. Customers can now pin Actions workflows to the top of the list (a maximum of 5 pinned workflows per repository) to make them easily accessible. When a workflow is pinned, it is visible to everyone with access to that repository. Any collaborator with write access will be able to pin or unpin workflows. In addition, all workflows, including required workflows, will be displayed in a single list. Disabled workflows will be sorted to the bottom of the list and will display a disabled label.

If you have any feedback you wish to share about these changes, please reach out in the GitHub Community Discussion.

See more

Repository Updates April 30th, 2024

  • Deploy keys are now supported as a bypass actor in repository rules, allowing additional granularity for your automations. Previously for deploy keys to bypass a ruleset the Repository Administrator role was required.
  • Webhooks and GitHub Actions will no longer be run for any push that includes over 5000 branches. Clients will now receive the following warning indicating they have reached this limit. remote: warning: No webhooks or actions will be performed for this push as it updates more than 5000 branches.

Join the discussion within GitHub Community.

See more

Starting today, developers using GitHub Enterprise Cloud (GHEC) and Free, Pro, and Teams accounts can enable their repositories and/or organizations to run Dependabot updates as an Actions workflow. With this change, the job that Dependabot runs to generate pull requests will run in GitHub Actions. This is the start of an effort to consolidate Dependabot’s compute platform to Actions, with further migration plans to be announced later.

Who can opt-in?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions today.

What if I’m on Enterprise Server (GHES)?

GitHub Enterprise Server (GHES) and Proxima users already run Dependabot on Actions; no further steps are required to enable Dependabot on Actions for these users.

Why choose to run Dependabot as an Actions workflow today?

Enabling Dependabot on Actions will yield performance benefits like faster Dependabot runs and increased visibility into errors to manually detect and troubleshoot failed runs. Actions APIs and webhooks will also be able to detect failed runs and perform downstream processing should developers wish to configure this in their CI/CD pipelines. There will be no change or impact to the Dependabot functionality, and there will be no impact to billed Actions minutes (i.e. Dependabot runs are free).

Will this count towards Actions minutes or costs?

This does not count towards GitHub Actions minutes – meaning that using Dependabot continues to be free for everyone. Beginning today, using Dependabot as an Actions workflow is free for everyone and generally available on all repositories.

What’s the next migration phase for Dependabot on Actions?

Over the course of the next year, we are migrating all Dependabot workflows to run on Actions compute infrastructure. You can opt-in today to gain access to these benefits, but they’ll be coming soon to all repos without needing to opt-in as well. We’re excited for faster runs, increased troubleshooting visibility, and other future benefits running Dependabot on Actions will unlock. We’ll be in close contact with those organizations who own repositories with Actions disabled and Dependabot enabled as we kick off the compute infrastructure migration. If you have questions or concerns, please contribute to our community discusson or contact our support team.

How to enable Dependabot on Actions?

GHEC, Free, Pro, and Teams administrator users can enable Dependabot on Actions runners at either the repository or organization level from the Code security and analysis settings pages. For more information, see our documentation on enabling Dependabot on Actions runners.

When will Dependabot support self-hosted runners and larger GitHub-Hosted runners?

May 2024

When will VNETs be supported?

This work is still in progress; we don’t yet have an estimated date when these will be available.

Can I use Actions workflows and APIs to trigger Dependabot jobs?

Today, Dependabot jobs can only be triggered from the Dependabot UI, and not by Actions workflows or APIs.

If I see a Dependabot job fail in Actions, how can I restart it?

Check out our documentation on re-running a verison updates job or re-running a security updates job.

If I enable Dependabot on Actions, can I later opt-out?

At this time, you can opt out of enabling Dependabot on Actions. However, this ability will change within the next year as we consolidate Dependabot’s compute platform to Actions.

What if I don’t want to turn on Actions for my repository or organization? What happens if Actions is disabled in a repository but Dependabot is enabled to run on Actions?

During this opt-in phase of the compute infrastructure migration, if you enable Dependabot on Actions but disable Actions at the repository or organization level, Dependabot will run on the legacy compute infrastructure. Please enable Actions either in your Dependabot-enabled repository or across your organization if you wish to opt in to run Dependabot on Actions.

Read more about Dependabot on GitHub Actions runners.

Join the discussion within GitHub Community.

See more

From the 15th of May 2024 we will no longer support multiple labels on larger GitHub Hosted Runners.

In February 2023 we announced that customers could no longer add or manage additional labels on larger runners. Following on from this, we will now be fully deprecating support for multi-labels on larger runners. This means that jobs targeting more than one label or jobs targeting labels that do not match the runners name for GitHub Hosted Larger Runner, after May 15th, will no longer be able to pick up jobs.

We will be running a brown out on the 8th of May between 18:00 and 20:00 UTC, during this time multi label larger runner jobs will fail to start.

To prepare for this change and avoid any disruption, please ensure the runs-on: references only the runner name in your workflows prior to the dates above.

Join the discussion within GitHub Community.

Update 8th May: We did not run the brownout as planned today on May 8th. We apologize for any inconvenience. There will be additional details on the multi-label larger runners deprecation coming soon, with the future brownout date planned for June.

See more

Starting November 30, 2024, GitHub Actions customers will no longer be able to use v3 of actions/upload-artifact or actions/download-artifact. Customers should update workflows to begin using v4 of the artifact actions as soon as possible. While v4 of the artifact actions improves upload and download speeds by up to 98% and includes several new features, there are key differences from previous versions that may require updates to your workflows. Please see the documentation in the project repositories for guidance on how to migrate your workflows.

The deprecation of v3 will be similar to the previously announced v1 and v2 deprecation plans, which is scheduled to take place on June 30, 2024. Version tags will not be removed from the project repositories, however, attempting to use a version of the actions after the deprecation date will result in a workflow failure. Artifacts within their retention period will remain accessible from the UI or REST API regardless of the version used to upload. This deprecation will not impact any existing versions of GitHub Enterprise Server being used by customers.

This announcement will also be added to actions/upload-artifact and actions/download-artifact. Please visit the documentation to learn more about storing workflow data as artifacts in Actions.

See more

Docker Compose v1 has been deprecated as of July 2023. All customers utilizing Compose v1 on GitHub-hosted runners are encouraged to migrate to Compose v2. Per GitHub’s support policy we will remove this tool from our GitHub managed runner images effective July 9, 2024.

To avoid breaking changes, customers will need to update their Actions workflow files from using docker-compose to docker compose. After July 9, workflows will begin to fail that are using the previous syntax. Customers are advised to review the migration instructions to ensure they are making all the changes required.

For more information on GitHub managed images, see the runner-images repository.

See more

Available now, Actions users of our 2-vCPU GitHub-hosted Linux runners will be able to make use of hardware acceleration for Android testing. Previously this feature was only available on runners with 4 or more vCPUs.

To make use of this on Linux, Actions users will need to add the runner user to the KVM user group

      - name: Enable KVM group perms
        run: |
            echo 'KERNEL=="kvm", GROUP="kvm", MODE="0666", OPTIONS+="static_node=kvm"' | sudo tee /etc/udev/rules.d/99-kvm4all.rules
            sudo udevadm control --reload-rules
            sudo udevadm trigger --name-match=kvm

You will then be able to make use of hardware acceleration when making use of Android emulator actions such as reactivecircus/android-emulator-runner.

For more information on how to set-up hardware acceleration, please see our documentation.

See more

Today we are announcing exciting updates for GitHub Actions hosted runners, the cloud-based service that provides powerful virtual machines to developers and teams to integrate their automation and CI/CD workflows within GitHub. These updates mark a significant leap towards enhancing enterprise readiness for GitHub Actions and a testament to our commitment to simplifying the adoption of GitHub Actions hosted runners across all project sizes and complexities.

  • Azure private networking functionality, that was previously in public beta, is now generally available. This feature allows you to run your Actions workflows on GitHub-hosted runners that are connected to your Azure virtual network, without compromising on security or performance.
  • We are introducing additional runner SKUs to our hosted runner fleet including a 2 vCPU Linux runner and a 4 vCPU Windows runner, both equipped with auto-scaling and private networking functionalities. Both these SKUs are generally available starting today and are geared to support scenarios where smaller machine sizes suffice yet the demand for heightened security and performance persists.
  • Apple silicon (M1) hosted runners, specifically macOS L (12-core Intel) and macOS XL (M1 w/GPU hardware acceleration) which were previously in public beta, are now generally available.
  • We are also unveiling a GPU hosted runner (4 vCPUs, 1 T4 GPU) available in public beta. The GPU runners are available on Linux and Windows, and are enabled with auto-scaling and private networking functionalities. These runners empower teams working with machine learning models such as large language models (LLMs) or those requiring GPU graphic cards for game development to run their tests more efficiently as part of their automation or CI/CD process.

Get Started

  • Azure private networking for GitHub-hosted runners is available across Team and Enterprise plans. To get started, navigate to the ‘Hosted Compute Networking’ section within your Enterprise or Organization settings. For more details, consult our documentation. To request support for additional Azure regions, please fill out this form. As a note, Azure private networking for GitHub Codespaces continues to remain in beta.
  • The newly added 2 vCPU Linux and 4 vCPU Windows SKUs are generally available starting today across Team and Enterprise plans. To use these runners, create a GitHub-hosted runner by selecting the ‘2-core’ or ‘4-core’ size options in the runner creation flow.
  • macOS L and macOS XL runners are generally available across Free, Team and Enterprise plans, and can be used by updating the runs-on key to use one of the GitHub-defined macOS runner labels. To learn more about pricing for these SKUs, refer to our documentation.
  • GPU runners are available starting today in public beta across Team and Enterprise plans. To learn more about how to setup the runner, images, and pricing, refer to our documentation. To share your feedback and help us find the right additional GPU SKUs to support, please fill out this form.

We’re eager to hear your feedback on any and all of these functionalities. Share your thoughts on our GitHub Community Discussion.

See more

macOS 14 (Sonoma) is now generally available. Over the next 12 weeks, jobs using the macos-latest runner label will migrate from macOS 12 (Monterey) to macOS 14 (Sonoma). 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. This announcement also applies to larger macOS runners, for which the following runner labels can be used:

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

To use macOS 14 directly, update runs-on: in your workflow file to macos-14, macos-14-xlarge, or macos-14-large:

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

The macOS 14 runner image has different tools and tool versions than macOS 12. See the full list of changed software.

Please note that once your workflows run on macOS 14 using latest they will not revert to run on older image versions. If you spot any issues with your workflows when using macOS 14, please let us know by creating an issue in the runner-images repository.

See more

Customers desire clear, relevant, and actionable insights about how Actions workflows are being used in their organization. Today, we are thrilled to announce that Actions Usage Metrics is available in public beta for GitHub Enterprise Cloud plans.

Actions Usage Metrics screenshot

Time is the most important metric for DevOps and DevEx teams. The question they want answered is, “where are all my minutes going?” Actions Usage Metrics addresses this question and others by focusing on minutes used per workflow, job, repository, runtime OS, and runner type. This data helps organizations locate areas of improvement in their software delivery lifecycle, saving time and money.

Customers can filter data by any combination of workflows, jobs, repositories, runtime OS, and runner type to view total minutes, number of jobs, workflow executions, and more. All usage metrics, filtered or not, can be downloaded as a .csv file to use with your tool of choice.

By default, organization owners can access Actions Usage Metrics. However, access permissions can be granted to other members or teams using Actions fine-grained permissions. This ensures the right level of access to Actions Usage Metrics data, enabling informed decisions and improvements.

To learn more about Actions Usage Metrics, check out our docs or head to our community discussion.

See more