Customize Your Workspaces and Workflows

This newsletter will provide an overview of new features on Crafting Sandbox that allow you to customize your workspace and create a development workflow around it.

At Crafting, we believe the development environment should be fully customizable to maximize developers' productivity. Therefore, we provide developers with sudo permissions for any workspace in order to make it easier for them to install software they require. Consequently, we also provide convenient base snapshots and home snapshots to make the same comfortable configuration repeatable team-wide. Here, we take it a step further with Personal Snapshots,Workspace Launch Scripts, and CLI Extensions.

Personal Snapshots

As the name implies, Personal Snapshots allow developers to customize their workspaces to suit their personal preferences. For example, a power user of vim will want the “.vimrc” file exactly the way he/she wants, which may differ significantly from his/her teammates. The personal snapshots feature allows users to create sandboxes with their own personal touch, e.g., having the proper “.vimrc” file preloaded to any sandbox/workspace they created.

To create a Personal Snapshot, similar to Home Snapshot, you need to first create a config file to indicate which directories/files to be included, and save it in your workspace as ~/.snapshot.personal/includes.txt, and optionally what to exclude in ~/.snapshot.personal/excludes.txt. Afterwards, use cs snapshot create --personal to create.

The existing personal snapshots are listed in Resources → Snapshots, under Personal Home Snapshots. Since the personal snapshot is applied to all sandboxes the user creates, only one personal snapshot can be active at a time. It is called default personal snapshot, indicated by a checkmark next to it. The default personal snapshot can be changed at any time.

How Personal Snapshots differ from Base and Home Snapshots?

Here we quickly summarize different usage scenarios for Base Snapshots, Home Snapshots, and Personal Snapshots.

  • Base Snapshots: Base Snapshots are used to include system libraries needed for the workspace, e.g. stuff installed by sudo apt install, for the whole team to share.

  • Home Snapshots: Home Snapshots are used to include the libraries on user land, e.g., pyenv, or cache file based on your repository, e.g. npm cache, which are under the home directory. They are also shared by whole team.

  • Personal Snapshots: Personal Snapshots are for individual developers to further customize based on their personal preference, e.g., .vimrc, .bashrc, etc. For each workspace the user creates, they are appended to Home Snapshots.

Workspace Launch Scripts

There are times when it is desirable to run certain things as a routine whenever a workspace is prepared, for example, connecting to the VPN. Crafting allows this type of automation by Workspace Launch Scripts, which can be run as root or as the user owner. The scripts are run whenever a workspace is created or resumed from suspension. Therefore, you can assume things in these scripts are always run when you access a workspace that is ready.

  • The executable file /etc/sandbox.d/setup is script for running something as root, it would be included in the base snapshot by default

  • The executable file ~/.sandbox/setup is script for running something as owner, it needs to be in the ~/.snapshot/includes.txt to be persisted in home snapshot

Unlike loading files from snapshots, a workspace launch script runs when the workspace is mostly functional, so it can rely on dynamic information. When installing software, it is better to include it in the snapshot for the fast launching process.

In contrast to repo manifests, workspace launch scripts don't bind to any specific repository and are intended to set up the whole workspace instead of building code from specific repositories.

CLI Extenstions

In addition to the powerful CLI tool we provide, we encourage users to further extend it to automate your workflow.

An example would be launching a sandbox from a branch, setting up two-way file synchronization between local and sandbox, opening a local IDE, and then opening a browser to reach the endpoint, all from a single command. This is made possible by the CLI extension.

A CLI extension is an executable with file name like cs-FOO, so the command cs FOO will invoke the executable cs-FOO with rest of the command line arguments. An extension can be placed in any folder that can be looked up in PATH environment variable, or to make it easier to manage and distribute to the whole team, a git repository containing these files can be installed.

By using a CLI extension, you can create a unified team-wide best practice for using Crafting, that is easy to learn and tailored to your specific workflow needs.


  • Charlie Gao
    Charlie Gao

    July 19, 2022

  • Share:

    Newsletter

    Subscribe to our Newsletter

    Crafting

    Your production-like cloud dev environments, instantly.

    © Crafting Inc. 2024. All rights reserved