Enabling coverage near-doubles the incremental build time and adds
overhead to individual tests on the order of **5-10x** or more. It's not
essential to have this for quick local system-test runs, so add an option
to disable it.
sort both aptly output and gold file. output original output for
debugging on failure.
* Makefile: enable CAPTURE=1 env variable for capturing gold files
* docker-system-test: use AWS env vars for S3 tests
* fix system tests timing issue with order of gpg logs in publish tests
This commit allows to add, remove and update components of published repositories without the need to recreate them.
Signed-off-by: Christoph Fiehe <c.fiehe@eurodata.de>
gpgv: can't allocate lock for '/home/runner/.gnupg/aptlytest.gpg'
this forced running local system tessts in /home/runner, as it is
in the gitgub actions.
- add t13_etcd test directory
- etcd will be started for the unit tests and each system test
- etcd will load fixture DB export if requested by the test
- existing tests are reused for etcd testing
- 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>
- 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>
To capture the coverage also for the integration tests,
a test only executing the cmd.Run function is used.
The test always exits with code 0 and prints the
real exit code to stdout. Otherwise no coverage
report is generated.
Those changes enable a more accurate coverage report
for future contributions.
It may happen that aptly retries to download data during tests (maybe because
of a network issue), but our fixtures doesn't account for it. So, we strip
those irrelevant lines before comparison.
Apply retries as global, config-level option `downloadRetries` so that
it can be applied to any aptly command which downloads objects.
Unwrap `errors.Wrap` which is used in downloader.
Unwrap `*url.Error` which should be the actual error returned from the
HTTP client, catch more cases, be more specific around failures.
* aptly can sign and verify without issues with GnuPG 1.x and 2.x
* aptly auto-detects GnuPG version and adapts accordingly
* aptly automatically finds suitable GnuPG version
Majority of the work was to get unit-tests which can work with GnuPG 1.x & 2.x.
Locally I've verified that aptly supports GnuPG 1.4.x & 2.2.x. Travis CI
environment is based on trusty, so it runs gpg2 tests with GnuPG 2.0.x.
Configuration parameter gpgProvider now supports three values for GnuPG:
* gpg (same as before, default): use GnuPG 1.x if available (checks gpg, gpg1),
otherwise uses GnuPG 2.x; for aptly users who already have GnuPG 1.x
environment (as it was the only supported version) nothing should change; new
users might start with GnuPG 2.x if that's their installed version
* gpg1 looks for GnuPG 1.x only, fails otherwise
* gpg2 looks for GnuPG 2.x only, fails otherwise
'E722 do not use bare except' wants us not to use except without type
restriction as it catches everything and the kitchen sink. Since we use
them to catch exceptions in test cases this is intentional as we implement
general purpose error handling on test failure there.
