Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Node 8 installs different versions depending on system #27

Closed
sergiohgz opened this issue Aug 12, 2019 · 23 comments
Closed

Node 8 installs different versions depending on system #27

sergiohgz opened this issue Aug 12, 2019 · 23 comments
Assignees
Labels
bug Something isn't working enhancement New feature or request

Comments

@sergiohgz
Copy link

sergiohgz commented Aug 12, 2019

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

damccorm commented Aug 12, 2019

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!

@damccorm damccorm self-assigned this Aug 12, 2019
@sergiohgz
Copy link
Author

sergiohgz commented Aug 12, 2019

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
Copy link
Contributor

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

@sergiohgz
Copy link
Author

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

@sergiohgz
Copy link
Author

@damccorm, is there any update on this?

@damccorm
Copy link
Contributor

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
Copy link

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
Copy link

XhmikosR commented Oct 8, 2019

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

@damccorm damccorm assigned bryanmacfarlane and unassigned damccorm Oct 8, 2019
@razzeee
Copy link

razzeee commented Oct 16, 2019

I also just hit this problem when migrating :/

@bryanmacfarlane
Copy link
Member

I will look into this today

@bryanmacfarlane
Copy link
Member

With approximately weekly updates to the various images and node releasing versions independently, it means the images can have different versions.

See: https://github.com/actions/virtual-environments#updates-to-the-virtual-environments

Right now, we match 8 and 8.x to mean give me any version of 8.

Issue #26 is related but still doesn't provide the fine grained control of "give me the latest 8"

Options:

  • Always query and don't match against cache first. This impacts everyone's build perf and frequently renders the cache useless because of minor patch discrepencies and timing.
  • Add an input to alwaysCheck for folks that care more about having the absolute latest over perf.

Either option will still not guarentee a consistent version as the variable job start times could cross a node release but it does narrow the window significantly. The only way to guarantee a consistent version would be to have one job that queries and resolves the version, sets an output is some fashion and a matrix of jobs that depend on that one (which all happen on different machines of different OSes).

I think we're going with the second option.

@XhmikosR
Copy link

But this is only observed with 8.x on Windows. Every other OS and Node.js version follows the latest release, which IMO is what I'd expect.

@bryanmacfarlane
Copy link
Member

@XhmikosR - yes, that's why I created actions/runner-images#42 (that repo tracks issues with the VM images created for the hosted pools)

But note, they release approximately weekly and not synchronized on cadence so it can and will occur again even if they update that image.

The only option that drives a more recent and consistent toolset is the second option I outlined ☝️

@razzeee
Copy link

razzeee commented Oct 16, 2019

From an outside view this seems like a bug. All my builds are green, just the one that's stuck on the old node version is not.

@bryanmacfarlane
Copy link
Member

Yes, actions/runner-images#42 is a bug with the image gen that has an old version cached. This actions just uses that. But the enhancement noted above will allow you to optionally bypass what's cached/installed and check for latest @ https://nodejs.org/dist/index.json (that's how azure pipelines solves the problem).

@bryanmacfarlane bryanmacfarlane added the bug Something isn't working label Oct 16, 2019
@bryanmacfarlane
Copy link
Member

^ I'll label it as both ;)

XhmikosR referenced this issue in paulmillr/chokidar Oct 17, 2019
@somewhatabstract
Copy link

somewhatabstract commented Oct 29, 2019

This is pretty easy to workaround. The setup-node action uses semver which supports syntax like ^8.12.x, so instead of just specifying 8.x provide a rule that forces a more recent version. I did this in somewhatabstract/ancesdir#24 and it addressed the problem.

image

yhatt added a commit to marp-team/marp-cli that referenced this issue Nov 6, 2019
According to actions/setup-node#27, we have to use semver format to
install correct version.
@gmaclennan
Copy link

Just hit this problem and was scratching my head for an hour. From the docs it seems like 8.x would pull the latest version of Node 8 according to semver, rather than 'random version of Node" which is what currently happens on Windows.

gmaclennan added a commit to gmaclennan/zip-fs that referenced this issue Nov 6, 2019
asfernandes added a commit to asfernandes/node-firebird-drivers that referenced this issue Nov 21, 2019
@XhmikosR
Copy link

Can we really get this fixed? It's been so long since this inconsistency has been reported.

luketurner added a commit to luketurner/cli-of-mine that referenced this issue Dec 1, 2019
@felipefranklin570
Copy link

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.

@dmitry-shibanov
Copy link
Contributor

Hello everyone. Thank you all for your response. Sorry for the late reply. I think the issue should be resolved according to this issue. If you have any concerns, feel free to ping us.

krzyk pushed a commit to krzyk/setup-node that referenced this issue Apr 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

10 participants