Some updates following the 3Q 2025 priority updates. We have a lot of
spikes that accompany work not listed here but given they are not true
features, I am not adding them
Signed-off-by: Brent Baude <bbaude@redhat.com>
Recognize that pseudoversions that look like
v0.0.0-20250814150820-1f7f1d285d22 are also not real branch names.
Signed-off-by: Nalin Dahyabhai <nalin@redhat.com>
Prior to this commit `artifact remove --all` was not supported on remote
clients.
This patch adds a new artifact API endpoint `artifact/remove` which can
either take a list of artifacts to remove or remove all artifacts by
setting all=true.
This patch removes the temporary warning message in the tunnel interface
implementation of ArtifactRm if `--all` was passed on the command line
and uses the new `artifact/remove` endpoint.
This patch also updates the `artifact remove` command both remote and
local to accept a list of artifacts to remove rather than limiting to
just one.
Signed-off-by: Lewis Roy <lewis@redhat.com>
The docs were outdated mentioning the qemu backed for Mac and I find the
way they are written to be a bit confusing.
I think it is best to start with that this option is not supported on
all the providers except WSL.
Fixes: #26780
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Right now, only log-level=info, so not shown by default. We can
continue to up this in subsequent releases to convince folks of
the urgency of switching.
Resolves https://issues.redhat.com/browse/RUN-3343
Signed-off-by: Matt Heon <mheon@redhat.com>
There is a rather surprising bug in the current test checkout logic. The
go.mod version parsing never actually consider a go.mod replace for
buildah and always read the main version.
This meant a buildah replace actually is testing the old version with
the new code and that means the new tests are not run leading people in
false belive when testing a buildah vendor that it worked. But then
later it fails when doing the proper update without replace.
To fix this first use go list to parse go.mod which is more robust. Then
first check if there is a replace and then use that repo/version
instead.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Added log_path variable in containers/common, User sets default log path in containers.conf under the `[containers]` section.
The directory has to exist beforehand. Container logs go under this directory, sub-directories named with the container id
and inside the sub-directory a ctr.log file will be created where the container logs for the corresponding container will go.
This path can be overridden by using the `--log-opt` flag.
Signed-off-by: Joshua Arrevillaga <2004jarrevillaga@gmail.com>
manpages
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
Manpages: Added --filter examples to podman-stop.1.md.in
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
Manpages: Added examples for --filter flag for 'podman start' command in podman-start.1.md.in
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
Manpages: Added examples for --filter flag for 'podman rm' command in podman-rm.1.md.in
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
Manpages: Added examples for --filter flag for 'podman restart' command in podman-restart.1.md.in
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
Manpages: Added examples for --filter flag for 'podman pod ps' command in podman-pod-ps.1.md.in
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
Manpages: Added examples for --filter flag for 'podman system prune' command in podman-system-prune.1.md
Signed-off-by: mohitjain1911 <mohitjain19113@gmail.com>
This patch adds a new --tls-verify flag to the `podman machine init`
sub command which matches many of our other commands. This allows the
user to optionally control whether TLS verification is enabled or
disabled for download of the machine image.
The default remains to leave the TLS verification decision to the
backend library which defaults to enabling it, this patch just
allows the user to explicitly set it on the CLI.
Fixes: #26517
Signed-off-by: Lewis Roy <lewis@redhat.com>
The machine images should contain a new enough podman on the server side
to support this so the skips can be removed.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
podman-next failure notifications are mostly if not totally ignored so
there's no point keeping them.
While these notifications ideally shouldn't be ignored, some builds on
podman-next frequently fail because of older toolchain and end up
causing a lot of noise.
Signed-off-by: Lokesh Mandvekar <lsm5@redhat.com>
