GitLab

kde/pim is not really the right prefix, nor does it match the category
on invent, but we don't seem to have "kde/libs". With that apparently
having little impact beyond this file and the dependency metadata, I've
just followed what was previously done for similar modules that also don't
really belong into kde/pim, like kosmindoormap.

CCBUG: 424196

Ref T14046

Ref T14022

Ref T14006

Ref T14006

We cannot provide Marble on FreeBSD (due to conflicts with ASAN and it's build system that does not use ECM) which is a hard dependency of KGeoTag, therefore we cannot do KGeoTag builds either.

Ref T13998

Ref T13998

Ref T13995

Hopefully this fixes https://binary-factory.kde.org/view/Management/job/Kate_Nightly_appimage-centos7/2/console

We only installed the jdk, but not java itself which was missing.

Run sshd-keygen, which requires a workaround to be able to run
ssd-keygen: We need to provie /etc/rc.d/init.d/functions, which
doesn't exist in the image.

Sadly the docker base image isn't available from docker hub. So we
need to setup the latest devtoolset manually ourselves. This is
required to update ld.gold to a version which fixes a linker bug
encountered while building qtwayland.

The package list was tested over at [1], and I now adapted the
other steps from the ubuntu craft image too. But I'm not sure how
to test whether this docker image is usable by jenkins now? Can
anyone tell me how I could test this?

I also noticed that there's now a devtoolset-8, which we may want
to use instead of version 7 to get an even newer compiler. But I
can't pull from centos/devtoolset-8-toolchain-centos7, so apparently
that's not ready yet. Version 7 is good enough for now anyways.

[1]: https://invent.kde.org/mwolff/kf5-appimage-centos7/

This might fix the missing package in my pipeline: https://binary-factory.kde.org/view/Android/job/Neochat_android/40/console

This complements the move of the fastlane metadata generation to ECM:
frameworks/extra-cmake-modules!44

Remove warnings processing, as the module providing this functionality is no longer available upstream

It now comes with QML syntax highlighting contributed by myself :)

People are lazy to run tests. Because of this, broken tests are
typically discovered long after the regression had been introduced.

This problem is very common in kwin and from time to time it
re-appears in kwayland-server. The best way to deal with issues of
this kind is to catch them during the code review stage, but as it's
been said, people are lazy and they typically, including me, forget
to run tests. GitLab provides a feature called "pipelines" that can
help us with it.

While kwin is a bit nitpicky about CI, for example it doesn't like if
the test runner machine is too loaded, kwayland-server is less prone
to this kind of issues.

Ref T13903

CCMAIL: kde-frameworks-devel@kde.org

CCMAIL: kde-frameworks-devel@kde.org

In fd8cc96a we introduced ci-static-analysis.yml with GitLab jobs to run
clazy. The normal build job uploads its 'build' directory as an artifact
and the static-analysis job then uses that artifact and runs clazy on it.

Making the entire 'build' directory an artifact is making *all* builds
take very long and sometimes even timeout, even if they don't use static
analysis. This commit removes 'build' as an artifact in ci-before.yml, and
adds it to ci-static-analysis.yml, so that it's only done for projects
using the static analysis job.

Ideally we should find a way to run clazy without having to pass artifacts
between jobs, eg. run it on the same job as the compilation.

It does not make much sense to build it on the build.kde.org since it is
already covered by the binary-factory.kde.org as well as to my knowledge
build.kde.org does not do full APK build anyway, so this is not much
useful for application

The build script was using 75% of the available CPUs if there were >=4.
This makes sense on our Jenkins build nodes, since we run multiple
concurrent jobs, some of them in VMs where even the load limit via -l won't
avoid overcommitting resources. However, on GitLab we currently run 1 job
at a time, and using max 75% CPU is being very wasteful.

This commit makes the 75% limit apply only to Jenkins.