Unable to set global npm version, npm v8 is always used...

[busticated]

Description:
I need to run my action using npm@6. Despite installing the correct version globablly, npm@8 is always used and my action fails. i see a series of warnings in my logs like:

my-package: npm WARN EBADENGINE Unsupported engine {
my-package: npm WARN EBADENGINE   package: '@particle/tmp@2.0.1',
my-package: npm WARN EBADENGINE   required: { node: '>=10', npm: '6.x' },
my-package: npm WARN EBADENGINE   current: { node: '12.22.7', npm: '8.1.0' }
my-package: npm WARN EBADENGINE }

i first noticed the failure on monday (12/6/2021), the last successful run was ~7days ago (11/30/2021 - log)

inspecting the logs for both runs, i see Current runner version: '2.284.0' (success) vs. Current runner version: '2.285.1' (fail). looks like the earliest failure happened under Current runner version: '2.285.0' which was released ~8days ago (info)

running locally (outside of GH Actions entirely but within a comparable environment), i'm able to reproduce the warnings and subsequent failures by simply using npm@8. at no point does my code attempt to install npm@8. reverting to npm@6 and re-running fixes things.

the Unsupported engine warnings are triggered by running a tool which itself runs npm via child-process in a descendant directory (see here). this is what my npm run build command does under the hood.

interestingly, Node.js v12.22.7 ships w/ npm@6.14.15 by default (see ~pg10 here) so something is explicitly pulling in npm@8.1.0 somewhere

Action version:
v2.5.0, v2.4.1, and v2.4.0

Platform:

• Ubuntu
• macOS
• Windows

Runner type:

• Hosted
• Self-hosted

Tools version:
node: v12.22.7
npm: 6.14.15 (but npm@8.1.0 is always used)

Repro steps:
Using an action step like:

      - uses: actions/setup-node@v2
        with:
          node-version: '12'
          registry-url: 'https://registry.npmjs.org'
      - name: Install Dependencies
        run: |
          npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}
      - name: Debug
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}
        run: |
          echo ":::: NPM SETTINGS"
          npm config set '//registry.npmjs.org/:_authToken' "${NODE_AUTH_TOKEN}"
          node --version
          npm --version
          npm whoami
          npm i npm@6 --global
          npm run build

(note: using either ubuntu-18.04 or ubuntu-latest yields the same result)

Expected behavior:

npm run build command succeeds, npm@6 is used

Actual behavior:

npm run build fails with the following log output:

my-package: npm WARN EBADENGINE Unsupported engine {
my-package: npm WARN EBADENGINE   package: '@particle/tmp@2.0.1',
my-package: npm WARN EBADENGINE   required: { node: '>=10', npm: '6.x' },
my-package: npm WARN EBADENGINE   current: { node: '12.22.7', npm: '8.1.0' }
my-package: npm WARN EBADENGINE }

npm@8 is used despite previously installing npm@6 via npm i npm@6 --global and despite Node.js v12.22.7 shipping with npm@6.14.15 by default

[busticated]

i should add: this pipeline has been working without issue for months. my last successful run was ~7days ago (11/30/2021 - log). i noticed things failing starting yesterday (12/6/2021)

edit: comparing the last successful run to my recent failures, i see Current runner version: '2.284.0' (success) vs. Current runner version: '2.285.1' (fail). looks like the earliest failure happened under Current runner version: '2.285.0' which was released ~8days ago (info)

edit: this seems relevant 👉 actions/runner#1439

edit: doesn't look like i can downgrade the runner itself ☠️

edit: actions/runner#1439 (comment) seems to confirm my expectation that setup-node would handle things such that the base environment wouldn't conflict with the environment where my actions run

[ethomson]

my last successful run was ~7days ago (11/30/2021 - log).

Your repository is private and I cannot see the runs. When I try to reproduce this, I am running the expected versions of node and npm after running setup-node.

    steps:
      - uses: actions/setup-node@v2
        with:
          node-version: '12'
      - name: Debug
        env:
          NPM_TOKEN: foobar
        run: |
          echo ":::: NPM SETTINGS"
          node --version
          npm --version

shows:

:::: NPM SETTINGS
v12.22.7
6.14.15

Is this what you're seeing? Or are you seeing something different from node --version and npm --version? Is this only failing in the npm run build step or are you seeing odd version numbers before that step?

[busticated]

@ethomson thanks for taking a look 🙏

Is this only failing in the npm run build step

correct. i'm running a tool via the npm run build command that then builds my source code. the line that is triggering the warnings is here

Your repository is private and I cannot see the runs

as you are a Github employee, i'm happy to grant you access. fwiw, we are a Github Enterprise customer (info). if it's helpful, i can file a ticket.

[busticated]

