Different working directories in jenkins pipeline - jenkins

Here's a simple Jenkins pipeline job that highlights the different working directories seen by sh vs script.
pipeline {
agent any
stages {
stage('Stage1') {
steps {
sh """
pwd
"""
script {
echo "cwd--pwd: "+ "pwd".execute().text
}
}
}
}
}
Here's how the Jenkins instance was launched
/Users/MyJenkinsUser/dirJenkinsLaunched$ java -jar /Applications/Jenkins/jenkins.war --httpPort=8080
Here's the console output of the job...
Started by user MyJenkinsUser
Running in Durability level: MAX_SURVIVABILITY
[Pipeline] node
Running on Jenkins in /Users/MyJenkinsUser/.jenkins/jobs/TestPipeline/workspace
[Pipeline] {
[Pipeline] withEnv
[Pipeline] {
[Pipeline] stage
[Pipeline] { (Stage1)
[Pipeline] sh
[workspace] Running shell script
+ pwd
/Users/MyJenkinsUser/.jenkins/jobs/TestPipeline/workspace
[Pipeline] script
[Pipeline] {
[Pipeline] echo
cwd--pwd: /Users/MyJenkinsUser/dirJenkinsLaunched
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // withEnv
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
Finished: SUCCESS
I find it curious that they would be different working directories, the shell command sh step uses the workspace as the working directory while the groovy script step uses the directory the Jenkins process was launched.
Question: how can I make my Jenkins scripted pipeline steps (script) use the workspace as the working directory by default?
I guess it makes sense after realizing this most clearly, that groovy is a java thing and we launch the Jenkins war file from java, and that launching imposes a certain working directory. I wonder the origins of this design for the Jenkins behavior. It made me go a bit wonky with a bunch of file not found errors as I ported some sh commands into the more substantive groovy syntax because I wanted to avoid all the double nesting escaping craziness that one can fall into in the shell, especially when spaces are invoked in paths and what not.

You shall not use execute() in Jenkins pipelines. Use the pipeline DSL's steps instead of arbitrary Groovy code.
As you noticed, this such "native" code is executed on the Jenkins master and without any relation to the current job.

Unfortunately this may not be a possible operation. I'll have to redesign the script code to explicitly use the workspace variable instead of relying on the current working directory Java uses.
Changing the current working directory in Java?

Related

Jenkins console output not printing anything between start and end of pipeline

I have created a new job in Jenkins using pipeline. After this I have provided Gitlab project url and Jenkinsfile path in SCM. While building the pipeline I am not able to see any message between start pipeline and end pipeline.
While putting invalid code to JenkinsFile, build is failing but when running simple command like echo its not printing anything to console.
Is there anything I am missing?
Console Output
[Pipeline] Start of Pipeline
[Pipeline] End of Pipeline
Finished: SUCCESS
Jenkinsfile
pipeline {
agent any
stages {
stage ('Build') {
steps {
echo
'Running build phase. '
}
}
}
}
console output
Jenkinsfile code
I would suggest to install all the required plugins and then restart your Jenkins server and if you are running this locally then a system restart might be helpful.
For testing, try the same echo in a scripted pipeline block:
steps {
script {
echo 'Running build phase. '
}
}

Disable displaying '[Pipeline]*' lines in Jenkins pipeline logs?

Jenkins scripted pipeline logs are littered with lines that begin with [Pipeline] that give insight to pipeline flow. Is there a way, using groovy scripted pipelines, to not include them in the logs?
[Pipeline] Start of Pipeline
[Pipeline] node
Running on Jenkins in /var/jenkins_home/jobs/pipe/jobs/pd.oh52a1/branches/dev/workspace
[Pipeline] {
[Pipeline] sh
+ echo /var/jenkins_home/jobs/pipe/jobs/pd.oh52a1/branches/dev/workspace
[Pipeline] }
[Pipeline] // node
[Pipeline] echo
I am hoping I can programmatically enable/disable these at the beginning of a run so I can see them if I want to but turn them off by default.

How to reduce the console output of a Jenkins Groovy pipeline job?

I have a Jenkins job implemented as a groovy pipeline with some windows batch calls (NOT bash shell) in it. The Jenkins console output is very verbose, so every line of the groovy script, even the curly braces "{" are being displayed...
Example:
[Pipeline] }
[Pipeline] // script
[Pipeline] }
[Pipeline] // node
[Pipeline] }
[Pipeline] // stage
[Pipeline] stage
I actually expected this to be a simple Jenkins setting... However after reading a dozen of links I could not find any useful solution for this particular case - a groovy pipeline (with some windows batch calls in it).
Anyone know a way to solve this?
Interestingly enough there's an open bug for this: https://issues.jenkins-ci.org/browse/JENKINS-45210
You can quiet those down by altering the Extra CSS field in Jenkins' System Configuration. I added the following:
.pipeline-new-node {
display: none;
}

jenkins workspace dir issue

My pipeline has been work all good until today.
Jenkins dynamically spins up a slave container (docker cloud) where all my steps are run from. Error as below, just wondering why jenkins create a tmp dir in the workspace dir.
[Pipeline] sh
[xxx_root_proj] Running shell script
+ cd ./xxx_root_proj
/home/jenkins/workspace/xxx_root_proj#tmp/durable-b532c37c/script.sh: 3: cd: can't cd to ./xxx_root_proj
[Pipeline] }
[Pipeline] // withCredentials
[Pipeline] }
[Pipeline] // stage
[Pipeline] }
[Pipeline] // node
[Pipeline] End of Pipeline
ERROR: script returned exit code 2
Finished: FAILURE
Just wondering if anyone has come across this before.
I think the "/home/jenkins/workspace/xxx_root_proj#tmp" is the problem, not sure how jenkins uses this.
Thanks in advance
#tmp folder is created by Jenkins in workspace for shared library components etc. Basically a temp working dir for the pipeline

