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.

Passkeys are a replacement for passwords when signing in, providing higher security, ease-of-use, and loss-protection. They are now generally available on GitHub.com for all users. By using a passkey you no longer need to enter a password, or even your username, when you sign in – nor do you need to perform 2FA, if you have 2FA enabled on your account. This is because passkeys validate your identity, as well as possession of a device, so they count as two authentication factors in one. Once enrolled, you can register a brand new passkey and upgrade many security keys to passkeys.

Screenshot of the security key upgrade prompt, asking the user if they'd like to upgrade a security key called 'fingerprint' to a passkey.

To learn more, check out our documentation "About passkeys", as well as this previous blog post from the passkeys beta announcement. If you have any feedback, please drop us a note in our public discussion – we're excited for this advance in account security, and would love to understand how we can make it better for you.

See more

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