Re: Add Salsa pipeline to default Go pipeline?

[Shengjing Zhu <zhsj@debian.org>]

On Wed, Jan 24, 2024 at 11:05 PM Simon Josefsson <simon@josefsson.org> wrote:
>
> Nilesh Patra <nilesh@nileshpatra.info> writes:
>
> > On 24 January 2024 2:25:53 pm IST, Simon Josefsson <simon@josefsson.org> wrote:
> >>Definitely -- however I don't see how we can ever have confidence in
> >>uploads of core Go packages without building all reverse dependencies.
> >>
> >>If that building is on developer local laptops or via Salsa is not that
> >>different from a resources perspective.  The CPU usage needs to happen
> >>somewhere.
> >>
> >>Going via Salsa allows everyone to easily see the result and help
> >>resolve each issue, and to have higher confidence that we don't miss
> >>anything since it is automated.  For package failure rebuilt via 'ratt'
> >>only the developer see the results.
> >>
> >>Of course, reverse dependency builds on Salsa should only be done
> >>manually for critical packages and not automatically on every push.
> >
> > IIRC, the salsa admins were unhappy with building reverse-depends via
> > salsa CI even for critical packages only during releases since it puts
> > a significant amount of load on the runners.
> >
> > I guess someone (maybe Jeremy) tried to do a reverse-builds for nodejs
> > and salsa admins were not okay with the same. I don't think the
> > situation is going to change much with core go package with lots of
> > revdeps either.
>
> Maybe the situation with salsa runner usage policy has changed.  I have
> several servers that can be used if the shared salsa runner admin
> doesn't want to support this usage.  We can tag reverse build jobs so
> they aren't picked up by the normal salsa runner too.  I've asked on
> #salsa to see if there are any guidelines.
>

I'm not a salsa admin, so it's not accurate. We don't lack the runner
resource, because it's on Google cloud, and we (the Debian project)
have budgets for it. The Gitlab CI not only needs runner resources,
but also resources on the scheduler, which is the main Gitlab
instance.

-- 
Shengjing Zhu