On Sat, 2025-04-19 at 20:33 +1200, Ben Cooksley wrote: > On Sat, Apr 19, 2025 at 8:07 PM Vlad Zahorodnii > <vlad.zahorod...@kde.org> wrote: > > On 4/19/25 10:53 AM, Kai Uwe Broulik wrote: > > > Hi, > > > > > > thanks for looking into this. > > > > > > It seems a major contributor to CI time is the fact that a merge > > > request runs and once merged, master runs another pretty much > > > identical pipeline right after that. > > > > > A big part of the issue here is our rebase centric workflow - > normally with Gitlab you use merge commits and in this workflow CI > only runs when the MR changes. > With a rebase workflow like ours though, other changes to the repo > require the merge request to be updated - triggering unnecessary CI > runs.
With merge-based workflow you wouldn't find if someone's master changes resulted in the merge-request no longer building; well, not until it's merged, which is too late. So rebase-based workflow is better for development. > Note that builds on master are absolutely critical - both for > applications making use of CD builds, and for general applications - > because only master (and release branches) are marked as "protected". > Binary signing for CD builds as well as publishing of build artifacts > for other CI jobs to reuse only happens on protected branches - as > these are sensitive. This doesn't sound like "identical pipeline". Merge request would include linters and tests, but "after the merge" there's no point in running them, because that code was already checked. I imagine, the compilation stage does run anew, I'm wondering if it's possible to reuse build artifacts from MR on the master… Not sure how much time would it save though. > > > > Not sure what we can do about kwin. I looked how we can reduce the > > time > > needed to run tests, and there's not much space for improvements > > > > anymore. Speaking for kwin, I personally wouldn't mind if KDE > > adopts a > > different policy regarding running CI. For example, only run CI > > when > > it's time to merge a change and after a change lands in master or > > if a > > pipeline is manually triggered by a developer. > > > > > Gitlab doesn't support what you are describing i'm afraid - there is > no way of telling it "i'm ready to merge this change now". > Realistically merge requests shouldn't be proposed until people are > ready to get something reviewed and merged in... There's a rule called "manual", which I think can be used in this case. So CI won't run till a person decides the code is ready. Not sure how comfortable would that be, just mentioning.
