Calling 'podman system cleanup' causes problems with containers/images
in a separate Podman root. Despite being stored elsewhere, they are
still under Podman's influence and the cleanup removes them. Also,
running containers (outside the scope of the tests) still got affected
by this call and e.g., lost the ability to follow terminal size changes.
Despite the raised concerns, to ensure proper cleanup of any Podman
state, the reset still needs to be done. Thus, do it only once during
the test suite teardown, moving the potential source of problems to a
single position..
https://github.com/containers/toolbox/pull/1024
The previous commit added a means to generating the completion scripts
and this one plugs that into the build system.
A new build option 'install_completions' has been introduced. Set to
'True' by default.
Completions for bash and fish use pkg-config for getting the preferred
install locations for the completions. If the packages are not
available, fallbacks are in-place.
The 'completion' subdir has been kept to work around the ideology of
Meson that does not allow creating/outputing files in subdirectories nor
using the output of custom_target() in install_data().
https://github.com/containers/toolbox/pull/840
Cobra (the CLI library) has an advanced support for generating shell
completion. It support Bash, Zsh, Fish and PowerShell. This offering
covers the majority of use cases with some exceptions, of course.
The generated completion scripts have one behavioral difference when
compared to the existing solution: flags (--xxx) are not shown by
default. User needs to type '-' first to get the completion.
https://github.com/containers/toolbox/pull/840
Co-authored-by: Ondřej Míchal <harrymichal@seznam.cz>
Using a non-supported distribution via `--distro` resulted in a silent
fallback to the Fedora image which confuses users. When a faulty release
format was used with `--release` a message without any hint about the
correct format was shown to the user.
This separates distro and release parsing into two chunks that have
greater control over error reporting and provides more accurate error
reports for the user.
Fixes https://github.com/containers/toolbox/issues/937https://github.com/containers/toolbox/pull/977
The deprecated golang.org/x/crypto/ssh/terminal API was replaced with
golang.org/x/term. Now, every invocation of 'go build' insists on
updating src/go.mod to drop the 'indirect' marker from
golang.org/x/term.
Fallout from d323143c46https://github.com/containers/toolbox/pull/982
It's only necessary to call 'systemd-tmpfiles --create' when building
and installing from source on the host operating system.
It's not needed when using a pre-built binary downstream package,
because:
* When 'meson install' is called as part of building the package,
that's not when the temporary files need to be created. They need
to be created when the binary package is later downloaded and
installed by the user.
* Downstream tools can sometimes handle it automatically. eg., on
Fedora, the systemd RPM installs a trigger that tells RPM to call
'systemd-tmpfiles --create' automatically when a tmpfiles.d snippet
is installed.
It's also not needed when installing inside a toolbox container because
the files that 'systemd-tmpfiles --create' is supposed to create are
meant to be on the host.
Downstream distributors set the DESTDIR environment variable when
building their packages. Therefore, it's used to detect when a
downstream package is being built.
Unfortunately, environment variables are messy and, generally, Meson
doesn't support accessing them inside its scripts [1]. Therefore, this
adds a spurious build-time dependency on systemd for downstream
distributors. However, that's probably not a big problem because all
supported downstream operating systems are already expected to use
systemd for the tmpfiles.d(5) snippets to work.
[1] https://github.com/mesonbuild/meson/issues/9https://github.com/containers/toolbox/issues/955
For the sake of greater control over the testing of images and for having an
infrustructure for hosting images that are not endorsed by the distirbutions.
The images are to be rebuilt every day at midnight.
https://github.com/containers/toolbox/pull/973
Defining the YAML anchor as part of the Rawhide tests, instead of the
Fedora 34 test, will prevent it from getting lost by mistake when
Fedora 34 reaches its End of Life.
https://github.com/containers/toolbox/pull/971
Currently, the CI has been frequently timing out when running the unit
tests. It's possible that the current 5 minute timeout isn't enough,
because it's significantly lower than the 20 minute timeout on stable
Fedoras for the system tests.
Increase the timeout to 10 minutes to see if that makes the CI more
stable.
https://github.com/containers/toolbox/pull/970
Currently, the CI has been frequently timing out on Fedora Rawhide
nodes, and it's not clear why that is. One possibility is that this is
due to Rawhide using Linux kernels that are built with debugging
enabled, which makes it slower than released Fedoras. So it might be a
matter of just increasing the timeout.
Currently, the timeout for stable Fedoras is 20 minutes, and that for
Rawhide is 22 minutes. An attempt to increase the Rawhide timeout to 30
minutes didn't succeed, so maybe 45 minutes will be sufficient.
https://github.com/containers/toolbox/pull/964
In version 1.1.2 of Cobra has been included a change[0] that changes
how custom usage functions are handled.
Example of the wrong behaviour:
$ toolbox --foo
Error: unknown flag: --foo
Run 'toolbox --help' for usage.Error: Run 'toolbox --help' for usage.
Desired behaviour:
$ toolbox --foo
Error: unknown flag: --foo
Run 'toolbox --help' for usage.
A workaround is to define a template string for the usage instead. The
template uses the templating language of Go[1]. See the default
template string in version 1.2.1[2].
Because the template is set only once, the executableBase needs to be
set before the template is applied. That required the move of
setUpGlobals() into init() of the cmd package. This is a better place
for the function call as init() is called earlier than Execute()[3].
Upstream issue: https://github.com/spf13/cobra/issues/1532
[0] https://github.com/spf13/cobra/pull/1044
[1] https://pkg.go.dev/text/template
[2] https://github.com/spf13/cobra/blob/v1.2.1/command.go#L491
[3] https://golang.org/doc/effective_go#inithttps://github.com/containers/toolbox/pull/917
This will be used by the subsequent commit to add a page to document
the configuration file, which should go into section 5 of the manual.
https://github.com/containers/toolbox/pull/963
Not all file are equal when it comes to testing. Unit tests are related
strictly to the source code and documentation changes do not concern it.
System tests have a wider range of influence but documentation and some
other areas also do not concern them.
I'm unsure about the effect of this change on the periodic pipeline
execution.
https://github.com/containers/toolbox/pull/948
github.com/coreos/toolbox bind mounts the entire /run from the host
operating system into the toolbox container. Due to this, when run
rootful, the /run/.containerenv created by Podman inside the container
is also seen on the host. This confuses Toolbox into thinking that it's
running inside a container, even when it's running on the host.
This is an attempt to differentiate between a toolbox container and
the host by looking at the 'container' environment variable, so that
the user can be presented with a more helpful error message.
https://bugzilla.redhat.com/show_bug.cgi?id=1998191https://github.com/containers/toolbox/pull/951
Commit 6c86cabbe5 changed the command line interface to behave
a lot similar to that of github.com/coreos/toolbox, which makes things
easier for those switching over from it. Make it conditional so that
only those OS distributors who truly need it may enable it, and
restore the previous behaviour as the default.
The tests were updated to test the default behaviour that the vast
majority of users would be seeing. Ideally, the test suite would be run
twice with the migration path turned off and on. However, that would
require a more intrusive surgery of the test suite and likely make it
slower. It might not be worth the hassle because of the small number
of users who should be using the migration path.
Note that the copyright and license notices really must use C++-style
// line comments, because build constraints can only be preceded by
blank lines and other line comments. C-style /* */ block comments can't
precede the build constraints.
This reverts commit ca899c8a56 and parts
of commit 3aeb7cf288.
[1] go help buildconstraint
https://pkg.go.dev/cmd/go#hdr-Build_constraintshttps://github.com/containers/toolbox/pull/951