On 19-09-15 20 h 31, Louis-Philippe Véronneau wrote: > On 19-09-05 01 h 40, Louis-Philippe Véronneau wrote: >> 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 > These are the steps I see going forward with this: > > ---------------------------------------------------------------------- > 1. Agree on a default pipeline we should be using on the DPMT & PAPT > packages. > > 2. Draft a proposed modification to the DPMT and the PAPT policies > > 3. Adopt that proposed modification once we reach consensus > > 4. Wait for the "All Clear" from the Salsa Team > > 5. Commit the previously agreed upon CI pipeline to all the DPMT & PAPT > packages, while making sure the CI isn't ran on that push ("-o ci.skip") > ---------------------------------------------------------------------- > > 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. > > Hans-Christoph Steiner proposed we use "ci-image-git-buidpackage" > instead [2]. The code behind it is simpler and the way it's built makes > it possible for maintainers to modify the CI for their packages. > > 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 > > Please contribute to this discussion if you care about this issue! I'll > try to draft something more concrete in the next few days. > > [1] https://salsa.debian.org/salsa-ci-team/pipeline > [2] https://salsa.debian.org/salsa-ci-team/ci-image-git-buildpackage >
As promised, here's a draft proposal on CI usage for the team: https://salsa.debian.org/python-team/tools/python-modules/merge_requests/12/ -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Louis-Philippe Véronneau ⢿⡄⠘⠷⠚⠋ po...@debian.org / veronneau.org ⠈⠳⣄
signature.asc
Description: OpenPGP digital signature
