The KDEPIM / Akonadi situation

[Ben Cooksley]

On Sun, Jun 14, 2020 at 4:29 AM Ingo Klöcker <kloecker at 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