El dissabte, 30 de novembre del 2024, a les 4:29:22 (Hora estàndard del Centre d’Europa), Ben Cooksley va escriure: > On Sat, Nov 30, 2024 at 10:48 AM Ingo Klöcker <[email protected]> wrote: > > On Freitag, 29. November 2024 15:06:51 Mitteleuropäische Normalzeit Ingo > > > > Klöcker wrote: > > > On Freitag, 29. November 2024 10:31:10 Mitteleuropäische Normalzeit Ben > > > > > > Cooksley wrote: > > > > On Fri, Nov 22, 2024 at 4:51 AM Volker Krause <[email protected]> wrote: > > > > > (2) Optimizing CI operations to reduce energy use > > > > > > > > > > That's IMHO the more interesting goal. However there's probably > > > > bigger > > > > > > > things > > > > > to look into first, such as identifying unnecessary pipeline runs (a > > > > > work > > > > > branch push/MR creation currently triggers two pipelines which are > > > > > identical > > > > > in most cases for example). > > > > > > > > We already have optimisation in place to prevent duplicate jobs > > > > triggering > > > > > > when a merge request already exists, but yes there is potentially some > > > > work > > > > to be done here to improve efficiency. > > > > If a developer knows they are going to be immediately creating a MR > > > > then > > > > > > they can use the Git option ci.skip to prevent CI from running (git > > > > push > > > > > > -o ci.skip) > > > > > > There's an even better approach. If one pushes a work branch with > > > `git push -o merge_request.create` then GitLab immediately creates an > > > MR, > > > runs an MR pipeline and does NOT run a branch pipeline. (I have just > > > > tested > > > > > this.) > > > > Sadly, it seems this does not always work. It worked for > > https://invent.kde.org/pim/libkleo/-/merge_requests/170 > > but it didn't work for > > https://invent.kde.org/pim/mimetreeparser/-/merge_requests/62 > > where a branch pipeline was started 2 seconds before the MR pipeline. > > Might be > > a timing problem. :-/ > > Likely a race condition between the various involved components of Gitlab. > > The two options I can see for resolving this are: > a. Making use of the "ci.skip" Git push option when pushing a new work > branch to be used in a merge request > 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) > > 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.
How is it non-obvious? You created a "work" branch so no automatic CI for you, if you want one, create a Merge Request (so you show your work to the rest of us) or run the CI manually. Cheers, Albert > > > Regards, > > Ingo > > Cheers, > Ben
