On 7/30/25 9:15 PM, Ben Cooksley wrote:
On Thu, Jul 31, 2025 at 4:52 AM Harald Sitter <sit...@kde.org> wrote:
On Wed, Jul 30, 2025 at 1:25 PM Ben Cooksley <bcooks...@kde.org>
wrote:
>
> On Wed, Jul 30, 2025 at 7:18 PM Vlad Zahorodnii
<vlad.zahorod...@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
