Gitlab configuration change

[Nicolás Alvarez]

Note that a CI pipeline will still run on the target branch after the
merge. If the rebase breaks the build, yes it would be *ideal* to catch it
before the MR gets merged, but at least it won't go *entirely* unnoticed.

-- 
Nicolás

El vie, 30 oct 2026 a la(s) 10:31 p.m., Kristen McWilliam (kristen at kde.org)
escribió:

> If I read this right, the default will now be to rebase and merge
> *without* running CI on the rebased state.
>
> Will this not lead to merges that successfully rebase but nevertheless
> have some breakage (that CI would hopefully have caught)?
> On 2026-10-30 09:09 p.m., Ben Cooksley wrote:
>
> Hi all,
>
> I've just pushed a change which will shortly begin rolling out to our
> repositories which will enable the "automatic rebase on merge" function of
> Gitlab.
> This feature recently became available in Gitlab from 19.2 onward.
>
> This means going forward when a merge request is ready to be merged it is
> no longer necessary to first rebase it and wait for CI to complete before
> you can merge.
> Clicking merge will automatically trigger a rebase, skipping CI as
> required on merge.
>
> [image: image.png]
>
> If you wish you can select "Rebase with pipeline" to trigger a traditional
> manual rebase and CI run.
>
> Regards,
> Ben Cooksley
> KDE Sysadmin
>
> --
> Cheers,
>   Kristen
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20261030/1b486722/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 22714 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20261030/1b486722/attachment-0001.png>