The pasta network mode has been added in podman v4.4 and this causes a
conflict with named networks that could also be called "pasta". To not
break anything we had special logic to prefer the named network over the
network mode. Now with 5.0 we can break this and remove this awkward
special handling from the code.
Containers created with 4.X that use a named network pasta will also
continue to work fine, this chnage will only effect the creation of new
containers with a named network pasta and instead always used the
network mode pasta. We now also block the creation of networks with the
name "pasta".
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The current field separator comma of the inspect annotation conflicts with the mount options of --volumes-from as the mount options itself can be comma separated.
Signed-off-by: Vikas Goel <vikas.goel@gmail.com>
Irrespective of reason/cause, a commit was merged into main that broke
podman-machine, and went unnoticed for several days. Improve the
situation by including podman-machine testing in the daily cirrus-cron
builds. These are monitored by e-mail when `Total Success` reports a
failure.
Also: Add a comment for Windows & Mac build tasks, documenting the
reason they don't execute on RHEL release branches.
Signed-off-by: Chris Evich <cevich@redhat.com>
By using main instead of the v1.1 branch, we drop an unnecessary
dependency on cilium/ebpf, saving ~1mb of binary size.
Signed-off-by: Matt Heon <mheon@redhat.com>
The update to runc broke creation of devices for containers in
the pod cgroup. We don't support the device cgroup for pods at
present, so just disable it for now, resolving the issue.
Thanks to Giuseppe for finding this one!
[NO NEW TESTS NEEDED] This is a fix for broken tests
Signed-off-by: Matt Heon <mheon@redhat.com>
We were pinned to a specific commit to ensure that tests kept
passing. Hopefully they pass now, as we need to grab latest runc
for CVE fixes.
Also grab Buildah main to fix a build issue on FreeBSD. After a
botched manual vendor, I used Ed's treadmill script and squashed
it into this commit to make Git happy. Thanks bunches Ed.
Signed-off-by: Matt Heon <mheon@redhat.com>
I have no idea why the `event_name` != `github.event.action`, but in
this case it doesn't. For consistency with other related condition
checks, use the later over the former.
Signed-off-by: Chris Evich <cevich@redhat.com>
As of this commit, there are several pages worth of lint findings for
the mac. Once they're all addressed, this commit may be reverted to
enable continuous checking.
Signed-off-by: Chris Evich <cevich@redhat.com>
There are darwin-specific code paths which were not being linted prior
to this commit. Fix this with a new, darwin-specific section of the lint
runner script.
Signed-off-by: Chris Evich <cevich@redhat.com>
Fix the way we set skipTLSVerify on the client side
to ensure that the push stage in farm build takes into
account the configuration in the farm node's registries.conf
when the user hasn't set it on the client side.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Previously when a leak was detected under any circumstance, the workflow
would splat out a giant wall of gray, unreadable git-log text. This often
enormous text might contain, somewhere, possibly, maybe, a little tiny
snippet of code that leaks a secret.
Improve the situation greatly by providing easy-to-use URLs that covers
the relevant changes based on the triggering context (new pr, force-push,
or merge). Store the former (often) giant git-log output into a file
and stuff it into the artifacts in case it's ever useful.
Signed-off-by: Chris Evich <cevich@redhat.com>
Podman Desktop [1] is looking into improving the user experience which
requires to know the source of an image. Consider the user triggers an
image pull and Podman Desktop wants to figure out whether the image name
refers to a Red Hat registry, for instance, to prompt installing the RH
auth extension.
Since the input values of images may be a short name [2], Podman Desktop
has no means to figure out the (potential) source of the image. Hence,
add a new `/resolve` endpoint to allow external callers to figure out
the (potential) fully-qualified image name of a given value.
With the new endpoint, Podman Desktop can ask Podman directly to resolve
the image name and then make an informed decision whether to prompt the
user to perform certain tasks or not. This for sure can also be used
for any other registry (e.g., Quay, Docker Hub).
[1] https://github.com/containers/podman-desktop/issues/5771
[2] https://www.redhat.com/sysadmin/container-image-short-names
Signed-off-by: Valentin Rothberg <vrothberg@redhat.com>
We now no longer write containers.conf, instead system connections and
farms are written to a new file called podman-connections.conf.
This is a major rework and I had to change a lot of things to get this
to compile again with my c/common changes.
It is a breaking change for users as connections/farms added before this
commit can now no longer be removed or modified directly. However because
the logic keeps reading from containers.conf the old connections can
still be used to connect to a remote host.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When inspecting a container that does not define any health check, the health field should return nil. This matches docker behavior.
Signed-off-by: Ashley Cui <acui@redhat.com>
SpecGen is our primary container creation abstraction, and is
used to connect our CLI to the Libpod container creation backend.
Because container creation has a million options (I exaggerate
only slightly), the struct is composed of several other structs,
many of which are quite large.
The core problem is that SpecGen is also an API type - it's used
in remote Podman. There, we have a client and a server, and we
want to respect the server's containers.conf. But how do we tell
what parts of SpecGen were set by the client explicitly, and what
parts were not? If we're not using nullable values, an explicit
empty string and a value never being set are identical - and we
can't tell if it's safe to grab a default from the server's
containers.conf.
Fortunately, we only really need to do this for booleans. An
empty string is sufficient to tell us that a string was unset
(even if the user explicitly gave us an empty string for an
option, filling in a default from the config file is acceptable).
This makes things a lot simpler. My initial attempt at this
changed everything, including strings, and it was far larger and
more painful.
Also, begin the first steps of removing all uses of
containers.conf defaults from client-side. Two are gone entirely,
the rest are marked as remove-when-possible.
[NO NEW TESTS NEEDED] This is just a refactor.
Signed-off-by: Matt Heon <mheon@redhat.com>
