META: Turning `hippofactory` into `hippo`, the CLI for Hippo

[technosophos]

We've been talking about using Hippofactory as the basis for the general Hippo CLI. I think these are the major things we would need for a full-fledged UI (some of which are done, and some of which tie closely to demos):

In all of these cases, the assumption is that APP_NAME and other details can be gotten from ./HIPPOFACTS and that some information can be gained from contacting the API server (e.g. which channels exist, which is default, etc)

Required

• hippo login URL - login to a Hippo server, after which all ops go to that server
• hippo create|remove [APP_NAME] - create and remove apps. If app name is not specified, use name in ./HIPPOFACTS
• hippo push [CHANNEL] - push to Bindle and notify the current app on the given (or default) channel.
• hippo logs [CHANNEL] - view logs for the given (or default) channel.
• hippo run - Run the code in a local Wagi instance (for local testing)
• hippo prepare - Prepare a local bindle, but don't upload
• hippo env set NAME VALUE [CHANNEL] - Set an env var
• hippo env get|remove NAME VALUE [CHANNEL] - Set an env var
• hippo domain set DNS_NAME [CHANNEL] - Set the DNS name for an app
• hippo domain get|remove [CHANNEL] - Get/remove the DNS name for an app. Remove sets it back to the default
• hippo cert set CERT [CHANNEL] - Set a TLS/SSL cert for a channel (This might need to split cert and key into two files... we can figure that out)
• hippo cert remove [CHANNEL] - Remove TLS/SSL cert for a channel

Optional (Possibly unnecessary)

• hippo init - Create a new HIPPOFACTS file

Optional (Maybe UI only)

• hippo rollback [CHANNEL]
• hippo pin|unpin CHANNEL RELEASE_VERSION - pin a channel to a version
• hippo channel create|remove CHANNEL

Optional (So user doesn't need bindle client, too)

• hippo bindle search STRING - Search the bindle repo, useful for adding dependencies
• hippo bindle yank VERSION - Mark a particular bindle as yanked

Conventions:

• The convention for commands is hippo [NOUN] VERB, with the exception of hippo logs (I am open to a verb that means "to read logs" and has some traction in other CLIs)
  • The most common user actions will be on apps, so instead of doing hippo app create, hippo app logs, etc., I reduced it to hippo create and hippo logs. This is consistent with the vast majority of CLIs out there.
  • Subgroups are then used for less frequently accessed commands/objects: hippo channel create
• I used remove instead of delete per the Helm UX research on the topic, and we could use the rm alias if we want

[bacongobbler]

I'm in favour of this. Having one tool to interact with Hippo would drastically simplify the user experience. It would also drastically simplify the authentication/authorization aspect of Hippo so that we can ensure users can only interact with applications/resources they've been granted access. in other words, I as user "bacongobbler" cannot interact with "areese"'s applications unless they granted me access as a collaborator.

I also thought of a few extra commands:

• hippo register [username] - register a new user, opening a prompt for a password.
• hippo share [username] - add an existing user as a collaborator to an application
• hippo unshare [username] - revoke collaborator access to an application

One thing I would change: hippo deploy to hippo bindle push, or hippo push. That way we're consistent with commands that interact with bindle. I'd also prefer hippo push because pushing a bindle does not always correlate to a "deploy", as the channels may be configured not to deploy the revision that is to be uploaded, either with hippo pin or through a semver range constraint for the active channels.

[bacongobbler]

Do we need a hippo unregister command as well? I'd assume so, but we'd also have to come up with a strategy to ensure applications do not become orphaned by either asking the user change the application's ownership or promote a collaborator as the new "owner" or their apps. That might fall into the "nice-to-have, but not mandatory" category.

[technosophos]

I just updated with hippo push, since I think your argument is compelling. I wasn't as keen on hippo bindle push for two reasons: (a) it implies a bindle-only op (though IIRC, Hippo is notified on this operation), and (b) hippo push is shorter and easier to remember.

[itowlson]

the assumption is that APP_NAME and other details can be gotten from ./HIPPOFACTS

Unfortunately, this isn't the case at the moment. The artifacts spec contains a bindle ID, but not an application ID. Obviously, nothing prevents us changing this, but we'd need to phrase it carefully, because registering a revision affects all applications that use that bindle ID, and we don't want users to think registrations are scoped to that one application. (Though we can change that too, if we feel the current behaviour is wrong.)

I do like the idea of using the current directory / spec for context, though, so this would definitely be good to investigate.

[itowlson]

The most common user actions will be on apps, so instead of doing hippo app create ... I reduced it to hippo create

I think this works well for logs but I'm not sure creating new applications will be a day-to-day operation. I'd vote to keep this one explicit. (Commenting here because this feels like a de facto spec document, happy to defer or move the discussion if you'd rather.)