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
This will be used by the subsequent commit to highlight some of the
more common commands that new user is likely to be interested in, when
none has been specified.
https://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.
However, it makes things confusing for the vast majority of users who
have never used coreos/toolbox. The Toolbox CLI aims to be friendly to
new users by being self-documenting and offering a smooth onboarding
experience. It's jarring to new users when 'toolbox', without any
commands specified, suggests that it needs to perform a big download.
It's difficult to document two different sets of CLIs, and if the
manuals don't mention the second behaviour, then it just leaves the
users even more confused.
Hence, it will be good to keep the migration path for coreos/toolbox
behind a build-time option, so that only those OS distributors who
truly need it may enable it without impacting others. Fortunately,
coreos/toolbox doesn't have any manuals, which means that there's no
need to conditionalize the documentation.
This commit merely adds the build-time option. Subsequent commits will
use this to actually conditionalize the code.
https://github.com/containers/toolbox/pull/951
Some downstream distributors like RHEL don't have patchelf(1). Relying
on patchelf(1) during the build will make it difficult for such
downstreams to distribute Toolbox.
Fortunately, the path of the dynamic linker (ie., PT_INTERP) is
hardcoded in the ABI specification of each architecture [1]. This means
that Toolbox's build system can keep it's own architecture to dynamic
linker mapping, and specify it during the build through the GNU ld
linker's --dynamic-linker flag, as opposed to using a tool like
patchelf(1) to change the path of the dynamic linker in the built
binary to the one inside /run/host. Currently, the list of
architectures covers the ones that Fedora builds for.
[1] https://sourceware.org/glibc/wiki/ABIListhttps://github.com/containers/toolbox/pull/942
Now that there's a website at https://containertoolbx.org/ it makes
more sense to link to it instead of linking back to the same location
where the README.md resides.
