Epic: Persisted Terminal History

[svenefftinge]

Context

• Currently, workspaces do not persist history.
• When starting a new workspace you do not get history from all previous workspaces launched in Gitpod.
• History is relied on by many developers to do their work.

Context

A terminal history is a very important productivity tool in local dev environments. With ephemeral workspaces we only have a history per session, which is inconvenient. Gitpod should persist the terminal history between workspaces for the same project and user. It's the expectation of all users coming from a local dev environment with a heavy use of terminals.

Acceptance Criteria

• Opening a new workspace will show bash history for previous workspaces
• Documentation is updated with history support

Out of scope

• Shells other than bash.

Archive

### Out of scope

• Other shells beyond bash.

This feature doesn't necessarily need to be advertised, as it is an existing expectation when working with terminals. Users will be positively surprised to see that Gitpod finally keeps history state across multiple workspaces.

Persona(s)

All users with a terminal heavy workflow.

In scope

Keep history for our default shell (bash) for the same project and user.

Out of scope

Supporting all possible shells.

[csweichel]

@akosyakov could we reuse what we built for VS Code user setting sync here?

[akosyakov]

@akosyakov could we reuse what we built for VS Code user setting sync here?

It maybe easy to use blob API from server. User setting sync is scoped to a user and versioned. It looks like here it is scoped to the same workspace and does not need support multiple versions.

keeps history state across multiple workspaces

@svenefftinge I'm not sure about this bit. If I start a completely new workspace I would expect that it is fresh. For me preserving history only between restarts of the same workspace actually makes sense. Maybe should be configurable.

[kylos101]

@akosyakov I would expect new workspaces to have empty history too. But, if I were to restart an existing one, having that history would be nice. If you "really" need something in a new workspace, I would argue that is what dotfiles are for. 😅

Another thing to consider is, how would a user delete history. Say for example, if it contained a secret they did not want persisted.

[akosyakov]

One thing which come up today that there are many clients controlling shell sessions, i.e. supervisor, VS Code, JetBrains, OpenSSH server and so on? Which one we are talking here? If all of them and we don't need to sync between different workspace then maybe the history should be preserved as a part of workspace backup? @csweichel

[csweichel]

there are many clients controlling shell sessions

We would rely on the behaviour of the shell (e.g. bash) and just backup/restore the $HISTFILE. This way we're independent of the process/client controlling the shell session, and users can get creative how they want to handle multiple sessions.

how would a user delete history. Say for example, if it contained a secret they did not want persisted.

If we just back up the histfile, users can modify this file to delete things from their history.

A few questions arise though:

• how do we know where the histfile is located? If the user is using e.g. zsh or fish the history will be stored elsewhere compared to e.g. bash. We could try and detect/guess which shell is used, look at the envvars of that shell to find the HISTFILE and in absence fall back to sensible defaults (bash: ~/.history, zsh: ~/.zsh_history).
• in what context to we restore the history? There doesn't seem to be consensus yet as to the "scope" of the terminal history. We could try and maintain history for a user, a project or a single workspace across restarts.

[axonasif]

But, if I were to restart an existing one, having that history would be nice.

@kylos101 I had the same needs and found that it's relatively easy to do from dotfiles alone [1] 😁

The idea is to create dummy hist files within /workspace/.persist for a newly started Workspace, later symlink them back to their default $HOME based locations for the first time and on every re-start from dotfiles install.sh

[akosyakov]

how do we know where the histfile is located? If the user is using e.g. zsh or fish the history will be stored elsewhere compared to e.g. bash. We could try and detect/guess which shell is used, look at the envvars of that shell to find the HISTFILE and in absence fall back to sensible defaults (bash: ~/.history, zsh: ~/.zsh_history).

Detection is rather tricky, a user can overwrite shell configuration on level of editors as well. Could not we store all?

in what context to we restore the history? There doesn't seem to be consensus yet as to the "scope" of the terminal history. We could try and maintain history for a user, a project or a single workspace across restarts.

I wonder for cross workspaces support how are we going to merge it? Last workspace wins and overwrites, always append? Should it sync in real time?

[akosyakov]

found https://github.com/rcaloras/bashhub-client maybe somebody tried

[loujaybee]

I do agree with keeping simple and limiting supported shells, but I must say that zsh is very popular. Looking into usage stats I think would be worthwhile here. Also the recent move from Apple might impact zsh adoption going forward [1].