Javier Palacios, my case is as follows:
1) I have a project at Gitlab. Suppose it is named "ProjectFoo".
2) I want each branch to spawn a dedicated Jenkins job.
The intention is as follows: each developer works in his/her own branch, thus having separate Jenkins jobs helps a lot.
However, the build process itself is not that simple.
Basically it includes several stages:
S1) Fetch & compile project
S2) Prepare database (each test is to be executed in a clean environment, thus each job execution gets its own database schema)
S3) Deploy the code (run installation SQL scripts, etc, etc)
S4) Execute fast tests (if they fail, no need to run full suite)
S5) Execute full suite of tests (here additional DB instances are provisioned to test against different DB versions, etc)
S6) Uninstall (to test uninstall)
I think it is somewhat typical scenario for integration tests.
In order to simplify management of those integration jobs, I use Job DSL plugin.
In other words, I have a "seed job" that generates all those S1, S2, ..., S3 given the input parameters like "branch name", "DB versions to test", etc.
The "seed job" has just a single step: "invoke groovy script".
Job management via groovy scripts turned out to be very efficient.
So my end-to-end is:
E1) A developer pushes commit to Gitlab
E2) Gitlab notifies Jenkins. Here only seed job should be triggered.
E3) Seed job fetches project sources, figures out the proper set of integration jobs, creates/updates as required, then triggers the actual integration testing.
The problem is at step E2 my Jenkins server has lots of jobs with given GIT project URL.
For each project I have exactly one seed job, so I do not want to trigger all of them.
Does that make sense?