suggest next logical command

[SyedFasiuddin]

closes #898

[oddgrd]

Nice, thanks for picking this up @SyedFasiuddin! I think we can also add a message to the deployment stop command, something like "Run cargo shuttle deploy to re-deploy your service". Perhaps we can also add one to deployment list about how you can use the deployment id in the cargo shuttle logs <id> command to get the logs for a given deployment.

[oddgrd]

I'm not sure we need this message in local run, but it might be useful 🤔 Either way we should not show the URL the project will be hosted at here, because they may use a name that is already taken, but that won't fail in local runs, it will only fail when they run cargo shuttle project start.

[SyedFasiuddin]

The users might do the local run multiple time, over and over again; do you think this message will get annoying to see every time? If yes then we should remove this but the user already see a lot of output from cargo, we could however print this to stderr, but there are no eprintln in the entire file just println.

[iulianbarbu]

There is also the issue of possibly printing this multiple times because locally we'll spin a runtime for each workspace service. This log might be handy for people, so maybe we can add it in the local_run function, but before waiting for runtimes to finish. This is somehow conflicting with what I said previously, but I see the point here of having the next logical command be project start/deploy.

LE: The URL shouldn't be added though because what @oddgrd said. Also, we have two flavours of local_runs (unix/windows), and it will be good to have the log for both.

[SyedFasiuddin]

local_run both of unix and windows call spin_local_runtime and I have added those two suggestion in this method rather than adding it to both local_run methods. Anything wrong with this?

[SyedFasiuddin]

oops sorry spin_local_runtime gets called multiple times if we have multiple services, I didn't see this because of my limited testing on hello world shuttle service.

[SyedFasiuddin]

When cargo shuttle stop is ran the service stays deployed but is inactive i.e. stopped, is this right?

How am I now supposed to start the service back? Do I need to run cargo shuttle deploy again?
There is no cargo shuttle start to start a stopped service, perhaps we could have a cargo shuttle start <id> to do the same.

[SyedFasiuddin]

The git history looks bad sorry. Can you cherrypick commits on github? 😄

[iulianbarbu]

When cargo shuttle stop is ran the service stays deployed but is inactive i.e. stopped, is this right?

Correct.

How am I now supposed to start the service back? Do I need to run cargo shuttle deploy again? There is no cargo shuttle start to start a stopped service, perhaps we could have a cargo shuttle start <id> to do the same.

A cargo shuttle project start is what you're looking for. This will restart the environment for the project deployment.

[SyedFasiuddin]

As @oddgrd mentioned here

I think we can also add a message to the deployment stop command, something like "Run cargo shuttle deploy to re-deploy your service".

we could use cargo shuttle deploy and you are suggesting cargo shuttle project start ??

[iulianbarbu]

As @oddgrd mentioned here

I think we can also add a message to the deployment stop command, something like "Run cargo shuttle deploy to re-deploy your service".

we could use cargo shuttle deploy and you are suggesting cargo shuttle project start ??

Hmm, seems a bit confusing I agree. Probably there is some misunderstanding, but you can try it yourself as well. Testing this is doable by following the CONTRIBUTING.md. Doing a sequence of project start, deploy, project stop, deploy results on my local machine with:

Error: 503 Service Unavailable
message: project not ready

But if I am doing a project start between the last stop and deploy, it's working as expected. This is an issue that I think was documented somewhere. I can't find though where.

[SyedFasiuddin]

so something like this is desirable:

$ cargo shuttle init
...
Run `cargo shuttle project start` to create project environment on Shuttle.

$ cargo shuttle project start
...
Run `cargo shuttle deploy` to deploy your Shuttle service.

$ cargo shuttle deploy
...
$ cargo shuttle project stop
...
Run `cargo shuttle project start` to recreate project environment on Shuttle.

$ cargo shuttle project start
...
Run `cargo shuttle deploy` to deploy your Shuttle service.

$ cargo shuttle deploy
...

Some of these commands will eventually call wait_with_spinner to which I have added the deploy command suggestion but this will be false in the case of project stop as we need to call project start before deploy which means I have to move the deploy suggestion out of wait_with_spinner

[SyedFasiuddin]

project start command will call project_create method where I can suggest to run deploy, thats fine.
project stop command will call project_delete method where I can suggest to run project start, thats fine.

But project restart command will call project_delete and then project_create and in this case we only want to suggest to deploy and not project start

Or should we just leave it?

[iulianbarbu]

project start command will call project_create method where I can suggest to run deploy, thats fine. project stop command will call project_delete method where I can suggest to run project start, thats fine.

But project restart command will call project_delete and then project_create and in this case we only want to suggest to deploy and not project start

Or should we just leave it?

Good question. We can suggest to deploy.

[iulianbarbu]

so something like this is desirable:

$ cargo shuttle init
...
Run `cargo shuttle project start` to create project environment on Shuttle.

$ cargo shuttle project start
...
Run `cargo shuttle deploy` to deploy your Shuttle service.

$ cargo shuttle deploy
...
$ cargo shuttle project stop
...
Run `cargo shuttle project start` to recreate project environment on Shuttle.

$ cargo shuttle project start
...
Run `cargo shuttle deploy` to deploy your Shuttle service.

$ cargo shuttle deploy
...

Some of these commands will eventually call wait_with_spinner to which I have added the deploy command suggestion but this will be false in the case of project stop as we need to call project start before deploy which means I have to move the deploy suggestion out of wait_with_spinner

Indeed, good catch. We might need to duplicate a bit the println here and there, but it should be fine.

[SyedFasiuddin]

project restart will look something like this then:

$ cargo shuttle project restart
project '...' is destroyed
Run `cargo shuttle project start` to recreate project environment on Shuttle.
project '...' is ready
Run `cargo shuttle deploy` to deploy your Shuttle service.

Both those suggestions coming from project_delete and project_create respectively.

[iulianbarbu]

project restart will look something like this then:

$ cargo shuttle project restart
project '...' is destroyed
Run `cargo shuttle project start` to recreate project environment on Shuttle.
project '...' is ready
Run `cargo shuttle deploy` to deploy your Shuttle service.

Both those suggestions coming from project_delete and project_create respectively.

Love it :D

[SyedFasiuddin]

If every thing is resolved then still I don't think we should merge this PR as adding a few println statements should not require 9 commits, it should have been a single commit. If you agree with me then I'll create another PR.

[iulianbarbu]

Thanks, we're almost there. 👍

[iulianbarbu]

If every thing is resolved then still I don't think we should merge this PR as adding a few println statements should not require 9 commits, it should have been a single commit. If you agree with me then I'll create another PR.

No worries, we can keep all these commits for now. Usually, the commits of a shuttle PR are squashed and merged by using GitHub, after the PR was approved. So merging into main will consist of a single commit at the end.

[SyedFasiuddin]

So merging into main will consist of a single commit at the end.

Didn't knew about this. Thanks.

[iulianbarbu]

Thanks! LGTM.

[iulianbarbu]

Thanks! LGTM.