You might want to have a read of https://github.com/gocd/gocd/issues/1583
I believe often this is a side-effect of having one upstream pipeline manually triggered (infrequently) which shares a material with another upstream pipeline which is auto-triggered on each commit - and sometimes due to use of inconsistent filters on triggers for the same material (allowlists or denylists for particular paths in the repo). It's difficult to comment on your specific case without some kind of description of the topology of your pipelines and triggers but generally I find this is due to pipeline design or material/repo structure challenges where people have relied on trigger filters in ways that "breaks" or prevents fan-in. GoCD is basically saying "I tried to go back a long way (100 revisions by default) through the ancestor pipelines and couldn't find a successful build of the relevant ancestors which could be traced to matching/consistent material revisions so I gave up". Assuming you *do* want fan-in semantics and revision matching across your server, you can increase the limit by setting the system property *-Dresolve.fanin.max.backtrack.limit=200* (default=100) but I am not personally sure of the implications of that for performance, especially not in your specific case - and it may not get to the root cause of why in your pipeline/trigger design it is difficult for GoCD to resolve a common ancestor, so may not solve the *real* problem. One way of debugging this is to identify the problematic shared material, and then view the Value Stream Map *from the perspective of individual commits* and see which downstream pipelines actually had builds triggered for that commit. The ones that didn't trigger might have filters, failures or manual approvals preventing the later fan-in. -Chad On Thu, Mar 2, 2023 at 12:11 AM Pedro Carriço <[email protected]> wrote: > Hi, > > Recently I've been having the following error: > > "Error while scheduling pipeline: smoke-tests- Feb, 2023 at 12:14:00 Local > Time > Maximum Backtracking limit reached while trying to resolve revisions for > material DependencyMaterialConfig{pipelineName='app-staging', > stageName='deploy'}" > > I can't find anything recent regarding that error or how to fix it, this > just started happening and seems to go away if I trigger the pipeline > manually or if another commit triggers the upstream pipeline. That specific > pipeline is also in the middle of a fan-in pipeline. > > How am I able to fix this error or debug what's happening? > > Thanks > > > > > > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/go-cd/dc19ee7b-f937-42a7-8505-71990f588f60n%40googlegroups.com > <https://groups.google.com/d/msgid/go-cd/dc19ee7b-f937-42a7-8505-71990f588f60n%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/go-cd/CAA1RwH97rD4Oz_qk11R3guSLQ-5PXeZTZ3XCgtmJyZVrrvQD%3Dw%40mail.gmail.com.
