Jenkins build step fails when calling "npm" on mac-os-x Yosemite - node.js

Before I start, I want to say that I already checked these answers:
Jenkins build step fails on 'npm install <whatever>'
Jenkin's build failing on npm install
Now, I'm dealing with this issue for a while already and thus I tried a bunch of stuff.
Firstly, I installed node + npm via homebrew. A simple $ node -v and $ npm -v echoed the version v0.10.36 for node and v2.3.* for npm, which also means I HAVE THEM IN THE PATH and they work while called in the terminal.
Simply adding node -v; npm -v to the execute shell in Jenkins didn't do it. After a bit of tinkering I copied what $: which node yielded in the terminal to the above mentioned script, which now looked like this: /usr/local/bin/node and apparently that worked. The Jenkins build succeeded and 'node-v0.10.36' was proudly displayed in the console output.
When doing the same for 'npm' which happened to be /usr/local/bin/npm --version the computing gods weren't so merciful anymore. A big 'env: node: No such file or directory' error was thrown this time and the whole build failed.
The actual command that fails is
$ /bin/sh -xe /var/folders/wr/g_dl81tn5_x0t_yz3jw602cr0000gn/T/hudson8770480548136671253.sh and "surprisingly" when I run the same command in the terminal it succeeds.
I also uninstalled the homebrew node & npm versions and installed them afterwards via the package manager. Same results.
Ultimately I also did this: https://gist.github.com/DanHerbert/9520689, with no luck.
Notes:
I'm running Jenkins 1.613 and tried with 1.5**
I didn't create a "Jenkins" specific user but instead I'm using the admin. This happens to be the same user that Jenkins runs, since the who am i command inside the executable script yields the admin's user name.
sudo'ing doens't help
I'm also running the whole thing in a Virtual Environment - vagrant
I'm not running Jenkins as a deamon, as it's conflicting with xtools, but as a simple process
I also tried out jenkins-node plugin with various configs (can detail if needed)
Thanks a lot for your help, and let me know if you need any other info, screenshots, logs, etc.

I found my own solution. The problem was that the PATH although visible in shell was not exported for the Jenkins job, and so, the first workaround, as found here, was to export it in the actual script like so:
but this feels like a hack!
The right and elegant solution is to use Jenkins EnvInject Plugin and export the path in the added Properties content textarea on the configuration page, like so:

Manage Jenkins -> Configure System -> Global properties -> Environment variables

Related

npm command is not found when ssh with bitbucket pipelines on shared hosting

