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

Parameterized trigger blocks executors

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      In Freestyle job, the "Trigger parameterized build on other projects" step in Post-build Actions seems to block an executor until the triggered downstream job starts. This creates a situation, where using this plugin might lead to deadlock, which can only be resolved by cancelling the step. 
      For instance, I have 4 available executors. I schedule 4 jobs to run at the same time, all of which have a parameterized trigger in post-build actions. Once any job is finished, it attempts to trigger its downstream project, however since there are no free executors available, the downstream project is simply moved to the build queue. This prevents the upstream project from ever releasing the executor, which results in a deadlock. I'm not sure if this is intended behaviour, however this makes the plugin unusable when applied to multiple projects. Here's what it looks like:

        Attachments

          Activity

          kmagomedov Kamil Magomedov created issue -
          Hide
          clangsmith Casey Smith added a comment -

          We are encountering this exact same issue.  (using Jenkins v2.204.4 and Parameterized Trigger plugin v2.36)  We only have 1 available executor, so we encounter this deadlock every time. I suspect this is a regression that was introduced at some point, as we used not to have this problem.

          Show
          clangsmith Casey Smith added a comment - We are encountering this exact same issue.  (using Jenkins v2.204.4 and Parameterized Trigger plugin v2.36)  We only have 1 available executor, so we encounter this deadlock every time. I suspect this is a regression that was introduced at some point, as we used not to have this problem.
          Hide
          kmagomedov Kamil Magomedov added a comment -

          Casey Smith I have found a workaround for this problem.
          Upstream job doesn't release the executor until its downstream job starts, and since there are no available executors, the downstream project is forever left in the build queue. So the issue can be fixed by using a pipeline job, where the first step doesn't require an executor to run. 
          In my case I've simply converted all downstream freestyle projects into pipelines and put sleep() as their first step. This solved the issue for me. 

          Show
          kmagomedov Kamil Magomedov added a comment - Casey Smith I have found a workaround for this problem. Upstream job doesn't release the executor until its downstream job starts, and since there are no available executors, the downstream project is forever left in the build queue. So the issue can be fixed by using a pipeline job, where the first step doesn't require an executor to run.  In my case I've simply converted all downstream freestyle projects into pipelines and put sleep() as their first step. This solved the issue for me. 
          Hide
          clangsmith Casey Smith added a comment -

          Thanks Kamil Magomedov.  For now, though not very graceful, I worked around by setting the "Abort the build if it's stuck" property on the promotion of the upstream job to 1 min.  So, it currently stays in deadlock for 1 min, then aborts, thus freeing up the downstream "freestyle" job that is waiting in the queue.  Of course, the promotions then all show up as aborted, which is not desirable. 

          I'm not very familiar with the Pipeline syntax, but I'll give that a shot.  Here was my first attempt, but it just hangs on master and I can't cancel:

          pipeline {
            agent none
            stages {
              stage('Sleep') {
                steps

          {         sleep 5       }

              }
              stage('Promote')

          {       agent \{ label 'ecdpromote' }

                steps

          {         echo 'Hello World $PURL'       }

              }
            }
          }

          I'll keep playing around with it.  Thanks for the suggestion!

          Show
          clangsmith Casey Smith added a comment - Thanks Kamil Magomedov .  For now, though not very graceful, I worked around by setting the "Abort the build if it's stuck" property on the promotion of the upstream job to 1 min.  So, it currently stays in deadlock for 1 min, then aborts, thus freeing up the downstream "freestyle" job that is waiting in the queue.  Of course, the promotions then all show up as aborted, which is not desirable.  I'm not very familiar with the Pipeline syntax, but I'll give that a shot.  Here was my first attempt, but it just hangs on master and I can't cancel: pipeline {   agent none   stages {     stage('Sleep') {       steps {         sleep 5       }     }     stage('Promote') {       agent \{ label 'ecdpromote' }       steps {         echo 'Hello World $PURL'       }     }   } } I'll keep playing around with it.  Thanks for the suggestion!

            People

            Assignee:
            Unassigned Unassigned
            Reporter:
            kmagomedov Kamil Magomedov
            Votes:
            1 Vote for this issue
            Watchers:
            2 Start watching this issue

              Dates

              Created:
              Updated: