<aside> 🌍 This page is public. Read about our take on public when possible, private when necessary.

</aside>

Issue

Our users are asking us to add a means for persistent per-user configuration: https://github.com/gitpod-io/gitpod/issues/5198

Proposed solution

The happy path is pretty close to how Codespaces implements this feature.

User-facing configuration

<aside> 💡 This section desperately needs visual design @George Tsiolis

</aside>

Users configure a "dot file repository" in their user preferences. Super rough outline for where this could be positioned:

This repo must either be public, or can be pulled using one of the authentication providers the user has signed in with.

Workspace initialisation

1. Cloning the dotfile repo: the dotfiles must be in place before the IDE starts, because they're likely to change the PATH environment variable. dotfile repo init can happen in parallel with the content init though.

   We would clone the repo to /home/gitpod/.dotfiles. If that directory already exists, it will be removed prior to the clone operation.

2. Installing the dotfiles: we look for a setup script in the cloned dotfile repo using this list:

   • install.sh
   • install
   • bootstrap.sh
   • bootstrap
   • script/bootstrap
   • setup.sh
   • setup
   • script/setup

   If no such script is found, we symlink every file and folder starting with a . from within the cloned repo to /home/gitpod. For example:

Workspace backup

As long as we just backup/snapshot the /workspace directory, dotfiles do not concern this process. With full workspace backup however, they do.

Full workspace backups

We could argue that dotfiles are installed once on first workspace startup and are not updated during restarts. This means we don't have to treat dotfiles in any special way.

Full workspace snapshots

<aside> 💡 This section will need a discussion on the desired behaviour.

</aside>

It's not clear if users would expect