Node 8 installs different versions depending on system

[sergiohgz]

When setting up Node with the next strategy matrix and action from v1 or master:

strategy:
      matrix:
        node_version: [8, 10, 12]
        os: [ubuntu-latest, windows-latest, macOS-latest]

# ...

    - name: Use Node ${{ matrix.node_version }}
      uses: actions/setup-node@master
      with:
        version: ${{ matrix.node_version }}

With Node 10 and 12, it works like a charm, installing 10.16.2 and 12.8.0 respectively, using 10 or '10.x' and 12 or '12.x', but with Node 8 using 8 or 8.x it will not install the latest version in Windows. I made a table with the versions installed depending on the base system and the value in the node_version array specified:

System specified	Node specified	Node installed
ubuntu-latest	8	8.16.0
macOS-latest	8	8.16.0
windows-latest	8	8.10.0
ubuntu-latest	8.x	8.16.0
macOS-latest	8.x	8.16.0
windows-latest	8.x	8.10.0
ubuntu-latest	8.16	8.16.0
macOS-latest	8.16	8.16.0
windows-latest	8.16	8.16.0

Windows is installing 8.10 when Ubuntu and MacOS install 8.16. If we force 8.16 it will install it, but this is not scaling.

[damccorm]

So I think what is happening here is that its pulling from our image's pre-loaded tool-cache. We look for a matching node version in the cache before downloading, and just use that if its there. So for some reason, we have 8.16 installed in the tool-cache for Linux/Mac, but only 8.10 installed for Windows. We should probably update that to install 8.16 in the Windows cache as well.

With that said, a more scalable solution to this problem is coming in #26 which I think is the right solution to this problem. When that is resolved, you'll be able to specify something like node_version: [carbon, dubinium, latest] which will guarantee the latest release of 8.x, 10.x, and 12.x respectively - does that seem like an appropriate solution here?

[sergiohgz]

I think this problem will be solved as you said, caching Node 8.16 for Windows like in Linux and MacOS, as is the latest release below 8.x branch. How can we know which versions are cached at any moment?

Using the names instead of explicit version for better scalability is a good improvement, but I think is better use lts and latest as that names will scale better with next releases. But this is better to talk in #26 😉

[damccorm]

How can we know which versions are cached at any moment?

The easiest way is probably to run ls $TOOL_CACHE. That will display folders from all the installed tools. From there, you'll see that node is one of the tools installed, and you can run ls $TOOL_CACHE/node to see the installed versions.

EDIT: used the wrong variable name, should be ls $RUNNER_TOOL_CACHE and ls $RUNNER_TOOL_CACHE/node

I think is better use lts and latest as that names will scale better with next releases.

Makes sense, we're planning on supporting those as well!

[sergiohgz]

I'm trying to look content of $TOOL_CACHE (with dir because, if I'm not wront, Windows don't have ls in cmd), but I cannot see (this is run in GitHub CI directly). When the new version is cached, could you warn here and close this? Great thanks

Also, I don't know which relation are between GitHub Actions and Azure DevOps Pipelines, but in Azure we are taking the same 8.10 when using 8.x hahahahahaha

[damccorm]

Whoops, used the wrong variable name, should be $RUNNER_TOOL_CACHE. I'll follow up here as progress is made though

[sergiohgz]

Perfect, I'll hear you when the cache is updated 😉

[sergiohgz]

@damccorm, is there any update on this?

[damccorm]

No, there was a bit of a mixup on our end on what exactly should be fixed - we're working towards a solution now though.

Note that to get a consistent latest version of 8.x you can also specify 8.9.x since 8.9 is (and I believe will continue to be) the latest minor version of 8

[XhmikosR]

Could we get this sorted? It's pretty non-standard to ship different Node.js versions based on the OS and this breaks due to 8.10.0 having an old npm which doesn't has the ci command.

[XhmikosR]

@damccorm can we get some movement on this? It's a pretty important issue.