Gitpod: a ruby installation with rvm should survive stop and restart of a workspace

[bwl21]

Describe the bug
a ruby installation with rvm should survive stop and restart of a workspace

To Reproduce

• open a workspace
• install a ruby with rvm: rvm install ruby-2.4.1
• stop the workspace
• restart the workspace

Expected behavior
I expect the the installed ruby 2.4.1 to be still there

[svenefftinge]

Installed packages (bundle install) should survive as well. See https://spectrum.chat/gitpod/general/snapshots-save-the-state-of-the-workspace-what-does-that-include~2edb3776-dfd4-4224-8322-2b1545f35414

[bwl21]

fully agree.

[rmacklin]

I may have found a workaround using asdf-vm (the tool I suggested in https://github.com/gitpod-io/workspace-images/issues/64) instead of rvm.

asdf-vm allows you to specify the directory where it'll install ruby versions using the ASDF_DATA_DIR environment variable: https://github.com/asdf-vm/asdf/pull/335/files#diff-2104e55eba383a664b1bd9bd9f3db956R37

So, if you install asdf inside /workspace, like:

git clone https://github.com/asdf-vm/asdf.git /workspace/.asdf --branch v0.7.0

and then export ASDF_DATA_DIR=/workspace/.asdf in your .bashrc, it'll install plugins and language versions in that directory which is preserved when you make a snapshot. You'll still need to re-run:

echo -e '\n. /workspace/.asdf/asdf.sh' >> ~/.bashrc
echo -e '\n. /workspace/.asdf/completions/asdf.bash' >> ~/.bashrc

in new workspaces created from the snapshot in order to enable the new workspace to locate asdf, but the installations themselves will have been preserved.

I went as far as trying to rebuild the gitpod/workspace-full Dockerfile to install languages through asdf like this: https://gist.github.com/rmacklin/3d153c34541f399026d4bdcfc2a7ddf3

However, it seems that anything you write into /workspace during the docker build is dropped/ignored once the actual workspace starts. So that part hit a dead end, but at least manually installing asdf inside /workspace once the image comes up (and then installing whatever language versions you need) prior to taking a snapshot can be an imperfect but somewhat reasonable workaround right now.

(Note: a similar approach may be possible with rvm. I didn't try to make it work with rvm because I think asdf-vm is superior since it can manage many languages -- i.e. a solution for asdf-vm should effectively apply to all of asdf-vm's supported languages, whereas an rvm solution would only solve it for ruby.)

[svenefftinge]

Yes, the workspace/is a volume that is mounted into the container. So you cannot add stuff there during Docker build. But couldn't we install asdf into the user's home and just point the environment variable to /workspace/.asdf/?

[rmacklin]

I'm not totally sure if I understand what you mean, so I apologize if this reply doesn't make sense.

The reason I was trying to install into /workspace/.asdf during the docker build was so that the container would come pre-installed with those language versions like workspace-full already does. That way the user wouldn't have to do a slow install each time they start the workspace - it'd just happen once during the build. I could install them in ~/.asdf but then they wouldn't get persisted when the workspace is restarted.

What might be ideal is to install asdf into the home directory (like a normal install), not worry about the environment variable (just install language versions inside ~/.asdf during docker build), and make it such that the contents of ~/.asdf are persisted across workspace restarts. The last part requires changes in gitpod, of course, and I don't know how significant a change it would be to persist that additional directory.

[svenefftinge]

... and make it such that the contents of ~/.asdf are persisted across workspace restarts

Yes, that is what we will do long term.

But we are also looking into an immediate solution for this. For the dependencies it did a quick test and set

export GEM_HOME=/workspace/.rvm

which makes bundler install all dependencies into the workspace. We should add that variable to the workspace-full. For the different ruby versions we could for now just install the most frequently used versions in the docker image. So then people only need to add e.g. nvm use 2.6.0 in the before task or their Dockerfile.

[jankeromnes]

export GEM_HOME=/workspace/.rvm

We should add that variable to the workspace-full.

✔️

This makes the result of gem install <gem> and bundle install peristent, but not rvm install ruby-2.4.1.

However, I agree that adding something like that to .gitpod.yml should be a good (although slow) workaround:

tasks:
  - before: rvm install ruby-2.4.1

[svenefftinge]

If install goes into the dockerfile then people would only need activate the version during 'before'

[jankeromnes]

I tried to get an idea of which Ruby versions are the most popular out there, so that we can pre-install them in our workspace-full image.

It turns out there are many releases. In 2018, the most popular versions were 2.4 (39%) and 2.3 (23%) (source). In 2017, it was 2.3 (58%) and 2.2 (20%) (source).

I think that we should pre-install:

• latest stable Ruby (currently 2.6.2)
• some 2.5 version (e.g. 2.5.4?)
• some 2.4 version (@bwl21 do you need specifically 2.4.1 or would 2.4.5 work as well?)

[bwl21]

as it is impossible to pre-install all currently supported ruby versions I think is is ok to provide the latest patch of the recent three minor version.

https://www.ruby-lang.org/de/downloads/

[bwl21]

@jankeromnes HI, I tried with my workspace today but it still sows ruby 2.6 only. I was told that it will go to master yesterday, so I waited so long.

[jankeromnes]

@bwl21 Hello! Some other issues came up with yesterday's deployment, so we had to postpone it to today, sorry that you waited so long!

Additionally, once we deploy, the new gitpod/workspace-full image will become the default image for new workspaces, but I believe that preexisting workspaces are tied to whatever image they were created with, so you might have to create a new workspace to pick up the updated image once it's deployed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.