Lifecycle

Workspaces are unique per user/branch. They are intended to be used as an alternative to a local environment on a laptop or workstation, and not as a replacement for a shared QA or test environment (use review environments for that). They're created with a persistent disk 5GB disk that saves the state of the configured repository between restarts. Deleting a workspace will delete this disk and entirely reset the Workspace state to the latest commit of the branch.

Workspaces will stay open and active from the time they are started until 30 minutes of inactivity passes. Keeping a browser tab open may, depending on local browser/network settings, keep a workspace active. They have a maximum 12 hour lifetime before a restart is required.

Seed data and migrations

You define your own seed and migration commands in coherence.yml. These are defined for each service, and run in the container for that service (which you write). They are therefore very flexible and powerful.

Configuration SHA

An environment and a workspace both have a Config SHA - this refers to the git hash of the commit that their coherence.yml was at when the configuration was last captured and applied. For workspaces, it refers to the commit sha of when they cloned the repo, and the tag of the docker containers used to run the services defined in coherence.yml, as well.

cocli CLI installed on IDE container

There is a CLI called cocli provided on your Workspaces and Toolboxes. It provides an easy to use wrapper around getting the logs out of your containers and running commands in those containers as well. No need to manage arcane kubectl invocations.

You can use cocli help in the terminal on a Workspace to get help, but the 3 most useful commands are:

• services list all the names of the running services
• logs SERVICE_NAME tail the logs of the service
• exec SERVICE_NAME COMMAND run a command in the service (will attach input and a TTY if required, e.b. when running bash or a REPL