| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
| |
podman exec leaks an exec_pid_<hash> file for every exec in tmpfs,
it's known rhbz#1731117, this case makes sure leakage issue has
been fixed.
rhbz: https://bugzilla.redhat.com/show_bug.cgi?id=1731117
Signed-off-by: Alex Jia <chuanchang.jia@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
podman-remote rm now works; that's the only thing we were
waiting for to enable podman-remote (varlink) system tests.
Add a (too-complicated, sorry) Makefile target that will
define a random socket path, start the podman varlink server,
and run the test suite using podman-remote.
Also: add two convenience functions, is_rootless and is_remote,
and use those in skip_if_rootless/if_remote and elsewhere
Also: workarounds for broken tests:
- basic version test: podman-remote emits an empty 'Client'
line. Just ignore it.
- looks like 'podman-remote pod' doesn't work; skip test.
Also: minor documentation update
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fedora CI tests are failing on rawhide under kernel
5.3.0-0.rc1.git3.1.fc31 (rhbz#1736758). But there's
another insidious failure, a 4-hour hang in the
rootless tests on the same CI system. The culprit
line is in the podman build test, but it's actually
BATS itself that hangs, not the build command -- which
suggests that it's the usual FD 3 problem (see BATS README).
It would seem that podman is forking a process that
inherits fd 3 but that process is not getting cleaned
up when podman crashes upon encountering the kernel bug.
Today it's podman build, tomorrow it might be something
else. Let's just run all podman invocations in run_podman
with a non-bats FD 3.
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
By default, podman points PIDFile in generated unit file to non-existent
location. As a result, the unit file, generated by podman, is broken:
an attempt to start this unit without prior modification results in a crash,
because systemd can not find the pidfile of service's main process.
Fix the value of "PIDFile" and add a system test for this case.
Signed-off-by: Danila Kiver <danila.kiver@mail.ru>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
podman-remote now supports rm! That's what we needed to start
running BATS tests.
Although most tests don't actually work, some do, and maybe
the rest will start working over time. For now, disable them.
The only significant difference found is that podman-remote
strips fractional seconds from timestamps in JSON output.
Probably not something worth caring about.
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- document a recommended convention for fail-fast tests
- document the requirement for jq. (And, add a fail-fast
test for its presence; remove the duplicated checks
in subtests)
- add further sanity checks to 'help' test. Add missing
documentation. Remove a no-longer-needed workaround for
usage-message bug fixed in #2486
- add a documented TEMPLATE
- and, since we're at 1.1, enable 'Remote API' check in
version test
- better diagnostics in setup/teardown; add vim filetype hint;
better formatting of actual-vs-expect errors
- new pod-top, logs, build tests
- improve error messages
- add $IMAGE alias for ridiculous $PODMAN_TEST_IMAGE_FQN
- final cleanup, in prep for merge
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
|
|
Initial attempt at writing a framework for podman system tests.
The idea is to define a useful set of primitives that will
make it easy to write actual tests and to interpret results
of failing ones.
This is a proof-of-concept right now; only a small number of
tests, by no means comprehensive. I am requesting review in
order to find showstopper problems: reasons why this approach
cannot work. Should there be none, we can work toward running
these as gating tests for Fedora and RHEL8.
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
