The git repo that was used for the example of a git build:
`podman build https://github.com/scollier/purpletest`
no longer exists. Someone reached out to @rhatdan about this
and he suggested using the Podman Hello World repo. However,
that didn't exist until a little bit ago, so I've updated
the man page with a pointer there. That should be a lot more
stable.
[NO NEW TESTS NEEDED]
Signed-off-by: TomSweeneyRedHat <tsweeney@redhat.com>
Tell sphinx not to process the "options" dir, those files
are not to be published.
Context: websearching for podman volume info, I stumbled upon:
https://docs.podman.io/en/latest/markdown/options/volume.html
...and panicked because I saw '<<container|pod>>', the options
include-file syntax that should never be seen by users. I thought
the filter script was broken.
Signed-off-by: Ed Santiago <santiago@redhat.com>
The newly introduced `idmap` section of rootfs lacked a header
(comparable to Overlay Rootfs Mounts), had odd formatting, and
wording that differed from other instances of idmap, e.g., the
one in the --volume section. This commits addresses those issues.
Signed-off-by: Peter Whittaker <PeterWhittaker@SphyrnaSecurity.com>
This reverts commit 5b148a0a68360892f57603b77e73c69e32fb7b7e.
Reverting to treating the `pull` query parameter as a boolean.
Because of deceiving Docker API documentation it was assumed that the
parameter is pull-policy, however that is not true. Docker does treat
`pull` as a boolean. What is interesting is that Docker indeed accepts
strings like `always` or `never` however Docekr both of these strings
treat as `true`, not as pull-policy. As matter of the fact it seems
there is no such a thing as pull-policy in Docker.
More context https://github.com/containers/podman/issues/17778#issuecomment-1673931925
Signed-off-by: Matej Vasek <mvasek@redhat.com>
Sometimes there is no output displayed from the podman top command but
no error is shown either. Looking at the code I think the issue here is
that we do not wait for the output reader to end as it runs in a
different goroutine. Thus the last lines of output might be missing.
The fix is simply to wait for said goroutine to finish before returning.
While at it also fix the missing scanner error check and return the read
errors back to the caller.
[NO NEW TESTS NEEDED] It is a flake.
Fixes#19504
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
...possibly because we somehow ended up with a two-line
log file for a simple 'echo hi'? Make our timestamp-getting
code safer by adding 'head -1'.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Fedora ELN targets were removed in the switch to ephemeral coprs. Add
them back.
Podman rpm doesn't depend on go-md2man package anymore and instead uses
vendored go-md2man for building manpages, so that's no longer a reason
for build failures on Fedora ELN.
[NO NEW TESTS NEEDED]
Signed-off-by: Lokesh Mandvekar <lsm5@fedoraproject.org>
The mechanism fueling the benchmarks job has long since been removed.
Running the job is useless now, remove it.
Signed-off-by: Chris Evich <cevich@redhat.com>
We've made rather a mess of those options, due to lack of testing.
Here we have a first step toward regression tests. --env is OK,
but there are three special-case exceptions in --env-file for
three incompatibilities introduced by #19096.
To be continued, but probably in future PRs. We need this ASAP
to prevent us from making any more regressions.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Add new --farm flag to podman system connection add so that
a user can add a new connection to a farm immediately.
Update system connection remove such that when a connection is
removed, the connection is also removed from any farms that have it.
Add docs and tests for these changes.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
Podman farm update allows users to update a farm by addig
connections, removing connections, or changing the default farm.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
The podman farm create command allows users to create
farms from the avaiable podman system connections.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
...to reduce flakes.
Reason: journald makes no guarantees. Just because a systemd job
has finished, or podman has written+flushed log entries, doesn't
mean that journald will actually know about them:
https://github.com/systemd/systemd/issues/28650
Workaround: wrap some podman-logs tests inside Eventually()
so they will be retried when log == journald
This addresses, but does not close, #18501. That's a firehose,
with many more failures than I can possibly cross-reference.
I will leave it open, then keep monitoring missing-logs flakes
over time, and pick those off as they occur.
Signed-off-by: Ed Santiago <santiago@redhat.com>
Vendor latest c/common with changes to add a new Farms
table to containers.conf and update system connection to
add a connection to a farm when --farm is set.
Signed-off-by: Urvashi Mohnani <umohnani@redhat.com>
There is a problem where our tail code does not handles correctly
partial log lines. This makes podman logs --tail output possibly
incorrect lines when k8s-file is used.
This manifests as flake in CI because partial lines are only sometimes
written, basically always when the output is flushed before writing a
newline.
For our code we must not count partial lines which was already done but
the important thing we must keep reading backwards until the next full
(F) line. This is because all partial (P) lines still must be added to
the full line. See the added tests for details on how the log file looks
like.
While fixing this, I rework the tail logic a bit, there is absolutely no
reason to read the lines in a separate goroutine just to pass the lines
back via channel. We can do this in the same routine.
The logic is very simple, read the lines backwards, append lines to
result and then at the end invert the result slice as tail must return
the lines in the correct order. This more efficient then having to
allocate two different slices or to prepend the line as this would
require a new allocation for each line.
Lastly the readFromLogFile() function wrote the lines back to the log
line channel in the same routine as the log lines we read, this was bad
and causes a deadlock when the returned lines are bigger than the
channel size. There is no reason to allocate a big channel size we can
just write the log lines in a different goroutine, in this case the main
routine were read the logs anyway.
A new system test and unit tests have been added to check corner cases.
Fixes#19545
Signed-off-by: Paul Holzinger <pholzing@redhat.com>
