search

SkygearIO / features

Feature Tracking Repo for Skygear
Apache License 2.0
3 stars 12 forks source link

Support Skycli Deployment #94

Closed chpapa closed 7 years ago

chpapa commented 7 years ago

Description

Portal Design

Portal Features

Put Portal Feature List here

API Design

Controller

API involves:

skycli Will do the following on deploy

Scenario

Open Questions

Related Issues

Progress Tracker

Advice

rickmak commented 7 years ago

With regards of adding skycli deploy and skycli login to existing skycli written in golang. I am proposing to drop the current skycli. And use javascript to releasing a new version of skycli which will reuse existing code in skygaer-SDK-JS and skygear-portal.

Current situation

Objective of skycli

Making a full experience as in portal.skygear.io to control, deploy, view log of the skygear server.

Likely scenario

Once we provide skycli login into the skycli. We are actually making the command line interface as web interface to both deis-controller and skygear-server. Not only a command line interface to skygear-server.

In that case, I can imagine feature request like granting permission to a user (interact with deis-controller). In addition, like pubsub interface, record schema modification (interact with skygear-server) will be also wanted.

Keeping it on golang

Pro

Cons

Move it to JS

Pro

Cons

Reference

I think if we are targeting to reduce the programming work load. JS will have a edge.

Thought?

chpapa commented 7 years ago

Agree with the objective and distribution analysis. No idea how portal and skygear-sdk-js interact so can't comment on the reusability part.

cheungpat commented 7 years ago

Sounds good!

cheungpat commented 7 years ago

@rickmak so the new skycli should depends on skygear-sdk-js and the api/controller/controller.js part of the portal? If following what you say to depend the new skycli to the portal (and in turn the SDK), that probably means a lot of react dependencies that otherwise not needed.

As for implementing the cli interface, heroku has its own https://github.com/heroku/cli-engine which is not supposed to be used by outside (they say this in README). Firebase-tools seem to have a better list of package to find inspiration for making the cli interface.

At the very least, the cli interface need to have argument parsing, so https://www.npmjs.com/package/commander is a good idea. https://www.npmjs.com/package/cli-table also looks good for presenting information.

cheungpat commented 7 years ago

@rickmak, see if this makes sense for you?

[ ] - optional input
" " - user input parameter
# Log in to portal using portal email and password
skycli auth login ["email"] [-p "password"]
# Log out from portal
skycli auth logout

# List all apps for this user (`list` is optional)
skycli apps [list]
# Show information of this app
skycli apps show ["appname"]
# Set the default app
skycli apps default "appname"

# Show the log of the app
skycli log
# Deploy the app in the current directory
skycli deploy
# Set and get environment variable
skycli env set "key"="value"
skycli env get "key"

Global options:

--app,-a appname  use this app instead of the default app

Typical user flow:

$ skycli auth login cheungpat@oursky.com
Password:
Logged in as "cheungpat@oursky.com".
$ skycli apps list
cheungpat
lunchbot
$ cd lunchbot
$ skycli apps default lunchbot
Set "lunchbot" as default app for this directory? [Y/n] Y
Default App is "lunchbot".
$ skycli deploy
Deploying to "lunchbot"...
... (deploy log)
Done
$ skycli log
Showing log for "lunchbot"...
... (app log)
$

For the future:

skycli push
skycli user
skycli schema update
skycli schema fetch
skycli permission
chpapa commented 7 years ago

@cheungpat looks good, I got two thoughts:

  1. When it say skycli login, I suppose it store the session data somewhere so that I will remain login even if I close the terminal / restart the machine?

  2. Instead of default app, would it be better if we have a "Project Directory"? e.g. When I use aws-site-mananger, some time I go into the wrong directly and type aws-site-manager sync, I expect people will do the same with skycli deploy and that could be disasters. Plus, an init command can help us pull the Python / Javascript Starter Code to help people kick start easier.

What about something like these?

$ skycli init
Requires authentication, please run skycli auth login

$ skycli auth login cheungpat@oursky.com
Password:
Logged in as "cheungpat@oursky.com".

$ skycli apps
cheungpat
lunchbot

$ skycli deploy
Not a Project Directory, please run skycli init in your Project Directory

