Files
Daniel J Walsh b765c91580 Add --replace option to podman artifact add command
This commit implements the --replace functionality for the artifact add command,
allowing users to replace existing artifacts without having to manually remove
them first.

Changes made:
- Add Replace field to ArtifactAddOptions entity types
- Add --replace CLI flag with validation to prevent conflicts with --append
- Implement replace logic in ABI backend to remove existing artifacts before adding
- Update API handlers and tunnel implementation for podman-remote support
- Add comprehensive documentation and examples to man page
- Add e2e and system BATS tests for --replace functionality
- Fix code formatting in pkg/bindings/artifacts/types_pull_options.go:
  * Reorder imports with proper spacing
  * Fix function declaration spacing
  * Convert spaces to proper tab indentation
  * Remove extraneous blank lines

The --replace option follows the same pattern as other podman replace options
like 'podman container create --replace' and 'podman pod create --replace'.
It gracefully handles cases where no existing artifact exists (no error thrown).

Usage examples:
  podman artifact add --replace quay.io/myimage/artifact:latest /path/to/file
  podman artifact add --replace localhost/test/artifact /tmp/newfile.txt

Fixes: Implements requested --replace functionality for artifact add command
Signed-off-by: Daniel J Walsh <dwalsh@redhat.com>
2025-10-06 12:22:40 -04:00
..
2020-01-17 09:59:22 -07:00
2023-11-20 15:10:17 -05:00
2025-01-22 11:43:47 -05:00
2023-04-03 15:33:50 +03:00
2025-04-25 19:29:18 +02:00
2022-08-25 11:07:11 -06:00

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

Never, ever, ever, seriously EVER exit from a test. Just don't. That skips cleanup, and leaves the system in a broken state.

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, .yaml, or .json, t will invoke curl with --data-binary @PATH and set Content-type as appropriate. This is useful for build endpoints. (To override Content-type, simply pass along an extra string argument matching application/*): t POST myentrypoint /mytmpdir/myfile.tar application/foo 400 ** Like above, when using PUT, t does --upload-time instead of --data-binary

  • The final arguments are one or more expected string results. If an argument starts with a dot, t will invoke jq 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 use expr to compare.

  • If your test expects curl to time out: APIV2_TEST_EXPECT_TIMEOUT=5 t POST /foo 999