* containers: Pull newer versions of containers
Allows topgrade to update a users containers. It will automatically skip
containers which come from the `localhost` repo as these are self-built.
Respects the version number the containers were initially checked out
with in order not to introduce semver-breaking changes.
Works with podman and docker.
* topgrade: Add 'containers' step
* containers: Ignore some errors for docker
This patch is needed to achieve compatibility between docker and podman.
In particular, docker doesn't store/tell the user from which repository
(i.e. `hub.docker.com`, or `registry.fedoraproject.org`) a container
originates. This has the side-effect, that self-built containers cannot
be distinguished from publicly available containers. Therefore this
patch introduces an exception to the error handling when pulling, by
scanning the output of the `docker pull` command. If it finds the
`registry does not exist` substring in the output, it will skip the
container but **NOT** consider the whole update step failed.
* containers: Skip '<none>' containers
that result from either intermediate products of a container build or
when images are dangling.
* steps: containers: simplify error handling
And don't return errors from within the "unknown container registry"
handling, since that would immediately terminate the whole update which
isn't intended.
* steps: toolbox: Add module to upgrade toolboxes
This adds a module to upgrade all toolboxes found on a host system.
[Toolbox][1] (More recently: `toolbx`) is a tool that easily provides
mutable, containerized command line environments. It is a means to work
and develop in a mutable environment on immutable operating systems such
as Fedora Silverblue, CoreOS, Kinoite and much more. However, it is not
limited to these use cases.
The integration into topgrade works as follows: Toolbx makes many of the
hosts folders available form inside the toolbx container by default. In
particular, all of the hosts filesystem is mapped under `/run/host`. This
module exploits this fact by:
- Gathering a list of toolboxes available on the host that runs
`topgrade`
- Executing `toolbox run` for each of these toolboxes to run a command
inside the toolboxes, **using the executing `topgrade` executable with
the `--only system` arguments**
[1]: https://containertoolbx.org/
* toolbx: Integrate toolbx into the application
* Toolbx is Linux specific
Co-authored-by: Roey Darwish Dror <roey.ghost@gmail.com>
* Re-add the Go step via go-global-update
go-global-update (https://github.com/Gelio/go-global-update) is a small
tool to update all executables installed in a user's GOBIN, effectively
providing a `go get -u all` replacement for Go 1.16+.
Since it appears that Go will not be receiving a built-in way to do this
in the near future, this could be a good option in the meantime.
* Skip silently if go-global-update is not present
This change adds the option `flatpak.use_sudo` that allows to update
the system-wide installation with sudo. When set to `true` the
system-wide installation will be updated with sudo. If set to `false`
(default) the update will be run as regular user.
This solves the problem where running `flatpak update` on a remote
system fails if run as regular user.
Fixes#737.
This change adds an option, firmware.upgrade, that if set to `false`
only checks for and displays available firmware updates. If set to `true`
(default) the user is offered to run the firmware upgrade.
This commit makes it possible to *not* to use `rpm-ostree` even on
systems where it is detected.
This commit is fully backwards compatible with previous releases, and
without changing the config file all previous behaviors are the exact
same.
This commit adds the `rpm_ostree` field in the `[linux]` table of the
configuration, and defaults to `true`. This means Topgrade will first
check if `/usr/bin/rpm-ostree` exists, and only if so then check if the
user does not want to use `rpm-ostree` via the configuration. If the
user *does not* want to use `rpm-ostree`, then normal operation
continues checking for DNF or YUM.
This makes it possible for people where `rpm-ostree` is installed, but
where the system is not an `ostree` based distribtuion. This happens
when people are using things like `osbuild-composer` to build images,
or Cockpit with the Compose feature enabled (which uses
`osbuild-composer` internally).
An alternative to this commit would be to make the config field a
negative such as `no_rpm_ostree`, however that goes against the norm in
other fields.
Closes#710
* Drop the Go step
With the release of Go 1.16 the behavior of `go get` has been changed.
In previous Go versions `go get` was used not only to add module
dependencies but also to install Go tools.
As of Go 1.16 `go get` can only add and upgrade module dependencies.
To install Go tools now the `go install` command has to be used.
Further on Go 1.16 enabled the GOMODULE mode by default and will drop
the GOPATH mode completly in Go 1.17.
So the package definition `all` like in `go get -u all` does not work
anymore if the PWD is outside of a Go module project.
Because of this `go list all` also does not work for the same reason.
That being said it seems that currently there is no way to get a list of
all installed Go tools or packages at the GOPATH level.
So the only possible solution to determine the installed Go tools and
also to update them would be by inspecting the `go env GOBIN` directory
as well as the `go env GOMODCACHE` sub-directories and to filter the
results according to their possible name-to-package boundaries.
As this approach seems to be very ugly and also not to be very safe or
stable and Go currently does not support any kind of automated upgrades
of installed Go tools it is best to drop the Go step for now until Go
implements some kind of Go tool upgrade feature.
Fixes#659
* Remove Go from Step enum
