I think we should definitely use Gitlab-CI! The 'salsa-ci-team/pipeline' project does have good coverage, with reprotest and piuparts. I'm the lead dev on another approach, also part of the salsa-ci-team, called 'ci-image-git-buildpackage': https://wiki.debian.org/Salsa/Doc#Running_Continuous_Integration_.28CI.29_tests
It has lintian, autopkgtest and more, but lacks piuparts and reprotest. It does have "aptly" support where it will automatically build and deploy binary packages to a apt repo. Then other CI builds can add those repos for CI runs. This is very helpful for complex suites of packages that depend on each other. We use it in the Android Tools Team (click on any "pipeline" button to see it in action): https://salsa.debian.org/android-tools-team/admin 'salsa-ci-team/pipeline' is quite simple for packages with simple requirements. One limitation with it is that you can't include a bash script directly in the debian/.gitlab-ci.yml file, which is the normal way of working with GitLab-CI. That was a central requirement for ci-image-git-buildpackage. The automation is just bash commands, so you can use them in a bash script as needed. Or easily add multiple jobs, or do anything you would normally do in GitLab-CI. For example: https://salsa.debian.org/android-tools-team/android-platform-system-core/blob/master/debian/.gitlab-ci.yml I am not a fan of pointing to a moving target with the "include" statement: include: - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml "master" will change, and that can break CI jobs where nothing in the local repo has changed. Louis-Philippe Véronneau: > Hello folks! > > I'd like to propose we start using Salsa CI for all the team packages. I > think using a good CI for all our packages will help us find packaging > bugs and fix errors before uploads :) > > I also think that when possible, we should be using the same CI jobs for > our packages. The Salsa CI Team's default pipeline [1] is a good common > ground, as currently it: > > * builds the package > * runs piuparts > * runs autopkgtest > * runs lintian > * runs reprotest > * and does more! > > I don't think a failing CI should be a blocker for an upload, but I > think it's a good red flag and should be taken in account. > > I know the Ruby team also decided to use debian/salsa-ci.yml instead of > debian/gitlab-ci.yml [2]. I guess we should also do the same. > > Thoughts? If we decide to go ahead with this, I guess we should modify > the policy accordingly and contact the Salsa Team to see if adding this > additional load is OK with them. > > [1] https://salsa.debian.org/salsa-ci-team/pipeline#basic-use > [2] https://salsa.debian.org/salsa-ci-team/pipeline/issues/86#note_106245 >
