-
Bug
-
Resolution: Unresolved
-
Major
-
None
-
Jenkins 1.609.1
Delivery Pipeline plugin 0.9.4
Join plugin 1.15
If a jobA triggers two other jobs (jobB and jobC), this would show as a split in a delivery pipeline view. If I want jobD to run after jobB and jobC completed (merge in the flow), I'd need to configure the Join plugin on jobA and say "run jobD once all downstream jobs have completed".
This works fine, but if say jobC failed and I rerun that stage in the delivery pipeline view, jobD doesn't get enabled. After testing it seems that whether jobD runs or not is determined by the initial assessment of the Join plugin. No matter what I rerun from the downstream jobs (jobB, jobC), jobD stays in its original state.
- is duplicated by
-
JENKINS-28979 Trigger if a failed dependency is retried and succeeds
-
- Resolved
-
[JENKINS-29652] Rerunning failed Delivery Pipeline stage doesn't enable/disable a manual trigger when using the Join plugin
Brian Villanueva
added a comment - I am also experiencing this issue. Really frustrating to have to start the whole pipeline over again when a job fails for a reason unrelated to code change.
Brian Villanueva
added a comment - I am also experiencing this issue. Really frustrating to have to start the whole pipeline over again when a job fails for a reason unrelated to code change. I made a quick hack to resolve the issue. This appears to work for me but I haven't verified it will work in all cases. But with this patch I'm able to retrigger a failed build and on success the expected join job will be run as I would expect. Added as attachment
Chris Engel
added a comment - - edited I made a quick hack to resolve the issue. This appears to work for me but I haven't verified it will work in all cases. But with this patch I'm able to retrigger a failed build and on success the expected join job will be run as I would expect. Added as attachment 
Harry Soehalim
added a comment - I'm running ver 1.19 and still seeing this issue - fyi. 
mdonohue
added a comment - When you say "rerun" is that distinguishable from just clicking "Build Now" on the job that failed?
mdonohue
added a comment - When you say "rerun" is that distinguishable from just clicking "Build Now" on the job that failed? Chris Engel
added a comment - Yes, I'm referring to doing a 'Rebuild' on the failed job not a 'Build Now'
Chris Engel
added a comment - Yes, I'm referring to doing a 'Rebuild' on the failed job not a 'Build Now' Harry Soehalim
added a comment - um, do we have any update on this issue? thx 
Neil Rhine
added a comment - I added another patch to the ticket that retries on more cases. This one will allow for both the eventual joined build to run on both failure and success until all upstream jobs succeed.
Neil Rhine
added a comment - I added another patch to the ticket that retries on more cases. This one will allow for both the eventual joined build to run on both failure and success until all upstream jobs succeed. I have the same issue and figured out a way implementing same requirement using promotionsbuild-plugin.
In this case configure Promotion as Trigger JobD when downstream projects JobB & JobC completed in JobA
mdonohue
added a comment - I'm looking at both patches that are attached here - it seems the test cases that break as a result of these changes are just commented out. Can you explain why they are no longer needed? Also, can you add a test case to exercise the path this is creating?
mdonohue
added a comment - I'm looking at both patches that are attached here - it seems the test cases that break as a result of these changes are just commented out. Can you explain why they are no longer needed? Also, can you add a test case to exercise the path this is creating? 
I have the same issue as above, I now run my jobs sequentially as it works, but it is not a very good scenario, I rather fan out and fan in to save time.