Epic: Remove need to commit to git (Gitpod "Inner Loop")

[mickmister]

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:

1. gitpod.yml - inclusive of the task commands
2. Image: Dockerfile updates / prebuilds
3. IDE integrations
4. Dotfiles iterations
5. Logs for feedback

Also useful to think on different dimensions:

1. Does it lint?
2. Does it build?
3. Does it run? (integrate)

In scope

• Support altering project-level environment variables with gp env #12208
• https://github.com/gitpod-io/website/issues/3417
• Prompt user to use gp rebuild after updating their .gitpod.yml or Docker configuration. #16299
• The workspace-full takes a long time to docker pull in a first run of gp rebuild #16298
• Review perf impact of gp rebuild on workspace caching, backup performance, etc.  #16480
• [inner-loop] run Isolated docker in debug workspace #16363
• Implement analytics on changes to the .gitpod.yml #6894
• Implement analytics on Dockerfiles #6898
• gp init -i is returning {} #16335

Nice to have

• Stream log output of terminals to gp rebuild #16180
• Faster way to run CMD+C and gp rebuild again.  #16178

Out of scope - Improve outer loop

• Stuck in a loop with incorrect workspace image #16264
• Improve error message for invalid .gitpod.yml configurations ("continue with default" options) #16236
• Create new workspace from stopped workspace page + show if configuration has changed. #16232

Closes

• Gitpod to support rebuild current workspace #1305
• Add "checkup" or "doctor" option to gp command line #12893
• [gp-cli] Validate .gitpod.yml #9025
• gp-cli: add gp prebuilt && gp prebuild-logs #4860
• Gitpod Pallete Command to Terminate and Launch a New Workspace for faster .gitpod.yml interation #6818
• proposal: gp prebuild-logs Gitpod cli command #13505
• [gp cli] restart tasks support #8691
• Improve user experience by overcoming the common issues/questions/struggles #10701 (partially)
• Menu item in VSCode to stop workspace and start a new one aka rebuild workspace #9956

Related issues:

• Gitpod Image Build Logs #16485
• https://github.com/gitpod-io/website/issues/2188
• [java] improve inner loop around configuration of SDKs #11149
• Improve user experience by overcoming the common issues/questions/struggles #10701
• [java] improve inner loop around configuration of SDKs #11149
• Why didn't dotfiles initiatize? Where can I find these logs. #11063
• https://github.com/gitpod-io/website/issues/2368
• Show error logs on the loading screen if dotfiles installation script exits with a non-zero code #13004
• presist signals fired via gp sync{await, done} so they survive workspace restarts #2186
• gp-cli: gp rebuild #4861

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.

[svenefftinge]

@mickmister this has been discussed more on a solution side in #4861 and #6818. I like that you framed it from the problem/user perspective, so would like to use this as the driving epic. That means we are updating the initial description as we discover this.

[mickmister]

@svenefftinge It would be interesting if the workflow could match the style of docker image development, how you can iterate on a dockerfile as it caches the execution of each step. It's more difficult in the .gitpod.yml case, because there are multiple scripts running at once, and probably a million other things I'm not aware of that makes it difficult to cache the steps.

I haven't tried the approach of using a dockerfile to setup the Gitpod image. In what's currently available, that may provide a faster workflow of building the workspace, as you can iterate on the Dockerfile and test with the resulting Docker image, without needing to recreate the workspace on each iteration.

We may be able to access the build context from the Docker build process using build arguments:

docker build --build-arg repository=https://github.com/gitpod-io --build-arg commit=8c3e9a08d96f61d74fad72d67029eefe61a53dba

Then the project maintainer can develop the Dockerfile with access to the repo name etc. Then the Dockerfile would clone the repo and install dependencies etc. It looks like we have access to /workspace during Docker build time here, so this seems possible from a cursory investigation.

[loujaybee]

Moving to Q3 as the currently proposed solution for this would be dependent upon #7185, which in turn is dependent on API changes introduced in #7900 and #8512. However, if required, some simpler (non-dependent) solutions could be found for immediate pain relief here rather than doing this via a Gitpod CLI / using the Gitpod API's.

[loujaybee]

Note: There is also the related use-case of iterating/feedback loop on updating dotfiles configuration (in addition to .gitpod.yml, which might well be solved with the same solution) but there might be some way to improve the feedback loop for dotfiles iteration in addition, so wanted to add the dotfile use-case / consideration here, also.

[raphaeltm]

Just adding some feedback from another perspective.

We have a custom Docker image for our workspaces where we pre-install various CLIs that we use on a bunch of projects. If I update the Docker image, to get the latest CLIs, but don't want to get rid of the files in my current workspace (which might include docker volumes with data that I still need), don't have a good path forward. To get the latest image, I need to create a new workspace. It would be really useful (in my use case) to be able to rebuild the current workspace, preserving all the files in /workspace. i.e. re-run the prebuild steps, and then remount /workspace.

We've only just started testing GitPod in the last few weeks, so I might be missing a few things about how it works, but I think this ties in well with this issue.