CI that doesn't run on MRs

[Nicolas Fella]

On 7/30/25 9:15 PM, Ben Cooksley wrote:
> On Thu, Jul 31, 2025 at 4:52 AM Harald Sitter <sitter at kde.org> wrote:
>
>     On Wed, Jul 30, 2025 at 1:25 PM Ben Cooksley <bcooksley at kde.org>
>     wrote:
>     >
>     > On Wed, Jul 30, 2025 at 7:18 PM Vlad Zahorodnii
>     <vlad.zahorodnii at kde.org> wrote:
>     >>
>     >> On 7/30/25 9:58 AM, Harald Sitter wrote:
>     >> > Hey
>     >> >
>     >> > So, I need to vent a bit. I am super unhappy with the manual CI
>     >> > trigger stuff. Half the time I forget.  When I don't forget I
>     want to
>     >> > press all the buttons, but I can't because of the prestage, I
>     usually
>     >> > sit there for 5 seconds, nothing happens because the prestage
>     takes
>     >> > more than 5 seconds, I get distracted and do something else
>     ... and
>     >> > forget I wanted to land something at all.
>     >
>     >
>     > I was working on some merge requests for sysadmin/repo-metadata
>     just a few hours ago, which only contains basic linting jobs.
>     > They were picked up and fully processed in the space of ~30
>     seconds - total of 6 different linter jobs (so 6 containers
>     spawned in total).
>     >
>     > All seems quite reasonable for processing turnaround.
>     >
>     >>
>     >> >
>     >> > More and more I find myself not caring and merging without
>     pre-merge
>     >> > CI. Between the manual triggers, failing appium tests, and
>     conflicting
>     >> > merges I just can't be bothered with the CI. Surely that
>     can't be the
>     >> > goal here.
>     >> >
>     >> > Can we get back a CI that helps?
>     >>
>     >> Hi,
>     >>
>     >> Just in case, the automatic CI got disabled because kwin had
>     too many
>     >> pipelines and it takes about 10-15 minutes for a single pipeline to
>     >> complete.
>     >>
>     >> There was a long and somewhat heated discussion about it. We
>     asked to
>     >> disable automatic CI for kwin specifically, so when you push to
>     a work
>     >> branch that is not ready to be merged yet, no CI resources are
>     wasted.
>     >> However, instead, automatic CI got disabled for all Plasma
>     projects.
>     >> Sorry! :(
>     >
>     >
>     > Plasma in general was set to manual for all merge requests
>     because the commentary in that thread made it appear that the
>     workflows were more Plasma than just KWin. There are also issues
>     with Appium tests in Plasma Desktop / Workspace which mean
>     pipelines take an extremely long amount of time to complete/fail
>     (something on the order of 40-50 minutes if memory serves)
>     >
>     > The overuse of CI resources by Plasma could in part be mitigated
>     by marking merge requests that are not ready to merge as draft,
>     which seems to be a Gitlab feature that is not in use at all at
>     least if I take a cursory look at current pending KWin MRs. We
>     already set CI into manual mode for draft merge requests as a
>     global rule, as well as for work branches.
>
>     What confuses me right now is whether this is just plasma being an
>     active project or gitlab having poor behavior. It occurs to me that
>     the former would be solved by giving plasma dedicated plasma resources
>     to use, while the latter is a matter of hiring someone to engineer the
>     problem(s) with gitlab away.
>     Both solvable problems though.
>
>
> If memory serves correctly the general view from that thread could be 
> summarised as:
> 1) Work branches were basically used to immediately open merge 
> requests in the majority of cases, so running CI on pushes to work 
> branches was simply a waste as CI would be (re-)run on the merge request.

That part seems pretty uncontroversial.


> 2) Merge requests were used as part of an iterative development 
> workflow, and as such CI runs on merge requests were in many cases 
> also useless because the MR was not yet ready to be merged and was 
> still under active development.
>
> Because merge requests that aren't actually ready for final review and 
> then merging cannot currently be distinguished from merge requests 
> that are not at all ready and are just collecting comments, the only 
> way to solve for (2) is to switch CI to manual on merge requests.
>
> Gitlab already has a mechanism for differentiating between those two 
> types of merge requests (marking as draft) however it is not used by 
> Plasma (or at least wasn't on the two pages of KWin reviews I quickly 
> skimmed)
>
> So this isn't really Gitlab's fault, it is how Plasma has opted to use 
> Gitlab.

That's not something that's unique to Plasma in any way. Sometimes you 
make a merge request and it quickly gets approved and merged, sometime 
it takes a few iterations until consensus is reached. That's how it 
works for any reasonably active project where it's not just one guy 
pushing straight to master.


> If you were to adopt the draft flag on merge requests that are in that 
> iterative phase and not intended to be merged then we could look at 
> adjusting how it works.
>
> Note that this won't do anything to solve broken tests, or tests that 
> take too long - that is something only Plasma developers can correct.
>
> Cheers,
> Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20250730/d0c0bafe/attachment-0001.htm>