ok, should have done this from the beginning but better late than never. running locally (edit: outside of GH Actions entirely), i'm able to reproduce the warnings and subsequent failures by simply running under npm@8. edit: reverting to npm@6 and re-running fixes things.

so the question really boils down to: why would a call to execute npm from a node.js script cause the base environment's npm instance to be used instead of the one configured via setup-node?

[busticated]

I should also note that I’m using the setup-node action to control node + npm versions as well (not exclusively via npm i but both together)

      - uses: actions/setup-node@v2
        with:
          node-version: '12'
          registry-url: 'https://registry.npmjs.org'
      - name: Install Dependencies
        run: |
          npm ci
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NODE_AUTH_TOKEN }}

[dmitry-shibanov]

Hello @busticated. Thank you for your report. Could you please provide a public repository to reproduce the issue. I've tried from my side, but it works as expected.

[ethomson]

so the question really boils down to: why would a call to execute npm from a node.js script cause the base environment's npm instance to be used instead of the one configured via setup-node?

I don't have an answer for you - I'd love to know if

echo ":::: NPM SETTINGS"
node --version
npm --version

is producing the expected values?

Expanding on this, I'd love to know what you're seeing here:

        run: |
          echo ":::: NPM SETTINGS"
          npm config set '//registry.npmjs.org/:_authToken' "${NPM_TOKEN}"
          node --version
          npm --version
          node -e 'child_process.spawnSync("npm", ["--version"], { stdio: "inherit" });'
          node -e 'child_process.spawnSync("which", ["npm"], { stdio: "inherit" });'
          npm i npm@6 --global
          npm --version
          node -e 'child_process.spawnSync("npm", ["--version"], { stdio: "inherit" });'
          node -e 'child_process.spawnSync("which", ["npm"], { stdio: "inherit" });'

For this, I get all the expected outputs:

:::: NPM SETTINGS
v12.22.7
6.14.15
6.14.15
/opt/hostedtoolcache/node/12.22.7/x64/bin/npm
/opt/hostedtoolcache/node/12.22.7/x64/bin/npm -> /opt/hostedtoolcache/node/12.22.7/x64/lib/node_modules/npm/bin/npm-cli.js
/opt/hostedtoolcache/node/12.22.7/x64/bin/npx -> /opt/hostedtoolcache/node/12.22.7/x64/lib/node_modules/npm/bin/npx-cli.js
+ npm@6.14.15
updated 1 package in 15.958s
6.14.15
6.14.15
/opt/hostedtoolcache/node/12.22.7/x64/bin/npm

If you're seeing this, too, then I think that your question here is very interesting, indeed:

so the question really boils down to: why would a call to execute npm from a node.js script cause the base environment's npm instance to be used instead of the one configured via setup-node?

I'd love to know how you're invoking npm from this Node.js script.

[busticated]

thanks @ethomson 🙏

i ran the debug step you provided along with a few more bits like changing directories to see if that mattered any and got the same results as you did: npm@6.14.15 is always reported.

the code that is executing is somewhat tricky:

1. first the npm run build command is run from a top-level node package
2. that command then calls down into a child node package (we're in a monorepo) which then executes oclif-dev pack, oclif-dev pack:win, and oclif-dev pack:deb in that order via its own npm run build command. the command that fails is oclif-dev pack:deb (the last one)
3. oclif-dev pack:deb itself tries to build tarballs (1) and errors out upon running npm install --production via child process(2)

i patched the underlying lib to output more debugging info and discovered something interesting. all of the oclif-dev commands i listed above run the "build tarballs" step. when i log out which npm in the context of that code, i see:

@particle/cli: > oclif-dev pack
@particle/cli: /opt/hostedtoolcache/node/12.22.7/x64/bin/npm
- - -
@particle/cli: > oclif-dev pack:win
@particle/cli: /opt/hostedtoolcache/node/12.22.7/x64/bin/npm
- - -
@particle/cli: > oclif-dev pack:deb
@particle/cli: /usr/local/bin/npm

(with a bunch of noise omitted)

so, at some point this code starts seeing /usr/local/bin/npm as the output of which npm and of course this version is npm@8.1.0.

i then tried running the oclif-dev pack:deb step on its own thinking maybe previous steps messed things up somehow and that failed on its own.

but here's the wrinkle - the oclif-dev pack:deb step is run like sudo -s -E oclif-dev pack:deb b/c the command requires root (issue, pr).

is that likely to be the culprit? and what changed to cause failures now? is it down to the base environment change rolled out in https://github.com/actions/runner/releases/tag/v2.285.0 ?

[busticated]

ok, well adding sudo -s -E npm i npm@6 --global just prior to calling npm run build fixes things. so, yay?

i suppose you can close this out - thanks for the help 🙏 👍

[6tukat]

oho tenku

[6tukat]

god blesu evribare