Currently, in order to bump the local pallet from a release-tagged commit to a newer release tag, either we have to manually mess around with the Git CLI (or some other Git tool) or we have to run the plt switch {pallet path}@{version query} subcommand again with a newer version query. It would be convenient if we could run plt switch @{version query} (with no pallet path) to switch to a different version of the current pallet. If our local pallet is github.com/PlanktoScope/pallet-standard, for example, then we could just run plt switch @stable to stage any available upgrade on the stable release channel (i.e. the stable branch), or plt switch @beta to stage any available upgrade on the beta release channel. And we could just run plt switch @ to stage any available upgrade for the most-recently-used version query; plt upgrade could be an alias for this, though it'd be nice if plt upgrade had a --dry-run option (which might also be nice for plt switch). This would probably involve loading a setting from a config file somewhere (maybe in ~/.config/forklift/pallet-upgrades.yml) about which release channel (i.e. branch) of the pallet the user wants to check for updates from.
Each time we call plt switch with a version query it should change the config file's setting to the version query used with plt switch. But we should also have a subcommand (maybe plt set-upgrade-query @{version query}) to change it to a version query other than what was used in the last plt switch invocation. This way, we can run plt switch with a particular version tag when building OS images and then run plt set-upgrade-query to have Forklift track a branch for upgrades starting with the next boot. This way, a user can even configure Forklift to attempt to upgrade to a new tagged version even before the tagged version is published, by running forklift plt set-upgrade-query @{version query for upcoming version}; then subsequent runs of forklift plt upgrade will look for the new tagged version for upgrades.
The plt upgrade command should return an error if there are any uncommitted changes, unless a --force flag is enabled; the behavior should be the same as for plt switch, including with whatever happens in #229.
plt upgrade should fetch all remote branches and tags, if there is internet, before deleting the local pallet and checking out a commit.
It would be great if plt upgrade could show the upgrade to be performed (e.g. the planned change in (pseudo)version string), and if we could query that without performing the upgrade using a plt show-upgrade command.
This way, a simple scheduled automatic update system could be implemented by just running forklift plt upgrade in a timer. We could also make a system service to run forklift plt fetch whenever we get internet access and/or in a timer - e.g. we can create a file whenever we get internet access or on a daily schedule, and when that file exists then another timer polling the file will run forklift plt check-upgrade && forklift plt upgrade and delete the file. Support for background downloading of upgrades (and all their staging requirements) is covered in #254 rather than this issue.
Currently, in order to bump the local pallet from a release-tagged commit to a newer release tag, either we have to manually mess around with the Git CLI (or some other Git tool) or we have to run the
plt switch {pallet path}@{version query}subcommand again with a newer version query. It would be convenient if we could runplt switch @{version query}(with no pallet path) to switch to a different version of the current pallet. If our local pallet is github.com/PlanktoScope/pallet-standard, for example, then we could just runplt switch @stableto stage any available upgrade on thestablerelease channel (i.e. thestablebranch), orplt switch @betato stage any available upgrade on thebetarelease channel. And we could just runplt switch @to stage any available upgrade for the most-recently-used version query;plt upgradecould be an alias for this, though it'd be nice ifplt upgradehad a--dry-runoption (which might also be nice forplt switch). This would probably involve loading a setting from a config file somewhere (maybe in~/.config/forklift/pallet-upgrades.yml) about which release channel (i.e. branch) of the pallet the user wants to check for updates from.plt switchwith a version query it should change the config file's setting to the version query used withplt switch. But we should also have a subcommand (maybeplt set-upgrade-query @{version query}) to change it to a version query other than what was used in the lastplt switchinvocation. This way, we can runplt switchwith a particular version tag when building OS images and then runplt set-upgrade-queryto have Forklift track a branch for upgrades starting with the next boot. This way, a user can even configure Forklift to attempt to upgrade to a new tagged version even before the tagged version is published, by runningforklift plt set-upgrade-query @{version query for upcoming version}; then subsequent runs offorklift plt upgradewill look for the new tagged version for upgrades.plt upgradecommand should return an error if there are any uncommitted changes, unless a--forceflag is enabled; the behavior should be the same as forplt switch, including with whatever happens in #229.plt upgradeshould fetch all remote branches and tags, if there is internet, before deleting the local pallet and checking out a commit.plt upgradecould show the upgrade to be performed (e.g. the planned change in (pseudo)version string), and if we could query that without performing the upgrade using aplt show-upgradecommand.This way, a simple scheduled automatic update system could be implemented by just running
forklift plt upgradein a timer. We could also make a system service to runforklift plt fetchwhenever we get internet access and/or in a timer - e.g. we can create a file whenever we get internet access or on a daily schedule, and when that file exists then another timer polling the file will runforklift plt check-upgrade && forklift plt upgradeand delete the file. Support for background downloading of upgrades (and all their staging requirements) is covered in #254 rather than this issue.