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

Dependabot Updates on Actions for GitHub Enterprise Cloud and Free, Pro, and Teams Users

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 self-hosted runners, larger runners, and actions runner controller (ARC) be supported?

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

Deprecation of multi-label larger runners

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 and jobs targetting more than one label for a 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.

See more

Deprecation notice: v3 of the artifact actions

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

GitHub-hosted runner images deprecation notice: Docker Compose v1

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

GitHub Actions: Hardware accelerated Android virtualization now available

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

What’s new for GitHub Actions hosted runners

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 generally available

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

Actions Usage Metrics public beta

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

GitHub Actions; All Actions will run on Node20 instead of Node16 by default

Node16 has been out of support since September 2023. As a result we have started the deprecation process of Node16 for GitHub Actions. We plan to migrate all actions to run on Node20 by Spring 2024.
Following on from our warning in workflows using Node16 we will start enforcing the use of Node20 rather than Node16 on the 13th of May.

If you would like to test this ahead of timer, you can choose to set
FORCE_JAVASCRIPT_ACTIONS_TO_NODE20=true
as an ‘env’ in their workflow or as an environment variable on your runner machine to force the use of Node20 now.

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
as an ‘env’ in their workflow or as an environment variable on your runner machine. This will only work until we upgrade the runner removing Node16 later in the spring.

Removal of Operating System support for non-Node20 OS versions

To support this change, we will be removing the Action runner support for the following operating systems which do not have official support for Node20:
– Red Hat Enterprise Linux 7
– CentOS 7
– Oracle Linux 7
– Debian 9
– Ubuntu 16.04
– Linux Mint 18
– openSUSE 15
– SUSE Enterprise Linux (SLES) 12 SP2
– Windows 7 64-bit
– Windows 8.1 64-bit

To find out more about our currently supported OS versions, please read our public docs

What you need to do

For Actions maintainers: Update your actions to run on Node20 instead of Node16 (Actions configuration settings)
For Actions users: Update your workflows with latest versions of the actions which runs on Node20 (Using versions for Actions)

See more

Actions Fine Grained Permissions

We’ve enhanced Custom Organization Roles by adding fine-grained permissions for GitHub Actions. Now, with Enterprise Cloud plans, organization owners can assign members and teams specific permissions for managing various aspects of Actions, including:

  • Actions general settings
  • Organization runners and runner groups
  • Actions secrets
  • Actions variables

These additional settings allow organization owners to delegate CI/CD automation management responsibilities to individuals or teams without granting access to any other organization owner privileges.

Please refer to our documentation for more detail about GitHub Actions fine grained permissions with Custom Organization Roles.

See more

Deprecation notice: v1 and v2 of the artifact actions

On December 14, 2023, GitHub Actions released v4 of the actions to upload and download artifacts. This version improves upload/download speeds by up to 98%, addresses long-standing customer feedback requests, and represents the future of artifacts in GitHub Actions.

With the introduction of v4, we will be deprecating v1 and v2 of actions/upload-artifact, actions/download-artifact, and related npm packages on June 30, 2024. We strongly encourage customers to update their workflows to begin using v4 of the artifact actions.

In order to prevent issues for customers using GitHub Connect, the tags for v1 through v2 will not be removed from the actions/upload-artifact and actions/download-artifact project repositories. However, attempting to use a version of the actions after the announced deprecation date will result in a workflow failure. 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

GitHub Actions: macOS 14 (Sonoma) is now available

The macOS 14 runner image is now available for GitHub hosted runners. Workflows executed on this image will run exclusively on the 3 vCPU M1 runner announced earlier today. To use the runner, simply update the runs-on: key in your YAML workflow file to macos-14, macos-14-xlarge, or macos-14-large.

The macOS 12 runner image will remain latest until migration of the latest YAML workflow label to macOS 14 in Q2 FY24 (April – June 2024). While macOS 13 is now generally available under the macos-13 label, this image will not be migrated to latest. Following this announcement, macOS 11 runner image will begin deprecation immediately with retirement expected to complete by June 2024.

The full list of software available for all macOS runner images can be found here. If there is software you require that is not installed on the image, please create an issue in the runner-images repository.

See more

GitHub Actions: Introducing the new M1 macOS runner available to open source!

Today, GitHub is excited to announce the launch of a new M1 macOS runner! This runner is available for all plans, free in public repositories, and eligible to consume included free plan minutes in private repositories. The new runner executes Actions workflows with a 3 vCPU, 7 GB RAM, and 14 GB of storage VM, which provides the latest Mac hardware Actions has to offer. The new runner operates exclusively on macOS 14 and to use it, simply update the runs-on key in your YAML workflow file to macos-14.

See more

GitHub Actions – Repository Actions Runners List is now generally available

The Repository Actions Runners List is now generally available. With the Repository Actions Runnners List you can view all available runners right within the Actions tab, without needing access to repository or organization settings.

The runner types listed include Standard GitHub-hosted, Larger GitHub-hosted, Self-hosted, and Scale-sets.

