31

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


19

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.


11

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


10

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


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

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

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.


6

I guess the simplest and direct solution would be to use GitHub API: https://docs.github.com/en/rest/reference/pulls#create-a-review-for-a-pull-request But for the requirement you have, PR checks is usually the way to go and you have a plugin that does the API communication for you: https://www.jenkins.io/doc/pipeline/steps/pipeline-githubnotify-step/


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


5

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


5

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


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

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


4

Having been down a similar road, here are my suggestions: Break your tasks apart by function; build is different to deploy, which is different to release. You can get more granular, but let's stick to the basics for now... Secondly, if you want to consider who is permitted to do certain actions, you might break these functions apart by team (dev, test, ...


4

I've done something similar to this in the past: stage('Step Tests') { steps { dir('test') { script { try { timeout(time: 5, unit: 'MINUTES', activity: true) { sh "yarn step-tests" } } catch (Exception e) { currentBuild.result = 'FAILURE' } } } } } I haven't tested ...


3

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.


3

Be aware, that dynamic build steps could cause some problems in some build steps, e.g. when you call an other job: pipeline { stages { stage('Test') { steps { script { def tests = [:] for (f in findFiles(glob: '**/html/*.html')) { // Create temp variable, ...


3

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


3

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


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' ) }


3

I agree with Omri that you are heading the wrong way. I would recommend using a shared library which implements the pipeline. You would then have a simple Jenkins file which looks all the same. See https://jenkins.io/blog/2017/10/02/pipeline-templates-with-shared-libraries/ Let's say you have a shared library which contains a vars/commonpipeline.groovy ...


3

This is quite complicated to achieve in Jenkins. We had a similar issue and here's how we solved it: We have a shared library where we keep our scripts ins ./vars/someScriptName.groovy We created a groovy script that generates the stages. Here's a working pipeline code for you to try it out: def generateITParallelStages(body) { def config = [:] ...


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


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