Hi Aravind SV, Many thanks for your answer!
Yes, that's exactly what is happening, the pipeline is running twice as you said (one when a new material is seen, and another one one P1 finishes). Actually, I just wanted to know if this was the expected behavior, and by your explanation it became clear that it is :) Thanks a lot for your time making this clear! Best Regards, Diogo Oliveira On Thursday, April 13, 2017 at 8:40:14 PM UTC+1, Aravind SV wrote: > > It's a little trickier than that. Another way of drawing your dependencies > is like this: > > [image: Inline image 2] > > In SVN, there's no real concept of a branch. So, me saying "Branch 1" and > you saying "<Branch>/Commons" is not different. In SVN, a branch is just a > directory in a different location and everything happens by convention. > This is the reason you can have a single atomic commit across branches in > SVN and cannot (as far as I know) in git, etc. > > Let's consider a few cases: > > 1. A *commit C1* only to "SVN branch 1" (S1): Only "Pipeline 1" (P1) > triggers. "Pipeline 2" (P2) waits. Once P1 is successful, P2 starts. This > is the usual fan-in case. Nothing special. P2 doesn't trigger immediately > because P2 has two materials and they won't be compatible till P1 has built > with C1. > > 2. A *commit C2* only to "SVN branch 2" (S2): Nothing special again. P2 > triggers and uses the latest green run of P1 (in case you want to fetch > artifacts, etc). We know that, since fan-in is in effect, the SVN commit > (C1) of the chosen green run of P1 will be the material for P2. So, this > run of P2 runs with: (P1-C1, C1 from S1 and C2 from S2). > > 3. A *commit C3* across "SVN branch 1" and "SVN branch 2": For GoCD, this > is just two different commits in two different materials. That's because > commits are used for uniqueness and fan-in per material. In GoCD domain > terms, it is called "material-revision". > > Now: > a) Because C3 is seen as a commit on "SVN branch 1", P1 triggers. > Remember that the latest green run of P1 is > *P1-C1.* > > b) Because *C3 is seen* as a commit on "*SVN branch 2*", P2 triggers. > It triggers, as earlier, with the latest green build of P1. So, P2 runs > with: (P1-C1, C1 from S1, C3 from S2) > > c) A little while later, once P1 finishes with its run of P1-C3, P2 > triggers again. This time it runs with: P1-C3, C3 from S1, C3 from S2. > > > Yes, this is confusing. Ideally, you shouldn't be (mis?)using this ability > of SVN to work across directories which it pretends are branches. If you > do, then you should expect this kind of behavior. As soon as you understand > how GoCD sees different materials and when it sees those commits, it > becomes a little easier. > > > Diogo: I haven't set this up and tried it. Is this what is happening with > you? > > Cheers, > Aravind > > > > > On Thu, Apr 13, 2017 at 6:07 AM, Ankit Srivastava <[email protected] > <javascript:>> wrote: > >> Thats weird. Do you have a pipeline dependency setup for the pipelines. >> What I mean is - BuildSS downstream pipeline with BuildCommons pipeline as >> a pipeline material. >> https://docs.gocd.io/current/configuration/managing_dependencies.html >> >> I quickly setup below scenario and it worked as expected. Downstream >> pipeline only get triggered once the upstream is finished and have the >> latest commits of github material. >> >> [image: Inline image 1] >> >> On Thu, Apr 13, 2017 at 2:31 PM, Diogo Oliveira <[email protected] >> <javascript:>> wrote: >> >>> Hi, >>> >>> Thanks for your answer :-) >>> >>> The problem is that I've done some experiments and I'm actually not >>> observing that... What is happening is that when I commit on both /Commons >>> and /SS both pipelines are being scheduled at the same time, the second one >>> with the previous /Commons version :-( >>> >>> quinta-feira, 13 de Abril de 2017 às 07:02:14 UTC+1, Ankit escreveu: >>>> >>>> Hi Diogo, >>>> >>>> >> My question now is: if I make a commit that changes files on both >>>> /Commons and /SS, since BuildSS depends on BuildCommons and they share the >>>> /Commons material, I was expecting that the BuildSS pipeline would only >>>> schedule when the first finished. >>>> >>>> Your understanding is correct. BuildSS will only get triggered once >>>> BuildCommons is finished. You can read more here about the pipeline >>>> dependencies: >>>> https://docs.gocd.io/current/configuration/managing_dependencies.html >>>> >>>> As there was change in both /Commons and /SS, BuildSS will wait until >>>> BuildCommons >>>> finishes as per above. Later once BuildCommons is build successfully, >>>> BuildSS will get triggered with latest commits of /Commons, /SS and >>>> whatever the state of /Plugins material. >>>> >>>> Cheers, >>>> Ankit >>>> >>>> On Tue, Apr 11, 2017 at 9:08 PM, Diogo Oliveira <[email protected]> >>>> wrote: >>>> >>>>> Hi guys, >>>>> >>>>> I was trying to model something in Go and some questions arised in the >>>>> way that go manages dependencies and pipeline scheduling. Namely, I'd >>>>> like >>>>> to know if the behavior I'm observing is the expected. >>>>> >>>>> So, what am I trying to do? >>>>> >>>>> I have one pipeline that depends on a previous pipeline. Both share a >>>>> common material, but the second one has more materials that are not on >>>>> the >>>>> first pipeline. A relevant detail is that all the materials are >>>>> subfolders >>>>> of the same SVN branch, so I can actually commit in more than one >>>>> "material" at the same time. >>>>> >>>>> Let's look at a small picture to make the problem understanding easier: >>>>> >>>>> >>>>> <https://lh3.googleusercontent.com/-J0Q8AzBD0zo/WOz39hxBXzI/AAAAAAAAGM4/t_Kr2B_ET0k_dVzw9yyB24GaIG1-1xZDwCLcB/s1600/godeps.PNG> >>>>> >>>>> >>>>> So, this is the setup. >>>>> >>>>> >>>>> My question now is: if I make a commit that changes files on both >>>>> /Commons and /SS, since BuildSS depends on BuildCommons and they share >>>>> the >>>>> /Commons material, I was expecting that the BuildSS pipeline would only >>>>> schedule when the first finished. >>>>> >>>>> >>>>> On the other hand, I also committed on /SS, so I understand that >>>>> BuildSS pipeline detects that it has material changes that are not shared >>>>> by ancestor pipelines. >>>>> >>>>> >>>>> So, my question is: what is the expected behavior here? :) >>>>> >>>>> >>>>> Thanks in advance! >>>>> >>>>> >>>>> Best Regards, >>>>> >>>>> Diogo Oliveira >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> 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 [email protected] <javascript:>. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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 [email protected] <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
