add support for podman-remote image scp as well as direct access via the API. This entailed a full rework of the layering of image scp functions as well as the usual API plugging and type creation also, implemented podman image scp tagging. which makes the syntax much more readable and allows users t tag the new image they are loading to the local/remote machine: allow users to pass a "new name" for the image they are transferring `podman tag` as implemented creates a new image im `image list` when tagging, so this does the same meaning that when transferring images with tags, podman on the remote machine/user will load two images ex: `podman image scp computer1::alpine computer2::foobar` creates alpine:latest and localhost/foobar on the remote host implementing tags means removal of the flexible syntax. In the currently released podman image scp, the user can either specify `podman image scp source::img dest::` or `podman image scp dest:: source::img`. However, with tags this task becomes really hard to check which is the image (src) and which is the new tag (dst). Removal of that streamlines the arg parsing process Signed-off-by: Charlie Doern <cdoern@redhat.com> |
||
---|---|---|
.. | ||
python | ||
00-TEMPLATE | ||
01-basic.at | ||
10-images.at | ||
12-imagesMore.at | ||
15-manifest.at | ||
20-containers.at | ||
22-stop.at | ||
23-containersArchive.at | ||
25-containersMore.at | ||
26-containersWait.at | ||
27-containersEvents.at | ||
30-volumes.at | ||
35-networks.at | ||
40-pods.at | ||
44-mounts.at | ||
45-system.at | ||
50-secrets.at | ||
60-auth.at | ||
70-short-names.at | ||
README.md | ||
containers.conf | ||
containers.no_hosts.conf | ||
test-apiv2 |
README.md
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(s) after the endpoint may be a series of POST parameters in the form 'key=value', separated by spaces: t POST myentrypoint 200 ! no params t POST myentrypoint id=$id 200 ! just one t POST myentrypoint id=$id filter='{"foo":"bar"}' 200 ! two, with json t POST myentrypoint name=$name badparam='["foo","bar"]' 500 ! etc...
t
will convert the param list to JSON form for passing to the server. A numeric status code terminates processing of POST parameters. ** As a special case, when one POST argument is a string ending in.tar
,t
will invokecurl
with--data-binary @PATH
and setContent-type: application/x-tar
. This is useful forbuild
endpoints. (To overrideContent-type
, simply pass along an extra string argument matchingapplication/*
): t POST myentrypoint /mytmpdir/myfile.tar application/foo 400 -
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.