Proposal: drop Salsa CI testing for now

[Dmitry Shachnev]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-kde-talk/attachments/20210829/e1c46532/attachment.sig>