| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1) fix lost credentials.
must_pass(), added in #6375, eats the credentials
generated via 'podman run --entrypoint htpasswd'.
Run that podman instance directly, and add explicit
error check.
(The error and stdout/stderr handling here has gotten
cumbersome. There must be something I'm missing that
could make it all simpler.)
2) fix default podman path.
When setting $PODMAN, default to the locally built
one -- there may not be one in $PATH (e.g. in
Ubuntu, see #6366). This in turn requires us to:
3) run registry test in integration, not unit test
It looks like unit tests run before podman is built,
causing a chicken-egg dilemma. Try to solve that by
running the new hack/podman-registry-go test in
integration tests, not unit tests.
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
My initial revision of the podman-registry helper script
was written in haste, with an enormous tradeoff: no
visibility into any errors. We are now paying for this
in #6366: the script is failing on Ubuntu and we
have no way of knowing why.
This PR adds a must_pass() function used for critical
steps. This runs the action silently; if the command
fails, it displays the failing command name with
full output logs, cleans up the temporary workdir,
and exits with error status.
As a reminder, the reason this is necessary is that
our script convention is to output a series of
environment variables to stdout -- we must therefore
take pains not to emit anything else to stdout.
And, unfortunately, podman and openssl tend to be
rather verbose.
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
|
|
In response to #6207: this is a helper script intended for
use in starting and stopping a local container registry.
It takes care of port, username, password assignments;
generates a self-signed certificate; and starts the
container in an isolated podman root/runroot to avoid
conflicting with the caller's environment.
Intended usage: invoke from shell script, using 'eval'
to get results into calling process environment. See
help message (-h) for invocation details. This will
work for shell scripts but will be difficult if
called from Go or C - if that is likely to happen,
I'd love to hear suggestions for alternate ways to
get the settings back to the caller.
Signed-off-by: Ed Santiago <santiago@redhat.com>
|
