Commit Graph

5 Commits

Author SHA1 Message Date
Paul Holzinger 4e0cd49148
test/system: check for leaks in teardown suite
At the end of all tests always check for leaks. That should make us more
robust against adding tests at the end that would leak stuff otherwise.

TODO: something seems wrong with bats when returning an error in
teardown_suite(), it prints a warning:
bats warning: Executed <NUM+1> instead of expected <NUM> tests
And also the output is formatted weirdly in this case where the podman
args are split over multiple lines.
But the test fails as expected so I don't think it is a problem.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 11:06:51 +02:00
Paul Holzinger 81c90f51c2
test/system: speed up basic_{setup,teardown}()
While these are not really slow they still take about 100-250ms if I
time this locally. Given they are run for every test this adds up
quickly. Looking at CI logs I can see the timings for skipped
tests are all in 600ms range. So I think it is safe to assume that these
functions need to get faster.

We have over 670 test cases currently so we talk about over 400s spend
in these functions in CI. This allows for big gains.

Now overall this is a tricky trade of, while all tests should cleanup
after themselves there is no guarantee for that as such errors can be
leaked into other tests making debugging much harder. To work at least a
bit against this teardown checks if the test was successful and only
skips the podman commands bases on that. Without it a single flake could
cause all following tets to fail.

As such this commit does the proper setup once one suite start then only
after a test failed.

In order for this to work at all we have to fix all leaks first, see
previous commits. And then for the future keep a very strong eye on
this during reviews.

Also add a PODMAN_BATS_LEAK_CHECK option

By default test must cleanup themselves and to speed up CI we no longer
do any cleanup in teardown by default. However there is still many cases
where we might have to debug a leak so add a new PODMAN_BATS_LEAK_CHECK
env option that can be set and should cause teardown to fail if the test
did not cleanup properly.

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2024-06-18 11:06:50 +02:00
Paul Holzinger fcf9327773
podman --runroot: remove 50 char length restriction
This was added ages ago in commit c65b3599cc, however in the meantime
both podman and conmon can support longer socket paths as they use a
workaround to open the path via /proc/self/fd, see openUnixSocket() in
libpod/oci_conmon_attach_linux.go

Thus this restriction is not needed anymore and we can drop a workaround
in the tests.

Fixes #22272

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
2024-04-05 14:41:50 +02:00
Ed Santiago 232c32bd35 CI: systests: safer isolation in registry & tests
Our test registry (used for login & local registry tests)
was being run using the standard podman tmpdir, hence the
standard podman database, This was then getting clobbered
in the 330-corrupt-images test, which runs "system reset".
We just didn't know this was happening. Until we added
a registry test after the system reset. Oops.

Solution: new helper function podman_isolation_opts()
sets --root, --runroot, *and --tmpdir*. Refactor all
existing --root/--runroot usages. Document.

Next problem: the "network reload" test in 500-networking.bats
did not (could not) know about our registry port, so the
"iptables -F" command reverted that to DROP, so the subsequent
podman-auth in 700-play timed out.

Solution: add a podman-isolated "network reload" to start_registry().

Final problem, because, really, those weren't enough: a BATS
bug where running with --filter-tags would set IFS=',' in setup_suite
which in turn has catastrophic consequences:

    https://github.com/bats-core/bats-core/issues/812

See #20966 for details of the failure and further conversation.

Signed-off-by: Ed Santiago <santiago@redhat.com>
2023-12-13 09:46:09 -07:00
Ed Santiago ba1355b230 system tests: refactor registry code
The podman-login tests have accumulated much cruft over the
years, because that's the only place where we run a local
registry, and the process was crufty: we actually start/stopped
the registry as the first & last tests of the file. Meaning,
you couldn't do 'hack/bats 150:just-one-test' because that
would skip the registry start. And just now, a completely
unrelated test has had to be shoved into the login file.

This PR revamps the whole thing, by adding a new registry helper
module that can be used anywhere. And, once the registry is
started, it just stays running until the end of tests. (This
requires BATS 1.7 or greater).

Signed-off-by: Ed Santiago <santiago@redhat.com>
2023-07-04 15:26:55 -06:00