$ skycli init
You're about to initialise a Skygear Project in this directory: /Users/chpapa/skygear-project

Confirm? (Y/n) Y

Select an app to associate with the directory:
> cheungpat
   lunchbot

Do you want to create your static hosting directory (public)? (Y/n)

Do you want to start with a Project Template? (Y/n)

Select the Project Template:
> Javascript
  Python
  Empty

Writing configuration to .skyclirc

Initialisation Completed!

$ skycli apps
Apps in the current Directory:
cheungpat

Other apps in your Skygear account:
lunchbot

Some other minor thought:

rickmak commented 7 years ago
  • skycli login instead of skycli auth login? Seems auth is not needed and login is common

This is to avoid confusion with skycli user login, since it will also an interface to skygear-server

  • If we use the above, skycli log will also reflect with the current directory's app. And -a / skycli apps default is not needed.

We already discuss on the project directory and it will be supportted. I agree skycli init is better than skycli apps default to set the current directoty default app.

  • What if people want to have two apps in one project directory? Shall we allow that by having sth like skycli apps add-to-project? Or require people to specify different .skyclirc?

I think no. If he need to works with multiple app, he will need to do skycli deploy -a anothapp. User will got confuse if we support to multiple app. He will not know which app/endpoint will be called if he do skycli logs, skycli pubcub and skycli permission.

In addtion, I am hestiate to make the scaffolding into the init command. Seem we already have some scaffolding, plugin and example on github, and we should try to enable user to use those scaffolding. And making skycli easy to discover them. Like skycli plugin add event_tracking will load the https://github.com/SkygearIO/event_tracking and include it?

chpapa commented 7 years ago

@rickmak thanks for reply. My comments on the specifics as follows:

This is to avoid confusion with skycli user login , since it will also an interface to skygear-server

Hmmm I think it will create more confusion if we have both skycli user and skycli auth? I think it is better to just use skycli login (which is the most common and basic command everyone need to call at least one) and rename skycli user to something else.

I think no. If he need to works with multiple app, he will need to do skycli deploy -a anothapp . User will got confuse if we support to multiple app. He will not know which app/endpoint will be called if he do skycli logs , skycli pubcub and skycli permission .

I think either we support two repo in one project directory or not, we should not have -a that can override the app name specified at skycli init. It will render the contract of the project directory linkage to app endpoint useless.

If we support multiple app, we can have a default (or not), so other commands will need to specify the app name if not default (or always specify the app name if we have no default)

I am hestiate to make the scaffolding into the init command. Seem we already have some scaffolding, plugin and example on github, and we should try to enable user to use those scaffolding. And making skycli easy to discover them. Like skycli plugin add event_tracking will load the https://github.com/SkygearIO/event_tracking and include it?

Why are you hesitate with scaffolding at init? Didn't saw any reasoning. The supporting reason is:

Btw I think the plugins thing is secondary, good to have but don't need to be phase 1

chpapa commented 7 years ago

Follow up for a face to face discussion with @rickmak about skycli user login

My understanding is that is operations that involve users in scygear-server, such as when creating a new record the owner should be...

My initial respond is in that case, the concept is hardly "login user", but to act as some user in the server as the "god" in the app server.

So I would suggest two approaches to deal with that instead of having sth confusing like skycli user login:

  1. (I think this is clearer) Use an option to make certain actions act as that user. e.g. if skycli db add < record.json will create a new record based on record.json's content, we should have skycli db add --ownerID=["ownerID"] < record.json to specific the user in context.
  2. have something like skycli god ["ownerID"] or skycli act-as-user ["ownerID"] or skycli set-default-owner ["ownerID"]. (I like the last one better)
rickmak commented 7 years ago

@chpapa I want to follow up on your view on user are interacting with db or record. Seem they are overlapping and we need only one way to access to data? Users should perceive as db or record.

chpapa commented 7 years ago

@rickmak I think it can only be discussed with specifics use cases of what to do....

I guess maybe need to do some hallway test (ask developers randomly in office?) for things like:

With two set of commands, let's make it like a simple references, and see which one they prefer / find it easier to understand

chpapa commented 7 years ago

Closing it as first version was already deployed on production