fix(installation): Optimize Rustlings Installation in Gitpod Workspaces #1766
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
haraldreingruber
changed the title
haraldreingruber
changed the title
|
I'm curious: Would the solution in #1780 also work for this? |
|
Closing because the installation script is removed in the upcoming v6 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, when opening a Gitpod workspace, Rustlings is cloned into a sub-directory. This can be confusing and also leads to issues with the paths of the compile errors not opening the correct file when ctrl+clicking the paths in the terminal output.
To improve the user experience, this Pull Request proposes to skip the cloning process when the
install.shscript is running in a Gitpod workspace. This change will ensure that the Rustlings exercises are directly accessible in the workspace root, thereby resolving the path issues in the terminal output.At the moment, the latest main branch revision is used, which is probably fine too. Or would you prefer still checking out the latest tagged release?
If this might make also sense for GH Codespaces, please let me know.
Feedback and suggestions are welcome.