When releasing, checks are run before merging and tagging. Having these
checks run again only slows down the release process, especially if some
tests are flaky.

fedora32 -> fedora 34
ubuntu2010 -> ubuntu2104
remove ubuntu1604

GitLab doesn't show the <system-*> tags, so let's replace them.
For now it's just hacky sed; I can't use xsltproc or similar.

https://docs.gitlab.com/ce/ci/unit_test_reports.html
https://mesonbuild.com/Unit-tests.html#testlogjunitxml

Implemented fully: build, build-asan; partially: pytests, deckard.

Vladimír Čunát authored 3 years ago and Tomas Krizek committed 3 years ago

The misaligned accesses were just throwing warnings for me (with gcc),
so I added the flag to stregthen what we get in CI.

Vladimír Čunát authored 4 years ago and Tomas Krizek committed 4 years ago

and break the overlong line

In 1f7678ea meson was updated and that broke our scan-build.
Now we work around that.  Quick analysis of why:
https://github.com/mesonbuild/meson/pull/5918#issuecomment-762064902

+ it's more efficient to schedule longer tests before shorter tests
- we get a warning (if meson is new enough to use priorities)

Priority numbers: I took the config tests as baseline.
I didn't touch tests with "is_parallel: false".

They need one go package which I can't find even in Debian,
so it probably can't work without network access.
The new dnstap in extra_tests runs if dnstap is built and go is found.
It also tries to keep the source tree clean.

Now both query and reply messages are tested.

In CI (after caching go deps in image) this tests only takes slightly
more time than the longest config.* tests, so that seems OK.
Even so, it's not added into the valgrind variant, as compilation
of the test still isn't split away from the run itself.

- update fedora to 33
- update ubuntu rolling to groovy

Often, the VM fails to boot (even twice in the row, as already handled
by the test itself) which leads to false negative result.

These nightly tests fail far too often (at least on of the ~7 tests) and
generate annoying notifications.

Adding yet another layer of retries should reduce the number of false
negatives without diminishing the value of the test (since the real
packaging issues are 100 % reproducible).

Use DAG dependencies to allow more precise control when a test
suite should be executed. It also enabled use of more descriptive
pipeline stages.

These tests are currently failing and since they're sort of
duplicate, and we want to get rid of them anyway, I'm removing
them from CI.

Related #612

The turris build was never migrated to support meson and these
files have been obsolete for far too long now.

This test fails far too often due to conditions inside the CI
environment. This test is already executed in test:valgrind without
paralelism, so let's keep it there instead.

This is to prevent issues like !1036

Vladimír Čunát authored 4 years ago and Petr Špaček committed 4 years ago

So that the overall pipeline time isn't extended too much.

Vladimír Čunát authored 4 years ago and Petr Špaček committed 4 years ago

In the past week the Travis runs have been consistently taking much more
time than before, usually around 20 minutes, leading to our CI timing out.
https://travis-ci.com/github/CZ-NIC/knot-resolver/builds

Vladimír Čunát authored 4 years ago and Tomas Krizek committed 4 years ago

s/gitlab\.labs\.nic/gitlab.nic/g
Redirects are in place, so it shouldn't be required now, but why not.

Add new target doc-strict for development to detect warnings, but avoid
failing package builds due to documentation warnings.

New Deckard repo without conflicting iter_refused.rpl test
does not contain libswrap and libfaketime anymore
so I had to remove hacks in build system for these.

38 -> 30. 8 were in Deckard's libswrap which is now longer used.