[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: The KDEPIM / Akonadi situation
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2020-06-13 20:11:33
Message-ID: CA+XidOHpgYbgtOKGRCq+m9nAt26ogaFYQKhtA52fQbHHg8V8Zw () mail ! gmail ! com
[Download RAW message or body]

On Sun, Jun 14, 2020 at 4:29 AM Ingo Kl=C3=B6cker <kloecker@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 lo=
op
> 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
[prev in list] [next in list] [prev in thread] [next in thread]