Add all, external, and label to Image.prune()

[inknos]

Param all is now supported by prune. Param external is now supported by prune. Filter by label, which was already supported, is now documented and tested.

Resolves: https://github.com/containers/podman-py/issues/312

[packit-as-a-service[bot]]

We were not able to find or create Copr project packit/containers-podman-py-413 specified in the config with the following error:

Packit received HTTP 500 Internal Server Error from Copr Service. Check the Copr status page: https://copr.fedorainfracloud.org/status/stats/, or ask for help in Fedora Build System matrix channel https://matrix.to/#/#buildsys:fedoraproject.org.

---

Unless the HTTP status code above is >= 500, please check your configuration for:

1. typos in owner and project name (groups need to be prefixed with @)
2. whether the project name doesn't contain not allowed characters (only letters, digits, underscores, dashes and dots must be used)
3. whether the project itself exists (Packit creates projects only in its own namespace)
4. whether Packit is allowed to build in your Copr project
5. whether your Copr project/group is not private

[inknos]

/packit build

[rhatdan]

LGTM @umohnani8 @jwhonce @mwhahaha PTAL

[inknos]

Quoting @jwhonce from the issue

Adding external and all as kwargs would require extra validation if the client has been instantiated in compatible_version mode

I scratched my head on this comment, but I think it's just a simple check that I am missing. Maybe you could help me out with what do you mean with this :)

[inknos]

Also, apologies for several force pushes, looks like I can't get pylint locally and in GH work nicely together, so it keeps complaining 🤦🏻‍♂️

[jwhonce]

Quoting @jwhonce from the issue

Adding external and all as kwargs would require extra validation if the client has been instantiated in compatible_version mode

I scratched my head on this comment, but I think it's just a simple check that I am missing. Maybe you could help me out with what do you mean with this :)

@inknos It is possible to configure the PodmanClient to only use the compatible API for a Podman service or talk to a Docker service. I was questioning how would we handle providing these additional parameters to the call since they are not supported in that case. Should podman-py report an error? Or, should it just make the call and allow the API service to either ignore them or report an error?

[inknos]

Should podman-py report an error? Or, should it just make the call and allow the API service to either ignore them or report an error?

As long as podman-py does not crash or give a traceback I like to see the api errors, more than translating what's happening. Maybe I would wrap the calls with a warning in the logs.

[jwhonce]

/lgtm

[jwhonce]

/approve

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: inknos, jwhonce

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [inknos,jwhonce]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment