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.

jglick:

this would be trivial in Scripted

Can you please explain here how "enable concurrent builds" can be activate with in a Scripted Pipeline?

You can pass whatever expression you like to a properties step. Please post to the Jenkins users’ list for usage questions.

Joining Op's request, our use case is very similar: Using the same Jenkinsfile for different jobs with declarative syntax.
This can be implemented by either having the options{} block accept a when{} clause, or (preferably) by having all the options support configurable parameters.

IMO this ticket should be reopened with a definition of done like Op's subject.

This issue should be reopened - the issue is not resolved - those who wish to use declarative syntax cannot easily change the build behavior programmatically for build concurrency. This would be a nice (and simple) way to allow us to do that. Also, it would help to keep directives consistent, skipDefaultCheckout for example uses the same implementation suggested on this ticket: https://issues.jenkins-ci.org/browse/JENKINS-41391

antogo do not reopen. Read my comment of 2018-07-20.

Removing of disableConcurrentBuilds() in PR from scripted pipeline didn't affect my develop branch until I went and manually removed it from branch's config.xml

node {
 properties(
  [
   disableConcurrentBuilds(),
  ]
 )
 stage('stage 1') {
  sleep(30000)
 }
}

manual changes to config.xml

<?xml version='1.1' encoding='UTF-8'?>
<flow-definition plugin="workflow-job@2.34">
  <actions>
    <org.jenkinsci.plugins.workflow.multibranch.JobPropertyTrackerAction plugin="workflow-multibranch@2.21">
      <jobPropertyDescriptors>
--        <string>org.jenkinsci.plugins.workflow.job.properties.DisableConcurrentBuildsJobProperty</string>
      </jobPropertyDescriptors>
    </org.jenkinsci.plugins.workflow.multibranch.JobPropertyTrackerAction>
  </actions>

...

   </org.jenkinsci.plugins.workflow.multibranch.BranchJobProperty>
--    <org.jenkinsci.plugins.workflow.job.properties.DisableConcurrentBuildsJobProperty/>
  </properties>
  <definition class="org.jenkinsci.plugins.workflow.multibranch.SCMBinder" plugin="workflow-multibranch@2.21">
    <scriptPath>Jenkinsfile</scriptPath>
  </definition>
  <triggers/>
  <disabled>false</disabled>

question:

If I write

properties()

inside my scripted pipeline, doesn't this remove the previously set properties (with the disableConcurrentBuilds)?

I also love the concept of Steve. 

I work only with decorative pipeline (IMO state of the art) and would like to:

options { disableConcurrentBuilds(abortPrevious: false) } 

when building branches

and 

options { disableConcurrentBuilds(abortPrevious: true) } 

when building pull requests

maybe with something like:

options { disableConcurrentBuilds(abortPrevious: env.CHANGE_ID ? true : false) }