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

          Eby Peters created issue -
          Eby Peters made changes -
          Attachment New: screenshot-1.jpg [ 20913 ]

          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.
          Fred G made changes -
          Assignee Original: huybrechts [ huybrechts ] New: Kohsuke Kawaguchi [ kohsuke ]

          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
          Aaron Stone made changes -
          Link New: This issue duplicates JENKINS-14160 [ JENKINS-14160 ]

          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.

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

              Created:
              Updated: