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

Add option to override node/label choice with default node/label field

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Labels:
      None
    • Environment:
      Jenkins 1.436, NodeLabel 1.1.1, Parameterized Trigger 2.11
    • Similar Issues:

      Description

      I would like to exclude certain jobs in a build sequence from running on the node I choose at the start. e.g. Most of the jobs will run on my chosen node, but I want to run some on the master.

      Currently it seems the NodeLabel plugin overrides the default node/label selection field ("Restrict where this project can be run"). I can see why that would be useful, but I want the option to reverse that priority.

        Attachments

          Activity

          Hide
          domi Dominik Bartholdi added a comment -

          That's why you are able to define the default node. If the plugin would not have priority over the "Restrict where this project can be run"-field, then the job would always run where this field point to.

          The nodelabel plugin adds two new parameter types, node and label - maybe you better use the label instead of the node and define the default label with the value you otherwise would define in the "restriction"-field.

          Show
          domi Dominik Bartholdi added a comment - That's why you are able to define the default node. If the plugin would not have priority over the "Restrict where this project can be run"-field, then the job would always run where this field point to. The nodelabel plugin adds two new parameter types, node and label - maybe you better use the label instead of the node and define the default label with the value you otherwise would define in the "restriction"-field.
          Hide
          mconlon Michael Conlon added a comment -

          Thanks for your quick reply!

          It's quite possible I just don't understand the best way to configure the setup. However, I don't think your solution will work for me...
          Let me elaborate on my configuration: My master is Unix, while my slaves are Mac. I want to run the first and last jobs of a diamond build on the master, one of the middle jobs on a Snow Leopard Mac, and all other jobs on a Lion Mac. I have labels for each of these machines to specify their OS type and version. I set up the parameters for the whole build at the first job, and I pass them all to the downstream jobs (Perhaps I need to exclude the node parameter by passing all other values individually??).

          If I do as you suggested above, and give a default label for either "master" or "unix", all of the jobs in the whole build will try to run on the master node or a Unix-labeled machine, respectively...regardless of what I specify in the middle jobs, which I want to run on Macs. Honestly, I'm not sure how your suggestion works any differently than specifying a node.

          Show
          mconlon Michael Conlon added a comment - Thanks for your quick reply! It's quite possible I just don't understand the best way to configure the setup. However, I don't think your solution will work for me... Let me elaborate on my configuration: My master is Unix, while my slaves are Mac. I want to run the first and last jobs of a diamond build on the master, one of the middle jobs on a Snow Leopard Mac, and all other jobs on a Lion Mac. I have labels for each of these machines to specify their OS type and version. I set up the parameters for the whole build at the first job, and I pass them all to the downstream jobs (Perhaps I need to exclude the node parameter by passing all other values individually??). If I do as you suggested above, and give a default label for either "master" or "unix", all of the jobs in the whole build will try to run on the master node or a Unix-labeled machine, respectively...regardless of what I specify in the middle jobs, which I want to run on Macs. Honestly, I'm not sure how your suggestion works any differently than specifying a node.
          Hide
          domi Dominik Bartholdi added a comment -

          Ok, I think the only way you can do something like this is to use this plugin together with the 'parameterized trigger plugin',
          see this section for https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin#NodeLabelParameterPlugin-BuildParameterFactory
          ...with this you could create some kind of coordinating job and use as many 'Trigger/call builds on other projects' in this job a you like.
          Or you use the build pipeline plugin (although I'm not 100% sure if that's what you'r looking for) https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin

          Show
          domi Dominik Bartholdi added a comment - Ok, I think the only way you can do something like this is to use this plugin together with the 'parameterized trigger plugin', see this section for https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin#NodeLabelParameterPlugin-BuildParameterFactory ...with this you could create some kind of coordinating job and use as many 'Trigger/call builds on other projects' in this job a you like. Or you use the build pipeline plugin (although I'm not 100% sure if that's what you'r looking for) https://wiki.jenkins-ci.org/display/JENKINS/Build+Pipeline+Plugin
          Hide
          mconlon Michael Conlon added a comment -

          I realized I could get around this issue by having the first job run on the slave, and then splitting off a build trigger for each job that needed to run on the master, by choosing "Predefined parameters" which matched all of my current parameters except the node.

          However, I found an underlying issue in the plugin that led to this problem. I've written up a new one to address it at JENKINS-12226.

          Show
          mconlon Michael Conlon added a comment - I realized I could get around this issue by having the first job run on the slave, and then splitting off a build trigger for each job that needed to run on the master, by choosing "Predefined parameters" which matched all of my current parameters except the node. However, I found an underlying issue in the plugin that led to this problem. I've written up a new one to address it at JENKINS-12226 .
          Hide
          domi Dominik Bartholdi added a comment -

          sorry, but I don't think there is anything more I can do for this...

          Show
          domi Dominik Bartholdi added a comment - sorry, but I don't think there is anything more I can do for this...

            People

            • Assignee:
              domi Dominik Bartholdi
              Reporter:
              mconlon Michael Conlon
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: