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

Upcoming breaking changes and releases for GitHub Actions

We’re introducing new controls for automation workflows, enhancing security and flexibility for teams. Additionally, we’ve released updates to Actions runner controller designed to improve performance, customization, and compatibility with evolving deployment strategies. As part of our commitment to maintaining up-to-date infrastructure, we’re retiring older images and encouraging users to transition to newer, more efficient options.

Copilot events not automatically triggering GitHub Actions workflows is in public preview

Copilot authored events will no longer automatically trigger GitHub Actions workflows – administrators will now need to approve these workflows to run.

The approval mechanism is the same as approving runs from forks. This means that a run requiring approval will be given the action_required conclusion before any jobs are started. Users with write access in the UI or actions:write fine-grained access through the API can approve any action_required run. Any triggered workflow runs associated with the same PR in the action_required state will show up in the PR merge box for approval.

If a run is not approved after 30 days, it will be deleted.

Join the discussion within GitHub Community.

Windows Server 2019 is closing down

We’re beginning the process of closing down the Windows server 2019 hosted runner image, following our N-1 OS support policy. This image will be fully retired by June 30, 2025. We recommend updating workflows use windows-2022 or windows-2025.

To raise awareness of the upcoming removal, we’ll temporarily fail jobs using the windows-2019 label starting in June 2025. The brownouts will occur on the following dates and times:

  • June 3 13:00 – 21:00 UTC
  • June 10 13:00-21:00 UTC
  • June 17 13:00-21:00 UTC
  • June 24 13:00-21:00 UTC

Actions runner controller release 0.11.0

The latest ARC release (0.11.0) includes two major product enhancements and numerous quality-of-life improvements.

Customers can now set custom annotations and resources, enabling them to use deployment methods like ArgoCD and Helm.

In addition, ARC customers experienced performance issues due to high cardinality metrics, particularly around labels such as runner name, ID, job workflow ref, and others. This significantly impacted resource consumption in Prometheus instances. With this release, customers can now configure metrics, enabling them to choose elements relevant to their reporting strategy.

All included changes in this release can be found in the release notes.

Updates to the network allow list for Azure private networking

GitHub previously reported the network communication requirements for Azure private networks as they relate to the upcoming release of immutable actions. Please use the IPs listed in the NSG template within our documentation, as previous changelog communications contained overlapping CIDR ranges.

See more

Windows arm64 hosted runners now available in public preview

Now in public preview, Windows arm64 hosted runners are available for free in public repositories. This runner comes with a Windows 11 Desktop image, fully equipped with all the tooling you need to quickly get started running your workflows. Following the release of linux arm64 hosted runners in January, this now extends to Windows support for the open source-community. These four vCPU runners provide a power-efficient compute layer for your Windows workloads. Arm-native developers can now build, test, and deploy entirely within the arm64 architecture without the need for virtualization on your actions runs.

How to use the runners

To leverage the arm64 hosted runners, add the following labels in your public repository workflow runs:

  • windows-11-arm

Please note that this label will not work in private repositories—the workflow will fail if you add it. All runs in public repositories will adhere to our standard runners usage limits, with maximum concurrencies based on your plan type. While the arm64 runners are in public preview, you may experience longer queue times during peak usage hours.

Images for arm64 larger runners

In partnership with Arm, there is now a Windows 11 desktop arm64 image with preinstalled tools available for all GitHub runner sizes, including both the new free offering and our existing arm64 larger runners. To use the new image on larger runners, you can create a new runner and select the Microsoft Windows 11 Desktop by Arm Limited image in the Images console.

To view the list of installed software, give feedback on the image, or report issues, visit the partner-runner-images repository.

Get started today!

To get started building windows on arm64 for free, simply add the new label to the runs-on syntax in your public actions workflow file. For more information on arm64 runners and how to use them, see our documentation and join the conversation in the Community discussion.

See more

GitHub Actions: macOS 15 and Windows 2025 images are now generally available

macOS 15 and Windows 2025 images are now generally available for all GitHub-hosted runners. You can use these images in your workflows on GitHub-hosted standard or larger runners.

Get started today

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

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

To use Windows 2025, you can target the image directly on standard runners using runs-on: windows-2025. For larger runners, create a runner and select Windows Server 2025 in the Images UI console.

The latest tag will migrate to these images later in the year.

Need support?

Keep in mind that the new runner images have different tools and tool versions than previous versions. To view the full list of software or report issues with your workflows when using the images, visit the runner-images repository.

See more

GitHub Actions hosted runner fleet now includes 96 vCPU larger runner

GitHub Actions 96 vCPU larger runners are now generally available. Customers in need of bigger, more powerful machines to run their workloads can use this runner to reduce runtime on their longer GitHub Actions builds.

This runner is an x64 machine and you can use any of our existing GitHub-owned Linux and Windows images on these runners. Our entire advanced feature set works with the new runner: static IPs, network configurations, autoscaling, and runner groups.

What are the machine specs?

  • vCPU: 96
  • RAM: 384 GB
  • SSD: 2040 GiB

Get started today

To get started, create a new, larger runner and choose the 96-core option in the Size console in the UI. Learn more about how to set up larger runners in our documentation. For pricing information on these larger runners see the billing for GitHub Actions page.

See more

Pull request merge experience – April 3 update

Today we’re announcing recent fixes and enhancements to the improved pull request merge experience that became generally available earlier this month.

🆕 Status checks grouping preference

You can now choose to show the list of status checks as a single flat list or grouped by status. Click the settings gear and choose either “Group by status” (the default) or “No grouping“.

Image showing the new merge experience status checks section expanded with a new settings gear menu opened and showing 2 options for controlling how status checks are grouped (no grouping or grouping by status)

Recent fixes

Some of the noteworthy fixes that have landed in the last few weeks:

  • The time since a status check started (e.g. Started 2s ago) now updates consistently.
  • The Draft section was previously hidden for users without write access, making it difficult to know that the pull request was not ready for review.
  • A tooltip was previously not appearing when hovering over a truncated status check’s name, making it difficult to differentiate status checks with similar, long names.
  • Various fixes related to updating the pull request branch by rebasing.
  • Various improvements to performance, especially when there were a significant number of status checks.

Get help

To ask questions or provide feedback, join the discussion within GitHub Community.

See more

Enterprise custom properties, enterprise rulesets, and pull request merge method rule are all now generally available

An image on a dark background with collaboration-themed colors, showcasing GitHub products. In the forefront, enterprise rulesets and custom properties are highlighted alongside a side angled profile of Mona the Octocat.

Enterprise custom properties and enterprise rulesets are now generally available, further improving the governance features for GitHub Enterprise customers.

Enterprise custom properties

With enterprise-level custom properties, you can now enrich your repositories with metadata across your entire enterprise. This ensures consistent properties across organizations without the need for manual synchronization. By sharing a common namespace, enterprise and organization properties prevent confusion when searching or targeting rulesets with properties. If you’re already using custom properties in your organizations, you can also promote those properties to the enterprise.

Learn more about enterprise custom properties in our documentation.

Enterprise rulesets

Enterprise-level rulesets enforce consistent code governance rules, helping ensure thorough reviews of critical repositories with pull requests, requiring actions workflows, protecting important locations from unauthorized pushes, and more. Rule insights and push rule bypasses are also available at the enterprise level, providing complete visibility into the rulesets.

Learn more about enterprise rulesets in our documentation.

We look forward to seeing how you leverage these new capabilities to streamline your workflows and maintain high standards of code governance.

Pull request merge method rule

An image of GitHub products displayed against a dark collaboration-themed background. In the foreground, there is text saying "Pull request merge method rule generally available", with Mona the Octocat looking at the title in a side-angled profile image.

The new pull request merge method rule is now generally available using whatever method is suitable for your branches, such as ensuring that all changes are squashed when merging to the default branch while rebasing into feature branches. This simplifies your workflows, ensuring consistency across your branches.

The merge method rule is available for rulesets at the repository and organization level. You can use this rule to choose what merge methods are allowed on the targeted branches when merging pull requests from the user interface or APIs. You can choose between merge commit, squash, or rebase.

Learn more in our documentation and join the discussion within the GitHub Community.

See more

Notification of upcoming breaking changes in GitHub Actions

Decommissioned cache service brownouts

GitHub has migrated customers to a new cache service and will now be shutting down the old service. This process will include brownouts of the old service before turning it off completely on April 15th, 2025. If your Actions workflows are still hitting the old cache service, your workflows may fail during these brownouts.
The brownout dates and times are as follows:

  • April 1, 2025, 3 p.m. – 7 p.m. UTC
  • April 8, 2025, 2 p.m. – 10 p.m. UTC

You may still be using the old service if you’re interacting with the cache in one of the following ways:

  1. Using a third party action (i.e. not actions/cache) or product that uses an actions cache service to perform caching. In this case, you may need to upgrade to the latest version. Examples: mozilla/sccache, Mozilla-Actions/sccache-action, Docker with GitHub Actions as a caching backend
  2. Using a runner version older than 2.320.1
  3. Have manually changed (edited or removed) any of the environment variables below:
    • ACTIONS_CACHE_URL
    • ACTIONS_RESULTS_URL
    • ACTIONS_RUNTIME_TOKEN
    • ACTIONS_CACHE_SERVICE_V2

Modification to deployment permissions

GitHub is modifying how deployment permissions operate. Those with the deployment: read fine-grain permission can currently review, approve, or reject deployments.

As of April 1, 2025, GitHub will require the deployments: write permission to review, approve, or reject a deployment. Please update any impacted fine-grain PATs to provide write access where needed. Impacted customers were contacted via email in early March 2025.

Failure to update your fine-grained PATs by April 1, 2025 will result in the inability to review, approve, or reject deployments.

See more

GitHub Actions now supports a digest for validating your artifacts at runtime

Developers using upload-artifact and download-artifact in their Actions workflows can now ensure the integrity of their artifacts with the new SHA256 digest. This feature automatically verifies that the artifact uploaded is identical to the one downloaded, providing security for Actions runs and ensuring the artifact remains unchanged.

How it works

Whenever upload-artifact is used, it now computes and stores an output called digest. This is the SHA256 digest of the artifact uploaded during the run.

When download-artifact is used to download that same artifact, it uses the same process to compute a digest for the downloaded file and compares the two digests to validate that they match.

If a mismatch is detected, the run displays a warning in the UI and in the job logs. The workflow won’t fail if the digests don’t match, but this may change in a future release.

Note: This functionality is only available with artifacts v4 or newer. It’s also not currently available on GitHub Enterprise Server.

Where can I view the digest?

The digest will appear in the logs of the workflow run under the “upload-artifact” step. They’ll also appear in the Artifact output that appears in the workflow run UI.

Learn more

To get started using the artifacts actions view our documentation on storing and sharing data from a workflow.

See more

Actions Performance Metrics are generally available and Enterprise-level metrics are in public preview

Performance Metrics for GitHub Actions are now generally available for repositories and organizations. Repository members can view workflow and job performance data including queue times and failure rates going back as far as one year. Organization members can also view this data aggregated across all repositories in their organization. These metrics are available on all GitHub Cloud plans.

In addition, usage and performance metrics aggregated at the Enterprise level are now available in public preview to Enterprise admins. This includes usage metrics (ex. jobs run and minutes used), as well as performance metrics (ex. job failure rates and queue times) across all repositories and organizations in an enterprise. These metrics can be found in the Enterprise UI under the “Insights” tab.

Screenshot of Enterprise Actions usage metrics in the Enterprise Admin UI

See more

Improved pull request merge experience is now generally available

The improved merge experience on the pull request page is now generally available! This update is designed to help you better understand the state of your pull request and get it merged faster.

Screenshot of the updated merge box page on the pull request page showing it is approved, a list of status checks (some failing), and a message about not having any merge conflicts.

This experience supports all the usual ways of merging: direct, bypass and merge, auto-merge, and merge queue, and works with rulesets to ensure pull requests meet all the requirements to merge.

What’s new

The new experience is designed to feel familiar, but also improves on the previous experience. Here are some highlights:

  • Checks grouped by status: checks are now grouped by status with failing checks prioritized at the top of the list, making it easier to identify problems that need attention
  • Checks ordered logically: status checks are now ordered using natural ordering to make it easier to find a specific check, especially when the list gets long
  • Improved rule enforcement: errors resulting from failing commit metadata rules (like invalid commit messages) are now reported at the point of merging so they can be corrected
  • Improved accessibility: consistent keyboard navigation, focus management, and landmarks help make the experience more accessible to everyone

Get help

Learn more about merging a pull request.

To suggest a feature, report a problem, or discuss this improved experience, visit the GitHub Community.

See more

Edit the GitHub-owned image on a larger hosted runner

Starting today, customers can change the runner image on larger hosted runners without deleting and re-creating them. You can now update the image and the change will be applied on all future workflow runs to that label. For customers using static IPs, you can change the image on your runner while keeping your IP addresses the same.

Note: partner images cannot be edited at this time and still require the runner to be deleted and re-created.

To edit your runners, follow the steps outlined in our documentation.

See more

Repositories – Enterprise rules and custom properties updates

Enterprise rules and custom properties are getting updates as part of the current public preview, as well introducing a new search and filter experience for custom properties.

Custom properties

Screenshot depicting new filter options available

There are new search and filtering options for custom properties now generally available to ensure you can easily find the right property.

  • Managed by allows you to limit your result by the organization or enterprise who manages the property.
  • Property type allows you to limit your result by the available type of properties.
  • Text allows you to limit your result by the context of the property name or values.

Enterprise custom properties

Screenshot of custom property promotion screen

Enterprise custom properties as part of the current preview can now be promoted from an organization to an enterprise property. This ensures properties configured in one organization are available across all organizations in an enterprise.

Enterprise code rulesets

Screenshot of configuring enterprise workflow rule

Required workflows are now available as a new rule in the enterprise code rules preview. This will allow you to target workflows across specific organizations and repositories with a single workflow file managed at the enterprise.

Note: GitHub Enterprise Cloud with data residency support for the enterprise workflow rule will be coming soon.

Join the discussion within GitHub Community.

See more

Recent improvements to Artifact Attestations

We released a collection of improvements to Artifact Attestations to make the verification of attestations easier and more consistent.

Artifact Attestations let you create provenance signatures, which provide an unforgeable paper trail that links your artifact back to its originating workflow run. By verifying the signature, you can gate deployments to ensure that what you deploy is exactly what you built, guaranteeing that the artifact has not been tampered with.

Today we are announcing multiple improvements based on the user feedback we have received:

  • Attestation verification defaults to build provenance: Build provenance is just one type of information that can be attested to an artifact. It provides a verifiable trail that links the artifact back to its originating workflow run, ensuring its authenticity and integrity. However, other types of information can also be attested to an artifact, for example a Software Bill of Materials (SBOM). Attestations can be verified by running gh attestation verify using the GitHub CLI. Previously, verification succeeded as soon as there was any attestation associated with the artifact. However, we observed that provenance is verified in the vast majority of cases. Therefore, we altered the CLI to default to provenance when no predicate type is specified. This change ensures that verification does not pass merely because, for example, an SBOM was attested to the artifact. To verify an SBOM, the predicate type must be explicitly supplied as a parameter using gh attestation verify with the --predicate-type parameter.
  • CLI outputs evaluated policies during verification: When verifying an attestation, the CLI now outputs all the policies it evaluated to determine whether the verification succeeds or fails. This increases transparency, making it easier to understand the reasons behind the verification outcome.
  • Attest actions support multiple subjects: Following the release to support attesting multiple subjects, we have enhanced our attest, attest-build-provenance and attest-sbom actions to also accept a checksum file that contains a list of artifacts and their corresponding digests as input.
  • Attestation verification is now monotonic: This means that once verification passes for an artifact, the addition of another attestation cannot change that status. Verification now succeeds if at least one attestation passes verification. This ensures that downstream processes, such as gated deployments, are not affected for any legitimate build that has a valid provenance attestation, even if someone adds another attestation that is bad or malformed.

For more information about Artifact Attestations, see Using artifact attestations to establish provenance for builds in the GitHub documentation. If you have any feedback on Artifact Attestations, join the discussion in the GitHub Community.

See more

Improved pull request merge experience enabled by default in public preview

The improved merge experience on the pull request page announced in December will be enabled by default over the next few days! The feature remains in public preview while we address feedback (keep it coming!) and make final improvements before making it generally available later this quarter.

Screenshot of the updated merge box page on the pull request page showing that 1 review is required, a list of status checks (some failing), and a message about not having any merge conflicts.

This improved experience, while still familiar, is designed to help you better understand the state of your pull request and get it merged faster. To learn more, see the public preview announcement.