Benefits of using the Repository Actions Runners List:

  • Visibility into all GitHub Actions runners: Users with repo:write access can now view which runner options are available for use within a repository, without needing to contact a Repo admin or an Organization owner to find runner label names.
  • Faster access to runner labels: Conveniently view and copy labels for all runners, making it straightforward to identify the type of runner you need and use it in a workflow.

To access the Repository Actions Runners List:

  1. Navigate to the main page of the repository.
  2. Click the "Actions" tab under your repository name.
  3. Under the "Management" section in the left sidebar, click on "Runners".
  4. Explore available runners within a repository and copy runner labels to use them in YAML workflow files.

Note: Enterprise and Organization owners can also create new runners from this page from the "New runner" button.
Repository Actions Runners List

This feature is available to users with:

  • Free and Pro Personal Accounts
  • Organizations on a Free Plan
  • Organizations on a Team Plan
  • Enterprises on a GitHub Enterprise Cloud plan (including Enterprise Managed Users)

Note: This feature is not available to users in Organizations on the GitHub Enterprise Server or Legacy plans.

If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.

See more

Reduce job queue times with newly updated ‘min’ attribute in Action-Runner-Controller

The min attribute in Action-Runner-Controller is now updated to enhance system responsiveness and efficiency. Previously, the min attribute was focused on determining the minimum number of runners that the system could scale down to during periods of inactivity. This meant that when there were few to no jobs running, the system would maintain this minimum number of runners, which could be either active or idle.

The new behavior of the min attribute shifts focus to maintaining a minimum number of idle runners at all times. This means that even when there are many jobs in progress, the system will ensure that a certain number of runners are always idle and ready to immediately take on new jobs. This change allows for smoother handling of incoming jobs, reducing wait times and improving overall job processing efficiency.

See more

GitHub Actions – Artifacts v4 is now Generally Available

We listened to your feedback and released new versions (v4) of actions/upload-artifact and actions/download-artifact. While this version of the artifact actions includes up to 10x performance improvements and several new features, there are also key differences from previous versions that may require updates to your workflows.

  • Artifacts will be scoped to a job rather than a workflow. This allows the artifact to become immediately available to download from the API after being uploaded, which was not possible before.
  • Artifacts v4 is not cross-compatible with previous versions. For example, an artifact uploaded using v3 cannot be used with actions/download-artifact@v4.
  • Using upload-artifact@v4 ensures artifacts are immutable, improving performance and protecting objects from corruption, which would often happen with concurrent uploads. Artifacts should be uploaded separately and then downloaded into a single directory using the two new inputs, pattern and merge-multiple, available in download-artifact@v4. These objects can then be re-uploaded as a single artifact.
  • A single job can upload a maximum of 500 artifacts.

Customers will still be able to use v1 – v3 of the artifact actions. If you wish to upgrade your workflow to use v4, please carefully consider the impact the aforementioned major version changes will have on your project and any downstream dependencies.

Artifacts v4 is only available to GitHub.com customers today but we will be extending support to GitHub Enterprise Server (GHES) customers in the future.

To learn more about what is included in v4, visit the actions/upload-artifact and actions/download-artifact repositories.

See more

GitHub Actions – Enforcing workflow scope when creating a release

Starting today, apps and tokens used to create a release via the REST API endpoint will require the workflow scope or workflows:write permission in certain cases.

The workflow scope or workflows:write will be required when creating a release that targets a commit SHA (target_commitish) that modifies an Actions workflow file and that SHA does not have an existing ref (branch head or tag).

For more details see the REST API documentation or visit the GitHub Actions community if you have any questions.

See more

Azure private networking for GitHub-hosted runners – Public Beta

Today we're announcing that Private Networking for GitHub-hosted runners with Azure Virtual Networks (VNET) is now in public beta. This feature allows GitHub Enterprise customers using Azure to integrate their GitHub-hosted runners directly into an Azure VNET under their Azure account.

Key Benefits

What sets this apart is the dual advantage it offers. On one hand, you can continue to enjoy the benefits of GitHub-managed resources. On the other hand, you gain full control over the networking policies applied to those resources. Once your GitHub-hosted runners are connected to your Azure VNET, your Actions workflows can securely access Azure services like Azure Storage and on-premises data sources such as artifactory through existing, pre-configured connections like VPN gateways and ExpressRoutes.

Security is also front and center in this update. Any existing or new networking policies, such as Network Security Group (NSG) rules, will automatically apply to GitHub-hosted runners giving platform administrators comprehensive control over network security.

To further simplify the management of Azure private networking settings across different business units, we're introducing Network Configurations. This feature allows administrators to consolidate various networking settings and assign them to runner groups based on specific operational needs. For example, production-grade runners can be configured with stricter networking policies using a dedicated Azure VNET, as opposed to runners used for testing or staging environments.

image

Starting today, Azure Private Networking and Network Configurations are available in public beta for GitHub Enterprise Cloud users. To get started, navigate to the 'Hosted Compute Networking' section within your Enterprise settings. For more details, consult our documentation.

We're eager to hear your feedback to further improve this feature. Share your thoughts on our GitHub Community Discussion.

See more
View more changes