<div dir="ltr"><div dir="ltr">On Sat, Nov 30, 2024 at 10:48 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@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 Freitag, 29. November 2024 15:06:51 Mitteleuropäische Normalzeit Ingo <br>
Klöcker wrote:<br>
> On Freitag, 29. November 2024 10:31:10 Mitteleuropäische Normalzeit 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>> wrote:<br>
> > > (2) Optimizing CI operations to reduce energy use<br>
> > > <br>
> > > That's IMHO the more interesting goal. However there's probably bigger<br>
> > > things<br>
> > > to look into first, such as identifying unnecessary pipeline runs (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 triggering<br>
> > when a merge request already exists, but yes there is potentially 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 then<br>
> > they can use the Git option ci.skip to prevent CI from running (git push<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 MR,<br>
> runs an MR pipeline and does NOT run a branch pipeline. (I have just tested<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. Might be <br>
a timing problem. :-/<br></blockquote><div><br></div><div>Likely a race condition between the various involved components of Gitlab.</div><div><br></div><div>The two options I can see for resolving this are:</div><div>a. Making use of the "ci.skip" Git push option when pushing a new work branch to be used in a merge request</div><div>b. We set CI jobs as manual by default on work/ branches (optionally making use of a CI environment variable to allow work branches to run by default)</div><div><br></div><div>I wouldn't be in favour of making the CI jobs disabled by default on work branches as that is non-intuitive / non-obvious behaviour, especially if you have to pass an environment variable to make them show up.</div><div> </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>
Ingo<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div></div></div>