This should speed up CI a bit.

CI stages are separated with a barrier, i.e. all the jobs from the
previous stage must finish before first job of a next phase starts.

In our current build phase we have the following jobs:
 * build (gcc)
 * build (clang-sanitizers)
 * clang-tidy

The build jobs are kind-of fast (ca. 5 and 10 mins, but not in parallel,
i.e. 15 mins in total) and the clang-tidy job is slow (ca. 27 mins).
After the clang-tidy jobs finishes we move on to the test phase where
the CI has to download dependencies (i.e. the build directory) in order
to run tests (ca. 3 + 5 mins, i.e. 8 minutes). I think we can squeeze
this 8 minute-test-jobs into the build phase where we have to wait
anyway.

Also, we don't have to upload and download the build directory which is
a big plus (and can save some time too).

It seems we do not need to alter anything in the spec file.

By pulling as much images as we can from local cached copy we could
(hopefully) avoid the docker TOOMANYREQUESTS error.

The build fails with the following error.

 cmake: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib/libstdc++.so.6)
 cmake: /usr/lib/libc.so.6: version `GLIBC_2.34' not found (required by /usr/lib/libgcc_s.so.1)

It turned out, the system was in inconsistent state -- some of the
packages were not updated. And now, when new glibc reached the repos, it
broke the system....

Some time ago we moved docker image builds into external repository
cd-release (together with packaging). Now that repository is useless
because we built packages here, so let's do the same for docker images.

F36 is not released yet [1] and it contains not-yet-released g++-12
which causes some problems for our code. Let's deal with it once g++-12
is released.

[1] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html

Tomáš Pecka authored 3 years ago and Tomáš Pecka committed 3 years ago

Also, I think that opensuse packagers are strange. Why the hell are
there gcc-c++ packages with default version of 7.5 in Leap 15.2 and
15.4?
So in order to build for different Leap versions I have to explicitly
specify build requirement to gcc<version>-c++? Why can't it be a single
package with bumped versions?

Tomáš Pecka authored 3 years ago and Tomáš Pecka committed 3 years ago

This would have been simpler with rules in gitlab 12, but we don't have
it yet.

Tomáš Pecka authored 3 years ago and Tomáš Pecka committed 3 years ago

apkg[1] is a tool for building packages for multiple distros with a
single interface. Something I was trying to do in the cd-release
repository.

[1] https://pkg.labs.nic.cz/pages/apkg/

Start working on custom code-style/code-requirements file checker.
So far we check only for missing license, for non-standard EOL (\r) and
for files that not-compliant with clang-format.

So we easily know what version of cppcheck and clang-tidy
are we running. Compiler version is announced by CMake.

Recently we moved infrastructure repositories under a new path. Docker
registries have therefore moved too.  Reflect this in our CI settings.

Run install target of the build process.

Adapts Doxygen generators to changes in previous commit.

Remove CMakeLists.txt generator scripts from build phase. Replaced with
CMake's GLOB that can re-run every time the build is invoked. We can
also drop the Python dependency now.

Removed header installs which will be redesigned in future commits.

This reverts commit 572b1e23.
Wrong approach, we need to do this in builder repository.