CI that doesn't run on MRs

[Nate Graham]

On 7/30/25 1:15 PM, Ben Cooksley wrote:
> 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.
> 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.

Every merge request (everywhere, not just in Plasma) is submitted in a 
state where the author believes it's ready for merging. The purpose of 
review is for others to challenge that belief and offer suggestions for 
improvement. Hence iteration, and avoiding that is impossible for all 
but the smallest and most trivial merge requests.

You only see this process using a lot of resources in Plasma because 
Plasma is the largest and most active project in KDE. As I recall, there 
were similar complaints about Krita and Kstars, which are also large and 
active projects.

Implicitly punishing projects for success and popularity is a rather 
perverse incentive, I hope you'll agree!



> 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.

I think we're all mostly in agreement that running the pipeline n times 
for n pushes in large and active merge requests is something that 
doesn't make a lot of sense.

The question is how to improve upon this without throwing the baby out 
with the bathwater.

Using the Draft flag for such merge requests once it becomes clear that 
they won't merge immediately is one option. Perhaps there are others, 
like running pipelines automatically only upon MR submission, and 
thereafter requiring a fully green pipeline as a prerequisite for 
merging and starting a pipeline automatically when someone clicks "Set 
to auto-merge". Lots of options here; we can brainstorm.



> 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.

There's plenty of blame to go around. We can and should improve this.

 From another quarter, an improvement I can envision is not re-running 
the pipeline on a commit that came from a merge request that already ran 
the pipeline right before merging. This is wasted work in 100% of cases.


Nate