[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The CI issue (was Re: Request push access on Salsa)



On 10/18/21 6:26 PM, Nilesh Patra wrote:
Hi Faust,

On Mon, 18 Oct, 2021, 9:43 pm Faustin Lammler, <faustin@fala.red> wrote:

     > To put it in a nutshell: we have a very special setup that allows us
     > to prevent any regression (efficiently) with all go packages currently
     > on the archive. But this setup requires a dedicated machine. That's
     > why we can't use the SalsaCI shared runners. (at least for the moment)
    This is the part that I do not understand sufficiently well I guess.


If I remember this properly, I think the reason was go packages are very sensitive to version changes. As you might see in go.mod files as well, version numbers are pinned.

So it's not unlikely to break something when doing minor updates. -- I *think* this was the reason, but I don't trust my memory much :)
Aloïs could shed some more light on this.


Exactly! Everything is explained in details in the go team ci page [1].

Since we try to keep only one version of a package at a given time, every package upload may break other
packages that depends on it. This is especially true for Go core package.

While we could use a standards workflow and use tools like dose-ceve(1) to fetch reverse depends of a
Go package and rebuild everything in a clean schroot to make sure nothing has been broke with the update,
it is much more faster to keep a local index of all Go packages and rebuild the whole Go archive and check
for breakage. That's why we have such a 'special' setup. Because it allows us to do efficient rebuild (<30sec
to rebuild the whole Go archive with an up-to-date cache). We sacrifice the easier common setup for performance.

    Also, the fact that the go team should provide personal runners seems a
    bit strange to me and I am wondering why those can not be provided by
    Debian infra... But again, I am maybe lacking information here.


I guess Aloïs planned asking DSA (Debian system administrator) for Debian infra in long run, so your thinking is right, that's actually the plan in long run.


Exactly.

Nilesh

Cheers!

[1]: https://go-team.pages.debian.net/ci.html

--
Aloïs Micard <creekorful@debian.org>

GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2

Attachment: OpenPGP_signature
Description: OpenPGP digital signature


Reply to: