Hi all! On Sun, Aug 29, 2021 at 04:18:33PM +0900, Norbert Preining wrote: > Any, I have done the above now for frameworks and apps. > > I am interested to see the result. I want to share my experience with Salsa CI. I usually enable it for all my packages which have full source code in the repository (i.e. except Qt which has debian directory only). Most of the time it passes without issues. However when it fails, it is most likely a real bug somewhere, which I would otherwise not notice. Building all packages in a chroot before upload indeed helps you to catch some issues early, but Salsa CI does much more: it also builds on i386, runs the autopkgtests, runs Lintian etc. It is inconvenient to do all these things manually. And, for example, if the autopkgtests fail and you didn't know about that before uploading, then you will have to do another upload to let the package migrate to testing. Regarding the failures, the main source of problems for me was the reprotest. Sometimes it can be fixed with a small patch or tweaking of build flags. But in case it's hard to fix or you simply want to ignore reprotest, you can allow it to fail by adding these lines to gitlab-ci.yml: reprotest: allow_failure: true Or disable certain variations, like this (you can enable atomic reprotest to check which ones are problematic): variables: SALSA_CI_REPROTEST_ARGS: --variations=-locales Even if you disable half of the jobs (reprotest, blhc, something else), Salsa CI will be still useful to detect other problems (such as symbols errors on i386). -- Dmitry Shachnev
Attachment:
signature.asc
Description: PGP signature