Jenkins pipeline working in different folders

Alright so I am just learning about pipelines in Jenkins and I've ran into a small problem.
It is building my war file in one directory but trying to build the docker image in another one, which will ofcourse fail.
so a shorthand log describes the problem quite well:
[Pipeline] stage
[Pipeline] { (build war)
[Pipeline] node
Running on Jenkins in /root/.jenkins/workspace/Wunderbaren#2
[Pipeline] {
[Pipeline] stage
[Pipeline] { (build dockerimage)
[Pipeline] script
[Pipeline] {
[Pipeline] dir
Running in /root/.jenkins/workspace/Wunderbaren/backend
[Pipeline] {
the Jenkinsfile:
pipeline {
agent any
stages {
stage('build war') {
agent {
docker { image 'gradle:latest' }
}
steps {
sh 'gradle war -b backend/build.gradle'
}
}
stage('build dockerimage') {
steps {
script {
dir('backend/') {
def image = docker.build("munhunger/wunderbaren")
docker.withRegistry('https://registry.hub.docker.com', 'docker-hub-credentials') {
image.push("${env.BUILD_NUMBER}")
image.push("latest")
}
}
}
}
}
}
}
What I find odd is that I have a similar project with pretty much the exact same configuration. only differs in folder names and docker tag. And that seems to be working 100% of the times, so I feel quite lost on this one!
Turns out you need to reuse the node:
stage('build war') {
agent {
docker {
image 'gradle:latest'
reuseNode true
}
}
steps {
sh 'gradle war -b backend/build.gradle'
}
}
From the documentation I found at https://go.cloudbees.com/docs/cloudbees-documentation/use/reference/pipeline/
reuseNode
A boolean, false by default. If true, run the container in the node specified at the top-level of the Pipeline, in the same workspace, rather than on a new node entirely.
This option is valid for docker and dockerfile, and only has an effect when used on an agent for an individual stage.
From Jenkins Pipeline Documentation
The agent section specifies where the entire Pipeline, or a specific stage, will execute in the Jenkins environment depending on where the agent section is placed. The section must be defined at the top-level inside the pipeline block, but stage-level usage is optional.
I believe this means the 'build war' stage will execute in a separate environment from the 'build docker image' stage. As far as similar syntax working in a different job, perhaps the same agent is defined for both stages?

Resources