Hi Aravinda, thank you for the elaborate example with timestamps. Really helpful.
However, at *Time 00:08* and at *Time 00:16* you said "*since there is no fan-in here*". What do you mean by "*since there is no fan-in here*". What defines something as whether it is a fan-in or not? Is it not simply *the converging of more than one upstreams* into a single pipeline which is defined as a *fan-in*? Or am i failing to clearly define what a fan-in is? On Thursday, September 8, 2016 at 4:53:04 PM UTC+6, Aravind SV wrote: > > No. Think of it this way: A pipeline will trigger only if all of its > upstreams are "green". Here's an example: > > Time 00:00 - Commit "git_1" happens. > Time 00:00 - Commit "svn_1" happens > > Time 00:01 - Build pipeline starts (Label: BP_1) > > Time 00:02 - Build pipeline finishes successfully (Label: BP_1) > > Time 00:03 - User acceptance pipeline starts (Label: UP_1) since build > pipeline finished successfully (Dependency which caused trigger: BP_1) > Time 00:03 - Capacity testing pipeline starts (Label: CP_1) - > (Dependencies which caused trigger: BP_1 and svn_1) > > Time 00:04 - Capacity testing finishes successfully (Label: CP_1) > Time 00:04 - Production pipeline does NOT trigger, since the correct > version of User acceptance pipeline is not yet finished (the one with BP_1) > > Time 00:05 - User acceptance pipeline finishes successfully (Label: UP_1) > > Time 00:06 - Production pipeline starts since its upstreams passed (CP_1 > and UP_1) and fan-in shows that they're compatible (lead back to BP_1 and > then git_1). > > > Time 00:07 - Commit "svn_2" happens > > Time 00:08 - Capacity pipeline starts (Label: CP_2) and dependencies are > svn_2 and BP_1 (latest green, since there is no fan-in here - build > pipeline does not depend on svn repo). > > Time 00:09 - Capacity pipeline finishes successfully (Label: CP_2) > > Time 00:10 - Production pipeline starts with UP_1 and CP_2. That's because > of fan-in. UP_1 is built by BP_1 which leads to git_1. Similarly, CP_2 is > build by BP_1 which leads to git_1. So, consistent. > > > Time 00:11 - Commit "git_2" happens. > > Time 00:12 - Build pipeline starts (Label: BP_2) > > Time 00:13 - Build pipeline fails (Label: BP_2) > > Time 00:14 - Capacity pipeline does NOT trigger. Upstream is not > successful. > > Time 00:15 - Commit "svn_2" happens. > > Time 00:16 - Capacity pipeline does NOT trigger. Latest run of upstream > pipeline is not successful, since there is no fan-in here. > > > I'd suggest trying these out. These should be easy to make happen using a > small script which exits with 0 (success) or 1 (failure). > > Cheers, > Aravind > > > On Thu, Sep 8, 2016 at 12:19 PM, Syed Rakib Al Hasan < > syed.raki...@gmail.com <javascript:>> wrote: > >> <https://www.go.cd/assets/images/image10.png> >> >> <https://www.go.cd/assets/images/image09.png> >> >> >> If triggering a pipeline requires *ALL* of its upstreams to be >> successful (and not just ANY ONE), does it mean that Capacity Testing >> Pipeline (which shows that it has 2 upstreams - the BuildPipeline and the >> SVN Material) will be triggered only if Build Pipeline is successful and >> ALSO there is a new commit in SVN material? It means, the completion of >> Build Pipeline will successfully trigger the User Acceptance Pipeline but >> it will not trigger the Capacity Testing Pipeline because the Capacity >> Testing Pipeline must ALSO wait for a new commit in SVN material. >> >> Is that correct? >> > -- You received this message because you are subscribed to the Google Groups "go-cd" group. To unsubscribe from this group and stop receiving emails from it, send an email to go-cd+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
