KDE Gear projects with failing CI (master) (10 December 2024)

[Volker Krause]

On Freitag, 13. Dezember 2024 21:27:00 Mitteleuropäische Normalzeit Ingo 
Klöcker wrote:
> On Freitag, 13. Dezember 2024 16:30:46 Mitteleuropäische Normalzeit Volker
> 
> Krause wrote:
> > On Mittwoch, 11. Dezember 2024 20:31:54 Mitteleuropäische Normalzeit Heiko
> > 
> > Becker wrote:
> > > On Wednesday, 11 December 2024 00:08:48 CET, Albert Astals Cid wrote:
> > > > ksudoku - NEW
> > > > 
> > > >  * https://invent.kde.org/games/ksudoku/-/pipelines/836274
> > > >  
> > > >   * craft mac jobs fail
> > > 
> > > https://invent.kde.org/games/ksudoku/-/merge_requests/30
> > > 
> > > It was easy enough to fix, but it wouldn't have happened if Laurent
> > > would
> > > use Merge Requests...
> > 
> > Merge requests don't run the deploy stage of the pipeline (which is the
> > part that failed here), so that on its own wouldn't have caught this
> > either, the MR would have been green and only failed after integration.
> 
> Frankly, I think it should be common sense that one triggers the
> corresponding CD job manually if one works on it. It's a bit annoying
> because one has to wait until the build stage is complete before one can
> trigger the job. 

Ideally, yes. From seeing how often things like that happen I don't think that 
is generally done though. It requires some understanding on how the entire CI/
CD stuff works and realizing which changes can break CD. I mean I have some 
understanding of this, and I miss that often enough myself.

Random other example I just ran into:
https://invent.kde.org/multimedia/elisa/-/merge_requests/620

MR was green, red after integration, CI/CD broken since then.

> But it's even more annoying for everybody else if one breaks CI/CD.

I'm fully with you on that. That's why I said it's essential that people 
receive failure notifications and act on them. Ignoring those is not 
acceptable.

Things may slip through one way or the other and break the build after all 
(and I'm guilty of that myself often enough), I expect everyone (myself 
included) to clean up after themselves if that happens though.

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/kde-devel/attachments/20241215/8415c6d7/attachment.sig>