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

fix(serve): connect to Cloud if process is started outside of project dir #4822

Merged
merged 6 commits into from Oct 6, 2023

Conversation

edvald
Copy link
Collaborator

@edvald edvald commented Jul 13, 2023

This came up in the Desktop client because it'd start the serve command outside of any project root, and thus not connect to Cloud at all for the live view etc. to work.

cc @eysi09

@edvald edvald requested a review from eysi09 July 13, 2023 12:02
@vvagaytsev
Copy link
Collaborator

@eysi09 is this ready to do? LGTM, but I might miss some context.

@eysi09
Copy link
Collaborator

eysi09 commented Jul 19, 2023

@eysi09 is this ready to do? LGTM, but I might miss some context.

I'm not sure. Maybe I'm missing something, but when we connect to Cloud we need to do that in the context of some specific project. What would that be in the case where Garden is started outside of a given project?

@trymbill
Copy link
Contributor

@eysi09 and I just verified this works now for Desktop. So LGTM! 👍

vvagaytsev
vvagaytsev previously approved these changes Sep 11, 2023
@eysi09 eysi09 marked this pull request as draft September 11, 2023 15:24
@eysi09
Copy link
Collaborator

eysi09 commented Sep 11, 2023

@eysi09 and I just verified this works now for Desktop. So LGTM! 👍

There's actually one issue here with the localServerPort that requires a bit more thought.

The original intent was for it to only be set for the dev command (and 0.12 serve command) and it's used by cloud to determine whether the core server is running. If a port is set, it suggests the server is running, and cloud will try to connect.

With this change it looks like we're setting the port for non-server commands and that breaks that behaviour.

Maybe the fix is just to not set it for this particular code path but I'm not entirely sure if that makes sense or not. In any case it's not clear from the code as is why it should be omitted in this context.

I flagged the PR as a draft until we fix that.

@eysi09
Copy link
Collaborator

eysi09 commented Sep 18, 2023

Just to follow up.

I think we just need to make sure we only set the localServerPort for the dev or serve command. So when registering a session for, say, a deploy command, we need to make sure that the local server port isn't set in the payload.

This hasn't been an issue until the change in this issue was introduced. Basically the added registerSession call appears to sometime set a server port when it shouldn't.

@shumailxyz shumailxyz marked this pull request as ready for review October 4, 2023 14:01
edvald and others added 3 commits October 4, 2023 16:34
… dir

This came up in the Desktop client because it'd start the serve command
outside of any project root, and thus not connect to Cloud at all for the
live view etc. to work.
@@ -403,7 +403,8 @@ export class GardenInstanceManager {
// Use the process (i.e. parent command) session ID for the serve/dev command session
sessionId: this.sessionId,
commandInfo: garden.commandInfo,
localServerPort: this.serveCommand.server.port,
// set localServerPort only for dev/serve commands
localServerPort: ["dev", "serve"].includes(garden.commandInfo.name) ? this.serveCommand.server.port : undefined,
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is called in more places and we need to update it all of them.

Can I also suggest that in the registerSession function we set the localServerPort type to number | null so that it's explicit and we won't forget to add it at other call sites.

Copy link
Contributor

@shumailxyz shumailxyz Oct 5, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we don't need to update other places. We basically have 3 calls of registerSession including this one. The other 2 calls are in base.ts and serve.ts.

The base.ts call already has a check and skips the registration in case of dev/serve.

const skipRegistration =
!["dev", "serve"].includes(this.name) && this.maybePersistent(params) && !params.parentCommand
if (!skipRegistration && garden.cloudApi && garden.projectId && this.streamEvents) {
cloudSession = await garden.cloudApi.registerSession({

And in serve.ts, we do not need this check as it only registers session for dev/serve.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha ok. Makes sense.

@shumailxyz shumailxyz requested a review from eysi09 October 5, 2023 12:25
@shumailxyz shumailxyz added this pull request to the merge queue Oct 6, 2023
Merged via the queue into main with commit 61b424e Oct 6, 2023
42 checks passed
@shumailxyz shumailxyz deleted the connect-cloud-on-demand branch October 6, 2023 09:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants