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

[Ben Cooksley]

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.


>
> Regards,
> Ingo
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20241130/f3ce408b/attachment.htm>