Since commit 708fe0af in buildah the tests can run in parallel, let's
enable it here to get the same speed up.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
They really should not take that long, however they timeout out more
often then they pass so let's give this is a try.
I have some hopes that the new worker pool from Adrian might perform
better.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
When the fs supports reflinks use that over a normal copy, this speeds
things up a lot when big files are used.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
- exportloopref is deprecated and deactivated so it should be removed
from the disable list.
- tenv is deprecated and was replaced by usetesting
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This is valid and the upstream linter allows it but somehow with
golangci-lint it produces an error:
Success matcher only support a single error value, or function with Gomega as its first parameter
I reported a bug upstream[1] but for now let's just ignore it so we can
update the linter.
[1] https://github.com/golangci/golangci-lint/issues/5398
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
The PodmanOptionsKey is never used anywhere so it is pointless to add
this. Second having several functions to return the same context makes
no sense so fold them all into one. Lastly create the context once and
always return the same one instead of having to nil check each time.
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
This seems to have been added as part of the cleanup of our
handling of OOM files, but code was never added to remove it, so
we leaked a single directory with an exit file and OOM file per
container run. Apparently have been doing this for a while - I'd
guess since March of '23 - so I'm surprised more people didn't
notice.
Fixes#25291
Signed-off-by: Matt Heon <mheon@redhat.com>
As part of our database init, we perform a check of the current
values for a few fields (graph driver, graph root, static dir,
and a few more) to validate that Libpod is being started with a
sane & sensible config, and the user's containers can actually be
expected to work. Basically, we take the current runtime config
and compare against values cached in the database from the first
time Podman was run.
We've had some issues with this logic before this year around
symlink resolution, but this is a new edge case. Somehow, the
database is being loaded with the empty string for some fields
(at least graph driver) which is causing comparisons to fail
because we will never compare against "" for those fields - we
insert the default value instead, assuming we have one.
Having a value of "" in the database largely invalidates the
check so arguably we could just drop it, but what BoltDB did -
and what SQLite does after this patch - is to use the default
value for comparison instead of "". This should still catch some
edge cases, and shouldn't be too harmful.
What this does not do is identify or solve the reason that we are
seeing the empty string in the database at all. From my read on
the logic, it must mean that the graph driver is explicitly set
to "" in the c/storage config at the time Podman is first run and
I'm not precisely sure how that happens.
Fixes#24738
Signed-off-by: Matt Heon <mheon@redhat.com>
I'm not sure if there is an equivalent to CAP_SYS_RESOURCE on FreeBSD
but for now, I have added a no-op stub which returns false.
Signed-off-by: Doug Rabson <dfr@rabson.org>
