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':

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):

'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:

I am not a fan of pointing to a moving target with the "include" statement:

  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.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

Reply via email to