On Sun, Jun 14, 2020 at 4:29 AM Ingo Klöcker <kloec...@kde.org> wrote: > > On Samstag, 13. Juni 2020 10:35:50 CEST Ben Cooksley wrote: > > There is nothing that can be done to delay builds for one repository > > on the build of another at this present time. > > Neither Jenkins or Gitlab CI provide the necessary support for us to > > link jobs together in the way that PIM demands in this case here. > > > [snip] > > > > In terms of Gitlab, while it does allow triggering jobs in other > > projects as part of a job run (see > > Minor correction: It does allow triggered pipelines in other projects. > > > https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) this is > > limited to a dependency chain only. > > Not sure what you mean by "a dependency chain only". I have implemented > dependency trees even with loops (and then taking care that they don't loop > too often) in GitLab. What has not been possible was to prevent pipelines from > being triggered too often in diamond shape dependency scenarios.
By "dependency chain only" what I mean is that we don't want it to waterfall down. A change in KCoreAddons should not cause most of Frameworks followed by all of Plasma/Release Service/Extragear to be rebuilt. Providing CI would become impossible in that case, as it takes many hours (something on the order of 24+ hours) for the CI system to rebuild everything for all platforms. > > > It does not extend to waiting for the parent job to complete. > > That doesn't matter if the job triggering the pipeline of the dependent > project is the last job (i.e. in the last stage) of the parent project's > pipeline. It does matter, because that is what Christophe was asking about. It is also the only scalable option. > > Regards, > Ingo Cheers, Ben