Raphael Hertzog: > Hi, > > On Sun, 15 Sep 2019, Louis-Philippe Véronneau wrote: >> For step 1, I proposed we use the "Salsa Pipeline" [1], as I feel it is >> the most mature solution, has more contributors and has more features >> (including reprotest and piuparts). This option seems to have had the >> most support so far. > > Ack. I also deployed this pipeline on 500 Kali packages at > https://gitlab.com/kalilinux/packages/ > and it has been working relatively well. There are a couple > of remaining issues but the project is evolving quickly and I'm > confident that we can get past them. > > One of the issue is related to the fact that the CI build does not bump > the version and it can conflict with the version in the archive and it > will often confuse piuparts. > https://salsa.debian.org/salsa-ci-team/pipeline/issues/78 > > The project is a bit lacking in terms of leadership/guidance and there are > pending issues that should have been resolved more quickly to avoid > confusion and better define the rules: > https://salsa.debian.org/salsa-ci-team/pipeline/issues/84 > https://salsa.debian.org/salsa-ci-team/pipeline/issues/76 > https://salsa.debian.org/salsa-ci-team/pipeline/issues/86 > >> For step 2, so far people seemed to agree that: >> >> * having a standardised CI pipeline is a good idea >> * the CI should be used as a tool to help us improve our packages, and >> not be required to pass > > On this, I disagree. The CI should pass, but it's perfectly OK to > disable some of the failing tests to make it pass. We want merge requests > to run the CI and we want them to succeed to prove that they are not > making the package regress compared to the current situation. > > Consider that the package tracker is likely to display the CI status at > some point. > > Note that for merge request, it won't really work until > https://gitlab.com/gitlab-org/gitlab/issues/30242 gets fixed in GitLab.
That's a good point. The tests that are there should be required to pass, otherwise they can be removed, run manually, run in dev branches, or set to "allow_failure: true" in a specific job. That reminds me of a related topic I've been thinking about: should salsa's GitLab-CI setup be considered its own test tool, or just purely a conduit for the other standard Debian test methods (lintian, autopkgtest, piuparts, reprotest, etc). I'm on the fence about this, so I opened this discussion: https://salsa.debian.org/salsa-ci-team/pipeline/issues/111 .hc
