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

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

GitHub Actions – New dashboard view for deployments across environments (public beta)

Today, we are announcing public beta of the new experience for deployments across environments. 🎉

Developers and DevOps managers can now view and track the full history of deployments in a repository or filter them across environments to:

  • view active deployments across various environments and navigate to the deployment URLs or
  • understand who and what commits, PRs triggered a deployment in a given environment or
  • monitor the deployment status and duration of deployments or
  • trace any deployment to its source workflow and view logs to diagnose any issues or review any pending approvals etc.

New Deployment views

Learn more about viewing deployments in your repository through our documentation and watching this video.

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

See more

GitHub Actions: Update on save-state and set-output commands

On October 11, 2022, we annouced plans to deprecate the save-state and set-output workflow commands on May 31, 2023. We have since decided to postpone the removal given the amount of usage we are still seeing with these commands.

Workflows using save-state or set-output in their workflows will continue to work as expected, however, a warning will appear under annotations indicating the planned deprecation. We recommend customers using these commands to upgrade their workflows to use environment files.

For more information on environment files, please check out our documentation. To see what's next for Actions, visit our public roadmap.

See more

GitHub Actions: Removal of Node12 from the Actions runner

Node12 has been out of support since April 2022. As a result we started the deprecation process of Node12 for GitHub Actions by migrating all actions to run on Node16 on June 14th.
We have seen no major issues reported and a minimal number of people opted out of the forced upgrade to Node16. Given this, we will remove Node12 from the Actions runner on the 14th of August 2023.

What you need to do

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

See more

GitHub Actions – OIDC integration with AWS no longer requires pinning of intermediate TLS certificates

GitHub Actions – OpenId Connect (OIDC) integration with AWS is now optimized to avoid pinning any intermediary certificate thumbprints.

While configuring GitHub as an OIDC IdP (ID Provider), AWS now secures communication by trusting GitHub Actions’s trusted root certificate authorities (CAs) instead of using a certificate thumbprint to verify GitHub’s IdP server certificate.
This will address and avoid any issues caused due to pinning certificate thumbprints while authenticating from GitHub to AWS using OIDC. No action is needed for GitHub customers.

Learn more about using OIDC with GitHub Actions.

See more

GitHub Actions – Update on OIDC integration with AWS

We have received customers reporting errors with Actions’ OIDC integration with AWS.
This happens for customers who are pinned to a single intermediary thumbprint from the Certificate Authority (CA) of the Actions SSL certificate.

There are two possible intermediary certificates for the Actions SSL certificate and either can be returned by our servers, requiring customers to trust both. This is a known behavior when the intermediary certificates are cross-signed by the CA.

Customers experiencing issues authenticating via OIDC with AWS should configure both thumbprints to be trusted in the AWS portal.
The two known intermediary thumbprints at this time are:

  • 6938fd4d98bab03faadb97b34396831e3780aea1
  • 1c58a3a8518e8759bf075b76b750d4f2df264fcd

Learn more about using OIDC with GitHub Actions.

See more

GitHub-hosted larger runners for Actions are generally available

Today, we are announcing that larger hosted runners for GitHub Actions are generally available for paid Team and Enterprise Cloud plans! This feature has been in public beta since September of 2022 where customers have been using it in production to run their CI/CD jobs faster and with more flexibility.

larger runner machine sizes

The new larger runners provide new capabilities:

  • Larger Linux and Windows machines: This allows development teams to use machine sizes up to 64 vCPUs with 256 GB of RAM, and 2 TB of SSD storage to support their on-demand CI/CD jobs and other workflows. Larger runners are charged by the job minute for both private and public repositories and do not consume included minutes.
  • Static IP address to enable secure access to your resources: Enterprise Cloud customers can now choose whether a static IP address range will be assigned to their larger runner instances. This provides a fixed IP address range that you can add to your allow list for access to internal systems. You can also use this in conjunction with GitHub’s IP allow list to enable hosted actions runners and IP allow listing at the same time.
  • Administrative control over access to larger runners and concurrency: Your administrators can decide who has access to larger machine sizes and at what concurrency, providing guard rails on spending.

You can learn about the larger runner per job minute pricing by checking the current pricing documentation and learn more about this feature by digging into the documentation.

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

See more

GitHub Actions – Securing OpenID Connect (OIDC) token permissions in reusable workflows

For securely enabling OpenID Connect (OIDC) in your reusable workflows, we are now making the permissions more restrictive.

If you need to fetch an OIDC token generated within a reusable (called) workflow that is outside your enterprise/organization, then the permissions setting for id-token should now be explicitly set to write at the caller workflow level or in the specific job that calls the reusable workflow.

permissions:
id-token: write # This is required for requesting the JWT

This change would ensure that the OIDC token generated in the called workflow is allowed to be consumed in the caller workflows only when intended.

Learn more about permission settings to enable OIDC in your workflows

See more

Fix to improve security around creation of pull requests in public repos

We've shipped a small fix to improve security around creation of pull requests in public repos.

Prior to this fix and under very specific conditions, a user could create a pull request in a public repo even though they did not have push access to either the base or head branch and were not a member of the repo's organization. Often these pull requests were created by mistake and quickly closed, but could still trigger unexpected GitHub Actions or other CI jobs.

This fix has no impact on the common open source workflow where a user forks a public repo, makes a change in their fork, and then proposes their change using a pull request. This fix also has no impact on pull requests already created.

We want to hear from you! Let us know if you have questions or feedback.

See more

GitHub Actions: All Actions will run on Node16 instead of Node12 by default

Node12 has been out of support since April 2022. As a result we have started the deprecation process of Node12 for GitHub Actions. We plan to migrate all actions to run on Node16 by Summer 2023.
Following on from our warning in workflows using Node12 we will start enforcing the use of Node16 rather than Node12 on the 14th of June.

To opt out of this and continue using Node12 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 Node12 later in the summer.

What you need to do

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

See more

GitHub Actions: You can now disable repo level self-hosted runners in an Enterprise and Organization

Enterprise administrators can now disable repository level self-hosted runners across organizations and enterprise user namespaces.

Once this new setting has been enabled users will no longer be able to register new self-hosted runners in a repository and existing runners will not be able to receive new jobs.

Learn more about Disabling or limiting GitHub Actions for your organization

See more

GitHub Actions – Just-in-time self-hosted runners

You can now create single-use self-hosted runners without time-limited registration tokens using the REST API.

When a runner registers using this API it will only be allowed to run a single job before being automatically removed from the repository, organization, or enterprise. This enables you to improve the security of your self-hosted runner infrastructure by limiting the exposure of long lived credentials.

Learn more about just-in-time runners

See more
View more changes