-
Notifications
You must be signed in to change notification settings - Fork 928
feat: restart stopped workspaces on ssh command #11050
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
Conversation
This is opt out by default. VScode ssh does not have this behavior
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice clean addition!
} | ||
// The workspace needs to be stopped before we can start it. | ||
// It cannot be in any pending or failed state. | ||
if workspace.LatestBuild.Status != codersdk.WorkspaceStatusStopped { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A case that I would personally like for to work is that I can ssh into a stopping workspace and have it wait until the stop is complete and then either issue the start or wait for a start to complete.
No action necessary for this PR, though. Just writing this down as a food for thought.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Things could be improved to handle more cases, but that felt a bit overkill atm.
cli/ssh_test.go
Outdated
err := inv.WithContext(ctx).Run() | ||
assert.NoError(t, err) | ||
}) | ||
pty.ExpectMatch("⧗ Running") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if this has the potential to be racy, i.e. workspace started before we end up streaming logs. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a good point. I am unsure how to prevent that 🤔.
We really should have a controllable provisioner in our unit tests to trigger this stuff 😢
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, we have coderdtest.AwaitWorkspaceAgents(t, client, workspace.ID)
before I run exit
which is sufficient to wait for the workspace to be ready.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I think workspace being ready shouldn't be an issue. But I'm wondering if the provisioner log missing could be an issue depending on at what stage of the workspace lifecycle we connect to it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup, I removed it because I check if the agent is ready right below it. So That agent ready will always work, even if we miss the logs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What this does
On
coder ssh
orssh
if the target workspace is off, the workspace will be started.Feature can be opt out, so by default this is on. To opt out:
$ coder ssh --disable-autostart local-docker # Or $ coder config-ssh --disable-autostart
Closes: #4973
VScode extension?
Vscode uses
coder vscodessh
and is unaffected:coder/cli/vscodessh.go
Line 34 in f422f47