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

Triggering a build with a parameterized node label to run on the same node doesn't work in most cases because it will take an addition executor on the node.

    XMLWordPrintable

Details

    Description

      If you have a parametrized job that you attempt to use node lables with for spawning a prerequisite build that cannot run with other builds running on the same node,eg. a set of MSI installer tests, the down stream job has to run on a different node.
      Example:
      if I have a project in the following state.
      JOB_NAME:test msi installer
      NODE_NAME:the_node #only 1 executor.. nothing should be running when we are running an msi installer.
      1rst build step:
      trigger parameterized build:run_install
      with:"Block until triggered projects"=True
      with:node lable parameter
      with: name=label
      with: parameter=$NODE_NAME

      When the root build is triggered, the first thing it will do is trigger a build on the sub project and wait for it to finish. However, when the sub build project, in the example run_install, starts running, it will take an additional executor on the node. This creates a hang which will go on forever or until the build times out or is canceled. The hang occurs because the sub job is waiting for an executor on the_node that is being taken by the job that kicked it off and is waiting for it to finish, the root job; a deadlock of resources. Jenkins should free up and then reserve executors for jobs that are running on the same node during the build process to fix issues like this.

      Attachments

        Activity

          I'm not sure how to solve this...
          The job does not actually take an additional executor, but the way you have organized your jobs means that your first job triggers a second. This will always use two executors.
          If your "prerequisite job" always has to run before the "main job", then maybe you should change the order?

          domi Dominik Bartholdi added a comment - I'm not sure how to solve this... The job does not actually take an additional executor, but the way you have organized your jobs means that your first job triggers a second. This will always use two executors. If your "prerequisite job" always has to run before the "main job", then maybe you should change the order?
          rweber Russell Weber added a comment -

          I worked around this by using the rest api and python on a proxy virtual machine to run and control the jobs; I needed something to monitor the machine as it rebooted anyway. If all else fails... use the api which is much more flexible than the web front end.

          rweber Russell Weber added a comment - I worked around this by using the rest api and python on a proxy virtual machine to run and control the jobs; I needed something to monitor the machine as it rebooted anyway. If all else fails... use the api which is much more flexible than the web front end.

          People

            Unassigned Unassigned
            rweber Russell Weber
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated: