node24 upgrade to v1 tag and no breaking changes?

With this commit
c4cd38d
you upgraded to node24
but this lead to errors on self hosted runners

Download action repository 'ruby/setup-ruby@v1' (SHA:866b91cc020931c510d42e43e498a7f07d335f60)

Error: System.ArgumentOutOfRangeException: Specified argument was out of the range of valid values. (Parameter ''using: node24' is not supported, use 'docker', 'node12', 'node16' or 'node20' instead.')
   at GitHub.Runner.Worker.ActionManifestManager.ConvertRuns(IExecutionContext executionContext, TemplateContext templateContext, TemplateToken inputsToken, String fileRelativePath, MappingToken outputs)
   at GitHub.Runner.Worker.ActionManifestManager.Load(IExecutionContext executionContext, String manifestFile)
Error: Failed to load ruby/setup-ruby/v1/action.yml

I’ve encountered the same issue. Pinning to this version worked as a temporary fix:

- uses: ruby/setup-ruby@v1.258.0

We also encountered the node24 error on our self hosted runners based off ubuntu's 22.04 image (ami-0655cec52acf2717b) and github runner version 2.323.0. Using a github managed ubuntu-latest runner for the job worked for some things that don't need to be run in our hosted env but this isn't a feasible solution for all tasks. Pinning the version to v1.258.0 also works but not v1.258, please consider additional tags for releases so that patch versions can be used for less strict version pins.

In addition to what was said above I think it's worth to reconsider ASAP the versioning idea applied to this repo.

Having v1 really mean latest isn't intuitive at all. It's very unexpected to have a "version 1" action suddenly break. This is causing some havoc in our org as many of our workflows depend on setup-ruby and we never assumed a v1 would imply latest.

Take for example the checkout action: https://github.com/actions/checkout — their v5 version is the one that upgrades Node.

Isn't this error a reminder that you need to update the self-hosted runner?
Isn't there a way to keep self-hosted runners automatically updated?
If not, how often do you update your self-hosted runners?

How would a major version bump help? You would see the issue slightly later, but is that helpful?
The way I see is it would cause a ton of churn for users using @v1 to update to @v2 and notice @v1 is no longer maintained, and frustration when it doesn't work when the self-hosted runner is outdated.
I guess it would give you a bit more time to update the self-hosted runners without breaking existing workflows? But at the same time prevent updating actions to their latest version too (and e.g. then prevent using latest Ruby releases, which could then imply using a version with known security issues, is that what you want?).

In this action we have transitioned from node 12->16 and 16->20 without a major version bump and had no issues.
I think a major version doesn't make sense here, from a workflow POV there is 0 incompatible change.
It's only incompatible for outdated self-hosted runners, which anyway will need to be updated sooner or later (if they are never updated I'm pretty sure many actions would stop working, regardless of node versions).

If there a way for an action to not restrict which node version it runs on (or e.g. >=20) and a way to test on different node versions I would be interested.
The closest thing I know of is ACTIONS_RUNNER_FORCE_ACTIONS_NODE_VERSION which you may be able to use for your self-hosted runners, see actions/runner#1911.

Take for example the checkout action: https://github.com/actions/checkout — their v5 version is the one that upgrades Node.

Yes, and I hate it that I have to change the major version with no breaking changes of something so basic regularly. It's a waste of time IMO, from the POV of workflows which just don't care on what node version it's running.

I can consider updating from node20 to node24 later (there is no* urgency to update to 24 from my POV), given node20 still has some time before EOL.
But will that help, or we'll just have the same issue then and there is no point to delay?

Isn't this error a reminder that you need to update the self-hosted runner?

I think we'd prefer that reminder to be something other than a ton of our GHA workflows suddenly failing, which is just not intuitive or expected when we're set to setup-ruby@v1. The self-hosted runner use case is, in my view, the very reason you should reserve major node version changes for major version bumps.

Now if node 20 was EOL, then I'd see your point. I don't think you have to support older Node versions in perpetuity.

FWIW GitHub deprecated Node 20 now: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/
I would be interested in more replies to:

Isn't there a way to keep self-hosted runners automatically updated?
If not, how often do you update your self-hosted runners?

That way I can adjust how fast/slow node updates should be.
In the meantime I can see from #541 (comment) that bumping to node24 early is likely more disruptive than it could be, and there is no need to bump early in this action.
So I will for now revert the bump to node24, and redo it a bit later, hopefully by then most self-hosted runners will have a node24 available/installed.
As a reference, actions/checkout bumped to node24 on August 11: actions/checkout#2226. I would have thought over a month is enough for self-hosted runners to be updated but apparently not.

https://github.com/ruby/setup-ruby/releases/tag/v1.260.0 is released and that goes back to node20 for now.

Hi, I'm coming here from the previous discussion #541 (comment). First, thank you for considering the future plan for self-hosted runners even though ruby/setup-ruby doesn't fully support them according to README: https://github.com/ruby/setup-ruby/blob/1dc795682739d28740ac76bf40227b89f2ab602a/README.md#using-self-hosted-runners.

Isn't there a way to keep self-hosted runners automatically updated?
If not, how often do you update your self-hosted runners?

Our setup uses self-hosted runners on our GitHub Enterprise Server (GHES). The minor version of GHES is upgraded several times a year, and the minimum required version of actions/runner is upgraded at the same time: https://github.com/proxy/docs.github.com/en/enterprise-server@3.17/admin/all-releases#minimum-github-actions-runner-application-versions.

This document also says:

For instances with GitHub Actions enabled, self-hosted GitHub Actions runners must run a minimum required version of the GitHub Actions Runner application.

Therefore, we usually upgrade our version of actions/runner to the required version just before upgrading the version of GHES. This process makes our upgrade cycle much slower than that of GitHub-hosted runners on github.com.

In this setup, I'm unsure if we can follow the latest version of actions/runner and still stay within the scope of GitHub Enterprise support. I have submitted a support request to GitHub to clarify this. I anticipate that GHES could work with the newer version of actions/runner, but GitHub Support might recommend to downgrade the runner version to the minimum when a problem arises.

In this action we have transitioned from node 12->16 and 16->20 without a major version bump and had no issues.

To be more precise, we did encounter the same problem at the 16->20 transition in the similar way to #541 (comment), and we left a thumbsup reaction on that issue. We were not using self-hosted runners at the earlier 12->16 transition.

In this setup, I'm unsure if we can follow the latest version of actions/runner and still stay within the scope of GitHub Enterprise support. I have submitted a support request to GitHub to clarify this.

I've received an answer to this. In summary:

Newer versions of actions/runner are supported with GHES. Mostly, releases of actions/runner maintain backward compatibility, so we can use it with GHES. There are, however, rare cases where actions/runner requires a new feature of GHES, which requires an update of GHES.
This document https://github.com/proxy/docs.github.com/en/enterprise-server@3.17/actions/reference/runners/self-hosted-runners#runner-software-updates-on-self-hosted-runners says that:

Any updates released for the software, including major, minor or patch releases, are considered as an available update. If you do not perform a software update within 30 days, the GitHub Actions service will not queue jobs to your runner.

But this is not applicable to GHES. As long as we're using a specific GHES version, we can use actions/runner which is shipped with the version, even if the runner version is old.

Therefore, in most cases GHES users can enable auto-upgrades of their runner version, but may be forced to pause upgrades if a new version of the runner requires an upgrade of GHES. Unfortunately, this may take more than a month...

I suppose a good strategy to use here is to wait that GitHub starts warning on workflow runs that node 20 is going away, and at that point to bump to node 24 in action.yml.
That way we're fixing the warnings for people using an up-to-date runner, and self-hosted runners should have plenty of time to catch up.

#806 (comment) looks good to me if you want to keep the v1 tag 👍

As a maintainer of our private GHES instance and self-hosted runners for it, I've asked GitHub Support about workarounds for our instance. They suggested some workarounds:

Option 1: Pin the version of ruby/setup-ruby by a commit SHA hash in each repository. This simplifies the runtime mismatching issue for GHES admins, but at the same time, this puts some burden on developers. Tools like https://github.com/suzuki-shunsuke/pinact will reduce the burden, though.
Option 2: Self-host ruby/setup-ruby in our GHES instance. GHES has a tool https://github.com/actions/actions-sync, which allows GHES admins to self-host external actions on github.com. Although this increases the burden of GHES admins, the runtime issue will be completely resolved by the self hosting.

So, in my case, I will be able to have enough time to deal with the runtime upgrade if there is some time lag before the version bump on the ruby/setup-ruby side, and even if I don't have time to prepare the upgrade on time, there are some workarounds.

Personally, I still consider that it's more natural to go with major version bumps of ruby/setup-ruby, but now that I know there's a workaround, I don't feel as strongly about it anymore. Thank you for considering this issue!

I suppose a good strategy to use here is to wait that GitHub starts warning on workflow runs that node 20 is going away, and at that point to bump to node 24 in action.yml.

This happening now 😄 What is the plan for node 24 rollout? Can't we simply release a @2?

Right, I see it in workflow runs as well, thanks for the ping.
Then it's time to update to node 24.

Can't we simply release a @2?

No I'm not bumping the major and requiring 300 000 usages of this action to change from v1 to v2 for no reason besides accommodating wildly outdated self-hosted runners.

IOW, I expect bumping to node24 should be smooth for 99.999% and the rest probably already knows they have to pin actions all the time because they're using such old runners.

Update Node to 24

Done in #886, released as https://github.com/ruby/setup-ruby/releases/tag/v1.292.0

IOW, I expect bumping to node24 should be smooth for 99.999% and the rest probably already knows they have to pin actions all the time because they're using such old runners.

I'm super fine with that, thank you so much 🙏

Navigation Menu

Repository navigation

node24 upgrade to v1 tag and no breaking changes? #806

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

node24 upgrade to v1 tag and no breaking changes? #806

Description

Activity

svyatmuzyka commented on Sep 19, 2025

jstewart-vanilla commented on Sep 19, 2025

TheMetalCode commented on Sep 19, 2025

nicholaspufal commented on Sep 19, 2025

eregon commented on Sep 19, 2025

eregon commented on Sep 19, 2025

TheMetalCode commented on Sep 19, 2025

eregon commented on Sep 20, 2025

eregon commented on Sep 20, 2025

nekketsuuu commented on Sep 20, 2025

nekketsuuu commented on Sep 20, 2025

nekketsuuu commented on Sep 30, 2025

eregon commented on Dec 11, 2025

nekketsuuu commented on Jan 5, 2026

fabn commented on Mar 11, 2026

eregon commented on Mar 11, 2026

eregon commented on Mar 11, 2026

fabn commented on Mar 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions