measuring software's embodied carbon; was: online meetup Wed. 20 Nov. 18h UTC | Green Coding Solutions: "Eco-CI" and "Powerletrics"

[Albert Astals Cid]

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 <kloecker at kde.org> 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 <vkrause at kde.org> 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