Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[feature request] command to update plugins or list outdated plugins #924

Closed
voelzmo opened this issue Aug 11, 2016 · 6 comments
Closed

Comments

@voelzmo
Copy link

voelzmo commented Aug 11, 2016

Hey there,

this is actually not a bug, it is more a feature request. Now that I've installed more than one plugin, I find it cumbersome to check if they are still up-to-date. How about a command to check if my installed plugins are available in a newer version in the repository they have been installed from? Something like packet managers, e.g. homebrew offer:

$ brew outdated
cloudfoundry/tap/bosh-init (0.0.81, 0.0.94) < 0.0.95
cmake (3.1.2) < 3.6.1
direnv (2.7.0, 2.8.1) < 2.9.0
gdbm (1.11) < 1.12
gettext (0.19.6, 0.19.7) < 0.19.8.1
git (2.1.3, 2.2.1, 2.3.5, 2.4.3, 2.4.5, 2.6.2, 2.8.1) < 2.9.2
glib (2.44.1, 2.46.1, 2.46.2) < 2.48.1
gmp (6.0.0a, 6.1.0) < 6.1.1
gnutls (3.3.18, 3.4.10) < 3.4.14
go (1.4.2, 1.5.1, 1.6.2) < 1.6.3
jq (1.5) < 1.5_1
lastpass-cli (0.6.0, 0.9.0) < 1.0.0
...

and then afterwards

$ brew upgrade [<name>]

where omitting <name> upgrades everything.

What do you think?

@cf-gitbot
Copy link

We have created an issue in Pivotal Tracker to manage this:

https://www.pivotaltracker.com/story/show/128135623

The labels on this github issue will be updated when the story is started.

@dkoper
Copy link

dkoper commented Aug 11, 2016

Hi Marco,

I have considered this. There are some practical considerations, and the question is how far we'd want to go:

  • We currently don't record whether a plugin was downloaded from a repository, and if so, what repository and url.
  • ... (maybe it was just the above one)

So we could introduce a cf update-plugin or cf install-plugin [-r REPO] [--update-all] [-f] which would look at the list of installed plugin names, compare it with the list of plugins available in the specified (or all) registered plugin repo's, and for each that reports a newer version perform an upgrade.
We have the confirmation prompt that could show what plugin it is about to update from where to "protect" users from accidentally installing a same named but different plugin from another repo, or install a major version bump of a plugin that may have removed or changed commands.

How does that sound?

Regards,
Dies Koper
CF CLI PM

@voelzmo
Copy link
Author

voelzmo commented Aug 16, 2016

Here would be my desired flow, pretty much referring to how I use something like homebrew:

$ cf plugins
Listing Installed Plugins...
OK

Plugin Name     Version   Command Name         Command Help
usage-report    1.1.0     usage-report         Report AI and memory usage for orgs and spaces
Diego-Enabler   1.2.1     enable-diego         Migrate app to the Diego runtime
Diego-Enabler   1.2.1     disable-diego        Migrate app to the DEA runtime
Diego-Enabler   1.2.1     has-diego-enabled    Report whether an app is configured to run on the Diego runtime
Diego-Enabler   1.2.1     diego-apps           Lists all apps running on the Diego runtime that are visible to the user
Diego-Enabler   1.2.1     dea-apps             Lists all apps running on the DEA runtime that are visible to the user
Diego-Enabler   1.2.1     migrate-apps         Migrate all apps to Diego/DEA
Stack-Changer   1.1.0     stack-change         Update stacks for apps from lucid64 to cflinuxfs2. Restart started apps.
Stack-Changer   1.1.0     stack-list           List all apps running on stack lucid64.
antifreeze      0.3.0     check-manifest       Check your manifest isn't missing any ENV vars or services currently in an app
autopilot       N/A       zero-downtime-push   Perform a zero-downtime push of an application over the top of an old one
open            1.1.0     open                 open app url in browser
open            1.1.0     service-open         open service instance dashboard in browser

$ cf outdated-plugins
 Checking if newer Version is available for Installed Plugins...
OK

Diego-Enabler   1.2.1 < 1.3.0
Stack-Changer 1.1.0 < 2.0

Use 'cf update-plugin <name>' to update a plugin to the most recent version

$ cf update-plugin Diego-Enabler
**Attention: Plugins are binaries written by potentially untrusted authors. Install and use plugins at your own risk.**

Do you want to update the plugin Diego-Enabler from version 1.2.1 to 1.3.0? (y or n)>

A few questions to be solved:

  • should cf install-plugin fail, if the plugin is already installed, or should it perform an update instead?
  • should plugins installed from a local binary also be able to be updated? Currently, trying to install-plugin again fails because a binary with that name already exists
  • Should there be a command to update all existing plugins?
  • Should it be allowed to update a plugin installed from one repository with something of the same name from another repository (or the local filesystem?). Sounds like a reasonable thing maybe for developing plugins. Maybe with something like --force?

@dkoper
Copy link

dkoper commented Aug 18, 2016

A cf plugins --outdated workflow is similar to e.g. Firefox: the About and Add-ons pages have version check features. (We currently have no adjective-verb commands).

Subsequently you can update your plugin with the existing cf install-plugin. (We can consider if we want to update all in a next iteration) - We have a story on allowing cf install-plugin to update a plugin.

@voelzmo
Copy link
Author

voelzmo commented Aug 18, 2016

Great, thanks!

@dkoper
Copy link

dkoper commented Jun 9, 2017

Added in 6.27.0. Thanks for suggesting!
https://github.com/cloudfoundry/cli#downloads

Cheers,
Dies Koper
CF CLI PM

@dkoper dkoper closed this as completed Jun 9, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants