abayer: This issue is possibly tagged incorrectly. I suspect that component=pipeline-model-definition-plugin might be correct?

This is expected - the lock is acquired before we know to skip the stage. It still gets released at the end of the stage, yes?

Ok, got it. So this is a feature request. I was really happy when the 'beforeAgent' option was introduced to the when block. Guess I'm looking for a 'beforeLock' option too, then.

The lock is released as it should. The problem (or rather my problem) is that the lock is required at all. My current workaround is to rename the lock resource when the stage should be skipped, but it makes the code a little messy.

So the only way we could address this directly would be to add a beforeOptions flag to when - but I'm not sure that's actually worth doing. You can always put lock or timeout (and any other block-scoped options) in your steps instead. The more complexity we add to when flags (since we're already adding beforeInput in JENKINS-50880), the hairier the code gets, and this case is one that can largely be worked around (unlike with agent and input). The workaround would create scenarios where, say, timeout or lock wouldn't be in place for acquiring the agent or waiting for input, but it would still work fine for everything in steps. Does that sound reasonable to you?

abayer perhaps we could work around this by using an expression in the quantity of the lock, e.g.

pipeline {
  stages {
    stage('Example stage') {
      when { expression { false } }
      options { lock resource: 'example resource', quantity: expr ? 1 : 0 }
      steps { // ... }
    }
  }
}

What I do not know is if declarative supports numerical expressions

so `quantity:0` doens't work as that is the default value and seems to indicate "grab all".

I'm now trying:

pipeline {
  stages {
    stage('Example stage') {
      when { branch 'master' }
      options { lock resource: "${BRANCH_NAME=='master' ? 'example resource':'dummy'}" }
      steps { // ... }
    }
  }
}

We'll see if that is an acceptable workaround for my use case