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

Lock label does not work with upstream trigger

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Minor
    • Resolution: Unresolved
    • Labels:
      None
    • Environment:
      Jenkins 2.138.3
      JDK1.8
      lockable resource plugin 2.3
      Pipeline multibranch 2.20
      Pipeline 2.6
    • Similar Issues:

      Description

      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'
          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.

      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.

        Attachments

          Activity

          There are no comments yet on this issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              tmo Timo Veldt
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated: