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?
Looked at this issue in detail, here is what I found out:
The reason for this is, that the Parameterized-Trigger plugin uses the dependency graph to set the downstream jobs (only past Jenkins 1.341).
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.
Possible solutions:
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?