Cloud-Native Development Environments Use an On-Demand Usage and Automatic Idle Destruction Policy

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

Workspace Code Backup

Don’t worry about losing uncommitted code in the workspace after the environment is destroyed. Cloud-native development uses the following two backup methods to ensure code safety:

Backup When Development Environment is Destroyed

After modifying code in the current workspace directory /workspaces, if you don’t commit it immediately, don’t worry—your changes won’t be lost. When the environment is recycled, the modified code will be backed up.

After rebuilding the development environment, the uncommitted code will be restored to the workspace.

1. Backup and Recovery Methods

• Backup When Development Environment is Destroyed: Uncommitted code is saved via git stash into a remote-invisible branch, leveraging the repository’s storage capability for backup.

• Recovery When Development Environment is Rebuilt: The backup code from the remote-invisible branch is restored to the workspace using git stash pop.

Tips

If the workspace contains large files, backup may fail or slow down. Avoid storing files larger than 100MB in the workspace.

2. Backup Content

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

3. Backup Deletion Timing

Each environment generates two backups, with the following deletion rules:

• Per Pipeline Backup: Deleted when the cloud-native development environment record is removed (e.g., deleted from the "My Cloud-Native Development" list).
• Per Branch Backup: Each branch has only one backup (the latest backup for each environment overwrites previous ones; each branch retains only the most recent backup). Deleted when the branch is deleted.

4. Recovery Strategy

• Rebuilding an environment after destruction: Restores the backup code from the original environment.

• Starting a development environment on a branch: Restores the latest backup code for that branch.

Tips

After code recovery, backups for remote-invisible branches will be deleted. That is, each backup can only be restored once. A new backup will be generated when a new environment is destroyed.

The following content will ​​not​​ be backed up:

• Content listed in .gitignore will not be backed up.
• Modifications in sub-repositories will not be backed up.
• Non-workspace modifications will not be backed up.

Scheduled Backup Strategy

To prevent failure of 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 retrieved and compressed into a package for upload.

• Download: You can download the backup code package from the "My Cloud-Native Development" list page.

• Delete: You can delete the backup when removing the development environment history from the "My Cloud-Native Development" list page.

Tips

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

Non-Workspace Files

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

After environment destruction and recreation, roamed files can be restored to the development environment.

Maximum roaming capacity: 64MB, 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 (~: current user's home directory, usually /root):

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

Instructions for using the ~/.cnb directory:

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

1. Example one, copy file to working directory:

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

# .cnb.yml
$:
  vscode:
    - name: vscode
      services:
        - vscode
      stages:
        - name: Copy .env.local file to 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

1. Example two, symlink file to working directory:

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

# .cnb.yml
$:
  vscode:
    - name: vscode
      services:
        - vscode
      stages:
        - name: Symlink .env.local file to 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 users modify configurations (like settings.json) in the development environment, the changes are not roamed immediately. Instead, when the development environment is destroyed, the files that need to be roamed are extracted and persistently stored.

How to restore roamed files:

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

How to verify if file roaming was successful:

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