17

Managed to solve it with the following code: pipeline { agent { label "master"} stages { stage('1') { steps { script { def tests = [:] for (f in findFiles(glob: '**/html/*.html')) { tests["${f}"] = { node { ...


14

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.


9

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


6

No, the credentials will only be visible within the block passed to withCredentials, not outside of that. There is no way to make the credentials globally available without switching to Scripted Pipeline. With Scripted, you can wrap your entire job in withCredentials. This is not possible with Declarative.


5

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 ...


5

This also works, if you want to stay within the Declarative Pipeline space // declare our vars outside the pipeline def tests = [:] def files pipeline { agent any stages { stage('1') { steps { script { // we've declared the variable, now we give it the values files = ...


5

You should look at Global Shared Libraries, which will allow you to reuse logic across different Jenkinsfiles. Rather than depending on the environment, it's probably safer to explicitly pass parameters and returns values from the functions, which will make their behavior more explicit. Another side benefit is that you will be able to unit test them using


4

This is a known bug. See JENKINS-42878 and JENKINS-41996. This bug has been resolved upstream, which means you should be able to fix the bug by upgrading the plugin to the latest version.


4

"This is great, but I want to run a command/script when a branch is removed, how can I have jenkins run a command when a branch is removed?" You will need to use a webhook for this, I use the following settings in Github: Bitbucket only supports the following webhooks: "Is there a way to have Jenkins trigger a job before it removes the branch?" ...


4

I'm not entirely sure what you're trying to ask in your question, so I'm answering the question I believe you're trying to ask. A build does not necessarily have a single commit author. It has a list of committers, which can be empty or can contain many committers. To create this list, you can use this snippet in a scripted Pipeline (note that you may ...


4

Visual Studio Team Services has a YAML Build feature in public preview that allows you to store your build definitions as source controlled files.


4

The strict answer is no, in that there is no direct equivalent to a Jenkinsfile. However, there are Build Process Templates and you can use the Psake Build Automation tool in combination with templates to reduce the barriers to entry for creating a new build, test and deployment build definitions. It is nowhere near as fluid as Jenkins' Pipelines as Code, ...


4

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}]" ...


3

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: ...


3

You can have conditionals in your declarative pipeline by using the when-block inside a stage. There is a plugin called "environment injector" which lets you set variables outside of the pipeline-script which is nice. Also if you put the step below the other steps, it won't execute if they fail. when { environment name: 'pushArtifact', value: 'true' }...


3

You need to use double quotes instead of single quotes. Single-quoted strings don't perform string interpolation. For instance: parameters { string( name: 'DEPLOY_BUILD_NUMBER', defaultValue: "${BUILD_NUMBER}", description: 'Fresh Build and Deploy OR Deploy Previous Build Number' ) }


2

I think your issue is rooted in the server variable not being reusable outside the pre-build stage block. In Jenkins declarative, you can define variables like that using the script { ... } block, but once you leave the stage those variables are inaccessible to other to stages. With the previous suggestions, I'd recommend this: House the artifactory ...


2

Based on this PR, the repoSlug was added and now the status is sent to the right repository. When it was not working: post { success { bitbucketStatusNotify( buildState: 'SUCCESSFUL', commitId: env.GIT_COMMIT ) } failure { bitbucketStatusNotify( buildState: 'FAILED', ...


2

I tried storing the slave job part status in a file and stashing it on node and then unstashing it back on master. It works but I am looking for a cleaner way. Following is the current approach i am using: def branches = [:] def allNodes = Jenkins.getInstance().getNodes() for (int i =0; i < allNodes.size(); i++) { String nodeName = allNodes[i].name....


2

You may want to try the Join plugin. Some more details about this plugin (from the linked page): This plugin allows a job to be run after all the immediate downstream jobs have completed. In this way, the execution can branch out and perform many steps in parallel, and then run a final aggregation step just once after all the parallel work is finished. ...


2

I assume you would like to run locally to test logic? If so there is a unit testing framework for Jenkins declarative / scripted pipeline. I have not personally used it but this would enable me to test stubbed logic locally. Alternatively, as you're no ta fan of GUIs you could have a look at Jenkins X which has a very powerful CLI and is more gitops driven.


2

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 ...


2

There is a retry parameter in the global options when using declarative pipeline : pipeline { agent any options { retry(3) } stages { ... } }


2

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 ...


1

I set credential globally in declarative pipeline like this and then my Jenkins could talk with Google Dataflow in all stages. For example, I used a secret file (google service account). pipeline { agent any environment { //Secret File ID was defined in Jenkins -> Credentials -> System -> Global credentials ...


1

To solve this, you need to include the volume mounts in the containers described here: Sample Jenkinsfile: pipeline { agent { kubernetes { label 'test-pod' defaultContainer 'jnlp' yaml """ apiVersion: v1 kind: Pod spec: containers: - name: frontend-test image: centos:7 command: - cat tty: true volumeMounts: ...


1

I've done this before. Essentially you can use the Jenkins CLI to import/export jobs, which will allow you to create and/or update a job with the definition you want to run. Be it JenkinsFile or some groovy script or whatever. Check this blog for details. Once you (re)define the job, you will simply remotely execute it using the same Jenkins CLI. You can ...


1

Your difficulty stems from encouraging potentially long-lived branches, which is deviating from the CI methodology - which is supposedly why you'd be using jenkins - a CI tool - in the first place. Normally you shouldn't be running the tests for those branches in the Jenkins pipeline for the trunk - you want to measure the quality of the integrated work, ...


1

As far as I see, there are two possible approaches, either by misusing reusing the Blue Ocean plugin or using the Groovy-based Jenkinsfile unit test tool. The groovy approach might be a bit of overhead, since it is not a client-side Javascript verification. An idea would be to run an async task, server side that tests the code the developer provides and ...


1

It's much easier to use scripted Pipelines to do this since you can use arbitrary Groovy, but you should still be able to do this with declarative Pipelines using the findFiles step.


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