CODEWITHSUNDEEP
npmgithub-actionsnpm-installnpm-ci
learner
learner

Reputation: 81

npm ci fails in GitHub Actions

I am working on a pipeline to install npm packages using GitHub Actions, I am getting this error:

npm ERR! code EUSAGE
npm ERR! 
npm ERR! The `npm ci` command can only install with an existing package-lock.json or
npm ERR! npm-shrinkwrap.json with lockfileVersion >= 1. Run an install with npm@5 or
npm ERR! later to generate a package-lock.json file, then try again.
npm ERR! 
npm ERR! Clean install a project
npm ERR! 
npm ERR! Usage:
npm ERR! npm ci
npm ERR! 
npm ERR! Options:
npm ERR! [--no-audit] [--foreground-scripts] [--ignore-scripts]
npm ERR! [--script-shell <script-shell>]
npm ERR! 
npm ERR! aliases: clean-install, ic, install-clean, isntall-clean
npm ERR! 
npm ERR! Run "npm help ci" for more info

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/runner/.npm/_logs/2022-09-09T06_53_34_562Z-debug-0.log
Error: Process completed with exit code 1.

My pipeline looks like this :

name: Veracode frontend Scan
on:
  workflow_dispatch:
    
jobs:
  veracode:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/setup-node@v3
      with:
        node-version: 16
    - run: npm ci

If anyone can help me out, I am not sure where I am going wrong.

Upvotes: 4

Views: 6361

Answers (3)

Matteo
Matteo

Reputation: 39440

Seems you miss to checkout the code first, just add the actions/checkout step, as example:

name: Veracode frontend Scan
on:
  workflow_dispatch:
    
jobs:
  veracode:
    runs-on: ubuntu-latest
    steps:
    - actions/checkout@v3
    - uses: actions/setup-node@v3
      with:
        node-version: 16
    - run: npm ci

Upvotes: 0

Vinay Kumar
Vinay Kumar

Reputation: 1307

This issue may be arise when we delete the existing package-lock.json or when we update the node version and to do that we delete the existing package-lock.json. It may happen with any pipeline(Azure, github action etc.).

So the solution you may try to run commands in:

install npm
npm ci

If it does not fix then and you are update the nodejs version run below commands:

sudo apt-get install -y nodejs # install whatever nodejs version you want

npm install -g nodemon@latest

Upvotes: 0

VonC
VonC

Reputation: 1328912

Check first if this is related to actions/setup-node issue 498 or PR 103

The npm-ci command does mention:

The main differences between using npm install and npm ci are:

  • The project must have an existing package-lock.json or npm-shrinkwrap.json.
  • If dependencies in the package lock do not match those in package.json, npm ci will exit with an error, instead of updating the package lock.
  • ...

Make sure:

  • your npm project does create a package-lock.json (which it should by default)
  • it is not ignored (.gitignore) and is part of your repository codebase.

As noted here:

Running npm install for a CI/CD is fundamentally flawed.
It might be acceptable for running tests, but if you rely on reproducible results, you cannot and must not use npm install.

The problem is that npm install will choose whatever version is the newest and that still matches your semver range specified in package.json.
This often works well for some time, but if you suddenly get burned by a broken dependency introduced through a patch release, you potentially will spend hours trying to figure out which exact version you used before.

Without a package-lock.json you have zero traceability and virtually no chance of reproducing the exact previous build ever again.
Quite frankly, anybody suggested otherwise never had to deal with a broken production build because a fricking dev dependency broke on the CI/CD side.

The OP learner confirms in the comments a path issue:

The problem was that I had been running the command in the wrong directory, once I switched that where the package-lock.json was and it was fine.

But the error message becomes:

UPSTREAM ERROR 

Fix the upstream dependency conflict, or retry this command with 
--force, or --legacy-peer-deps to accept an incorrect (and potentially broken) 
dependency resolution

From this answer, a npm ci --force is one way to go forward in that case.

Upvotes: 4

Related Questions