Standalone sandbox
As the name suggests, a Standalone Sandbox
is a sandbox that is not based on a Template
.
A standalone sandbox is also known as Template builder sandbox
in some contexts since it's useful for building a new Template
. Even though a template is basically a YAML file internally (see Sandbox Definition), we find in practice it's much easier to have a sandbox handy to set it up. The configuration of a standalone sandbox can be updated quickly and the change can be immediately apply to the sandbox for further testing and iteration. Basically, the process is to adjust settings in this sandbox until it matches the expectation, and save the config as a template.
For example, the following figure shows a standalone sandbox created in the Template builder wizard from previous page.
From the sandbox, click the Edit
button on the top right corner will get to the template editing view, as shown follows, here we can add a new component or click into any existing component for editing. After editing, you can click Apply
to save the configuration to the sandbox.
You can also edit the configuration directly in YAML format by clicking Edit in YAML
(see Sandbox Definition). After everything is properly setup, you can save the configuration as a template by clicking Save as Template
. We recommend you try the config with a fresh new standalone sandbox before saving to verify the end-to-end process.
Apply changes
When clicking Apply
, the changes of the configuration will be applied to the running sandbox instantly. However, due to the nature of individual configurations, some settings won't be applied to existing workloads:
Configurations | Workload Type | Reason/Comment |
---|---|---|
Checkout | Workspace | Checkouts are identified by the path properties.Existing checkouts (same path ) won't be updated for the risk of loosing data.Newly added checkouts (with new path values) will be applied instantly. |
Package | Workspace | When updated, packages are mounted to the workspaces instantly. However, some packages require the PATH environment to contains its bin folder. The environment of all running processes inside the workspace, including VSCode server, will not be changed, so they won't be able to see the updated package bin folder in the PATH . |
Base Snapshot Home Snapshot Dependency Snapshot Container Snapshot | Workspace/Dependency/Container | Snapshots are life-time configurations, once workspace is created, they will never change. |
Env | Workspace | All running processes including VSCode server will not be able to pickup environment changes. Only new processes will be affected. |
Service Type and Version | Dependency | These are life-time configuration, and won't be changed after the dependency is created. |
Properties | Dependency | This is service specific. In most cases, changing of properties of the running dependency won't have effect, unless the service process is restarted. |
To make these configurations effective, the corresponding workload must be rebuilt, from the Sandbox details view, use the button on the workload card
Note: rebuilding a workload is equivalent to deleting the current workload and creating a new one. All persisted data will be discarded. And it's irreversible.
Updated almost 2 years ago