73

Please note: The following works for scripted pipelines only. For a solution for declarative pipelines see @kgriffs' answer. --- Figured it out. Outside of any stages (otherwise this will just end the particular stage as a success) do the following; if( $VALUE1 == $VALUE2 ) { currentBuild.result = 'SUCCESS' return } return will stop the stage or node ...


23

Jenkins can filter branches in a multibranch pipeline by name using a wildcard or regular expression.


20

Any one facing the same problem and using pipeline project, set JENKINS_NODE_COOKIE instead of BUILD_ID. Dont waste your time setting HUDSON_COOKIE, HUDSON_SERVER_COOKIE, JENKINS_COOKIE or JENKINS_SERVER_COOKIE. None of them work for pipeline project. Refer to https://issues.jenkins-ci.org/browse/JENKINS-28182 for more details.


18

The variable must be defined in a script section. pipeline { agent none stages { stage("first") { script { foo = "bar" } sh "echo ${foo}" } } }


17

You can also use error to exit the current stage, then you don't have to consider the current stage hierarchy and similar stuff: def autoCancelled = false try { stage('checkout') { ... if (your condition) { autoCancelled = true error('Aborting the build.') } } } catch (e) { if (autoCancelled) { currentBuild.result = '...


15

You can use the "when" block combined with the built in "changeset" condition to conditionally run only certain stages of your monorepo's pipeline. From the when.changeset documentation: changeset- Executes the stage if the build’s SCM changeset contains one or more files matching the given string or glob. Example: when { changeset "**/*.js" } Here is an ...


13

