The KDEPIM / Akonadi situation

[Ben Cooksley]

On Sat, Jun 13, 2020 at 7:52 PM Christophe Giboudeaux
<christophe at krop.fr> wrote:
>
> On vendredi 12 juin 2020 23:54:19 CEST Ben Cooksley wrote:
>
> > They are however, terrible at reading emails from the CI system. To the
> > point I suspect they have filters sending such mail to the trash so it is
> > never seen.
> >
> > Akonadi has been in a broken state for several days now on FreeBSD. They
> > have received multiple notices of this to their mailing list, and yet no
> > action has been taken.
> >
>
> On samedi 13 juin 2020 09:29:36 CEST Volker Krause wrote:
>
> > sigh, not this again please... Ben, you very well know I look after Jenkins
> > issues at least once a day. Here's yesterday:
> > (1) manually triggered a number of PIM builds that were stuck due to having
> > ran in the wrong order, I'm sure the Jenkins log will confirm that if you
> > don't believe me.
>
> Now here's my question to sysadmins:
>
> Failures caused by the testing system being unable to build things in order
> has *always* being present and doesn't only concerns the pim repositories.
>
> What did you do to fix the repeated failures caused by systems you maintain?
>

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.

For Jenkins, it's support for this is done through
"upstream/downstream jobs". When specified in a job configuration,
these result in downstream jobs being triggered when upstream jobs
built. If the full dependency chain were to be set in Jenkins this
would have the highly undesirable side effect of rebuilding everything
in KDE each time a commit were made to one or more of the Frameworks
repositories.

As i'm sure you can understand, that is not sustainable or scalable in
any form. I should also note that this functionality does not always
behave in the manner you would expect (see
https://issues.jenkins-ci.org/browse/JENKINS-22800) and therefore
cannot be relied on to do this in any case.

In terms of Gitlab, while it does allow triggering jobs in other
projects as part of a job run (see
https://docs.gitlab.com/ee/ci/multi_project_pipelines.html) this is
limited to a dependency chain only. It does not extend to waiting for
the parent job to complete.

Therefore at this time what you are requesting is not technically
possible with either the solution we are currently on, or the solution
we are looking at moving to.

The generally accepted solution to this class of issue is to:
1) Ensure things such as version bumps are done in two phases, with
the version bump and dependency bump happening in separate commit/push
rounds
2) Perform pushes to repositories in the correct order, and provide
some time between them rather than doing them immediately.

(1) is how Frameworks manages this problem in particular. I know in
the past that PIM has not followed, and has refused to follow when
suggested, this practice.

Regards,
Ben