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

          tmo Timo Veldt created issue -
          tmo Timo Veldt made changes -
          Field Original Value New Value
          Environment Jenkins 2.138.3, JDK1.8 Jenkins 2.138.3
          JDK1.8
          lockable resource plugin 2.3
          Pipeline multibranch 2.20
          Pipeline 2.6
          tmo Timo Veldt made changes -
          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)
          {code:java|title=Use a lock}
          options {
              lock label: 'REGRESSION'
              disableConcurrentBuilds()
              buildDiscarder(logRotator(numToKeepStr: '20', daysToKeepStr: '30'))
          } {code}
          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.
          {code:java|title=Upstream for the service}
          triggers {
                  upstream(upstreamProjects: "../dep1/master,../dep2/master", threshold: hudson.model.Result.SUCCESS)
              } {code}
          {code:java|title=Upstream for the dashboard}
          triggers {
                  upstream(upstreamProjects: "../service/master", threshold: hudson.model.Result.SUCCESS)
              } {code}
          *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:
          {code:java}
          dep1 => dep 2 => service => dashboard {code}
          This prevents the second _service_ job from being triggered. However it creates dependencies that aren't really there and blocks some parallel processing.

           

          _I'll update the environment later, as I need to access the actual environment to get the information, which I cannot do at the moment._
          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)
          {code:java|title=Use a lock}
          options {
              lock label: 'REGRESSION'
              disableConcurrentBuilds()
              buildDiscarder(logRotator(numToKeepStr: '20', daysToKeepStr: '30'))
          } {code}
          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.
          {code:java|title=Upstream for the service}
          triggers {
                  upstream(upstreamProjects: "../dep1/master,../dep2/master", threshold: hudson.model.Result.SUCCESS)
              } {code}
          {code:java|title=Upstream for the dashboard}
          triggers {
                  upstream(upstreamProjects: "../service/master", threshold: hudson.model.Result.SUCCESS)
              } {code}
          *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:
          {code:java}
          dep1 => dep 2 => service => dashboard {code}
          This prevents the second _service_ job from being triggered. However it creates dependencies that aren't really there and blocks some parallel processing.

            People

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

              Dates

              • Created:
                Updated: