Parameterized Project Trigger with Downstream SCM Check

[AndyB]

Hi,

I'm trying to move some existing projects to be parameterised to allow testing of two different source branches, however I seem to have run into a problem. I'm able to parameterise the builds fine and have setup two upstream jobs to trigger the projects for the different branches (live and release). The problem is that don't seem to be able to trigger a downstream project with a parameter *only* if it has SCM changes. I've seen two ways to trigger the downstream projects:

o Downstream Trigger (extended) - this allows a downstream project to be triggered only if it contains an SCM change - but it doesn't allow a parameter to be passed to the project

o Parameterized Trigger - this allows a project to be triggered with a parameter - but it will always trigger even when downstream projects have no SCM changes

It's important that I don't trigger downstream projects when there are no SCM changes and the downstream projects are all carefully setup to view only part of the repository they need to (parameterised by branch name).  Can anyone sanity check the approach I'm trying - or suggest an alternative?  I could duplicate the downstream projects for each branch, but that sounds like a bad idea.  So unless I'm missing something it seems like it would be a good idea to combine some of the functionality of the two plugins above to allow downstream projects to be triggered with a parameter only if SCM changes exist. Can anyone comment on the feasibility of that?

Thanks

Andy

[Frank]

Hi Andy,

On Oct 19, 5:12 am, AndyB <andy.bi...@gmail.com> wrote:
> Hi,
>
> I'm trying to move some existing projects to be parameterised to allow
> testing of two different source branches, however I seem to have run into a
> problem. I'm able to parameterise the builds fine and have setup two
> upstream jobs to trigger the projects for the different branches (live and
> release). The problem is that don't seem to be able to trigger a downstream
> project with a parameter *only* if it has SCM changes. I've seen two ways to
> trigger the downstream projects:

Beyond SCM polling, my understanding of the literature is that all of
the other SCM options simply return a boolean flag for success or
fail. i.e. if there is a call to the SCM (update or full) then
Jenkins only knows that the SCM job completed and not whether the SCM
did anything.

>
> o Downstream Trigger (extended) - this allows a downstream project to be
> triggered only if it contains an SCM change - but it doesn't allow a
> parameter to be passed to the project
> o Parameterized Trigger - this allows a project to be triggered with a
> parameter - but it will always trigger even when downstream projects have no
> SCM changes
>
> It's important that I don't trigger downstream projects when there are no
> SCM changes and the downstream projects are all carefully setup to view only
> part of the repository they need to (parameterised by branch name).  Can
> anyone sanity check the approach I'm trying - or suggest an alternative?  I
> could duplicate the downstream projects for each branch, but that sounds
> like a bad idea.  So unless I'm missing something it seems like it would be
> a good idea to combine some of the functionality of the two plugins above to
> allow downstream projects to be triggered with a parameter only if SCM
> changes exist. Can anyone comment on the feasibility of that?
>

Can you use SCM polling to check if there were changes? I know this
is timer based, but it has some mechanism to check for changes between
one polling session and the next.

Regards,
Frank

[Grégory Boissinot]

There is also other kind of trigger such as XTrigger.

Please look at the BuildResultTrigger or the ScriptTrigger Jenkins plugin.

With this plugins, you are able to monitor upstream jobs according some conditions.

You can implement this use case by a script (complex in your use case) with the ScriptTrigger Jenkins plugin.

If this solution doesn't suit you, the best solution is to enhance the buildresult trigger or the downstream ext trigger.

However, you could think to provide the branch name for the testing job in a another way such as a meta information on the  generated artifacts by each upstream jobs. This meta information could be in the artifact name.

[AndyB]

Hi,

Thanks for the suggestions. I'd certainly overlooked some of the other trigger plugins available. I'm not sure that solutions which move the trigger into the downstream project (like using BuildResultTrigger) are ideal as they mean that the downstream jobs needs to know about all the possible upstream jobs. In the first instance I'll add a feature request to add support for checking downstream SCM state (like Downstream Ext) to the Parameterized Trigger Plugin (that way around as it seems easier to add that to the Parameterized Trigger plugin than parameter support to the Downstream Ext).  In the meantime I'll experiment with passing the 'parameters' via other methods (artefacts etc) - however I think fixing either of the mentioned plugins is the better solution  (solving it once rather than forcing everyone to re-invent more complicated ways to achieve this).  Actually I was kind of surprised that this kind of use-case hadn't been seen before - it doesn't seem that unusual.

Ah - I noticed JENKINS-10147 - 'Add 'poll SCM' option to build step' (for Parameterized Trigger Plugin) this is basically what I'd like. I'll vote up that as there is a least someone else with similar requirements.

Thanks
Andy

[Thomas Fields]

Hi there,

Has any progress been made on issue https://issues.jenkins-ci.org/browse/JENKINS-10147? The issue is assigned but there's been no comment from the developer whether it's doable or not. Can the functionality be added or can anyone give any guidelines as to how I'd implement it myself - it's a must-fix for us.

Cheers,
Tom.