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

Downstream project name is not accepting env variable/build parameters

      I am using Parametrized trigger to trigger downstream build projects. All our build projects are named as <NAme><release>. The Release name is set as a build parameter. So in the project name field of when I enter name${PARAMETER} its not triggering the right project.

      See screenshot attached

          [JENKINS-11280] Downstream project name is not accepting env variable/build parameters

          Fred G added a comment -

          Looked at this issue in detail, here is what I found out:

          • Env variables/build parameters are in fact not expanded, even though hudson.plugins.parameterizedtrigger.BuildTriggerConfig.getProjectList(EnvVars) supports expanding.
            The reason for this is, that the Parameterized-Trigger plugin uses the dependency graph to set the downstream jobs (only past Jenkins 1.341).
          • hudson.plugins.parameterizedtrigger.BuildTrigger.buildDependencyGraph(AbstractProject, DependencyGraph) is not called during
            an actual build. It's only called when a new project is created from xml, a project configuration is saved or a project gets deleted (and a few other events).
            During these events there are no env vars or build parameters around (obviously), therefore getProjectList() is called with null as parameter.
          • hudson.tasks.BuildTrigger (the simple downstream trigger in Jenkins core) has no support for variables expansion at all

          Possible solutions:

          • check if project list contains variables, if it does, either
            • use the deprecated hudson.plugins.parameterizedtrigger.BuildTrigger.perform(AbstractBuild<?, ?>, Launcher, BuildListener) to execute those downstream jobs or
            • rebuild the dependency graph dynamically during a build

          In both cases dynamically expanded downstream jobs could probably not be shown as sensible links on the job overview page. Maybe the unexpanded string could be shown with a note that it's computed during a build.

          Should the use-case be supported in general?
          If yes, how should it be displayed outside of the configuration page?
          If yes, what's an elegant way of implementing the functionality?

          Fred G added a comment - Looked at this issue in detail, here is what I found out: Env variables/build parameters are in fact not expanded, even though hudson.plugins.parameterizedtrigger.BuildTriggerConfig.getProjectList(EnvVars) supports expanding. The reason for this is, that the Parameterized-Trigger plugin uses the dependency graph to set the downstream jobs (only past Jenkins 1.341). hudson.plugins.parameterizedtrigger.BuildTrigger.buildDependencyGraph(AbstractProject, DependencyGraph) is not called during an actual build. It's only called when a new project is created from xml, a project configuration is saved or a project gets deleted (and a few other events). During these events there are no env vars or build parameters around (obviously), therefore getProjectList() is called with null as parameter. hudson.tasks.BuildTrigger (the simple downstream trigger in Jenkins core) has no support for variables expansion at all Possible solutions: check if project list contains variables, if it does, either use the deprecated hudson.plugins.parameterizedtrigger.BuildTrigger.perform(AbstractBuild<?, ?>, Launcher, BuildListener) to execute those downstream jobs or rebuild the dependency graph dynamically during a build In both cases dynamically expanded downstream jobs could probably not be shown as sensible links on the job overview page. Maybe the unexpanded string could be shown with a note that it's computed during a build. Should the use-case be supported in general? If yes, how should it be displayed outside of the configuration page? If yes, what's an elegant way of implementing the functionality?

          Fred G added a comment -

          Assigning this to you, as huybrechts is MIA.

          Fred G added a comment - Assigning this to you, as huybrechts is MIA.

          Aaron Stone added a comment - - edited

          JENKINS-14160 is a duplicate. Would be awesome to fix this

          Aaron Stone added a comment - - edited JENKINS-14160 is a duplicate. Would be awesome to fix this

          Tom Canova added a comment -

          Please fix this bug - I need this fixed so I can fully use parameters in my jobs and not have to hardcode variable stuff directly in parameterized trigger fields.

          Tom Canova added a comment - Please fix this bug - I need this fixed so I can fully use parameters in my jobs and not have to hardcode variable stuff directly in parameterized trigger fields.

          Ondrej Kupka added a comment -

          Same here. Just had an idea how to make our Jenkins working in a much better way, and in fact fix some issues, and what I see is that it does not work. What a pity :-/

          Ondrej Kupka added a comment - Same here. Just had an idea how to make our Jenkins working in a much better way, and in fact fix some issues, and what I see is that it does not work. What a pity :-/

          +1 here! I'm stuck looking for this exact functionality.

          Eduardo Rodrigues added a comment - +1 here! I'm stuck looking for this exact functionality.

          Ken Beal added a comment -

          Added a vote, duplicate of the ticket I just entered, https://issues.jenkins-ci.org/browse/JENKINS-23053

          Ken Beal added a comment - Added a vote, duplicate of the ticket I just entered, https://issues.jenkins-ci.org/browse/JENKINS-23053

          Yes we would like this as well.. seems it works for the "Build" section but not the "Post Build" section!

          Lorelei McCollum added a comment - Yes we would like this as well.. seems it works for the "Build" section but not the "Post Build" section!

          Sung Hong added a comment -

          It would be awesome if this can be fixed. It doesn't seem to work in either 'build' or 'post build' sections.

          Sung Hong added a comment - It would be awesome if this can be fixed. It doesn't seem to work in either 'build' or 'post build' sections.

          Jacek Tomaka added a comment -

          It is not fully addressing this issue but i have added ability to resolve default values of parameters. This is enough for me because i am using parametrized trigger plugin in conjunction with inheritance project plugin. Thank you Fred G for your analysis. It was helpful.
          For some reason when inheritance build configuration is changed the downstream job link does not get updated but build is triggered.
          https://github.com/J-cztery/parameterized-trigger-plugin/commit/9fdaca08fd480f5d01399f2e03a2fa2c1170d3bd

          Jacek Tomaka added a comment - It is not fully addressing this issue but i have added ability to resolve default values of parameters. This is enough for me because i am using parametrized trigger plugin in conjunction with inheritance project plugin. Thank you Fred G for your analysis. It was helpful. For some reason when inheritance build configuration is changed the downstream job link does not get updated but build is triggered. https://github.com/J-cztery/parameterized-trigger-plugin/commit/9fdaca08fd480f5d01399f2e03a2fa2c1170d3bd

          Adrian Popa added a comment -

          Still hasn't been fixed in Jenkins v1.634

          Adrian Popa added a comment - Still hasn't been fixed in Jenkins v1.634

          There is workaround. In the Build section you can add "Additional Step" and then add "Trigger/call builds on other project". Then you can use variable in the name of the next job. See picture.

          Igor Szlachcikowski added a comment - There is workaround. In the Build section you can add "Additional Step" and then add "Trigger/call builds on other project". Then you can use variable in the name of the next job. See picture.

          Eric Ackerson added a comment -

          This workaround works, but it also causes the Multijob view to not show the triggered job. Are there any plans to correct this?

          Eric Ackerson added a comment - This workaround works, but it also causes the Multijob view to not show the triggered job. Are there any plans to correct this?

          Ashish Rathi added a comment -

          This workaround does not work for me, any other possible solutions?

          Ashish Rathi added a comment - This workaround does not work for me, any other possible solutions?

            kohsuke Kohsuke Kawaguchi
            epeters Eby Peters
            Votes:
            29 Vote for this issue
            Watchers:
            33 Start watching this issue

              Created:
              Updated: