CI system maintainability

[Ben Cooksley]

On Fri, Mar 29, 2019 at 10:33 PM Friedrich W. H. Kossebau
<kossebau at kde.org> wrote:
>
> Am Donnerstag, 28. März 2019, 23:06:17 CET schrieb laurent Montel:
> > Le jeudi 28 mars 2019, 18:27:42 CET Friedrich W. H. Kossebau a écrit :
> > > Am Donnerstag, 28. März 2019, 16:56:33 CET schrieb laurent Montel:
> > > > Le jeudi 28 mars 2019, 16:11:12 CET Friedrich W. H. Kossebau a écrit :
> > > > > Given the actual purpose of this thread, I would be more curious how
> > > > > you
> > > > > have CI integrated in your workflow?
> > > >
> > > > CI: sometime I look at it, sometime not, sometime some guys informs me
> > > > that
> > > > it's broken (I remember that Luca told me some days ago that a package
> > > > didn't compile, so I fixed it).
> > > > Sometime my code compiles on local so for me it's ok but it's just that
> > > > I
> > > > forgot to trash my builddir.
> > >
> > > So you do not go on yourself to build.kde.org and check yourself? Does
> > > #kde- pim have a bot reporting build failures?
> >
> > Long time ago we had it in #kontact.
> > It's not the case now.
>
> Do you remember a reason why it is no longer the case?
>
> IMHO bringing the build report bot back to the chat channel could help with
> the issue this thread is about.

It was quite possibly lost during one of the various refactors we've
had to do of the CI system to solve maintainability issues.
We've had a couple of generations of the CI system so far (by my
count, we're on generation 4), and things have unfortunately been lost
in between the switch between various generations.

IRC channel notifications are currently governed by the rules in
sysadmin/irc-notifications (which is also where commits and Bugzilla
activity notifications for IRC channels are controlled from). See
https://cgit.kde.org/sysadmin/irc-notifications.git/tree/jenkins/notifications.cfg

>
> People tend to look more often into the chat channel then in their email
> folder, so this bot would improve the visibility of the state on
> build.kde.org, also be in a public place so people can directly chat about
> any reasons.
>
> > > > > more? Given you said you work daily on KDE projects, it seems that
> the
> > > > > brokeness of those projects on the KDE CI has slipped your attention.
> > > > > So
> > > > > how does this happen, and how could this be prevented, other than
> > > > > people
> > > > > having to hunt you down on irc and tell you :)
> > > >
> > > > I think that Luca idea to send an email directly to the people which
> > > > breaks
> > > > code when it breaks from several commit is a good idea.
> > >
> > > Noted. Personally I would also fancy that over the generic mass emailing,
> > > where most of the time it was somebody else breaking stuff, so they
> should
> > > care. Given the time-offset due to build times it is also unclear who
> > > broke
> > > things, given the email is not easy to parse, and one might already be
> off
> > > again to other things in life.
> > >
> > > Question is: when would you read the email, and how quick would you
> react?
> >
> > I read it sometime as it arrives in my kdepim-devel mailbox, but indeed
> > sometime we can have several mail in same time because we increase a
> package
> > dependancy and it breaks all other packages. So indeed I didn"t look at all
> > the time.
> >
> > But when a people signals me a problem I try to fix it quickly.
> >
> > An email send after 1 day that package is broken can be a good idea, so it
> > can't be a dependancy problem because we increase package version just that
> > it's really broken.
>
> Increasing the package version ideally should not result in CI breakages.
> Ideally CI only fails if there is a real issue, otherwise people just get
> used to it failing and do not give the deserved attention.
>
> What would prevent you to turn to a system like used with KDE Frameworks,
> where there is some internal dependency version and a separate actual
> version, with the actual version bumped earlier and the internal dependency
> version only bumped some days later? From what I saw, you increase versions
> quite often in PIM, so related breakages would happen quite often.
>
> Cheers
> Friedrich

Cheers,
Ben

>
> PS: Okay if we start to slim the list of CC:s a bit now? Would leave out
> plasma, kdevelop, frameworks-devel on any next reply at least.
>
>