CI system maintainability

Volker Krause vkrause at kde.org
Thu Mar 28 16:02:19 GMT 2019


On Thursday, 28 March 2019 16:32:34 CET Luca Beltrame wrote:
> In data giovedì 28 marzo 2019 15:15:23 CET, Nate Graham ha scritto:
> > In this case, it seems like the problem is that there are certain
> > individuals or teams that are pushing risky, breaking changes without code
> > review, and then ignoring failures in the CI. I think we might do well to
> > try to answer the question of why that's happening before we create a new
> > rule aimed at stopping it.

That "risky breaking change" was a 5 line fix for a Qt 5.13 build issue that 
had been successfully deployed to multiple repos before. The failure was also 
not ignored but noticed and fixed within about an hour, just not in all 
affected branches.

> Well put. Review or not review, clearly something in the process has failed,
> and I suspect "friction" rather than actual bad-faith ignorance of the CI
> results.
> 
> So, perhaps to force myself out of the bikeshedding (mea culpa) on reviews,
> I'll steal Friedrich's points from another mail and put them here
> synthetically:
> 
> - Why are the CI mails ignored / filtered? Too many, hard to parse,
> difficult to interpret?
> - What can be done to have people look at them and make sure they don't
> overlook breakage?
> 
> At least for the second point, as I mentioned earlier in the thread,
> probably having the committer being mailed in case of failure (GitLab does
> this IIRC) might be better than just on the mailing list. The second
> approach is what we use in openSUSE, where I usually don't subscribe to
> failure notifications (almost 300 packages is overkill) but a bot starts
> pestering me with mails the moment build failures go unfixed (granted, the
> time scale is different).
> 
> For the first, I'd like people more involved in the development to say their
> word.

See my earlier mail in this thread on how this slipped through for me.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20190328/0ef1efc7/attachment-0001.sig>


More information about the Plasma-devel mailing list