Recent fixes

There have been numerous bugs fixed and feature gaps filled since the public preview launched last year. Here are some notable fixes:

  • Fixed: Enabling auto-merge, deleting branch (after merging), or restoring branch previously failed with an unexpected error message.
  • Fixed: In certain scenarios, the commit author email address shown when merging the pull request would not match the email address in the resulting merge (or squash) commit.
  • Fixed: GitHub Actions workflow runs could only be approved from the classic merge experience.
  • Fixed: Status check durations were missing.

We’ve also made various improvements, including natural ordering for status checks. For a more complete list, see the recently fixed section of this discussion.

How to turn it off

To switch back to the classic experience, click the Switch back to the classic merge experience just below the merge experience on the Conversation page:

A screenshot showing how to switch back to the classic merge experience

If you want to return to the improved experience, click Try the new merge experience below the merge box on the pull request page:

A screenshot showing how to re-enable the improved merge experience

You can also toggle the experience via the feature preview dialog.

How to provide feedback

We want to hear from you! To provide feedback, ask questions, and see a list of known issues, visit the GitHub Community improved merge box discussion.

See more

Notice of upcoming deprecations and breaking changes for GitHub Actions

Update: Additional brownout dates for Ubuntu 20 were added in April. The following post has been updated to reflect this change.

Changes to check run status modification

To ensure the trustworthiness and security of Actions Check Run results, developers will soon lose the ability to modify the conclusion and status of an Actions-created check run using the GitHub token from a workflow run. This change will take effect on March 31, 2025. Impacted workflows will start displaying annotations during the week of February 17, 2025.

Updates to the network allow list for self-hosted runners and Azure private networking

In preparation for the public preview of consuming Immutable Actions in February 2025, GitHub has started migrating standard hosted runner customers to immutable actions. There is no action required on your end. This means GitHub Actions will use as an immutable action where available and will default to traditional actions resolution where none exist.

For customers using self-hosted runners, please ensure your self-hosted runner allow lists are updated to accommodate the network traffic. Specifically, you should allow traffic to pkg.actions.githubusercontent.com to ensure immutable actions can be downloaded successfully and jobs don’t fail during setup. If you already allow *.actions.githubusercontent.com (which is listed as a required domain) then no action is necessary. You will also need to enable traffic to ghcr.io for publishing new versions of an immutable action in the future, which will be available with the GA release.

Customers who have not updated their allow lists will automatically be opted out from using immutable actions during the migration. Once GitHub confirms that the runners have been updated, you will automatically be opted back in once the allow lists are updated. If you need to manually opt out or in for using immutable actions, please contact support.

This update also affects runners in all versions of GitHub Enterprise Server that use the GitHub Connect feature to download actions directly from github.com. Customers are advised to update their self-hosted runner network allow lists accordingly. For further guidance on communication between self-hosted runners and GitHub, please refer to our documentation.

Additionally, we’ve updated our guidance for configuring Azure private networking to account for the new domains. The following IP addresses have been added to the NSG template in our documentation.

– 140.82.121.33/32
– 140.82.121.34/32
– 140.82.113.33/32
– 140.82.113.34/32
– 140.82.112.33/32
– 140.82.112.34/32
– 140.82.114.33/32
– 140.82.114.34/32
– 192.30.255.164/31
– 4.237.22.32/32
– 20.217.135.1/32
– 4.225.11.196/32
– 20.26.156.211/32

Ubuntu 20 image brownouts

To raise awareness of the upcoming removal of Ubuntu 20, we will temporarily fail jobs using the ubuntu-20.04 label starting in March 2025. The brownouts will occur on the following dates and times:

  • March 4 14:00 UTC – 22:00 UTC
  • March 11 13:00 UTC – 21:00 UTC
  • March 18 13:00 UTC – 21:00 UTC
  • March 25 13:00 UTC – 21:00 UTC
  • April 1 13:00 UTC – 21:00 UTC
  • April 8 13:00 UTC – 21:00 UTC

actions/cache v1-v2 and actions/toolkit cache package brownouts

To raise awareness of the upcoming removal, we have scheduled brownouts for the following dates/times, Actions jobs referencing a deprecated verion of the Cache action will fail.

  • February 18, 2pm – 10pm UTC
See more
View more changes