summaryrefslogtreecommitdiff
path: root/test/system/helpers.bash
Commit message (Collapse)AuthorAge
* implement 'make remotesystem'Ed Santiago2019-08-08
| | | | | | | | | | | | | | | | | | | | | 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>
* System tests: resolve hang in rawhide rootlessEd Santiago2019-08-01
| | | | | | | | | | | | | | | | | | | 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>
* Use conmon pidfile in generated systemd unit as PIDFile.Danila Kiver2019-07-04
| | | | | | | | | | | 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>
* BATS tests: start supporting podman-remoteEd Santiago2019-04-10
| | | | | | | | | | | | | | 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>
* Implement review feedbackEd Santiago2019-03-07
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - 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>
* new system tests under BATSEd Santiago2019-03-07
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>