We need to improve the troubleshooting guide "Why my downstream job doesn't
A SQL approach could be interesting but as our queries are no trivial,
there would be a risk of misunderstanding. Maybe adding a troubleshooting
API/GUI/CLI on the withMaven pipeline graph is the most efficient way.
On Tuesday, March 13, 2018 at 3:12:38 AM UTC+1, Dan Tran wrote:
> I believe I don't have the scenario that you described. Mine is more
> like Project A, B, and C depends on D, after D builds, A, B, and C
> are not built
> So I need to troubleshoot, to see what I missed from my setup
> On Monday, March 12, 2018 at 9:00:20 AM UTC-7, Cyrille Le Clerc wrote:
>> > How can I troubleshoot this?
>> I discussed this feature with Arnaud Héritier today for another use case.
>> My understanding is that it is "work as design" and that you ask for an
>> improvement to disable this JENKINS-46313 Avoid excessive triggering of
>> downstream jobs <https://issues.jenkins-ci.org/browse/JENKINS-46313>
>> Do you have the same understanding of the status? If so, can you please
>> open an RFE ticket on Jira?
>> On Sunday, March 11, 2018 at 8:05:40 PM UTC+1, Dan Tran wrote:
>>> Thanks for the explanation. It is clear now
>>> In my case, I downstream should be built regardless, but it is not.
>>> How can I troubleshoot this?
>>> On Sunday, March 11, 2018 at 9:37:13 AM UTC-7, Cyrille Le Clerc wrote:
>>>> Sample: projects framework, shared-lib and webapp.
>>>> Both shared-lib and webapp depend on framework and webapp also depend
>>>> on shared-lib.
>>>> When framework build succeeds, it should trigger both shared-lib and
>>>> webapp. But it's a "waste" to trigger webapp now because shared-lib will
>>>> trigger "webapp" when it succeeds.
>>>> This is the message you get.
You received this message because you are subscribed to the Google Groups
"Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.