Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-54627

Lock label does not work with upstream trigger


    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Jenkins 2.138.3
      lockable resource plugin 2.3
      Pipeline multibranch 2.20
      Pipeline 2.6

      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)

      Use a lock
      options {
          lock label: 'REGRESSION'
          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.

      Upstream for the service
      triggers {
              upstream(upstreamProjects: "../dep1/master,../dep2/master", threshold: hudson.model.Result.SUCCESS)
      Upstream for the dashboard
      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.

            Unassigned Unassigned
            tmo Timo Veldt
            0 Vote for this issue
            1 Start watching this issue