The submit phase of the Fuzzit Travis job has been spuriously failing
for some time with various (and usually pretty hidden) errors, like:
```
./fuzzit create job --type regression ...
2020/04/23 17:02:12 please set env variable FUZZIT_API_KEY or pass --api-key. API Key for you account: ...
```
```
./fuzzit create job --type regression ...
2020/04/23 11:36:53 Creating job...
2020/04/23 11:36:54 Uploading fuzzer...
2020/04/23 11:36:54 Job created successfully
2020/04/23 11:36:54 Get https://...&action=create: read tcp x.x.x.x:39674->x.x.x.x:443: read: connection reset by peer
```
```
./fuzzit create job --type regression ...
2020/04/22 18:09:15 Creating job...
2020/04/22 18:09:16 Uploading fuzzer...
2020/04/22 18:09:37 Job created successfully
2020/04/22 18:09:37 500 Internal Server Error
```
etc.
Let's retry each submit job up to three times to (hopefully) mitigate this.
The compatibility issue in meson v0.53 has been fixed in v0.53.1, which
is already available through pip, so let's remove the pin for meson
introduced before.
Reverts: 514793658c
Latest meson doesn't work with older python 3.5, which is present on
Ubuntu 16.04. Let's pin in to the latest working version (0.52.1) until
we properly bump all necessary Ubuntu images to 18.04.
See: https://github.com/mesonbuild/meson/issues/6427
This avoids nasty race conditions between dnf/apt-get and unfinished
population of /tmp (among other things), as `docker exec` allows commands
to run before the system is fully booted (i.e. initializing/starting
state reported by `systemctl is-system-running`).
Judging by https://travis-ci.org/systemd/systemd/jobs/604425785
(where the script failed with "tools/coverity.sh: line 45: python: command not found")
python-unversioned-command is no longer installed by default with python2.
Given that it's not the first time python has vanished and it's not clear
what exactly should be installed to make sure it's there, let's just use jq instead.
I was informed that fuzzit-1.1 is going to be deprecated soon. Generally
the latest version isn't recommened because it's still in beta and theoretically
might be backwards incompatible but let's try rolling forward to avoid PRs
like this going forward. We can always roll it back :-)
Now that v243 is out, the script has been pulled by forks that are
activated on Travis CI. As a result, all those forks have started to send
their fuzzers to Fuzzit inadvertantly consuming our CPUs along the way.
Let's prevent this by bailing out early if the script is run outside of
the systemd repository.
includes two travis ci steps:
1) Every pull-request/push all fuzzing targets will do a quick
sanity run on the generated corpus and crashes (via Fuzzit)
2) On a daily basis the fuzzing targets will be compiled (from
master) and will and their respectible fuzzing job on Fuzzit
will be updated to the new binary.
As we build a custom Docker image, we need to ensure that systemd
correctly detects it's running in a container. One can simply do this
directly in a Dockerfile (ENV container docker) or when starting the
container (-e container=docker). For the sake of readability, let's
pick the latter approach here.
Now that https://github.com/systemd/systemd/pull/12542 is merged,
fuzzbuzz.sh should be changed a little bit to make it work
on Azure Pipelines. We can no longer assume that source repositories
are added "automagically" by Travis CI or that PATH is set properly.
The test has been flaky since varlink was merged.
Let's not annoy people with the test that fails more often than not.
It should be OK because the same test is run on Arch.
These were never set explictily because we relied on Travis CI
canceling a job if it's been stuck for 10 minutes. Now that
the script is run on Azure Pipelines (where the default timeout
is 60 minutes) we should limit the script manually to avoid waiting
for an hour for broken jobs to finish.
Evgeny Vereshchagin