If you do not want to disable them, just remove the property.

Hi jglick, sorry for jumping on an old ticket but is there any reason this cannot be done?

I have the following use case:

• a single Jenkinsfile is being used for multiple jobs
• each job can have a different configuration (parameter default values, options such as the buildDiscarder, etc)
• option values can be set using a custom pipeline config step cOption(String optionName) which returns the value for that particular job (e.g. release branches being given a longer build history than topic branches, etc)

At the moment it looks like this:

pipeline {
    agent none
    options {
    skipDefaultCheckout()
    timestamps()
    buildDiscarder(logRotator(
        artifactDaysToKeepStr: cOption('artifactDaysToKeepStr'),
        artifactNumToKeepStr: cOption('artifactDaysToKeepStr'),
        daysToKeepStr: cOption('daysToKeepStr'),
        numToKeepStr: cOption('numToKeepStr')
        )
    )
    disableConcurrentBuilds()
}

I would like to be able to add something like:

    disableConcurrentBuilds(cOption('disableConcurrentBuilds'))

and have the disableConcurrentBuilds value set depending on the job calling it.

I would be happy to make the changes for it. Just wanted to make sure it is okay to do so first.

lostinberlin if you want to have a generic Pipeline script used for multiple jobs, I would advise you to use Scripted syntax rather than Declarative.

jglick Sorry, I didn't add the context. It is not meant to be a generic Pipeline script to serve multiple and different jobs. The jobs in question are all the same job in principle, doing the same thing, just for a different branch. We could just as well have the Jenkinsfile configured as a Multibranch Pipeline or even Github Organisation job.

A little off topic, but the cOption thing is simply a way to set some defaults (for the buildDiscarder task for example) based on the BRANCH_NAME. This is possible for stages within the pipeline itself using the "when ... expression" but not at the configuration level.

So whilst we can say "if on release_branch then archive these artifacts (else do not)", we can't say "if on release_branch then keep all the build history else only keep the last 30 builds and artifacts of the last 10 builds". It's either have all your branches save all the build history, or accept losing some of your release branches build history.

Following this, it makes sense to allow the disableConcurrentBuilds to accept a boolean in the same way skipDefaultCheckout does. Having an optional boolean would allow this to be configured rather than being static statement.

Since your need is specific to Declarative (this would be trivial in Scripted), you should rather open an RFE for Declarative to permit parts of options to use a when clause.

Hi jglick, sorry for the late reply. I understand that we can do this quite easily with the Scripted syntax, but then one would lose the benefits of the declarative pipeline such as post-conditions, etc.

I can open an RFE but at the same time I can still see the advantage in being able to configure this parameter with a boolean value. Using templating to create jenkins files, for example, where you could just have an IS_CONCURRENT boolean placeholder to replace á la disableConcurrentBuilds($IS_CONCURRENT), rather than have to set IS_CONCURRENT to either disableConcurrentBuilds() or '' and have an empty line in your Jenkinsfile.

Sorry for being a pain . If it is a 'Won't Do' then so be it.

Is there update for the issue? I really love the concept of declarative pipeline. We have similar situation. There are multiple repositories and branches share the same jenkinsfile, we want disableConcurrentBuilds for development branches but not the master branch, and we don't want too many jenkinsfile which will bring too much maintenance effort. So a boolean parameter will be perfect, and "when...expression" is an acceptable work-round. But now, we have to define different but very similar jenkinsfile to get the function work.