On Sat, Jun 13, 2020 at 7:52 PM Christophe Giboudeaux <christo...@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
