I have a pipeline job, where I give npm install. The script goes like :
node {
stage('Configure repo') {
sh 'npm install'
}
}
I am getting error
/mnt/jenkins/workspace/project/proj/dura/script.sh: 2: /mnt/jenkins/workspace/project/proj/dura/script.sh: /usr/local/npm: not found
Even I tried giving sh '/usr/local/npm install' But still the same.
Please help
Run this command:
sudo -u jenkins which npm
You should see /usr/bin/npm or some other path to npm as the result. if not, run this command:
sudo apt install npm
This often happens when you don't specifically install npm after installing node. Because node installs an instance of npm in your home, which other user's will not have access to. Then you feel you already installed npm but the fact is, you didn't!
Related
Create a pipeline to do the jenkins cypress test, but I always run it, make a mistake, and try various solutions, including Jenkins Xvfb, but I still didn't succeed.
Error
+ npm run exec:e2e
> projectname#0.1.0 exec:e2e /var/lib/jenkins/workspace/project/myproject
> npx cypress run
It looks like this is your first time using Cypress: 3.4.0
[?25l[01:56:21] Verifying Cypress can run /var/lib/jenkins/.cache/Cypress/3.4.0/Cypress [started]
[01:56:21] Verifying Cypress can run /var/lib/jenkins/.cache/Cypress/3.4.0/Cypress [failed]
[?25hYour system is missing the dependency: Xvfb
Install Xvfb and run Cypress again.
Read our documentation on dependencies for more information:
https://on.cypress.io/required-dependencies
If you are using Docker, we provide containers with all required dependencies installed.
----------
Error: spawn Xvfb ENOENT
----------
Platform: linux (Ubuntu Linux - 19.04)
Cypress Version: 3.4.0
[?25hnpm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! projectname#0.1.0 exec:e2e: `npx cypress run`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the projectname#0.1.0 exec:e2e script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! A complete log of this run can be found in:
npm ERR! /var/lib/jenkins/.npm/_logs/2019-07-24T01_56_21_795Z-debug.log
I get resolved this question with other solution.
First, i created a pipeline
stage('E2E Tests') {
sh 'docker run -v $PWD:/e2e -w /e2e cypress/included:3.4.0'
}
What you can do is having a lock on your stage
stage('Run E2E tests') {
dir("cypress-e2e-tests") {
lock("cypress-e2e-tests-${env.NODE_NAME}") {
sh 'docker run -v $PWD:/e2e -w /e2e cypress/included:3.4.0'
}
}
}
I wrote a jenkins pipeline that check out the git repo code and do the npm install command and strapi start command . But when it execute strapi start it shows error like "(node:12501) UnhandledPromiseRejectionWarning: Error: ER_ACCESS_DENIED_ERROR: Access denied for user 'dev_user'#'localhost' (using password: YES)" . I does not know why it happens but it successfully completed the npm install command. Any help. This is stage I am getting error.
stage('Install all dependencies and start'){
echo 'INFO - Starting installing the package.json file'
sh 'npm install'
sh 'strapi start'
}
Thank you
I'm trying to get one of our very simple flutter apps to run its test suite in Jenkins.
I have the following Dockerfile:
FROM ubuntu:bionic
ARG WORKING_DIR=${HOME}
ARG FLUTTER_ARCHIVE=flutter_linux_v0.5.1-beta.tar.xz
COPY ${FLUTTER_ARCHIVE} ${WORKING_DIR}
RUN apt-get update
RUN apt-get -y install xz-utils
RUN tar -xf "${WORKING_DIR}/${FLUTTER_ARCHIVE}"
ENV PATH="${WORKING_DIR}/flutter/bin:${PATH}"
RUN apt-get -y install git libglu1 lib32stdc++6
RUN rm ${WORKING_DIR}/${FLUTTER_ARCHIVE}
I build the container on my machine, navigate to the source code directory of the flutter app and run the following command:
docker run -td -vpwd:/source flutter:flutter
Where flutter:flutter is my built image.
I navigate into the container using docker exec and execute flutter packages get and then flutter test. Everything works as expected and all tests pass.
However, when I try to use the exact same Dockerfile through Jenkins, I get following error:
/flutter/bin/flutter: line 161: /flutter/bin/cache/dart-sdk/bin/dart: Permission denied
I'm guessing it has something do with users and that differs somehow between how Jenkins runs and how it works when I run the steps manually. The steps in the Jenkinsfile are exactly as what I ran manually above:
stages {
stage('test') {
steps {
script {
sh 'flutter packages get'
sh 'flutter test'
}
}
}
}
And I have pointed to our local registry where the image resides:
agent {
docker "flutter:flutter"
}
I am out of ideas and I don't really know how to solve this error. Any help would be greatly appreciated.
UPDATE
I have tried the following:
Creating a user in the Dockerfile using useradd and then switching to that user using USER <user> Dockerfile syntax and performing all operations as that user.
Creating a user in the Dockerfile using useradd, performing all operations as root but then setting chown user:user -R /flutter to change ownership of Flutter directory
Both of the above required me to add the following to the Jenkinsfile:
agent {
docker {
image 'flutter:flutter'
args '-u user --privileged'
}
}
But still no luck.
Problem
My wercker build exits with Failed step: setup environment - Command exited with exit code: 1 when I'm switching user in my Docker image. I'm running wercker dev from the commandline. The Dockerfile builds fine with Docker itself on the commandline, as well as on Docker Hub. I can run it fine. It's just when I use it for wercker, that the error occurs.
For example in my Dockerfile is the following code:
# Adding user
RUN adduser --disabled-password --gecos '' dockworker && adduser dockworker sudo && echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers
RUN mkdir -p /home/dockworker && chown -R dockworker:dockworker /home/dockworker
USER dockworker # Line the build seems to break on
When I comment this line out, it seems to pass. Now the problem with this, for me, is the following: I'd like to switch to another user, since I'm trying to install nvm (for gulp, bower). Generally I don't prefer to install this this as root, therefore I add a user for this.
Workaround?
However, when I do install nvm as root in my Dockerfile (so just removing the user related lines in the codeblock above completely):
ENV NODE_VERSION 0.12.7
ENV NVM_DIR /usr/local/nvm
# NVM
RUN curl https://raw.githubusercontent.com/creationix/nvm/v0.25.4/install.sh | NVM_DIR=/usr/local/nvm bash
#install the specified node version and set it as the default one, install the global npm packages
RUN . /usr/local/nvm/nvm.sh && nvm install $NODE_VERSION && nvm alias default $NODE_VERSION && npm install -g bower && npm install -g gulp
Then it does get past the setup environment stage, but during the steps it errors out that nvm and npm are not found. The step in the wercker.yml:
box:
id: francobolli/docker-ubuntu-14.04-php-5.6
tag: latest
env:
NVM_DIR: /usr/local/nvm
dev:
steps:
- script:
name: gulp styles and javascript
code: |
npm install
bower install --allow-root
gulp --env=production
I don't really understand this. When I run both docker images from the commandline (so with wercker removed from the context completely) I can execute nvm and npm just fine, but when I'm running it through wercker, it seems the .bashrc file is not being executed. When I cat ~/.bashrc during the steps, I can see:
export NVM_DIR="/usr/local/nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # This loads nvm
Workaround!
When I enter this in a step, it will be executed and I can npm install without a problem, so it seems this is never executed through the .bashrc:
...
- script:
name: gulp styles and javascript
code: |
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh" # It works when I put it here, but it's also in ~/.bashrc, which doesn't seem to get executed
npm install
...
Note: If I source ~/.bashrc in the wercker step instead, it does not work.
Question
So my question is: What am I doing wrong, for not being able to switch user in the Wercker build and even if I could, would I have the same problem as running nvm with root: nvm and npm CAN be found when a Docker container is instantiated from the commandline, but CAN'T be found when running it with Wercker. What's the best solution?
I'd rather not add commands in the wercker.yml if it can be resolved through proper user configuration or proper nvm configuration. Sorry if I'm missing something very obvious.
This has nothing to do with Docker configuration, but with how Wercker handles Docker boxes. From the documentation:
Using Sudo
The sudo command is no longer supported in wercker v2 and effectively does nothing when used.
And for deployment:
Please note that if you update a project to make use of Docker (Ewok version) and this project has autodeployment, this deploy will most likely fail. We will update our documentation in the future on how to deploy these containers.
However, I did get it to build (and deploy) with the solution (temporary workaround?) as displayed in the original question.
It happens to me that most of the builds are compiled correctly, but from time to time the same error appears (without changing any .travis.yml parameter)
The error is:
The command "sudo easy_install cpp-coveralls" failed and exited with 1 during .
Now my build got stucked on it when the previous builds have successfully passed this step without problems.
This is the failing build: https://travis-ci.org/pubnative/pubnative-ios-library/builds/49482893
This is the repo: https://travis-ci.org/pubnative/pubnative-ios-library/
Why is it so randomly failing?
try pip install cpp-coveralls --user `whoami`
edit:
pip install cpp-coveralls is the way to install package on python (instead of easy_install)
--user `whoami` is to install it without sudo, in a Travis container (like OP is doing)
Just went through this yesterday. I've attached a simplified version of the .travis.yml file I use for my project.
before_install:
- pip install --user cpp-coveralls
after_success:
- '$([ "$TRAVIS_OS_NAME" == "osx" ] && echo ~/Library/Python/2.7 || echo ~/.local)/bin/cpp-coveralls --gcov-options "\-lp"'
pip install cpp-coveralls --user
is indeed the correct way to do it, but where it ends up required a bit (a lot?) of research. The answer was simple, but incredibly un-documented.