So sometimes with one repo and multiple pipelines you want fan-in
behaviour, e.g if you are splitting the pipelines to run different logical
testing blocks in parallel and either
- don't want to model them as parallel jobs within one pipeline or
- where pipelines require multiple source
You are spot on. We do share one of the repositories for the all
microservice(aka upstreams).
And was able to simulate and see where the fan-in didn't happen when
upstreams do not share any of the materials.
Thanks for prompt response,
Mani
On Tue, Jun 13, 2023 at 8:43 AM Chad Wilson wrote:
>
If it's "not monorepo", can you clarify if you have multiple upstreams that
point to one repository/material? That is the scenario that triggers
fan-in, and that does at least indicate that the repo is somewhat being
treated as a monorepo in the sense that you have multiple pipelines
directly
Ours is not monorepo. Is there any other alternative?
On Tue, Jun 13, 2023, 07:18 Chad Wilson wrote:
> Doing that means removing the guarantees fan-in offers you as to
> consistency of the material versions on upstream pipelines when triggering
> a downstream.
>
> It's possible to turn off
Doing that means removing the guarantees fan-in offers you as to
consistency of the material versions on upstream pipelines when triggering
a downstream.
It's possible to turn off fan-in globally (although I have never done so
personally) but to my knowledge not for individual pipelines.
We do have a fan-in where number upstream has exploded in the count,
Instead of waiting for all upstream to pass, can we pick most recent
successful upstream pipeline along with new pipeline instance of one(or
more) of upstream?
Thanks,
Mani
--
You received this message because you are