The Executor.interrupt(Result) method is the cleanest, most direct way I could find to stop a build prematurely and mark it as a success. script { currentBuild.getRawBuild().getExecutor().interrupt(Result.SUCCESS) sleep(1) // Interrupt is not blocking and does not take effect immediately. } Pros: Works in a declarative pipeline just as well as a ...


12

I had the same issue with node. The thing is files in the container are owned by "root:root". Try adding docker args -u root:root: docker { image 'node:8' args '-u root:root' }


12

You need to define variables before the pipeline block starts. Then it should be work. def foo = "foo" pipeline { agent none stages { stage("first") { sh "echo ${foo}" } } }


11

You may try something like this: node('my_kubernetes_pod') { passedBuilds = [] lastSuccessfulBuild(passedBuilds, currentBuild); def changeLog = getChangeLog(passedBuilds) echo "changeLog ${changeLog}" } def lastSuccessfulBuild(passedBuilds, build) { if ((build != null) && (build.result != 'SUCCESS')) { passedBuilds....


10

Based on the comments to my question, and some basic testing the following seems to work: Use nested parallel statements. (Thanks @lawnmowerlatte) Although today (May 15th 2017) Jenkins Blue ocean does not visualise this properly. Possible solutions discussed here


9

In my automatic jenkins job, launched daily, if there are no changes the git commit command returns 1. That will mark the build as failed. To solve this problem I use these two commands in my shell build step: git add -A git diff-index --quiet HEAD || git commit -m "Jenkins automatic update commit" the first will eventually add all unstaged files in the ...


9

Found the problem: I was using the human readable key name from the GUI. Need to use the key's UUId ID instead (this is specified next to the name in credentials screen) steps { sshagent ( ['THIS-SHOULD-HAVE-BEEN-A-UNIQUE-ID-INSTEAD-OF-A-NAME']) {


8

You can use the checkout scm step whenever you need the source: pipeline { agent none options { skipDefaultCheckout() } stages { stage('Build') { agent { node { label 'builder' } } steps { checkout scm echo 'build-the-app' stash(name: 'app', includes: 'outputs') } } stage('Test') { agent { ...


8

It really comes down to personal preference. One additional tool you might not be aware of are shared libraries for Pipeline. These allow you to quickly write custom Pipeline steps or factor out common Pipeline code without writing a Jenkins plugin in Java. Between multiple Pipeline jobs and shared libraries, there are many ways to split up your job's ...


6

In order to get a success, you need to avoid non-zero exit codes. A simple solution would be to change the last line of your script to git commit -a -m 'Changes pushed by Jenkins' || true, but better solutions would parse the output of git-add and only run git-commit when there is something to commit.


6

In Groovy you have to use double quotes to get string interpolation: if ( "$output" != null ) { slackSend (channel: "@${name}", color: '#36A64F', message: "Job succeeded") } else { slackSend (channel: "@${name}", color: '#36A64F', message: "Job failed") } You can also probably do something like this to avoid it entirely and have ...


6

Turns out you can hit the following URL to get an XML output of all currently running builds, including their build numbers. http://jenkinsURL/computer/api/xml?tree=computer[executors[currentExecutable[url]],oneOffExecutors[currentExecutable[url]]]&xpath=//url&wrapper=builds I greped it for a count and used that for my calculations.


6

Continuous integration means roughly what you said. Whenever something is committed, it is automatically built and tested, with a red/green light showing up at the end. Continuous deployment takes this a step further and whenever a green light turns up, automatically deploys that. Note that "tested" above can mean several steps: smoke tests (does it crash ...


6

Here is a solution which seems almost like a workaround that I have found which works for declarative pipelines. First, we need to add some code at the start of our file before we enter into the pipeline{} section. The code we add will run before the pipeline section, and will check if the env/param exists, and if it does will take the value, otherwise we ...


6

The other answer is incorrect. There is indeed a builtin to retry arbitrary sections of your job called retry. If you want to retry the whole job three times, you can wrap your entire job in a retry block: retry(count: 3) { // your job definition here } However, if it's safe to do so, I would recommend wrapping individual steps or stages instead: ...


6

You can also use environment block to inject an environment variable. (Side note: sh is not needed for echo) pipeline { agent none environment { FOO = "bar" } stages { stage("first") { steps { echo "${env.FOO}" // or echo "${FOO}" } } } } You can even ...


6

Rebuild, using the Rebuilder plugin allows a completed job to be re-executed while allowing you to change the parameters, assuming your job is parameterized. Replay does something similar, except it doesn't show you parameters. Instead, it shows the pipeline code directly. This is helpful when wanting to test changes iteratively as you can click Replay, ...


5

I had a similar situation in which I wanted to nest other parallel jobs threads inside another parallel one. This code worked for me: def performDeploymentStages(String node, String app) { stage("build") { echo "Building the app [${app}] on node [${node}]" } stage("deploy") { echo "Deploying the app ${app}] on node [${node}]" ...


5

You could try to run the artifactory file upload in parallel if you are using the Jenkinsfile syntax: https://github.com/jenkinsci/pipeline-examples/blob/master/pipeline-examples/parallel-from-list/parallelFromList.groovy Here is a simpler example to run things in parallel if you only have a fixed number of things you want to do in parallel: parallel ( ...


5

Get a list of changed files and use that to determine which tests to run. Load external Groovy scripts at run time in order to run your deploys.


5

Jenkins Job and Jenkins Pipeline are basically the same. In a pipeline you define the steps of your job as groovy code (actually it is CPS https://github.com/jenkinsci/workflow-cps-plugin, but that should in general just be a custom groovy interpreter). The point, that is making pipelines "better", form my perspective, is, that you can add those in so-...


5

You can use params['IP Address']. Think of params as a Map containing a key 'IP Address'. If the key didn't have a space, then you could use params.IPAddress or params['IPAddress'], but when there's a space, you can only use the latter syntax. That syntax is also useful when you're computing the key name to look up, and have stored it in a variable: final ...


5

Looks like you are using the Gitlab plugin for jenkins? if so this link should be of help https://github.com/jenkinsci/gitlab-plugin#declarative-pipeline-jobs


5

For Declarative Pipeline: This question already has a highly-upvoted answer on StackOverflow: If you want to use a file (since a script is the thing generating the value you need): pipeline { agent { label 'docker' } stages { stage('one') { steps { sh 'echo hotness > myfile.txt' script { // trim removes leading ...


Only top voted, non community-wiki answers of a minimum length are eligible