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

Variables used as node labes are not expanded in parameterized builds

      Our build process is split into several parameterized jobs. To make sure that these build steps are executed on a specific node, we defined a parameter with the node name the job should be executed on. Unfortunately the variable doesn't get expanded.

      Proposed solution:

      Values entered as labels should be expanded.

          [JENKINS-9665] Variables used as node labes are not expanded in parameterized builds

          Oleg Nenashev added a comment -

          Maik confirmed that "new" plugins resolved his issue

          Oleg Nenashev added a comment - Maik confirmed that "new" plugins resolved his issue

          ggi added a comment -

          Hi,

          I think that the proposals are workarounds for specific situations, but I think the issue is still not resolved, since can not be used variables in label parameters.

          In my case I don't found the way to with those workarounds, I have to send the job to a label (not node) depending of the parameters which are called the job.

          I have solved it with another workaround:

          • using the "Parameterized Trigger Plugin"
          • inside this call, using the option of pass parameters from a properties file
          • and inside this option, use the option "Don't trigger if any files are missing"
          • So depending the the properties files that I create or delete in a previous shell script, I control which jobs runs, and each job has a fixed label.

          Still all of these are complex workarounds because can not be used variables in label parameters.

          So if this can be fixed would the good solution.

          Regards,
          Gorka

          ggi added a comment - Hi, I think that the proposals are workarounds for specific situations, but I think the issue is still not resolved, since can not be used variables in label parameters. In my case I don't found the way to with those workarounds, I have to send the job to a label (not node) depending of the parameters which are called the job. I have solved it with another workaround: using the "Parameterized Trigger Plugin" inside this call, using the option of pass parameters from a properties file and inside this option, use the option "Don't trigger if any files are missing" So depending the the properties files that I create or delete in a previous shell script, I control which jobs runs, and each job has a fixed label. Still all of these are complex workarounds because can not be used variables in label parameters. So if this can be fixed would the good solution. Regards, Gorka

          Daniel Beck added a comment -

          Node Label Parameter Plugin and Parameterized Trigger Plugin resolve this issue.

          If you can't get them to work together, please file a new issue against these plugins, preferably after having asked for help on the jenkinsci-users mailing list and having read https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue

          Daniel Beck added a comment - Node Label Parameter Plugin and Parameterized Trigger Plugin resolve this issue. If you can't get them to work together, please file a new issue against these plugins, preferably after having asked for help on the jenkinsci-users mailing list and having read https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue

          Hi!
          I reopen this issue because suggested workaround is not acceptable for me. First, NodeLabel Parameter plugin does not allow to enter label expression for cloud. It says "The label expression "trusty" does not match any node" even if it matches one or more clouds. Second, it is very inconvenient to use. Person running the build shouldn't have to remember which labels are available, and the correct expression can be fairly complex. The best solution would be to use a choise parameter and substitute a variable in the label expression.
          For example, I use a label expression like "trusty && my_tools && docker" that is served by a cloud. At some point I need to add as alternative "xenial && my_tools && docker" that is served by another cloud. I want to use a choise parameter "DISTRO" with two possible values "trusty" and "xenial" and set label expression to "${DISTRO} && my_tools && docker".

          Dmitry Mikhirev added a comment - Hi! I reopen this issue because suggested workaround is not acceptable for me. First, NodeLabel Parameter plugin does not allow to enter label expression for cloud. It says "The label expression "trusty" does not match any node" even if it matches one or more clouds. Second, it is very inconvenient to use. Person running the build shouldn't have to remember which labels are available, and the correct expression can be fairly complex. The best solution would be to use a choise parameter and substitute a variable in the label expression. For example, I use a label expression like "trusty && my_tools && docker" that is served by a cloud. At some point I need to add as alternative "xenial && my_tools && docker" that is served by another cloud. I want to use a choise parameter "DISTRO" with two possible values "trusty" and "xenial" and set label expression to "${DISTRO} && my_tools && docker".

          Hello.

          Is there any work planned to fix this issue?

          I also find it quite difficult to handle node labels name for dockers with current implementation. 

          BR, Krzysztof

          Krzysztof Sokolowski added a comment - Hello. Is there any work planned to fix this issue? I also find it quite difficult to handle node labels name for dockers with current implementation.  BR, Krzysztof

          Guy Knights added a comment -

          We also have this requirement, using variables as content for the node label. The NodeLabel parameter plugin is not a solution as it also doesn't allow the use of variables as the default parameter value, the string entered has to match an existing node name.

          Guy Knights added a comment - We also have this requirement, using variables as content for the node label. The NodeLabel parameter plugin is not a solution as it also doesn't allow the use of variables as the default parameter value, the string entered has to match an existing node name.

          Hello everyone,

          Plus one vote for this option from my side. I have jenkins swarm slaves in Docker ran dynamically and  I need some functional to send build to exact node started for it. Using variables in node label would be really helpful in this task.

          Sergey Gordienko added a comment - Hello everyone, Plus one vote for this option from my side. I have jenkins swarm slaves in Docker ran dynamically and  I need some functional to send build to exact node started for it. Using variables in node label would be really helpful in this task.

          rode ed added a comment -

          +1 from me, in my case, upstream jobs decides where to run the donwstream job, this feature will be very useful.

          rode ed added a comment - +1 from me, in my case, upstream jobs decides where to run the donwstream job, this feature will be very useful.

          Mehul Oswal added a comment - - edited

          +1 from me too, This would be useful functionality in lots of different scenarios where we need to get the value of the label dynamically.

          Mehul Oswal added a comment - - edited +1 from me too, This would be useful functionality in lots of different scenarios where we need to get the value of the label dynamically.

          I would also need this functionality. It would be great to have it fixed.

          Anders Bergsten added a comment - I would also need this functionality. It would be great to have it fixed.

            Unassigned Unassigned
            compi Maik Richey
            Votes:
            13 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated: