Those are some horrible workarounds nfalco. Since the EnvInject issue has existed since at least January 2015, something was obviously removed from the NodeJS plugin that was allowing npm commands to function prior to v1.0. I understand that the root problem is an EnvInject plugin issue, but you've just broken a bunch of users (including my company and all of our Node-dependent builds), in place, by removing the workaround. This is bad form. You don't force another project to fix their issues by breaking your product for a bunch of your own users. And my options are to uninstall another plugin and break 75% of our builds, or start rolling custom plugin builds? Really?

adamdille I'm sorry BUT I become the maintainer of this plugin only on late november and the refactoring of this plugin was done by ndeloof (that I know, one of major bee developer). The refactor consist in a major update of Jenkins API for BuildWrapper (steps that contribute the Enviroment) that corrects the wrong way of NodeJS to set the PATH variable similar to Envinject that cause the same issue to other BuildWrapper plugins (see JENKINS-24425 for example).

I strongly agree with the work of ndeloof. I aware of EnvInject issue but a release of NodeJS was expected since a lot of time (14th febrary 2014) to be compatible with Jenkins 2.x. NodeJS and EnvInject plugin are not related (nodejs has not dependences to EnvInject), so I could not stop the develop of this plugin due unresolved issue of other unrelated plugin (like no other plugins does).

I could ship NodeJS with the workaround for JENKINS-26583, BUT it's not a best practice that I have to release workaround for issues in other plugin, consider that people could also not have EnvInject installed, and proposed workaround in the branch it's little bit dirty so I do not really want handle its side effect.

I had propose to you some valid options:

• remove EnvInject (you can also push for resolution of JENKINS-26583 or propose a PR)
• remain to NodeJS 0.2.1
• build and install a custom branch in our repository (the same that I have to use in my company)

Consider that all this stuff of issue management (and develop of plugin) are done in my free time at the week end or after work.

nfalco, I built plugins from both the custom branch at commit d6c6db7 as well as 2b6255c (just in case some of the post-1.0.1 stuff introduced an issue). After installing them and re-running builds, both of them gave me the same npm: command not found error as the public plugin v1.0.1.

Both commit are valid, I suggest to use latest on that branch.
Could you post me the configuration of NodeJS tool, the job config.xml and the output of echo $PATH from a shell script build step please?

nfalco, I've attached them all below. My setup really didn't change from the builds that were functioning previously on 0.2.2. Thanks for taking a look.

config.xml
build_output.txt

Strangely, the custom plugin from d6c6db7 seems to be working on our builds that run on Windows slaves, but the OSX slave, which worked fine on 0.2.2 is the one with the issue in the attached files above.

If Windows and Mac are slaves, on which OS run Jenkins master (just to reproduce your scenario)?
And if works on windows slave do you have customise some node properties for mac node?
To do this go to "Manage Jenkins" -> "Manage Nodes" -> select mac node -> configure and see if under Node Properties section Environment variables is checked and the variable PATH is setup there

That I can see on windows slave you had install a nodejs in the system, so nodejs executable could be always available. To compare behavior windows vs mac node you should select a NodeJS version different than installed in (C:\Program Files\nodejs) and add to shell

npm --version

command to ensure that you are using the NodeJS of the selected tools and not that one installed in the system.

The master is running on Windows Server 2012 R2. None of the remote slaves have any custom node properties, including the mac.

Our newest Windows slave doesn't have Node installed on the system at all, since I was using the NodeJS Plugin as a way to reduce that install requirement. That's the slave that is working fine with the custom built workaround plugin with the Node installer 'Latest' selected. With that working, I know for sure that the problem is limited to the OSX slave.

In the workaround branch I've integrate most recent master commits that fix regression introduced with pipeline work. So please consider to build again.

This build was used to reproduce your use case:

1. install a Jenkins 2.44 on a Windows 10 machine.
2. in setup page I skip any plugin from install.
3. install only the following plugins (need by your config):
   • custom NodeJS 7ec6423
   • job-restrictions
   • git-parameter
   • throttle-concurrents
   • shelve-project-plugin
   • cobertura
   • bitbucket-build-status-notifier
   • envinject
4. configure a macviabuild01 node started by JNPL (Java Web Start)
5. create ShopAtHome Extension Core freestyle job
6. copy your config.xml in on top the existing
7. restart Jenkins
8. setup NodeJS configuration tool like in your screenshot
9. edit job configuration to remove:
   • any SCM
   • comment gulp command
   • remove any job parameter

Follow the output:

Started by user anonymous
[EnvInject] - Loading node environment variables.
Building remotely on viamacbuild01 in workspace /Users/me/jenkinsslave/workspace/ShopAtHome Extension Core
Unpacking https://nodejs.org/dist/v5.9.1/node-v5.9.1-darwin-x64.tar.gz to /Users/nikolasfalco/jenkinsslave/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/5.9.1 on viamacbuild01
/Users/me/jenkinsslave/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/5.9.1/bin/npm install -g gulp jshint karma-phantomjs-launcher
npm WARN deprecated minimatch@2.0.10: Please update to minimatch 3.0.2 or higher to avoid a RegExp DoS issue
...CUTTED...
npm WARN karma-phantomjs-launcher@1.0.2 requires a peer of karma@>=0.9 but none was installed.
[ShopAtHome Extension Core] $ /bin/sh -xe /var/folders/jq/2l9t7bw1103_jjyv9rzk7kcr0000gn/T/hudson134818345472423975.sh
+ echo /Users/me/jenkinsslave/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/5.9.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
/Users/me/jenkinsslave/tools/jenkins.plugins.nodejs.tools.NodeJSInstallation/5.9.1/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/git/bin
+ npm install
npm WARN enoent ENOENT: no such file or directory, open '/Users/me/jenkinsslave/workspace/ShopAtHome Extension Core/package.json'
npm WARN ShopAtHome Extension Core No description
npm WARN ShopAtHome Extension Core No repository field.
npm WARN ShopAtHome Extension Core No README data
npm WARN ShopAtHome Extension Core No license field.

The path in echo command was right and npm command was found but fail due no package.json in workspace (miss source code).

In the future I will merge to this branch only released commits to avoid work in progress issues

Success! 7ec6423 is working on both Windows and OSX slaves without Node installed locally. Thanks for tracking down the problem, nfalco. Hopefully EnvInject fixes their issues sometime soon and I can get us back onto the public master branch plugins.