<html><head><style>pre,code,address {
margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
margin-top: 0.2em;
margin-bottom: 0.2em;
}
ol,ul {
margin-top: 0em;
margin-bottom: 0em;
}
blockquote {
margin-top: 0em;
margin-bottom: 0em;
}
</style></head><body><div>On Sat, 2025-04-19 at 20:33 +1200, Ben Cooksley wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Sat, Apr 19, 2025 at 8:07 PM Vlad Zahorodnii <<a href="mailto:vlad.zahorodnii@kde.org">vlad.zahorodnii@kde.org</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>On 4/19/25 10:53 AM, Kai Uwe Broulik wrote:<br>> Hi,<br>><br>> thanks for looking into this.<br>><br>> It seems a major contributor to CI time is the fact that a merge <br>> request runs and once merged, master runs another pretty much <br>> identical pipeline right after that.<br></div><br></blockquote><div><br></div><div><div>A big part of the issue here is our rebase centric workflow - normally with Gitlab you use merge commits and in this workflow CI only runs when the MR changes.</div><div>With a rebase workflow like ours though, other changes to the repo require the merge request to be updated - triggering unnecessary CI runs.</div></div></div></div></blockquote><div><br></div><div>With merge-based workflow you wouldn't find if someone's master changes resulted in the merge-request no longer building; well, not until it's merged, which is too late. So rebase-based workflow is better for development.</div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote gmail_quote_container"><div>Note that builds on master are absolutely critical - both for applications making use of CD builds, and for general applications - because only master (and release branches) are marked as "protected".</div><div>Binary signing for CD builds as well as publishing of build artifacts for other CI jobs to reuse only happens on protected branches - as these are sensitive.</div></div></div></blockquote><div><br></div><div>This doesn't sound like "identical pipeline". Merge request would include linters and tests, but "after the merge" there's no point in running them, because that code was already checked. I imagine, the compilation stage does run anew, I'm wondering if it's possible to reuse build artifacts from MR on the master… Not sure how much time would it save though. </div><div><br></div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote gmail_quote_container"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div><br>Not sure what we can do about kwin. I looked how we can reduce the time <br>needed to run tests, and there's not much space for improvements</div><br></blockquote><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><div>anymore. Speaking for kwin, I personally wouldn't mind if KDE adopts a <br>different policy regarding running CI. For example, only run CI when <br>it's time to merge a change and after a change lands in master or if a <br>pipeline is manually triggered by a developer.<br></div><br></blockquote><div><br></div><div>Gitlab doesn't support what you are describing i'm afraid - there is no way of telling it "i'm ready to merge this change now".</div><div>Realistically merge requests shouldn't be proposed until people are ready to get something reviewed and merged in...</div></div></div></blockquote><div><br></div><div>There's a rule called "manual", which I think can be used in this case. So CI won't run till a person decides the code is ready. Not sure how comfortable would that be, just mentioning.</div><div><span></span></div></body></html>