- log import errors for test modules
- log output only on test failure
- improve docker system test container
- use go 1.19 in docker system tests
- download go dependencies in docker container
- system tests: color failues output
- imrpove test result output
- do not install golangci-lint in system tests
None of the commands' output is ever treated as binary, so we can just
always decode it as text.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
This adds support for storing packages directly on Azure, with no truly
"local" (on-disk) repo used. The existing Azure PublishedStorage
implementation was refactored to move the shared code to a separate
context struct, which can then be re-used by the new PackagePool. In
addition, the files package's mockChecksumStorage was made public so
that it could be used in the Azure PackagePool tests as well.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
read_path() can read in binary, which the S3 tests don't support (simply
because they don't need it)...but it needs to be able to take the `mode`
argument anyway.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
This commit introduces a test which runs concurrent publishes (which
could be parallell with multiproccessing, python is fun).
The test purposly fails (at the point in history that this patch is
written) in order to make it as easy as possible to verify later patches,
which hopefully addresses concurrency problems.
The same behaviour can easily be tested outside of the system tests with
the following (or similar) shell
$ aptly serve -listen=:8080 -no-lock
$ aptly repo create create -distributions=testing local-repo
$ atply publish repo -architectures=amd64 local-repo
$ apt download aptly
$ aptly repo add local-repo ./aptly*.deb
$ for _ in $(seq 10); do curl -X PUT 127.0.0.1:8080/api/publish//testing
In the local testing perfomed (on a dual core vm) the first 1-4 jobs
would typically succeed and the rest would error out.
- use s3 mirror instead of internet download
- reduce download verbosity
- do not use venv in docker-system-tests
- be more verbose on test output
- do not run golangci-lint in system-tests
1.20 changes the output format of coverage checks slightly to include
a package name on each line, followed by `coverage:`, but the current
regex assumes that the line *starts* with `coverage:`.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
The current regex runs in exponential time, which massively impacts the
runtime of the test suite, taking several seconds (~4s on my system)
just to perform a single match. By replacing the mix of re.findall + the
initial capture group with re.search + some string slicing, the time
spent matching the regex becomes nearly instant, e.g.:
$ make system-test TESTS='Config*'
goes from taking ~10s to ~1.5s.
Signed-off-by: Ryan Gonzalez <ryan.gonzalez@collabora.com>
This should fix some tests, as a lot of them are dependent on
deb.debian.org which no longer supports Debian 9 "Stretch".
Instead we use archive.debian.org which will continue to contain
"Stretch" packages for a long time.