Cloud-native development environments use an on-demand approach with automatic destruction when idle.

To prevent the loss of uncommitted code and configuration files after the development environment is destroyed, cloud-native development adopts the following code backup and file roaming strategies:

Workspace Code Backup

There's no need to worry about losing uncommitted code in your workspace when the environment is destroyed. Cloud-native development employs two backup methods to ensure your code is not lost.

Tips

For team development, it's recommended to create personal branches for development. Each branch should be developed by only one person to reduce conflicts during code recovery.

Backup When Development Environment Is Destroyed

After modifying code in the current workspace directory /workspaces, if you haven't committed your changes in time, don't worry about losing your modifications. When the environment is reclaimed, the modified code will be backed up. After rebuilding the development environment, uncommitted code will be restored to the workspace.

1. Backup and Recovery Method

• Backup when the development environment is destroyed: Uncommitted code is backed up using git stash to a remote invisible branch, utilizing the repository's storage capability. Note: For the same user, this backup method only keeps one backup per branch, meaning it's an overwriting backup. If two cloud-native development environments are started for the same branch, the backup from the environment destroyed later will overwrite the backup from the environment destroyed earlier.

• Recovery when rebuilding the development environment: The backup code from the remote invisible branch is restored to the workspace using git stash pop.

Tips

Large files in the workspace may cause backup failure or slow backup speed. Try to avoid saving files larger than 100MB in the workspace.

2. Backup Content

• Uncommitted commits in the workspace
• Uncommitted code in the workspace
• Stashed changes in the workspace

3. Backup Code Deletion Timing

Each branch corresponds to a unique backup: Each environment's backup overwrites the previous environment's backup. Only the latest backup is saved for each branch, and the backup is deleted when the branch is deleted.

4. Recovery Strategy

When rebuilding or creating a new environment, it will always use the latest code, meaning the development environment starts with the latest code from the branch. During recovery, the latest backup will be restored. If code has been committed outside the cloud-native development environment, conflicts may occur. In this case, you can discard the recovered code.

Tips

After code recovery, the backup in the remote invisible branch will be deleted, meaning each backup can only be restored once. A new backup will be created when the new environment is destroyed.

The following content will not be backed up:

• Content declared in the .gitignore file
• Modified content in subrepositories
• Modifications outside the workspace

Scheduled Backup Strategy

To avoid failures with the above backup method, cloud-native development also employs a scheduled backup strategy, periodically packaging and uploading uncommitted code.

• Backup: Every 5 minutes, uncommitted code in the workspace is collected, compressed, and uploaded.
• Download: You can download the backup code package from the "My Cloud-Native Development" list page.
• Deletion: The backup will be deleted when you delete the development environment history record on the "My Cloud-Native Development" list page.

Tips

• Files larger than 100MB will not be backed up.
• Backup code packages larger than 100MB will not be backed up either.

Non-Workspace File Roaming

Remote development supports file roaming for certain directories outside the workspace.

After the environment is destroyed and a new development environment is created, roaming files can be restored to the development environment.

Maximum roaming capacity: 16MB. Exceeding this limit will result in an error and prevent roaming.

Roaming Content

The following files or folders will roam by user dimension, effective for all projects (~: the current user's home directory, generally the /root directory):

• ~/.gitconfig: Git global configuration file
• ~/.local/share/code-server/User/settings.json: WebIDE configuration file
• ~/.local/share/code-server/User/snippets/*: WebIDE related configurations
• ~/.local/share/code-server/User/keybindings.json：WebIDE shortcut key configuration
• ~/.cnb: Users can add personal environment configuration files as needed in this directory.

Instructions for using the ~/.cnb directory:

• Adding configuration files: If the repository needs to add a personal configuration file .env.local to store personal environment variables, you can add the .env.local file in the ~/.cnb directory
• After the environment starts, you can configure script tasks to copy or symlink ~/.cnb/.env.local to the working directory (default is /workspace), .cnb.yml configuration as follows
• Add the ignored file .env.local to .gitignore to prevent personal configuration files from being committed to the repository

Example 1, copying files to the working directory:

To modify the roaming configuration file, you need to directly modify /root/.cnb/.env.local

# .cnb.yml
$:
  vscode:
    - name: vscode
      services:
        - vscode
      stages:
        - name: Copy .env.local file to the working directory (repository root)
          # ./ is the working directory, default is /workspace
          script: |
            if [ -e "/root/.cnb/.env.local" ]; then
                cp -f /root/.cnb/.env.local ./
            else
                echo "File does not exist"
            fi

Example 2, symlinking files to the working directory:

To modify the roaming configuration file, you can modify /workspace/.env.local in the working directory (symlink method will synchronize changes to the source file)

# .cnb.yml
$:
  vscode:
    - name: vscode
      services:
        - vscode
      stages:
        - name: Symlink .env.local file to the working directory (repository root)
          # ./ is the working directory, default is /workspace
          script: |
            if [ -e "/root/.cnb/.env.local" ]; then
                ln -sf /root/.cnb/.env.local ./.env.local 
            else
                echo "File does not exist"
            fi

Roaming Principle and Timing

Roaming timing:

When a user modifies configurations (such as settings.json) in the development environment, the modified content is not immediately roamed. Instead, it waits until the development environment is destroyed, then extracts the files that need to be roamed from the development environment for persistent storage.

How to restore roaming files:

When rebuilding the development environment, roaming files will be automatically restored to the development environment.

How to verify if files have been successfully roamed:

After modifying roamable files, to verify the effect of the modifications, you need to wait until the development environment is destroyed, then create/rebuild the development environment to see the roaming effect of the modified files.

Tips

Note:

• When multiple development environments are open simultaneously, the roaming content from the environment destroyed later will overwrite the roaming content from the environment destroyed earlier.
• Closing the development environment using kill 1 will not successfully roam the files.
• If the file to be roamed is a soft link, we will roam the original file rather than the soft link, to prevent the loss of the original file. If the original file of the soft link does not exist, it will not be roamed.