<div dir="ltr"><div dir="ltr">On Tue, Dec 3, 2024 at 5:43 AM Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Samstag, 30. November 2024 11:41:12 Mitteleuropäische Normalzeit Albert <br>
Astals Cid wrote:<br>
> El dissabte, 30 de novembre del 2024, a les 4:29:22 (Hora estàndard del<br>
> Centre<br>
> d’Europa), Ben Cooksley va escriure:<br>
> > On Sat, Nov 30, 2024 at 10:48 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org" target="_blank">kloecker@kde.org</a>> wrote:<br>
> > > On Freitag, 29. November 2024 15:06:51 Mitteleuropäische Normalzeit Ingo<br>
> > > <br>
> > > Klöcker wrote:<br>
> > > > On Freitag, 29. November 2024 10:31:10 Mitteleuropäische Normalzeit<br>
> > > > Ben<br>
> > > > <br>
> > > > Cooksley wrote:<br>
> > > > > On Fri, Nov 22, 2024 at 4:51 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> <br>
wrote:<br>
> > > > > > (2) Optimizing CI operations to reduce energy use<br>
> > > > > > <br>
> > > > > > That's IMHO the more interesting goal. However there's probably<br>
> > > <br>
> > > bigger<br>
> > > <br>
> > > > > > things<br>
> > > > > > to look into first, such as identifying unnecessary pipeline runs<br>
> > > > > > (a<br>
> > > > > > work<br>
> > > > > > branch push/MR creation currently triggers two pipelines which are<br>
> > > > > > identical<br>
> > > > > > in most cases for example).<br>
> > > > > <br>
> > > > > We already have optimisation in place to prevent duplicate jobs<br>
> > > <br>
> > > triggering<br>
> > > <br>
> > > > > when a merge request already exists, but yes there is potentially<br>
> > > > > some<br>
> > > > > work<br>
> > > > > to be done here to improve efficiency.<br>
> > > > > If a developer knows they are going to be immediately creating a MR<br>
> > > <br>
> > > then<br>
> > > <br>
> > > > > they can use the Git option ci.skip to prevent CI from running (git<br>
> > > <br>
> > > push<br>
> > > <br>
> > > > > -o ci.skip)<br>
> > > > <br>
> > > > There's an even better approach. If one pushes a work branch with<br>
> > > > `git push -o merge_request.create` then GitLab immediately creates an<br>
> > > > MR,<br>
> > > > runs an MR pipeline and does NOT run a branch pipeline. (I have just<br>
> > > <br>
> > > tested<br>
> > > <br>
> > > > this.)<br>
> > > <br>
> > > Sadly, it seems this does not always work. It worked for<br>
> > > <a href="https://invent.kde.org/pim/libkleo/-/merge_requests/170" rel="noreferrer" target="_blank">https://invent.kde.org/pim/libkleo/-/merge_requests/170</a><br>
> > > but it didn't work for<br>
> > > <a href="https://invent.kde.org/pim/mimetreeparser/-/merge_requests/62" rel="noreferrer" target="_blank">https://invent.kde.org/pim/mimetreeparser/-/merge_requests/62</a><br>
> > > where a branch pipeline was started 2 seconds before the MR pipeline.<br>
> > > Might be<br>
> > > a timing problem. :-/<br>
> > <br>
> > Likely a race condition between the various involved components of Gitlab.<br>
> > <br>
> > The two options I can see for resolving this are:<br>
> > a. Making use of the "ci.skip" Git push option when pushing a new work<br>
> > branch to be used in a merge request<br>
> > b. We set CI jobs as manual by default on work/ branches (optionally<br>
> > making<br>
> > use of a CI environment variable to allow work branches to run by default)<br>
> > <br>
> > I wouldn't be in favour of making the CI jobs disabled by default on work<br>
> > branches as that is non-intuitive / non-obvious behaviour, especially if<br>
> > you have to pass an environment variable to make them show up.<br>
> <br>
> How is it non-obvious? You created a "work" branch so no automatic CI for<br>
> you, if you want one, create a Merge Request (so you show your work to the<br>
> rest of us) or run the CI manually.<br>
<br>
There are valid usecases for CI runs on non-MR work branches. Current example <br>
is the ki18n multi-language lookup work which exposed behavior differences on <br>
FreeBSD and Windows that I could not debug locally. Instead this was done in a <br>
work branch of a fork, with debug output committed and run on the CI. Only the <br>
final result made it back into the MR.<br>
<br>
I didn't do this in the MR to not spam you with two dozen extra change <br>
notifications and to avoid debug commits anywhere near an MR that might get <br>
merged.<br>
<br>
And that's not a rare exception, for me at least, as I have little options to <br>
debug on platforms I don't have local access to otherwise.<br>
<br>
I wouldn't mind the CI being opt-in in that case, but being able to trigger <br>
this via push options would be nice then, rather than having to go through the <br>
web UI and creating pipelines manually each time.<br></blockquote><div><br></div><div>Based on this i'd say it is sounding like we should go for either:</div><div>1) Controlling automatic start of CI jobs using an environment variable for work/ branches; or</div><div>2) Using Git aliases to ensure -o ci.skip is passed consistently to Gitlab (preferred)</div><div> </div><div>Thoughts?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Volker</blockquote><div><br></div><div>Thanks,</div><div>Ben </div></div></div>