detectExecuteScan needs to run "npm install"

[phil-mitchell]

Whereas whitesourceExecuteScan installs node modules prior to running the scan:

jenkins-library/cmd/whitesourceExecuteScan.go

Line 642 in 9ffe52d

if err := reinstallNodeModulesIfLsFails(modulePath, config, utils); err != nil {

There is no such action taken for detectExecuteScan.

If this installation is not done, it places a restriction on the structure and order of pipelines, which is overly restrictive and, in my case, not desirable.

Can we please relax this restriction by running "npm install" within the detectExecuteScan step?

[stippi2]

Actually, this is something we are not sure about in whitesourceExecuteScan. We almost removed it before merging. The basic principle should be that what is scanned is actually what will be deployed in the end. A problem with "npm ls" could either originate from a broken package-lock.json, or from running the build and the scan with different node versions. It isn't clear to me what the correct fix would be in each case, but maybe the pipeline is right in being restrictive. I am not sure what the root problem is in your case. Has "npm install" happened somewhere else already and the result is not properly transported via stashing/unstashing between stages?

[phil-mitchell]

"npm install" elsewhere in the pipeline has the same problem. We want to run the scans in parallel to the other steps. If package-lock.json is broken, would it not also affect other parts of the build in the same way? The current behaviour relies on "accidentally" having the node_modules already installed. Also, what if the node_modules directory exists but is not fully populated due to some behaviour earlier in the pipeline? It will silently scan the wrong thing.

It is messy and error-prone to rely on a particular state of the workspace at the start of the step, unless you are going to explicitly enforce some pre-condition. If you want to be restrictive, then, I would request that you make it explicit. i.e. require a stash to be specified that must be unstashed in a clean workspace prior to running the scans. Otherwise the problems you've listed above are only a small subset of the problems that can occur.

Or, just do the "npm install" yourself to ensure that the workspace is in a consistent state prior to running the scan. Node version should be configurable using a docker image. Broken package-lock is a code error and maybe the package-lock should be verified prior to running if you're worried about that.

[sebastianhof]

We have the same requirements to run npm install before executing the detect scan. Will there be an official support scanning npm projects in near future? There is even a configuration option InstallArtifacts which unfortunately only works with maven artifacts so far.

[phil-mitchell]

Any update on this topic? It's a bit of a blocker for us.

[github-actions]

Thank you for your contribution! This issue is stale because it has been open 60 days with no activity. In order to keep it open, please remove stale label or add a comment within the next 10 days. If you need a Piper team member to remove the stale label make sure to add @SAP/jenkins-library-team to your comment.

[github-actions]

Issue got stale and no further activity happened. It has automatically been closed. Please re-open in case you still consider it relevant.

[giancorderoortiz]

Any updates?
Still need to run 'npm install' so that actual scan can take place ?