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

Variables used as node labes are not expanded in parameterized builds

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Critical Critical
    • core, multijob-plugin
    • None

      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

          Maik Richey added a comment -

          I would like to give some more details. Given are the projects A, B, C, D, E and F.

          1. A checks out the workspace, builds it and does an install to the local repository.
          2. B gets then triggered n times, using parts of the workspace of A using the Clone Workspace SCM Plugin and generate large parts of our software. B gets executed in parallel on different nodes and copy what's generated back to the workspace of the node where A got executed on.
          3. When all jobs are finished the joining job C gets triggered. C then triggers D, E and F.
          4. D, E and F are executed sequentially using the workspace of A (including whats generated during the execution of B). To not set the node in each job to a specific one directly it is necessary to define the node to run on as a variable and pass it from one job to another.

          Problem:
          Problem is, that variables used as label for a node do not get expanded to the value given as parameter.

          Maik Richey added a comment - I would like to give some more details. Given are the projects A, B, C, D, E and F. 1. A checks out the workspace, builds it and does an install to the local repository. 2. B gets then triggered n times, using parts of the workspace of A using the Clone Workspace SCM Plugin and generate large parts of our software. B gets executed in parallel on different nodes and copy what's generated back to the workspace of the node where A got executed on. 3. When all jobs are finished the joining job C gets triggered. C then triggers D, E and F. 4. D, E and F are executed sequentially using the workspace of A (including whats generated during the execution of B). To not set the node in each job to a specific one directly it is necessary to define the node to run on as a variable and pass it from one job to another. Problem: Problem is, that variables used as label for a node do not get expanded to the value given as parameter.

          Maik Richey added a comment -

          Solution:
          Values entered as labels should be expanded for parameterized builds to keep track of the needs mentioned above.

          Alternative solution:
          If downstream jobs would get executed on the same node the upstream job was executed on when you leave the field "Label Expression" empty (instead of using the Master) then it should work as well. In that case you do not have the chance to define anything as "Label Expression" indeed.

          Maik Richey added a comment - Solution: Values entered as labels should be expanded for parameterized builds to keep track of the needs mentioned above. Alternative solution: If downstream jobs would get executed on the same node the upstream job was executed on when you leave the field "Label Expression" empty (instead of using the Master) then it should work as well. In that case you do not have the chance to define anything as "Label Expression" indeed.

          I would like to second the Alternative Solution. I have several jobs that would benefit from this change. It would greatly simplify creating generic steps for multiple jobs.

          Zephirin Broussard added a comment - I would like to second the Alternative Solution. I have several jobs that would benefit from this change. It would greatly simplify creating generic steps for multiple jobs.

          Maik Richey added a comment -

          Have a look at the Parameterized Trigger Plugin and the NodeLabel Parameter Plugin. Using both can give what you are looking for. Notice that you need at least Jenkins 1.417 in order to use the NodeLabel Parameter Plugin.

          Maik Richey added a comment - Have a look at the Parameterized Trigger Plugin and the NodeLabel Parameter Plugin . Using both can give what you are looking for. Notice that you need at least Jenkins 1.417 in order to use the NodeLabel Parameter Plugin.

          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: