-
Bug
-
Resolution: Unresolved
-
Major
-
None
Hi,
I'm seeing some strange issues when using the Join and Downstream-ext plugin. I've attached a screenshot of my job setup.
My perforce depot looks something like this:
\\source\root \\source\root\root.cpp \\source\root\folderA source\root\folderA\fileA.cpp \\source\root\folderB source\root\folderB\fileB.cpp
If I modify fileA.cpp and check it in, the build process happens like this:
1) JobA detects the change, builds, finishes and triggers a build of JobB. 2) JobB builds and this in turn triggers its downstream projects: JobB1, JobB2. 3) JobB1 builds because fileA.cpp is modified which is in JobB1's Perforce view (//source/root/folderA). 4) JobB2 doesn't build because no changes are detected. 5) JobC is then triggered.
This is all working as expected, which is great.
This isn't working as expected though...I modify root.cpp and check it in, the build process happens like this:
1) JobA detects the change, builds, finishes and triggers a build of JobB. 2) JobB builds and in turn triggers its downstream projects: JobB1, JobB2. 3) JobB1 doesn't build because root.cpp is outside of JobB1's view (//source/root/folderA) 3) JobB2 doesn't build because root.cpp is outside of JobB2's view (//source/root/folderB) 4) At this point JobC is NOT triggered when I believe it should be! JobC is the Join project specified in JobB.
So it seems that JobC will only be triggered if either JobB1 or JobB2 is triggered. This seems wrong to me and I think it's a bug in either of the plugins.
Has anyone else seen this issue? Is there something wrong with my project setup by any chance?
Regards,
Tom.
[JENKINS-10435] Join project not triggered correctly when passing SCM info downstream via downstream-ext plugin
Thomas Fields
created issue -
kutzi
added a comment - 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.
kutzi
added a comment - 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. 
Stefan Wolf
added a comment - 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.
Stefan Wolf
added a comment - 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. kutzi
added a comment - Before answering this question, I need to know how the join plugin gets this info currently.
kutzi
added a comment - Before answering this question, I need to know how the join plugin gets this info currently. 
Thomas Fields
added a comment - 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.
Thomas Fields
added a comment - 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. kutzi
added a comment - 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.
kutzi
added a comment - 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. kutzi
made changes -
| Assignee | Original: kutzi [ kutzi ] | New: Stefan Wolf [ wolfs ] |
Thomas Fields
added a comment - 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.
Thomas Fields
added a comment - 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.
Stefan Wolf
added a comment - 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.
Stefan Wolf
added a comment - 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. 
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.