I've installed nodejs as described here.
Everything works fine when I ssh to the server myself. But I've created a script that deploys my application and call it via bitbucket pipelines. Everything else works fine (composer install, php artisan migrate etc.), except npm install. The error message is
./deploy: line 26: npm: command not found
In bitbucket-pipelines.yml I call my script like this:
- step:
script:
- ssh user#ip_address ./deploy
When I call the script by myself everything works. The problem is only with bitbucket pipelines. I have no clue why this happens :(.
Running which composer revealed that at least composer command is not getting picked up from your assumed location i.e., ~/composer dir. Instead, it was found in /opt/cpanel/composer/bin/composer.
which npm returned the following:
no npm in (/usr/local/cpanel/3rdparty/lib/path-bin:/usr/local/jdk/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/usr/local/bin:/usr/X11R6/bin:/root/bin:/opt/bin:/opt/cpanel/composer/bin:/home/handmast/.local/bin:/home/handmast/bin)
Now since you are able to manually run the command npm, you just need to figure about the path from where npm is running and ensure that the path is explicitly added to the user's ~/.bashrc file and things should work fine. You need to do this because as per your observation, ssh is not able to find it.
export PATH=$PATH:/path/to/npm/binary
Note: To avoid any confusion, just remember that while adding the path to your binary, you just have to add the path to the directory where npm resides. Don't add npm at the end. For example, following is incorrect way:
export PATH=$PATH:/home/handmast/bin/npm
Correct way is this:
export PATH=$PATH:/home/handmast/bin

Team City "minimal build agent" Docker image - "npm: not found" Linux issue?

First of all, I think this is more of a Linux issue as the problem seems to be on a linux-flavoured Docker container, but I'm happy to accept that I can do something to the team city config to overcome this.
I'm also not very experienced with Linux, Docker or node/npm, though I do have a lot of development experience and am very comfortable with command line interfaces in general.
Background
We currently have Team City set up as a build server, for building a variety of projects:
.Net Framework,
.Net Core
Angular CLI
A couple of simple websites which use node packages to generate HTML from Markdown.
The server is running as a Docker container using Docker for Windows on a Windows Server box, and this is working well.
We have one Windows 10 Build agent (a VM) which is also working fine, and builds all the .Net and .Net Core stuff fine.
The simple docs site stuff primarily uses the markdown-to-html node package, so its build steps simply get all the source .md files and compile to html with markdown-to-html, plus use some other npm packages for SASS compilation and minification of js etc. No actual node code as such, just some jQuery. In order to not tie up the other agent, and because this stuff can run happily on Linux, I want to have this running on a small docker image rather than a full VM build agent somewhere.
I previously successfully used a node.js team city agent docker image (either jacobpeddk/teamcity-agent-nodejs or omez/teamcity-agent-nodejs - can't recall) which did work for a time, though I had issues with being able to install some npm packages globally in build scripts, which meant I had to get a bash terminal into the container and run some manual npm commands. I also I think had to run apt-get install zip to get a zipping step to work. This worked fine for a while (weeks).
I added some extra JS stuff to one of these simple projects, and suddenly I was getting errors when trying to build. I (perhaps stupidly) decided that this was probably due to the container having older versions of node and/or npm etc, so I attempted to update this by getting a bash shell into the container, installing nvm and updating node.js & npm.
This ended up with a rather broken container (node errors), so I thought I'd instead start again, but actually start with the jetbrains/minimal-build-agent Docker image instead, with the aim of ending up with a nice bespoke image for our needs specifically (as I couldn't find a very up-to-date pre-existing one)
I've running a Bash shell directly on the build agent container by executing this on the host:
docker exec -it basicagent /bin/bash
then from there I've installed nvm, Python (required for node install step) and node:
curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.2/install.sh | bash
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && \. "$NVM_DIR/nvm.sh" # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && \. "$NVM_DIR/bash_completion" # This loads nvm bash_completion
apt-get update
apt-get install python 3.6
nvm install v8.11.1 (matching version on my dev machine)
npm install -g markdown-folder-to-html (npm package I previously found I had to install globally)
apt-get install zip (just used for a build step to zip up artifacts)
If I now run (via the bash shell) npm -version I get back 5.6.
If I try to get a build to run that uses npm in a command line step, then I get this error in the build log:
/opt/buildagent/temp/agentTmp/custom_script2764770419520852926: npm: not found
I wondered if it was an issue with the user/path that the team city agent process is using vs. the one I'm using in Bash, so I added the following to the build script:
echo PATH = $PATH
echo user var = $USER
echo user via 'id':
id -u -n
the output of which is:
PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
user var =
user via id:
root
So it's running the agent as root, and doesn't appear to have node in the $PATH at all.
If I run the above directly from Bash however, I can see that I am root, but my $PATH is different:
PATH = /root/.nvm/versions/node/v8.11.1/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
root
So I'm now confused: I've re-started the container and this has had no effect - it seems that when I'm logged in as root manually I have a certain path set, but when the build agent service is running as root it's different.
I have no idea why this happens, but I've basically worked around the problem by adding:
export PATH=$PATH:/root/.nvm/versions/node/v8.11.1/bin
to the top of every build step that uses npm in a script. To my mind this seems a rather daft thing to have to do - considering this used to work without this, and the only real difference is possibly a slightly different flavour of linux container. AFAIK the original build agent container was based on the jetbrains minimal-build-agent one, so unless they've changed what they base that on it should be roughly the same...
I also had to change the compressor being used in a node-minify build step from gcc (google closure compiler) to babel-minify as the former was basically hanging indefinitely, but that is a separate problem (though also something that was fine and now isn't...)
Thanks to anyone who took the time to read... though I do wonder if one-day I'll exhaust my own research options, and finally go ask the internet and actually get someone respond - for some reason whenever I get to the point where I have to ask, it always seems no-one else has the answer either and I end up having to work it out myself. It's probably character-building though I suppose.. (this isn't just SO - I've found this be the case for over 15 years on various forums about various things...)

Browser-sync command not found even after setting the correct path to the environment variable

I am facing a problem which i found some solutions but it is still not working.I installed nodejs for windows 32 bit version, and everything went well.Now when i installed browser-sync via command line running the command
$ npm install -g browser-sync
Now everything got installed correctly with a couple of warnings. Now when i ran the command
$ browser-sync --version
it said browser-sync command not found.So i googled and found out that my environment variable might not be set correctly so it is not picking up my command. So then i tried finding the correct path to be set in the env variable via the following command which gave the result
$ npm bin -g
C:\Users\TEMP\AppData\Roaming\npm;npm\npm
(not in PATH env variable)
So i tried adding the path via the command
$ PATH %PATH%;C:\Users\TEMP\AppData\Roaming\npm;npm\npm
But it is still not working.I checked whether the path is actually added directly from the environment editor and via running the command $ Path,and it is actually adding the path but the problem still persists.
I think the problem is with the folder name which has semicolon in it "npm;npm" which is actually used to separate paths.I am not quite sure why it is adding the folder with such a name, i tried renaming it but as soon as i run the command npm bin -g it makes a new folder with the same name.
Also i tried using the short name for the folder which was "NPM_NP~1" to avoid that semicolon issue but it is still not working.
I am stuck with this since past 2 days and hopefully i can find a solution from you guys so i can get on with some actual development work. I gave you guys as much info as i could. Let me know if you need something more and specific.
You need to have NODE_PATH set:
$ set NODE_PATH=%AppData%\npm\node_modules

Grunt on Windows 8: 'grunt' is not recognized

I'm having a problem running Grunt from the command line on my Windows 8 machine.
My research indicates the most common solution is to install grunt-cli, since Grunt is no longer global. I also need to make sure I actually install the Grunt task runner, since that's not installed with grunt-cli.
Other solutions point to the PATH system environment variable, but that appears to be pointed as I'd expect to:
C:\Users[username]\AppData\Roaming\npm
Having done all that, I'm still getting a "'grunt' is not recognized as an internal or external command, operable program or batch file" error message in the CLI. I've tried the following things, uninstalling everything after every attempt:
Installed grunt-cli globally (npm install -g grunt-cli), then grunt at the directory level I want to use it (npm install grunt)
The same as above, but with the order of installation reversed
The same as both of the above, but using the Admin Command Prompt
Am I missing something obvious?
I've not had any issues with grunt on several different windows 8 machines.
If you open the folder: C:\Users\[username]\AppData\Roaming\npm
Do you have a file named grunt.cmd in this folder?
If not I'd maybe try npm install -g grunt-cli again, maybe from an elevated command prompt.
If this exists and you have C:\Users\[username]\AppData\Roaming\npm in your PATH environment variable then typing grunt from a command prompt should work.
Silly question, have you tried closing the command prompt and opening a new one?
Confirm your PATH is correct (and not messed up). Just type PATH from the command prompt. There's really no other explanation that makes sense given the error you're describing and the steps you've taken.
Normally, using the where grunt command would have found grunt.cmd in your path if npm is installed correctly and it has been properly added to the system path.
Close all Command Prompt instances.
Start a new Command Prompt instance.
Type PATH Enter and verify if C:\Users\Username\AppData\Roaming\npm is part of the path.
If not, you need to log off and on again,or close the Command Prompt and restart the explorer process.
In the Command Prompt, type where grunt Enter.
You're good if it reports:
C:\Users\Username\AppData\Roaming\npm\grunt
C:\Users\Username\AppData\Roaming\npm\grunt.cmd
Otherwise, you have to reinstall the grunt-cli package if it reports:
INFO: Could not find files for the given pattern(s).
Apparently, programs that change the PATH environment variable must broadcast a WM_SETTINGCHANGE message. The Windows' System settings window does it correctly when you change the PATH variable, but the NPM installer doesn't. That's why you have to restart explorer (or log off or restart, which has the same effect).
I know this has been answered but I thought I'd offer my step by step solution for windows 8.
First thing I checked was the PATH in my laptops Environment Variables (Right click my computer > properties > advanced system settings > Environment Variables)
It wasn't listed in there so I added a new variable in User variables (so it was specific only to my user account)
In the new user variable prompt I entered the following;
Variable Name: PATH
Variable Value: %USERPROFILE%\AppData\Roaming\npm
Quit command prompt, repoened, navigated to my projects directory and tried running grunt again and... SUCCESS!
I had the same issue.
I tried different things:
Restart computer
Deleted the grunt folder and ran
npm install -g grunt -cli
Didn't work.
Finally tried:
npm install -g grunt-cli
Worked perfectly.
Tried
where grunt
and I saw 2 locations where it was found.
I was facing the same problem on windows 8
I have added ' %APPDATA%\npm ' to the path variable . It has been working fine.
some times NPM install corrupts the basic windows path. i usually have a copy of my own version of PATH mainted separately. every week or on some installs i manually configure and update the %PATH% variable.
Basically Grunt.cmd is not availbe through %PATH% variable.
I have stucked with problem on Windows 8, that after install grunt-cli I've always got "command not found" while I'm tried to check grunt -v or where grunt. So I've added to enviroment PATH this path C:\Program Files (x86)\Git\local and run grunt.cmd from that folder (you need to look in node_modules folder here). And after reloading my terminal everything started to work.
Same happened to me and here was the solution:
Have you got 2 different versions of Node.JS installed?
Maybe Nodist?
This means you likely got NPM installed twice which will install the commands into 2 different folders:
Once into C:\Users\<user>\AppData\Roaming\npm and once into C:\dev\nodist\bin\bin.
C:\dev\nodist\bin\bin wasn't on my path variable so I added it, and I removed the Node.JS version I didn't want to use.
If you have no grunt.cmd file created by npm, make sure that you do not have a .npmrc in your home directory with: bin-links=false in it.
After getting a tonne of "'grunt' is not recognized as an internal or external command," errors, I solved this on Windows 10 by going to Path and adding C:\Users\Username\AppData\Roaming\npm

Running Azure node.js Tools on Ubuntu

I have followed these instructions.
And as far as I can tell I have successfully installed node.js azure tools. No error - nothing to suggest it failed.
However, I cannot, and the documentation says, simple run "azure"...
Maybe there is something I am missing with node.js?
There are a few problems you may be experiencing.
First of all, I would ensure you are running Node.js v0.6.20. You can do this by opening the command prompt and running:
node -v
You should have v0.6.20 echoed back.
If this doesn't work, you may be missing a path variable to Node.js or the NPM cache. Verify the Environment variables exist by running [in the command prompt]:
path
you should see two paths:
%appdata%\npm
[x64 Machine]
%programfiles(x86)%\nodejs\
[x86 Machine]
%programfiles%\nodejs\
If this doesn't work, I would check to ensure that the azure module was loaded into the %appdata%\npm\node_modules directory.
It could be the PATH issue. In my case, the azure program is located at ~/.npm-global/bin.
run "export PATH=$PATH:~/.npm-global/bin". Or just add to bash source file

Resources