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. /Simon
Attachment:
signature.asc
Description: PGP signature