Improve the speed that users can iterate on their configuration, particularly their .gitpod.yml in a way that doesn't require them to leave gitpod and/or start other workspaces. Doc or research progress.
There are some main configuration areas to improve on:
gitpod.yml - inclusive of the task commands- Image: Dockerfile updates / prebuilds
- IDE integrations
- Dotfiles iterations
- Logs for feedback
Also useful to think on different dimensions:
- Does it lint?
- Does it build?
- Does it run? (integrate)
In scope
Nice to have
Out of scope - Improve outer loop
Closes
Related issues:
Original issue description
Context
When I'm building a workspace, I oftentimes want to iterate on the .gitpod.yml file and test its behavior. My workflow is:
- make a change to .gitpod.yml
- commit and push change
- open gitpod through the commit's/branch's GitHub url
- now I have a workspace created from my edited .gitpod.yml file
Problem with this approach
Two things that are inconvenient about my current workflow:
- I'm going to github as part of the workflow. I'd rather stay in gitpod while I'm iterating
- I end up with an extra workspace that I need to delete
Possible Solution
Add a command to the gp CLI, which takes the current .gitpod.yml (and dockerfile) and starts a fresh workspace with an explicit prebuild stage (so it runs through the automation). The CLI would output the build logs (docker build, prebuild, tasks) to standard out and at the end (ready state) print a link so one can optionally go and open the IDE.
The workspace stops when I terminate the process.
We can then have IDE commands to run this. I think a code lens in the .gitpod.yml would be even better. Also, a notification when the config has changed could be useful for users to discover this.
Improve the speed that users can iterate on their configuration, particularly their
.gitpod.ymlin a way that doesn't require them to leave gitpod and/or start other workspaces. Doc or research progress.There are some main configuration areas to improve on:
gitpod.yml- inclusive of the task commandsAlso useful to think on different dimensions:
In scope
gp env#12208gp rebuildafter updating their.gitpod.ymlor Docker configuration. #16299workspace-fulltakes a long time todocker pullin a first run ofgp rebuild#16298gp rebuildon workspace caching, backup performance, etc. #16480.gitpod.yml#6894gp init -iis returning{}#16335Nice to have
gp rebuild#16180gp rebuildagain. #16178Out of scope - Improve outer loop
.gitpod.ymlconfigurations ("continue with default" options) #16236Closes
gpcommand line #12893gp prebuild-logsGitpod cli command #13505Related issues:
Original issue description
Context
When I'm building a workspace, I oftentimes want to iterate on the .gitpod.yml file and test its behavior. My workflow is:
Problem with this approach
Two things that are inconvenient about my current workflow:
Possible Solution
Add a command to the gp CLI, which takes the current .gitpod.yml (and dockerfile) and starts a fresh workspace with an explicit prebuild stage (so it runs through the automation). The CLI would output the build logs (docker build, prebuild, tasks) to standard out and at the end (ready state) print a link so one can optionally go and open the IDE.
The workspace stops when I terminate the process.
We can then have IDE commands to run this. I think a code lens in the .gitpod.yml would be even better. Also, a notification when the config has changed could be useful for users to discover this.