sön 2024-11-24 klockan 21:03 +0800 skrev Shengjing Zhu: > On Sun, Nov 24, 2024 at 8:56 PM Simon Josefsson <simon@josefsson.org> > wrote: > > > > Shengjing Zhu <zhsj@debian.org> writes: > > > > > On Sun, Nov 24, 2024 at 8:31 PM Simon Josefsson > > > <simon@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. One compromise would be to have an opt-in transition plan: only enable Salsa shared pipeline for all packages that we upload from now going forward. Then the action plan is simpler: 1) Patch dh-make-golang to create debian/salsa-ci.yml instead of debian/gitlab-ci.yml, pointing to a combination of salsa CI and test_the_world. And drop the disabling of shared runners on salsa on create-salsa-project. 2) On every package update, maintainers do the pipeline change manually. OTOH, this costs maintainer time compared to my other plan which just costs shared runner time. So I think this is a worse trade-off, human time is costlier than CPU time. My perception is that while definitely salsa speed could be improved, it is not that much of a difference compared to working on gitlab.com which I do a lot as well, and find acceptable. Maybe this is a question for the Salsa CI team, are they okay with shared runner CPU time for Go packages? /Simon
Attachment:
signature.asc
Description: This is a digitally signed message part