Hi Aravinda (and others in the community). Hope you can see this query and 
help me out in solving this puzzle.

On Friday, September 9, 2016 at 7:50:55 PM UTC+6, Syed Rakib Al Hasan wrote:
>
> 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> 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.

Reply via email to