On Sun, Nov 24, 2024 at 8:56 PM Simon Josefsson <si...@josefsson.org> wrote: > > Shengjing Zhu <z...@debian.org> writes: > > > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson <si...@josefsson.org> wrote: > >> > >> Hi. > >> > >> I never understood what > >> the 'test_the_archive' job does or what it helps with. All failures I > >> have ever encountered are cought by the standard Salsa pipeline (and it > >> catches many other mistakes). Does 'test_the_archive' test for anything > >> that the normal Salsa pipeline would not catch? I never understood > >> that. > > > > The normal salsa CI is for QA for the package itself. > > 'test_the_archive' is something like ratt, but designed with cache and > > efficiency (well, currently broken and half implemented). But they are > > two different things. > > > > The normal salsa CI is good for "go programs", but I'm not convinced > > it's good for the large amount of "go libraries", which are just based > > on the standard template from dh-make-golang. > > Then I think both jobs are useful. The Salsa CI catches many usual > packaging mistakes for "go libraries" that "test_the_archive" doesn't > (e.g., it performs real packages builds and runs lintian). There is no > conflict with running jobs from both pipelines. There is added (of > course) CPU time to run all jobs, but presumably people donating the > shared runners believe it is worth it for better Debian package quality. >
Please be aware that the large number of CI jobs not only consumes resources of gitlab runner, but also increases the load of the gitlab server. I'm already very sad with the slowness of our gitlab instance - salsa. Well you may argue that the number of go libraries is a small ratio of the whole debian packages, but I hope we can still save a little load for the salsa server. -- Shengjing Zhu
