f5b3dc976c
- apiv2 - the 'ten /info requests' test is flaking often, taking ~8 seconds (our limit is 7, up from 5 a few weeks ago). Brent suggested that the first /info call might be expensive, because it needs to access storage. So, let's prime it by running one /info outside the timing loop. And, because even that continues to fail, bump it up to 10 seconds and file #8076 to track the slowdown. - toolbox test - WaitForReady() has timed out, even on one occasion causing a run failure because it failed 3 times. Solution: bump up timeout from 2s to 5s. Not really great, but CI systems are underpowered, and it's not unreasonable that 2s might be too low. - sdnotify test - add a 'podman wait' between stop & rm. This may prevent a "cannot rm container as it is running" race condition. While working on this, Brent and I noticed a few ways that test-apiv2 logging can be improved: - test name: when request is POST, display the jsonified parameters, not the original input ones. This should make it much easier to reproduce failures. - use curl's "--write-out" option to capture http code, content type, and request time. We were getting the first two via grep from logged headers; this is cleaner. And there was no other way to get timing. We now include the timing as X-Response-Time in the log file. - abort on *any* curl error, not just 7 (cannot connect). Any error at all from curl is bad news. Signed-off-by: Ed Santiago <santiago@redhat.com> |
||
---|---|---|
.. | ||
rest_api | ||
00-TEMPLATE | ||
01-basic.at | ||
10-images.at | ||
12-imagesMore.at | ||
20-containers.at | ||
22-stop.at | ||
25-containersMore.at | ||
30-volumes.at | ||
35-networks.at | ||
40-pods.at | ||
README.md | ||
test-apiv2 |
API v2 tests
This directory contains tests for the podman version 2 API (HTTP).
Tests themselves are in files of the form 'NN-NAME.at' where NN is a two-digit number, NAME is a descriptive name, and '.at' is just an extension I picked.
Running Tests
The main test runner is test-apiv2
. Usage is:
$ sudo ./test-apiv2 [NAME [...]]
...where NAME is one or more optional test names, e.g. 'image' or 'pod'
or both. By default, test-apiv2
will invoke all *.at
tests.
test-apiv2
connects to localhost only and via TCP. There is
no support here for remote hosts or for UNIX sockets. This is a
framework for testing the API, not all possible protocols.
test-apiv2
will start the service if it isn't already running.
Writing Tests
The main test function is t
. It runs curl
against the server,
with POST parameters if present, and compares return status and
(optionally) string results from the server:
t GET /_ping 200 OK
^^^ ^^^^^^ ^^^ ^^
| | | +--- expected string result
| | +------- expected return code
| +-------------- endpoint to access
+------------------ method (GET, POST, DELETE, HEAD)
t POST libpod/volumes/create name=foo 201 .ID~[0-9a-f]\\{12\\}
^^^^^^^^^^^^^^^^^^^^^ ^^^^^^^^ ^^^ ^^^^^^^^^^^^^^^^^^^^
| | | JSON '.ID': expect 12-char hex
| | +-- expected code
| +----------- POST params
+--------------------------------- note the missing slash
Notes:
-
If the endpoint has a leading slash (
/_ping
),t
leaves it unchanged. If there's no leading slash,t
prepends/v1.40
. This is a simple convenience for simplicity of writing tests. -
When method is POST, the argument after the endpoint must be a series of POST arguments in the form 'key=value', separated by commas.
t
will convert those to JSON form for passing to the server. -
The final arguments are one or more expected string results. If an argument starts with a dot,
t
will invokejq
on the output to fetch that field, and will compare it to the right-hand side of the argument. If the separator is=
(equals),t
will require an exact match; if~
(tilde),t
will useexpr
to compare.