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:

          [JENKINS-60765] Parameterized trigger blocks executors

          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.

          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.

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

          Kamil Magomedov added a comment - clangsmith 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. 

          Casey Smith added a comment -

          Thanks kmagomedov.  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!

          Casey Smith added a comment - Thanks kmagomedov .  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!

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

              Created:
              Updated: