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

Accelerate your CI/CD with Arm-based hosted runners in GitHub Actions

Arm-based hosted runners are coming to GitHub Actions!

Unlock the power of Arm in Actions

By leveraging the power and efficiency of the Arm® architecture, GitHub is offering a new solution that will accelerate software development in GitHub. These new capabilities empower GitHub users to shift-left software development on the Arm architecture across the embedded edge, IoT and cloud infrastructure while providing significant power, performance and sustainability improvements to all users. Developers can now take advantage of Arm hardware hosted by GitHub to build and deploy their release assets anywhere Arm’s architecture is used.

Seamlessly integrated into GitHub Actions, these runners are powered by Arm-based Ampere® Altra® processors. Preloaded with a base image that contains a foundational set of development tools to build upon, these runners are extremely versatile and can handle any embedded software project from key markets such as automotive, IoT and industrial. The benefits do not stop at the embedded edge, as non-embedded, cloud native and everything in between will benefit by reducing their carbon footprint and getting more done within existing budgets.

These runners will be entering private beta in January 2024.

“With Arm-based GitHub-hosted runners, software developers can move faster while taking full advantage of the efficient Arm architecture, from cloud to edge,” said Bhumik Patel, director of software ecosystem development, Infrastructure Line of Business, Arm. “Our partnership with GitHub allows developers to optimize their Arm-based software development workflows and leverage GitHub’s ubiquitous deployment capability to more efficiently deliver code wherever they deploy – all while reducing costs and time to market.”

Interested?
Click here to join the waitlist for the private beta.

See more

Requiring workflows with rulesets now supports the pull_request_target trigger

Starting today, in Actions workflows, the pull_request_target trigger is now supported for repository rulesets that require a successful workflow run. This is in addition to pull_request and merge_group, making pull_request_target the third workflow trigger supported by repository rulesets.

Read our recent general availability announcement to learn more about how organizations can set up policies with repository rules that require a successful workflow run before code can be merged into its repositories.

Learn more in our repository rulesets documentation and don’t forget to ask questions or leave feedback in the community discussion.

See more

Actions – Prevent self-reviews for secure deployments across Actions environments

Actions environments now makes it more secure to review and control deployments using manual approvals.

Previously, any user could trigger a workflow and also manually approve/reject a deployment job targeting a protected environment, if they are a required reviewer.

We are now introducing an option for environment admins to prevent required reviewers from self-reviews to secure deployments targeting their critical environments.
This would enforce that a different reviewer could approve and sign off the deployments, rather than the same user who triggered the run – making the deployments more secure.
Prevent self-reviews

Learn more about securing environments using deployment protection rules.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

Requiring workflows with Repository Rules is generally available

Requiring Actions workflows with Repository Rules is now generally available on GitHub.com!
Screenshot showing the add required workflow modal overtop the enabled rule inside a ruleset

Through Repository Rules, GitHub Enterprise Cloud customers can now set up organization-wide rules to enforce their CI/CD workflows, ensuring workflows pass before pull requests can be merged into target repositories. Additional settings allow for fine-tuning how the workflow file can be selected — either from a specific branch, tag, or SHA — and provide maximum control over the version expected to run.

Applying a newly created workflow policy across an organization can feel risky. To ensure confidence when enabling a workflow rule across targeted repositories, workflow rules can be put into “evaluate” mode which will validate the rule is working correctly. And don’t worry, organization administrators can even allow select roles to “break the glass” and bypass a rule when necessary.

Learn more about this release and how requiring workflows with Repository Rules can protect your repositories.

To share feedback or ask questions, join our Community Discussion!

See more

Actions – Secure deployment rollouts to protected environments based on select tag patterns

We now allow defining selected tag patterns for securing your deployments that can run against Actions environments.

Previously environments supported 'Protection Rules' for restricting deployments only for selected deployment branches. We are now enhancing this feature for securing deployments based on selected "Deployment branches and tags".

