allow indicating project name in property files

[rjarry]

When triggering multiple builds, it is now possible to wait for completion on multiple projects and indicate in property files what project they should trigger a build on.

For example, if we have 5 properties files:

# foo.properties
JOB=foo
PARAM=12

# bar-1.properties
JOB=bar
PARAM=1

# bar-2.properties
JOB=bar
PARAM=2

# baz-1.properties
JOB=baz
PARAM=1

# baz-2.properties
JOB=baz
PARAM=2

And the following configuration on the parent job:

• Projects to build: foo, bar, baz
• For every property file, invoke one build:
  • File pattern: *.properties
  • Project Name Property: JOB

The result will be the following triggered builds:

1. foo with params from foo.properties
2. bar with params from bar-1.properties
3. bar with params from bar-2.properties
4. baz with params from baz-1.properties
5. baz with params from baz-2.properties

If the Project Name Property field is left blank, the behaviour is the same as before: For every property file, invoke one build ON ALL Projects to build.

Important: the value of Project Name Property is NOT passed as a parameter to the downstream builds.

Signed-off-by: Robin Jarry robin.jarry@6wind.com

[rjarry]

By the way, I executed all unit tests. There is 1 failure that also happen without my patch.

Tests in error:
testRevisionParameter(hudson.plugins.parameterizedtrigger.test.SubversionRevisionBuildTriggerConfigTest)

[jenkinsadmin]

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

[jglick]

Sounds like the kind of specialized use case more cleanly handled with Workflow.

[rjarry]

Hi,

I just want a simple job that forks a lot of others (in parallel not sequence) while preserving all capabilites of the freestyle project (envinject, html-publisher, multiple git clones, run sub jobs on the same node). Parameterized trigger is perfect for this.

Please correct me if I am wrong but it seems that the support of these is not yet integrated into workflow.

[jglick]

it seems that the support of these is not yet integrated into workflow

HTML publisher support (from the flow itself) is not yet there. I think everything else is, to the extent I can understand your use case.

[rjarry]

In the meantime, the feature added by this commit would be useful wouldn't it?

Since parameterized-trigger already allows to run multiple projects combined with multiple properties files, isn't it a good thing to be able to filter out some combinations?

[ikedam]

How about adding an option to allow to use parameters for downstreams in the "Projects to build" field ?
It can be a simple design and can work also for other ParameterFactories.

e.g., you can easily trigger builds for downstream1...downstream100 by:

• Projects to build: downstream${COUNTER}
  • Check "Use variables for downstream builds" (a new field)
• ParameterFactories: Invoke i=0...N builds
  • From: 1
  • To: 100

[rjarry]

Gentle bump :-)

@ikedam, this sounds like a different feature, no?

The idea behind this PR is to allow a parent job to "wait" for multiple builds (from different projects) to be finished before passing to the next build step.

[oleg-nenashev]

The feature seems to be too narrow-specifc for me. It may be merged, but IMO functional tests are required to cover changes in the logic.

[github-actions]

This PR is stale because it has been open 365 days with no activity. Remove stale label or comment or this will be closed in 30 days.