Jenkins could not run shell script. I've installed Jenkins on my kubernetes cluster.
Here is the part of build console output:
Start building Frontend and Backend Docker images
[Pipeline] }
[Pipeline] container
[Pipeline] {
[Pipeline] container
[Pipeline] {
[Pipeline] echo
Building Bmf Frontend Image
[Pipeline] sh
[Pipeline] echo
Buildinging Bmf Backend Images
[Pipeline] sh
+ chmod +x build.sh
[Pipeline] // stage
[Pipeline] }
[Pipeline] sh
+ chmod +x build.sh
[Pipeline] sh
+ ./build.sh --build_bmf_frontend
build.sh - Script for building the Web Application, Docker image and Helm chart
Usage: ./build.sh <options>
--build_bmf_frontend : [optional] Build Bmf Frontend image
--build_bmf_backend : [optional] Build Bmf Backend image
--push_bmf_frontend : [optional] Push Bmf Frontend image
--push_bmf_backend : [optional] Push Bmf Backend image
--delete_frontend : [optional] Delete Bmf Frontend image
--delete_backend : [optional] Delete Bmf Backend image
--deploy_stage : [optional] Deploy to Stage Server
--deploy_production : [optional] Deploy to Production Server
--registry reg : [optional] A custom docker registry
--docker_usr user : [optional] Docker registry username
--docker_psw pass : [optional] Docker registry password
--tag tag : [optional] A custom app version
-h | --help : Show this usage
[Pipeline] }
[Pipeline] // container
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
The job is executed on kubernetes worker provisioned from template Kubernetes Pod Template.
Here is my Jenkinsfile command:
stage('Build BMF Frontend') {
steps {
container('jnlp') {
echo 'Building Bmf Frontend Image'
sh "chmod +x build.sh"
sh "./build.sh --build_bmf_frontend"
}
}
}
Below is a screenshot of my Jenkins workspace;
When using the snippet generator, all sh commands are generated with single quotes. Perhaps you should use that instead?
https://jenkins.io/doc/book/pipeline/getting-started/#snippet-generator
Your pipeline is executed correctly.
The output returned suggests that the issue is from your script.
Even though Jenkins executed successfully, you do not get it to work as projected owing to a problem in your code.
You may want to check your build.sh script, probably the section where it parses input options.
I am executing it with sh which has a less extensive syntax ;)
Related
I am using a very simple script mentioned below as per the official docs (https://www.jenkins.io/doc/book/pipeline/docker/):
pipeline {
agent {
docker { image 'node:14-alpine' }
}
stages {
stage('Test') {
steps {
sh 'node --version'
}
}
}
}
Simple as it is, it outputs follows:
22:58:45 [Pipeline] }
22:58:45 [Pipeline] // stage
22:58:45 [Pipeline] withEnv
22:58:45 [Pipeline] {
22:58:45 [Pipeline] isUnix
22:58:45 [Pipeline] sh
22:58:45 + docker inspect -f . node:14-alpine
22:58:46 Sorry, home directories outside of /home are not currently supported.
22:58:46 See https://forum.snapcraft.io/t/11209 for details.
22:58:46 [Pipeline] isUnix
22:58:46 [Pipeline] sh
22:58:46 + docker pull node:14-alpine
22:58:46 Sorry, home directories outside of /home are not currently supported.
22:58:46 See https://forum.snapcraft.io/t/11209 for details.
22:58:46 [Pipeline] }
22:58:46 [Pipeline] // withEnv
22:58:46 [Pipeline] }
22:58:46 [Pipeline] // node
22:58:46 [Pipeline] End of Pipeline
22:58:46 ERROR: script returned exit code 1
22:58:46 Finished: FAILURE
Not sure what I am doing wrong.
The hyperlink inside the message leads to a page that says:
Snapd does currently not support running snaps if the home directory of the user is outside of /home.
It says that for the docker command. I suspect you're trying to run the docker command as the jenkins user. The default home directory for the jenkins user is /var/lib/jenkins. The default home directory of the jenkins user is outside /home.
If that's the case, there are several alternatives available:
Create a user on that computer with a home directory in /home and run a Jenkins agent as that user
Install docker on that computer using apt instead of using snapd (following the Docker directions rather than the Ubuntu directions)
Create a user on another computer with a home directory in /home and install docker there with snapd, then configure an agent to use that computer
It's likely you are inheriting the HOME environment variable from Jenkins in some way. You can use env config to override that. If you want the HOME from the worker node executing the docker build you can mount env.HOME into /home/jenkins (or something like that) into the container.
Something like:
pipeline {
agent {
docker {
image 'node:14-alpine'
args '-v $HOME:/home/jenkins'
}
}
...
}
I am extremely new to Jenkins. I tried out few basic pipeline examples which worked.
My concrete use case is following:
I have a base image in my docker hub repository : my_dockerhub_rep/myImage:v1
Now I want to build another image based on this base image through a Jenkins pipeline.
So i wrote the following dockerfile :
FROM my_docker_hub_rep/myImage:v1
RUN /bin/bash -c 'echo entering in MC container'
To build this image from Jenkins, i wrote the following Jenkinsfile:
pipeline {
agent { dockerfile {
filename "/home/user/Desktop/Dockerfile"
registryUrl ""
registryCredentialsId 'dockerHub'
}}
stages {
stage('Build') {
steps {
echo 'hello !'
sh 'echo LM_LICENSE_FILE = $LM_LICENSE_FILE'
}
}
The jenkins server can successfully login to the docker repository at first but then as soon as it tries to fetch the base image it throws an error that pull access denied : repository doesnt exist or requires docker login.
What i dont understand is if it could login into the docker repo once then why not again ?
Here is the console output of jenkins :
Started by user unknown or anonymous
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/lib/jenkins/workspace/docker_test
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] withDockerRegistry
$ docker login -u mydockerID-p ******** https://index.docker.io/v1/
WARNING! Using --password via the CLI is insecure. Use --password-stdin.
WARNING! Your password will be stored unencrypted in /var/lib/jenkins/workspace/docker_test#tmp/a548cbfa-5d55-4a2c-87a7-4954052d7e5b/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Declarative: Agent Setup)
[Pipeline] isUnix
[Pipeline] readFile
[Pipeline] sh
+ docker build -t b2f2e9020bdfdbcd1bc3d0a6f0f28b1c7abff41b -f /home/user/Desktop/Dockerfile .
Sending build context to Docker daemon 2.095kB
Step 1/8 : FROM my_docker_rep/myImage:v1
pull access denied for my_docker_rep/myImage, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withDockerRegistry
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 1
Finished: FAILURE
ps: i already added jenkins to the user group.
Your docker file should have a full image reference. <registry>/<repository>/<imagename>:<image_tag> if not, the docker demon will always try to pull image from the default docker registry. Change the FROM part of your DOCKERFILE to contain the full image path. It will work
I need to build docker image with set of attributes through Jenkins, i also need to pass my private key as a argument, but while build the image i am getting the private key in my Jenkins log. I need to get rid of it and i need only the image build logs, anyone please help me on this
docker build --build-arg SSH_PRIVATE_KEY=$(cat ~/.ssh/id_rsa)-t ${REGISTRY}/${APPLICATION_NAME}:PR-${CHANGE_ID} .
As mentioned by #David
You shouldn't pass ssh keys into your build sequence like this at all
But to answer your question, modify the bash script and it will not display the content your ssh-key.
set +x
docker build --build-arg SSH_PRIVATE_KEY="$(cat ~/.ssh/id_rsa)" -t ssha .
set -x
you will not able to see the ssh_key during the build time, but it will be set, you can verify
docker run --rm ssha bash -c "cat ~/.ssh/id_rsa"
Try using MaskPasswordWrapper, it would successfully mask all the variables that are specified throughout the jenkins console log.
Plugin Link: https://wiki.jenkins.io/display/JENKINS/Mask+Passwords+Plugin
script{
san7ket = 'lololol'
wrap([$class: 'MaskPasswordsBuildWrapper', varMaskRegexes: [[regex: '(.)']], varPasswordPairs: [[var: 'sjagtap', var:'a']]]) {
// some block
echo san7ket
echo a
}
}
Output:
[Pipeline] script
[Pipeline] {
[Pipeline] wrap
[Pipeline] {
[Pipeline] echo
********************************************************
[Pipeline] echo
****************************************************************************************
[Pipeline] }
[Pipeline] // wrap
[Pipeline] }
[Pipeline] // script
So, I have this pipeline job that builds completely inside a Docker container. The Docker image used is pulled from a local repository before build and has almost all the dependencies required to run my project.
The problem is I need an option to define volumes to bind mound from Host to container so that I can perform some analysis using a tool available on my Host system but not in the container.
Is there a way to do this from inside a Jenkinsfile (Pipeline script)?
I'm not fully clear if this is what you mean. But if it isn't. Let me know and I'll try to figure out.
What I understand of mounting from host to container is mounting the content of the Jenkins Workspace inside the container.
For example in this pipeline:
pipeline {
agent { node { label 'xxx' } }
options {
buildDiscarder(logRotator(numToKeepStr: '3', artifactNumToKeepStr: '1'))
}
stages {
stage('add file') {
steps {
sh 'touch myfile.txt'
sh 'ls'
}
}
stage('Deploy') {
agent {
docker {
image 'lvthillo/aws-cli'
args '-v $WORKSPACE:/project'
reuseNode true
}
}
steps {
sh 'ls'
sh 'aws --version'
}
}
}
post {
always {
cleanWs()
}
}
}
In the first stage I just add a file to the workspace. just in Jenkins. Nothing with Docker.
In the second stage I start a docker container which contains the aws CLI (this is not installed on our jenkins slaves). We will start the container and mount the workspace inside the /project folder of my container. Now I can execute AWS CLI command's and I have access to the text file. In a next stage (not in the pipeline) you can use the file again in a different container or jenkins slave itself.
Output:
[Pipeline] {
[Pipeline] stage
[Pipeline] { (add file)
[Pipeline] sh
[test] Running shell script
+ touch myfile.txt
[Pipeline] sh
[test] Running shell script
+ ls
myfile.txt
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Deploy)
[Pipeline] getContext
[Pipeline] sh
[test] Running shell script
+ docker inspect -f . lvthillo/aws-cli
.
[Pipeline] withDockerContainer
FJ Arch Slave 7 does not seem to be running inside a container
$ docker run -t -d -u 201:201 -v $WORKSPACE:/project -w ... lvthillo/aws-cli cat
$ docker top xx -eo pid,comm
[Pipeline] {
[Pipeline] sh
[test] Running shell script
+ ls
myfile.txt
[Pipeline] sh
[test] Running shell script
+ aws --version
aws-cli/1.14.57 Python/2.7.14 Linux/4.9.78-1-lts botocore/1.9.10
[Pipeline] }
$ docker stop --time=1 3652bf94e933cbc888def1eeaf89e1cf24554408f9e4421fabfd660012a53365
$ docker rm -f 3652bf94e933cbc888def1eeaf89e1cf24554408f9e4421fabfd660012a53365
[Pipeline] // withDockerContainer
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (Declarative: Post Actions)
[Pipeline] cleanWs
[WS-CLEANUP] Deleting project workspace...[WS-CLEANUP] done
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
In your case you can mount your data in the container. Perform the stuff and in a later stage you can do your analysis on your code on your jenkins slave itself (without docker)
Suppose you are under Linux, run the following code
docker run -it --rm -v /local_dir:/image_root_dir/mount_dir image_name
Here is some detail:
-it: interactive terminal
--rm: remove container after exit the container
-v: volume or say mount your local directory to a volume.
Since the mount function will 'cover' the directory in your image, your should alway make a new directory under your images root directory.
Visit Use bind mounts to get more information.
ps:
run
sudo -s
and tpye the password before you run docker, that saves you a lot of time, since you don't have to type sudo in front of docker every time you run docker.
ps2:
suppose you have an image with a long name and the image ID is 5ed6274db6ce, you can simply run at least the first three digits, or more
docker run [options] 5ed
if you have more image have the same first three digits, you can use four or more.
For example, you have following two images
REPOSITORY IMAGE ID
My_Image_with_very_long_name 5ed6274db6ce
My_Image_with_very_long_name2 5edc819f315e
you can simply run
docker run [options] 5ed6
to run the image My_Image_with_very_long_name.
I set up pipeline to build my wildfly-swarm based microservice build docker image and push it to docker repository. So I set up pipeline script and executed build and from logs (attached bellow) we see that build was successful but I get failed status in stage view with error: "Script returned exit code 1".
And the script that failed was:
docker build -f Dockerfile -t swarm-microservice .
It does not matter if I change script execution from:
sh '''docker build -f Dockerfile -t swarm-microservice .'''
to:
script {
docker.build("swarm-microservice", '.')
}
I have also tried to change the output of the script result by changing script to:
sh '''docker build -f Dockerfile -t swarm-microservice . || true '''
But its not helping. What am I missing?
Started by user test
[Pipeline] node
Running on node-lin02 in /build/workspace/XYZ/some-docker-image
[Pipeline] copyArtifacts
Copied 2 artifacts from "XYZ » swarm-microservice" build number 49
Copied 0 artifacts from "XYZ » swarm-microservice » XYZ-swarm-microservice" build number 49
[some-docker-image] Running shell script
[some-docker-image] Running shell script
+ docker build -f Dockerfile -t swarm-microservice .
Sending build context to Docker daemon 380.9MB
Step 1/4 : FROM openjdk:8u151-jdk-slim
---> 22f79f57057d
Step 2/4 : ADD swarm-microservice-swarm.jar /opt/swarm-microservice-swarm.jar
---> Using cache
---> 16f16f07a4da
Step 3/4 : EXPOSE 8281
---> Using cache
---> 26820815d1d1
Step 4/4 : ENTRYPOINT java -jar -Djava.net.preferIPv4Stack=true -XX:MaxRAM=512m /opt/swarm-microservice-swarm.jar -S src
---> Using cache
---> 41c896987ba6
Successfully built 41c896987ba6
Successfully tagged swarm-microservice:latest
[Pipeline] sh
[some-docker-image] Running shell script
+ set -e
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (tag docker image)
[Pipeline] sh
[some-docker-image] Running shell script
+ docker tag swarm-microservice my.awesome.demo.so.test.repo.com:5000/XYZ/swarm-microservice
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
[Pipeline] { (push docker image to repository)
[Pipeline] sh
[some-docker-image] Running shell script
+ docker push my.awesome.demo.so.test.repo.com:5000/XYZ/swarm-microservice
The push refers to a repository [my.awesome.demo.so.test.repo.com:5000/XYZ/swarm-microservice]
2e35fec0db40: Preparing
c09cee929b6f: Preparing
5f09fc66f922: Waiting
cec7521cdf36: Waiting
2e35fec0db40: Layer already exists
063e7100cc44: Layer already exists
latest: digest: sha256:xxx size: 1788
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS