Proposal: drop Salsa CI testing for now

[Norbert Preining]

Hi

> first of all, I just noticed this after you started to disable the
> salsa CI almost everywhere; this email was sent to the wrong discussion
> list, and thus it got buried in the usual flood of upload/bug emails.

Sorry for that, I don't really see which list all that should go to,
emails are coming in on soo many channels for KDE that it is rather
unclear where what should go (and more, to remember it).

> > I contemplate disabling the whole salsa-ci for now, since all tests
> > always fail,
> 
> No, all tests do not "always fail".

Ok, but for every commit I make in frameworks, gears, plasma build
failure messages return.

I don't know where you see successful commit tests.

> What is usually failing is the blhc test, due to blhc mistaking the
> cmake automoc commands as build commands. There is a semi-long story
> about this, which is a different discussion topic than this. To make

Indeed.

> it short, it can be easily disabled for the affected projects (i.e.
> only those using qt5+cmake, qt5+qmake is not affected) using the
> following variable in the yaml file:
> <<<<<
> variables:
>   SALSA_CI_DISABLE_BLHC: 'no'
> >>>>>

Sounds easy, only that nobody came around doing it for about 6 months or
more now.

> Every other test is perfectly valid and working. Even better, they
> actually showed issues in your recent uploads that would have been
> nice to first *before* the upload, rather than afterwards; for example

Well, I usually build everything I upload in clean chroots before
uploading. Errors happen.

But seeing all the error messages filling up my inbox does not help
reduce the number of errors.

> There are possible failures due to another kde package being not
> available yet in the archive; I think the various plasma package use a
> custom repository for it, which should do the job. If it does not, let's
> look into it.

As I said, nobody looked into it since 6 months or more, and I have no
intention looking into it. That means, if nothing changes, error
messages will return.

> Well, if you don't care about it, that isn't the same as saying it is
> not useful. It only means that, well, you don't care about it.

Allow me to disagree, or be more specific, *for me* it is not useful.
If you enjoy digging through hundreds of failure emails, fine with me.

> I mentioned above the way to avoid getting rid of the majority of the
> "issues". Hence, please re-enable the salsa CI, which *is* useful even
> if you don't care about it.

Instead of writing a long email, you could have run a
	for i in *.git ; do
	  cd $i
	  if [ -r debian/salsa-ci.yml.disabled ] ; then
	    sed -i -e "s/^variables:/variables:\n  SALSA_CI_DISABLE_BLHC: 'no'"/ debian/salsa-ci.yml.disabled
	    git add debian/salsa-ci.yml.disabled
	    git commit -m "Fix CI build failures due to BLHC."
	    git mv debian/salsa-ci.yml.disabled debian/salsa-ci.yml
	    git add debian/salsa-ci.yml
	    git commit -m "Reenable Salsa CI"
	  fi
	  cd ..
	done
That would have:
* fixed (at least according to you) most/all ci test failures
* reverted and reactivated CI

Any, I have done the above now for frameworks and apps.

I am interested to see the result.

Best

Norbert

--
PREINING Norbert                              https://www.preining.info
Fujitsu Research  +  IFMGA Guide  +  TU Wien  +  TeX Live  + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13