Did you try the version from JENKINS-9903 (the fix there is not released yet)? If not, then the downstream-ext plugin is not even supported.
If you do use this version, you will probably also experience this behaviour. On finishing jobB, the join action gets all (not disabled) downstream projects of jobB (= [jobB1, jobB2]) and waits for their completion. Since they don't get executed, the join will never be triggered.
I am actually surprised that the join gets triggered in the first example and not in the second one. I would actually expect that it gets triggered either immediately (without waiting for jobB1 or jobB2) in both cases (if the fix of JENKINS-9903) is applied or not triggering at all (if the fix isn't applied).
Feedback from the author of the downstream-ext plugin how to handle this situation would be appreciated.

I don't see the downstream-ext actually be part of the problem (it there is a problem) as it is - if I've understood correctly - is the trigger between B and B1,B2 and in that area everything is working as expected, right?

BTW: downstream-ext is not "passing downstream" any SCM infos. It simply - if configured so - skips the triggering of a downstream job if the downstream job has no SCM changes currently.

I didn't say that downstream-ext has a problem - I was just saying that getting the info from the downstream dependency that it didn't get triggered in this particular case is difficult. The join plugin gets the downstream projects (jobB1, jobB2) on the completion of jobB but before the dependency of the downstream-ext plugin is triggered. So, do you have any idea how I would get the information that the dependency decided not to trigger or any other idea how to solve the issue with the join plugin.

Before answering this question, I need to know how the join plugin gets this info currently.

Hi wolfs,

I was using the fix you provided in https://issues.jenkins-ci.org/browse/JENKINS-9903 - it's version is "1.12-SNAPSHOT (private-07/12/2011 20:57-jenkins)" in the Plugin Manager screen.

It seems that JobC is no longer getting triggered at all so I must have changed something in my job setup or upgrading to Jenkins 1.421 from 1.420 has changed the behaviour. One thing I did notice was that JobB1 and JobB2 list "JobC" as a Downstream project, which I believe is expected but as you pointed out - because JobB1 and JobB2 aren;t triggered neither is JobC.

Thanks,
Tom.

wolfs and I agreed that this is no actual bug, but just the way these 2 plugins tend to work together.
For the downstream-ext plugin there's e.g. no real difference if a downstream job isn't trigger because it has no SCM changes or if it's not triggered because the upstream build's result isn't matching the configured level.

Hi kutzi, wolfs,

Thanks for your reply, I'm afraid I'm having trouble understanding why this is not a bug though.

I believe JobC should still be triggered even if JobB1 or JobB2 are not triggered because they did not detect SCM changes in their view.

The example I originally gave is a cut down version of my current setup. JobB is my main job that has a view of the entire repository, this means that every check-in triggers a build of JobB. It's the sub jobs - JobB1, JobB2 etc that I need to then filter on a more specific Perforce view. I could have JobB1 to JobB100 so it's not practical for them all to build just to trigger the join project, JobC. This is why I want to selectively build those sub-jobs based on the change that was actually made.

Can you give me some advice as to how I could configure my jobs to behave in the way I've described? Using the downstream-ext and join plugins seemed like the perfect tools for the job.

Regards,
Tom.

Hi Tom,

I could add the following feature to the join plugin: A checkbox like "Trigger join job even when not all downstream jobs get built". If checked, the behaviour would be like you wanted. But you would also have the following effect:
2) JobB builds and fails
3) JobB1 doesn't build because JobB failed
3) JobB2 doesn't build because JobB failed
4) At this point JobC would be triggered, because JobB1 and JobB2 have been triggered but not built.

If that is what you need, I will add the feature. But there is also another solution to your problem:
Remove the join trigger from JobB and have JobC as a downstream project of JobB1 and JobB2 (using the regular build trigger). Then check the checkbox in JobC "Block while upstream projects are building". Then you will have the behaviour you want.

Hi wolfs,

I tried your workaround but it doesn't appear to work. JobB uses the downstream-ext plugin to selectively build JobB1 and JobB2 based on the SCM information. In my test, JobB was triggered, JobB1 and JobB2 didn't trigger due to the SCM changes that were made, so JobC wasn't triggered either. This is why I thought the Join plugin would work because I assumed the join project would be triggered even though JobB1 and JobB2 might not be. Am I mis-understanding your alternate solution?

I appreciate your offer of updating the join plugin to support my needs. The only thing that concerns me there is step 4) - JobC triggering irrespective of upstream build failures. Ideally I'd like:

1) JobB builds and fails
2) JobB1 doesn't build because JobB failed
3) JobB2 doesn't build because JobB failed
4) JobC doesn't build because JobB failed OR either JobB1 or JobB2 failed.

Is that possible?

Regards,
Tom.

Yeah, sorry. You have to add a trigger from JobB directly to JobC, too. JobC will not start to build directly, because it is blocked by its downstream jobs JobB1 and JobB2, so this should work.

About your concern: I see a possibility to add the desired behaviour to the join plugin, something along the lines "Don't trigger join project if this projects' build failed". But this would have nothing to do with the downstream-ext plugin, either.

Hi wolfs,

Did you up date the Join plugin at all?

Thanks,
Tom.

Hi wolfs,

Sorry to keep perstering but did you get chance to update the Join plugin?

Thanks, Tom.

Sorry, I didn't find any time to do this up to now. It could be possible that I release the current trunk version of the join plugin, giving at least support for the downstream-ext plugin, this weekend. For your requested feature I don't know when I will find time. Don't expect too soon, since you need to have in mind that a change to Jenkins core itself is necessary, too. Without this change I cannot update the join plugin to support this feature. Obviously, the feature will then require the new version of Jenkins.

Thanks for the update wolfs.

The reason I kept asking was because I couldn't get your workaround to work properly - maybe I setup my jobs wrong - I'll provide the details shortly.

Although it's not ideal I wouldn't mind building my own version of the join plugin and Jenkins for that matter - I really need a fix for this issue.

Thanks Tom

Just going over some of my old issues - did you manage to make the change to the join plugin and Jenkins core?

Are we any closer to getting this released?

Sorry, I had no time to do something about this. Are you interested in contributing?

I wouldn't be adverse to contributing but my time is also very limited. I'm sure someone with a firmer grasp on how this all works would be in a better position to fix it though.