Admins who want to have more secure and controlled deployments can now specify selected tags or tag patterns on their protected environments – Ex: They could now define that only deployments triggered by tags that match the pattern of "releases/*" could deploy to their "Production" environment.
Deployment Branches and Tags

Learn more about securing environments using deployment protection rules.
For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

GitHub Actions: NODE_OPTIONS is now restricted from GITHUB_ENV

Due to security restrictions, users can no longer use GITHUB_ENV to set the NODE_OPTIONS environment variable in their workflows. Developers who have NODE_OPTIONS set as an environment variable will now receive an error: Can't store NODE_OPTIONS output parameter using '$GITHUB_ENV' command.

This change was introduced in actions/runner v2.309.0.
For more information on how to set environment variables, please see our docs here.

See more

GitHub Actions: Apple silicon (M1) macOS runners are now available in public beta!

Apple silicon (M1) hosted runners can now be used by any developer, team, or enterprise! You can try the new runners today by setting the runs-on: key to macos-latest-xlarge or macos-13-xlarge. The 12-core Intel macOS runner is still available as well and can be used by updating the runs-on: key to macos-latest-large, macos-12-large, or macos-13-large in your workflow file.

More information about using the M1 hosted runner can be found here.
To learn more about hosted runner per job minute pricing, check out the docs.

Join the Community Discussion to share thoughts and feedback.

GitHub

See more

Changes to token permission on packages

Announcing changes to permissions for packages.

We are restricting the refs REST API endpoint from accepting POSTs from users and apps that only have the permission to read and write packages. Previously, this endpoint accepted updates to both tags and branches.

If that ability is critical to your development flows you will now be required to add explicit contents permissions to create refs.

A small cohort of customers relying on this flow have been notified of these changes and will have additional time to remediate.

We appreciate your feedback in GitHub's public feedback discussions.

See more

GitHub Actions: Transitioning from Node 16 to Node 20

Node 16 has reached its end of life, prompting us to initiate its deprecation process for GitHub Actions. Our plan is to transition all actions to run on Node 20 by Spring 2024. We will actively monitor the migration's progress and gather community feedback before finalizing the transition date. Starting October 23rd, workflows containing actions running on Node 16 will display a warning to alert users about the upcoming migration.

What you need to do

For Actions maintainers

Modify your actions to run on Node 20 instead of Node 16. For guidance, refer to the Actions configuration settings.

For Actions users

Ensure your workflows use the latest versions of actions that are running on Node 20. For more information, see Using Versions for Actions.

For self-hosted runner administrators:

Update your self-hosted runners to runner version v2.308.0 or later to ensure compatibility with Node 20 actions.

See more

GitHub Actions – Force cancel workflows

Actions customers will now be able to clear stuck workflows by forcing a cancel request from the REST API. This is a new feature and the existing endpoint to cancel a workflow run will remain unchanged.

Sometimes an Actions workflow can become stuck in a state that will not respond to a cancel request. This could block other workflows from executing and would often require customers to contact GitHub Support to resolve the issue. Going forward, customers can invoke force-cancel from the REST API, which will bypass conditions that would otherwise cause the workflow execution to continue. Customers should still only use force-cancel if the workflow fails to respond to POST /repos/{owner}/{repo}/actions/runs/{run_id}/cancel.

For more details see the GitHub Actions workflow runs REST API documentation.

For questions, visit the GitHub Actions community.

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

See more

Migrate Bamboo and Bitbucket Pipeline to GitHub Actions

GitHub Actions Importer now supports migrations from Bitbucket, Bamboo Server, and Bamboo Data Center. Companies using those tools can plan, test, and automate the migration of pipelines to GitHub Actions more easily than ever before.

GitHub Actions Importer is available via the GitHub CLI or IssueOps. To get started, please visit our docs. For questions and feedback, check out the GitHub Actions Importer community.

See more

Increased Concurrency Limit for GitHub-Hosted Runners

GitHub-hosted runners now support up to 1000 concurrent jobs for our 4 – 64 vCPU runners, enhancing their capability to handle large-scale CI/CD workloads.

Our runners are designed to automatically scale to meet your needs. The concurrency limit feature allows users to specify the maximum number of jobs that can run simultaneously to execute Actions workflows. Previously capped at 250, we've made backend improvements to now support a maximum of 1000 concurrent jobs for runners within the 4-64 vCPU range for Windows and Linux operating systems.

Enterprise or organization administrators can set this concurrency limit under the Auto-scaling setting. GitHub-hosted runners with 4 or more vCPUs are available on both the GitHub Team and Enterprise plans.

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

See more

GitHub Actions – Updates to GITHUB_REF and github.ref

We have implemented a fix so that GITHUB_REF and the github.ref context value return a fully-formed ref (e.g – refs/heads/main) when a workflow is triggered as a result of a pull request being merged. This change only impacts a small subset of workflows that trigger as a result of a pull request closing after being merged and that make use of GITHUB_REF or github.ref.

Previously, GITHUB_REF and github.ref were incorrectly returning a shortened ref (e.g. – main). These should always return a fully-formed ref regardless of the scenario.

Please visit our documentation for more details about using Actions context and variables.

For questions, visit the GitHub Actions community.

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

See more

Dual Static IP ranges for GitHub-hosted Larger runners

GitHub-hosted larger runners now support dual IP ranges when configured with Static IPs for the GitHub Enterprise Cloud plan.

Static IP enables Enterprise Cloud customers to choose whether a static IP address range will be assigned to their larger runner instances. This provides a fixed IP address range that can be added to your allow list for access to internal systems and can be used in conjunction with GitHub’s IP allow list to enable hosted actions runners and IP allow listing at the same time.

With dual IP ranges, larger runner instances will now receive two IP ranges instead of a single range. This enables runners to scale beyond the previously existing 500 concurrency limit. Additionally, the two IP ranges are created in different geographical locations, providing resiliency against regional outages.

Getting started

For newly created larger runner instances with the Static IP feature, 2 IP ranges will be assigned by default going forward and no additional action is required.

For existing larger runner instances that have Static IP configured:

  • GitHub will assign an additional IP range(s) that admins can view by heading to their existing static IP enabled larger runners.
  • Admins will have 30 days to update their existing firewalls or internal IP allowlists with the new IP ranges before GitHub starts utilizing the new ranges for the runners.
  • Admins will also receive an email guiding them to take the necessary steps for their existing static IP enabled larger runners to continue to function as they switch to the dual IP range functionality.

You can learn more about the Static IP feature by heading over to documentation. If you have any feedback to help improve this experience, be sure to post it on our GitHub Community Discussion.

See more

Update to Actions usage in Enterprise Managed User namespace repositories

Enterprise Managed User namespace repositories were previously able to use GitHub-hosted Actions runners outside of the owning enterprise's entitlements. This was not an intentional configuration. Today we have disabled the ability for EMU user namespace repositories to use GitHub-hosted runners.

For customers using inner source workflows we recommend forking from an organization owned repository into your user namespace. You may then open a pull request back to the upstream repository and actions workflows will run as usual within the context of that organization and enterprise.

Learn more about enabling private repositories to run actions workflows from forks.

See more

GitHub Actions: Review network access settings for the self-hosted runners

GitHub Actions asks customers to review their network allow list for self-hosted runners according to the requirements in our documentation.

Network access to GitHub's *.actions.githubusercontent.com is essential for the self-hosted runners. Requiring wildcard access allows GitHub Actions to be flexible moving forward as we improve the service. Customers that do not allow wildcard access risk having interruptions in their GitHub Actions usage as we start enforcing this requirement on September 12, 2023. Please reach out to the customer support if you have limitations with configuring wildcard access in the on-premises firewall solution.

Learn more about GitHub Actions self-hosted runners.

For questions, visit the GitHub Actions community.

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

See more

Repository Actions Runners List

With the Repository Actions Runners List, you can now view all available runners in the Actions tab of a repository. This feature is now in public beta and will be gradually released in the upcoming weeks.

The runner types listed include Standard GitHub-hosted, Larger GitHub-hosted (for faster builds), Self-hosted, and Scale-sets.

Repository Actions Runners List

For some benefits of using the Repository Actions Runners List:

  • Visibility across all GitHub Actions runners: Users with repo:write access can now view runner options without needing to rely on internal documentation or contacting a Repo admin or an Organization owner for runner label names.
  • Faster access to runner labels: Quickly 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 the available runners for the repository and copy runner labels as needed.

Note: Enterprise and Organization owners can also create new runners from this page from the “New runner” button.

This feature is available to users with:

  • Free and Pro Personal Accounts
  • Free Organizations
  • Paid Organizations on the Team and GitHub Enterprise Cloud plans

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

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

See more

Actions runs triggered from tags or forks with the same name as a protected branch will now be blocked

GitHub environments can be configured with deployment branch policies to allow-list the branches that can deploy to them.

We are now security hardening these branch policies further by blocking runs triggered from forks with branches that match the protected branch name. We are also preventing tags with the same name as a protected branch from deploying to the environments with branch policies around protected branches.

Learn more about configuring environments with deployment protection rules to set up rigorous and streamlined guardrails for your deployments.

For questions, visit the GitHub Actions community.
To see what's next for Actions, visit our public roadmap.

See more

[Private Beta] Jenkins Scripted Pipeline Migrations

Support for migrating Jenkins Scripted Pipelines to GitHub Actions is now available as a private beta! If you use Scripted Pipelines in your Jenkins instances, you can now automate the migration of your pipelines to GitHub Actions using GitHub Actions Importer.

To get started, please reach out to your GitHub account manager or contact our sales team! For questions and feedback about the private beta, please visit the GitHub Actions Importer community.

See more

GitHub Actions: Required Workflows will move to Repository Rules

We will be moving the private beta of required workflows on GitHub Actions to Repository Rules to give organization administrators a powerful way to protect their repositories with added feature benefits including unified configuration, dry running workflow rules, branch targeting, and a consistent UI experience.

Starting September 20th, 2023, users can configure their workflows using rulesets in order to run and pass in selected repositories before merging their code. On October 18th, users will no longer be able to access Actions Required Workflows and must use rulesets in its place.

How does this impact beta users of Actions Required Workflows?

Existing Actions Required Workflows private beta users will continue to have access until October 18th, 2023, allowing them time to adapt to the forthcoming changes. During this transitional period, users will maintain their existing workflows without disruption. This ensures that organizations can smoothly navigate the migration process, avoiding any abrupt disruptions to their current code merging practices. Here’s a quick overview of the events leading up to the move.

For GHEC customers

Leading up to October 18th:

  • GitHub will attempt to automatically migrate any existing Required Workflows to Rulesets for customers.
  • Any workflow files that did not successfully migrate will need to be manually migrated by code owners.

After October 18th:

  • The ability to require a workflow to pass before merging code will only be available on GitHub Enterprise plans via Repository Rules
  • Organization Rulesets will enable administrators to define, configure, and manage all workflows required to pass before merging code in repositories.
  • The feature formally known as Actions Required Workflows will no longer be accessible and users will be directed to Rulesets.

For GHES customers by version

  • GHES 3.8 and 3.9 will not be impacted until their next upgrade
  • GHES 3.10 and 3.11 will not be impacted if Actions Required Workflows are already in use
  • GHES 3.12 Requiring a workflow to run and pass before merging will be only be available vis Repository Rulesets

To learn more about how Repository Rules can help control how people can interact with branches, visit our documentation.

See more
View more changes