Skip to content

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

Closed
Closed
Unable to set global npm version, npm v8 is always used...#376
Labels
bugSomething isn't working

Description

@busticated
busticated
opened on Dec 7, 2021

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/[email protected]',
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/ [email protected] by default (see ~pg10 here) so something is explicitly pulling in [email protected] 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 [email protected] 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/[email protected]',
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 [email protected] by default

Activity

  1. busticated
    added
    bugSomething isn't working
    needs triage
    on Dec 7, 2021

  2. busticated commented on Dec 7, 2021

    @busticated
    busticated
    on Dec 7, 2021
    Author

    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

  3. ethomson commented on Dec 8, 2021

    @ethomson
    ethomson
    on Dec 8, 2021

    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?

  4. busticated commented on Dec 8, 2021

    @busticated
    busticated
    on Dec 8, 2021
    Author

    @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.

  5. busticated commented on Dec 8, 2021

    @busticated
    busticated
    on Dec 8, 2021
    Author

    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?

  6. busticated commented on Dec 8, 2021

    @busticated
    busticated
    on Dec 8, 2021
    Author

    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 }}

  7. dmitry-shibanov commented on Dec 8, 2021

    @dmitry-shibanov
    dmitry-shibanov
    on Dec 8, 2021
    Contributor

    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.

  8. ethomson commented on Dec 8, 2021

    @ethomson
    ethomson
    on Dec 8, 2021

    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
+ [email protected]
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.

  9. busticated commented on Dec 9, 2021

    @busticated
    busticated
    on Dec 9, 2021
    Author

    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: [email protected] 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 [email protected].

    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 ?

  10. busticated commented on Dec 9, 2021

    @busticated
    busticated
    on Dec 9, 2021
    Author

    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 🙏 👍

  11. 6tukat commented on Dec 10, 2021

    @6tukat
    6tukat
    on Dec 10, 2021

    oho tenku

  12. 6tukat commented on Dec 10, 2021

    @6tukat
    6tukat
    on Dec 10, 2021

    god blesu evribare

  13. dmitry-shibanov
    removed
    needs triage
    on Dec 10, 2021

  14. dmitry-shibanov commented on Dec 10, 2021

    @dmitry-shibanov
    dmitry-shibanov
    on Dec 10, 2021
    Contributor

    Hello everyone. For now I'm closing the issue. If you have any concerns feel free to contact us.
    Thank you for the help @ethomson .

  15. dmitry-shibanov
    closed this as completedon Dec 10, 2021
  16. deining
    added a commit that references this issue on Nov 9, 2023

    fix!: fail when there's an error while committing (actions#376)

    0b47528
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions