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

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

Run your ML workloads on GitHub Actions with GPU runners

GitHub is introducing GPU hosted runners for GitHub Actions to provide teams working with ML models to have a single platform to build, test and deploy from.

GPU accelerated Builds

GitHub enables teams working with GPU accelerated ML models as part of their applications to fully adopt Actions as their DevOps platform to test and deploy their services. These new runners empower teams working with models such as large language models (LLMs) to run these more efficiently as part of their CI/CD process, empowering teams to do complete application testing, including the ML components, in Actions.

We know that developers and data scientists love GitHub Actions. Data scientists are moving away from ‘working in isolation’ towards a model of ML Ops and trying to understand how this feeds into the wider DevOps practices of their teams.

These runners will be entering private beta in November.

Interested?

Click here to join the waitlist for the private beta.

See more

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
View more changes