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

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

Introducing the “Sustainability” category on GitHub Marketplace

We’re thrilled to announce the launch of a new category on GitHub Marketplace: Sustainability.

This new category is designed to highlight GitHub Actions and apps that focus on optimizing workflows to minimize environmental impact. Whether it’s by reducing resource consumption, streamlining builds, or enabling green practices in software development1, this is a space for creators to showcase tools that contribute to a more sustainable future.

If you’re a creator, we encourage you to tag your listings with Sustainability if you believe your app or action aligns with the above. Publishing to the Marketplace is straightforward — here’s how you can get started:

For users, this category provides a dedicated space to discover and explore tools that aim to make software development workflows more environmentally friendly. While GitHub doesn’t verify the claims made by creators in this category, we encourage you to do your own research and find tools that align with your values and needs.

Currently, the Sustainability category is a blank slate, but we’re excited to see it come to life as creators tag their listings. Visit github.com/marketplace to explore the category and check back as new tools become available.

We can’t wait to see what the community shares! 🚀🌍

  1. The Green Software Foundation defines green software as “Software that is responsible for emitting fewer greenhouse gases.” ↩
See more

Actions Get workflow usage and Get workflow run usage endpoints closing down

As part of the ongoing transition of Enterprise customers and Team plan customers to our new billing platform, the Actions Get workflow usage and Get workflow run usage endpoints will be closing down. The transition of Enterprise and Team plan customers to the new billing platform will complete by April 1, 2025.

Actions usage information is available via the billing platform usage endpoint. This endpoint summarizes Actions usage by SKU, organization, and repository, however it does not provide detailed workflow information. For more information, refer to Getting GitHub Actions billing data from the new response data.

On the new billing platform, workflow information is available in the usage report, which can be requested from the usage page. For more information, refer to Viewing usage.

Learn more about the new billing platform or share feedback on this change in the community discussion.

See more

Larger hosted runner enhancements: Edit runner size and Windows Server 4vCPU runner availability

GitHub Actions is excited to announce new enhancements to our suite of larger hosted runners.

Edit the size of a runner

Starting today, you can edit the size of your larger hosted runners. For customers using static IPs, you can size up or down while keeping your IP addresses the same. To edit your runners, follow the steps outlined in our documentation.

Windows Server 2025 4vCPU runner

We now offer Windows Server on a 4vCPU machine using the Windows 2025 image. The Windows Server 2025 image is still in public preview and subject to change. For more information on the Windows Server 2025, visit our runner-images repository. To set up a 4vCPU runner, follow the guide in our documentation.

See more

Actions: GitHub-hosted larger runner & network configuration REST APIs (GA)

Today, Actions larger runner REST APIs are now generally available. These new APIs empower you to programmatically create larger runners, assign them to a runner group, configure network settings for Azure private networking, and apply these configurations to specific runner groups.

With this release, you can now create and manage runners at scale without using the GitHub interface, saving time and reducing manual effort. Additionally, the APIs offer flexibility to apply network configurations to specific runner groups for Azure private networking, ensuring the desired configurations are available to your development teams.

For more information, please refer to the Actions API documentation and look for the new larger runner and network configuration endpoints. Come join the conversation in the community discussion and share your experience on the new APIs.

See more
View more changes