node24 upgrade to v1 tag and no breaking changes?

[davideramoaxa]

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

[svyatmuzyka]

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

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

[jstewart-vanilla]

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.

[TheMetalCode]

Why force every user of setup-ruby to be on Node 24 when 22 is still active LTS? https://nodejs.org/en/about/previous-releases#release-schedule

[nicholaspufal]

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.

[eregon]

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.

[eregon]

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?

[TheMetalCode]

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.

[eregon]

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.

[eregon]

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

[nekketsuuu]

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://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.

[nekketsuuu]

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.