We have several independent multi-branch pipeline jobs. Two of them perform regression tests on the same environment (including the database), which is why they cannot be performed together. 

To achieve this, we used locking in the Jenkinsfile(s)

options {
    lock label: 'REGRESSION'
    disableConcurrentBuilds()
    buildDiscarder(logRotator(numToKeepStr: '20', daysToKeepStr: '30'))
} 

This worked fine for blocking builds. However there exist several upstream dependencies in the project which should at least trigger downstream jobs. So we added a trigger in the Jenkinsfiles.

triggers {
        upstream(upstreamProjects: "../dep1/master,../dep2/master", threshold: hudson.model.Result.SUCCESS)
    } 

triggers {
        upstream(upstreamProjects: "../service/master", threshold: hudson.model.Result.SUCCESS)
    } 

Note that both service and dashboard have the "Use a lock" code snippet, right above the triggers block (nothing in between).

The resulting behavior is that when dep1 finishes a build for the service is scheduled. During the service build, dep2 finishes and queues a new service job. When the first service build finishes, it triggers a dashboard build and this starts immediately. However since the first service build finished, the enqueued service build can also start.

What I expect is that either the dashboard or the second service build will go first (preference for the latter to go first, since it is an upstream job to the dashboard).

What I see is that both jobs get started, both acquiring the lock on the label. (As a side effect the regression tests for both projects fail since they're both updating the same environment at the same time).

I found a workaround by making a singular upstream "pipeline", like so:

dep1 => dep 2 => service => dashboard 

This prevents the second service job from being triggered. However it creates dependencies that aren't really there and blocks some parallel processing.