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
