In a a declarative pipeline i have a stage grouping several other stages and need to hold a lock for the duration of the group.  I see I can add lock() to the options of the group and it works fine in that scenario.  However the group also has a When clause so I can turn that group off with a job parameter.  

The problem is that when the "when" evaluates false so the stage will be skipped, it wait for the lock anyway.  If the stage will be skipped for any reason, we should not block on the lock.  The "when" defines a "beforeAgent" attribute for a similar need, so that might be an approach, but I'm not seeing a scenario where you would want to do it in the current order.

My pipeline looks like:

—

pipeline {

agent none
stages {

      stage ('Build')

      stage('Deploy-and-Test') { // Group Stage Deploy and test the Build - lock the deployment VM so we don't step on other runs
          when {
               expression {
                    "${params.Deploy}" == "true"
               }
              beforeAgent true
          }
          options {
               lock(quantity: 1, resource: "${params.DeployAgent}", variable: 'myDeployAgent')
          }
          agent none

          stages { ...}

     }}}

When I run it withthe param to disable the stage I see:

—
[Pipeline] stage[Pipeline] { (Deploy-and-Test)[Pipeline] lockTrying to acquire lock on [DeploymentVM_Win]
Lock acquired on [DeploymentVM_Win][Pipeline] {Stage "Deploy-and-Test" skipped due to when conditional
—

Since the stage is being skipped there is no point in holding the lock, but it the lock is already allocated, this will block anyway.  The lock() should be processed after the decision whether to execute the stage.