Skip to content

[dashboard] Remove the auto start option #18645

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

Closed
wants to merge 2 commits into from
Closed

Conversation

svenefftinge
Copy link
Member

@svenefftinge svenefftinge commented Sep 1, 2023

Description

This change removes the autostart option on the create workspace page. Instead we always auto start when you come with a contextUrl (unless you use the ?autostart=false query param).

Screenshot 2023-09-01 at 15 58 52

This change also replaces the persistent warning for vscode in the create workspace screen with a toast containing the same information that is shown whenever you select VS Code Desktop (no matter where).

Screenshot 2023-09-01 at 15 58 29
Summary generated by Copilot

🤖 Generated by Copilot at 91fe550

This pull request improves the user experience and code quality of the dashboard component, and fixes some TypeScript errors in the usage API component. It adds a toast message for the experimental VS Code for Desktop option, changes the default and visibility of the autostart option, simplifies the workspace creation UI and logic, and removes an unnecessary callback from the workspace mutation hook. It also adds // @ts-ignore comments to the imports of Long in the generated protobuf files.

Related Issue(s)

Fixes #

How to test

Start a workspace using a regular contexURL

Documentation

Preview status

Gitpod was successfully deployed to your preview environment.

Build Options

Build
  • /werft with-werft
    Run the build with werft instead of GHA
  • leeway-no-cache
  • /werft no-test
    Run Leeway with --dont-test
Publish
  • /werft publish-to-npm
  • /werft publish-to-jb-marketplace
Installer
  • analytics=segment
  • with-dedicated-emulation
  • workspace-feature-flags
    Add desired feature flags to the end of the line above, space separated
Preview Environment / Integration Tests
  • /werft with-local-preview
    If enabled this will build install/preview
  • /werft with-preview
  • /werft with-large-vm
  • /werft with-gce-vm
    If enabled this will create the environment on GCE infra
  • with-integration-tests=all
    Valid options are all, workspace, webapp, ide, jetbrains, vscode, ssh. If enabled, with-preview and with-large-vm will be enabled.
  • with-monitoring

/hold

@jeanp413
Copy link
Member

jeanp413 commented Sep 1, 2023

nit: is it possible to keep track that the same toast is already displayed?
image

@jeanp413
Copy link
Member

jeanp413 commented Sep 1, 2023

Do we need to delete this from user preferences?

image

@jeanp413
Copy link
Member

jeanp413 commented Sep 1, 2023

Doesn't respect setting if workspace is created from a project, steps:

  • Create workspace from workspace page and select an editor, e.g. vscode desktop
  • Create a project on the repor you opened in the step above
  • Open workspace from project page, it will redirect to autostart
  • 🐛 it will open vscode browser by default, but UI says editor is vscode desktop

@mbrevoort
Copy link
Contributor

Setting autoStart=false did not prevent the workspace from auto-starting. It is case sensitive and needs to be autostart=false.

@loujaybee
Copy link
Member

image

We added the VS Code Desktop warning to elicit feedback when we changed the SSH behaviours. Our primary concern was that it might be unexpected for users that we modify their SSH configuration, so we wanted to be more cautious at first. However as we are only appending, we do add settings to a separate folder, and we append the config update with code comments so the user can easily remove themselves if they want. So far we've not had any negative feedback on that functionality so far. I have also since seen that this is the same approach used in both code catalyst + codesandbox I would suggest it's safe to remove entirely. It is also documented:

https://www.gitpod.io/docs/references/ides-and-editors/vscode#connecting-to-vs-code-desktop

What do you think, Sven? Should we just remove?

CC: @akosyakov / @mustard-mh / @jeanp413 as they were originally involved in the discussions around this feature.

@loujaybee
Copy link
Member

Thanks for pushing for improvements, Sven 🙏 - I had a think through the different use cases here, and do have some questions about the impact. Since it's a fairly longer comment/discussion I posted on the internal issue to avoid cluttering the PR with comments.

@svenefftinge
Copy link
Member Author

Doesn't respect setting if workspace is created from a project, steps: ....
🐛 it will open vscode browser by default, but UI says editor is vscode desktop

I couldn't reproduce this. Can you verify one more?

@jeanp413
Copy link
Member

jeanp413 commented Sep 4, 2023

/gh run recreate-vm

Comment triggered a workflow run

Started workflow run: 6075466411

  • recreate_vm: true

@jeanp413
Copy link
Member

jeanp413 commented Sep 4, 2023

Still there 🐛
Recording 2023-09-04 at 11 14 52

@selfcontained
Copy link
Contributor

selfcontained commented Sep 14, 2023

/gh run recreate-vm

Comment triggered a workflow run

Started workflow run: 6187648378

  • recreate_vm: true

Copy link
Contributor

@selfcontained selfcontained left a comment

Choose a reason for hiding this comment

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

If I pick a repo on the new workspace page it updates the hash to track that selected state. If I then reload the page, it auto-starts. I don't think we want that behavior, but that would mean we can't rely on a context url in the hash being present to trigger auto starting.

if (result && result.createdWorkspaceId) {
// successfully started a workspace, wait a bit before we allow to start another one
setTimeout(() => {
setIsStarting(false);
Copy link
Contributor

Choose a reason for hiding this comment

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

Seems like isStarting will remain true now even after it's done. Maybe we can just use the isLoading state now instead - isStarting: mutation.isLoading?

@geropl
Copy link
Member

geropl commented Sep 18, 2023

What's the current state with this PR? Can we close it (for now)?

@svenefftinge
Copy link
Member Author

I'll continue and merge when the nee browser extension is out

@svenefftinge svenefftinge deleted the se/no-autostart branch September 25, 2023 15:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants