Blacklisting of PIM from the CI system

[Harald Sitter]

On Tue, Dec 3, 2019 at 8:55 PM Volker Krause <vkrause at kde.org> wrote:
>
> On Sunday, 1 December 2019 04:00:19 CET Ben Cooksley wrote:
> > On Sun, Dec 1, 2019 at 10:17 AM Volker Krause <vkrause at kde.org> wrote:
> > > On Saturday, 30 November 2019 19:14:38 CET Ben Cooksley wrote:
> [...]
> > > > Fixing the current set of failures will not prevent this blacklisting
> > > > action from being carried out - as a recurring issue it needs a
> > > > permanent solution.
> > >
> > > What do you envision this permanent solution to look like?
> >
> > It's hard to say.
> >
> > Given the current problem, which is changes being actively made that
> > break the build, the ideal solution would be the developers who are
> > making these breakages to actively keep an eye on their jobs on the CI
> > system.
>
> That isn't an entirely fair statement IMHO, the changes triggering this were
> perfectly fine with either the latest Frameworks release or a recent enough
> master, just not the delayed master we had available on the CI at this point.
> Seeing this hit other master-tracking builds too (e.g. OpenSuse in #kontact
> this morning), I completely agree though this needs a better solution overall.
>
> Tracking the latest release would be one approach, but from direct discussion
> I understand that's currently not a viable solution due to Plasma's needs. Not
> allowing changes for master compatibility (with the corresponding version
> #ifdefs) is also counter-productive though, as it prevents early testing of
> Frameworks changes (even if just locally). So the best I can think of is
> making sure this situation is widely enough understood, and we have a way to
> find out which exact revisions of Frameworks are deployed. Then we can maybe
> get to the point where we can defer such commits until a recent enough
> revision is available, which IIUC would usually take 48-72h.

Random thought to make dependency problems more obvious: glue the git
sha into the cmake package version for frameworks (when built from
git) so it finds "5.65.0.abcd123" given us a lead on what is actually
available.

https://phabricator.kde.org/D24641 would give us the foundation for that.

Not sure how viable this is, or even if it adds much value. After all
everyone still needs to know to check the specific in the build logs.

Food for thought I guess.

HS