Cloud Native Build

Tips and Tricks

# Keyboard Shortcuts

# Browser Clipboard Authorization

When using the Ctrl/Command + V shortcut to paste in the browser, a clipboard authorization prompt may appear. You can avoid this prompt by:

  • Using the following shortcuts to paste, which will not trigger the clipboard authorization prompt in Chrome:

    • Win: Shift + Insert
    • Mac: Shift + Command + V

  • Adding clipboard authorization in browser settings

Copy chrome://settings/content/clipboard and open it in the Chrome browser to access the clipboard settings. Add the website domain to the "Allow" list under "Allow sites to view your clipboard".

Specific path: Settings -> Privacy and Security -> Permissions (Additional Permissions) -> Clipboard -> Allow sites to view your clipboard

# Resolving Shortcut Conflicts

If there are conflicts between the WebIDE shortcuts and browser shortcuts, here's how to resolve them:

  • Use the VSCode client for development.

# VSCode/Cursor Client Remote Development

The default environment for Workspace supports remote development through WebIDE, VSCode client, and Cursor client.

However, if you choose to customize the development environment, you need to make the following configurations to support remote development with the VSCode client and the Cursor client:

# Enabling VSCode/Cursor Client Support

  • Install openssh-server in the development environment

When customizing the development environment, you can install the ssh service in the Dockerfile beforehand.

# .ide/Dockerfile
FROM your-image

# Note: The installation method may vary depending on the base image.
# Use the appropriate installation method based on your situation.
apt-get update
apt-get install -y openssh-server
  • Download the VSCode client and install the Remote-SSH extension

# Resolving VSCode/Cursor Window Overlapping Issue

When clicking the "Open VSCode Client" button, the existing window may be overlapped.

You can modify the VSCode/Cursor settings to solve this issue by setting Open Folders In New Window to on to open a new window each time.

The path to the setting is:

  • Manage -> Settings -> User -> Window -> New Window -> Open Folders in New Window

# File Roaming

Workspace supports roaming for certain configuration files. After the environment is destroyed and a new development environment is created, the roaming files can be restored in the development environment. Maximum roaming capacity: 64 MB. An error will be reported and roaming will fail if the maximum capacity is exceeded.

# Roaming Content

The following files or folders will be roaming based on the user dimension, effective for all projects(~: The current user's home directory, usually the /root directory):

  • ~/.*rc: bash, zsh, and other shell configurations
  • ~/.*profile: bash, zsh, and other shell configurations
  • ~/.local/share/code-server/User/settings.json: WebIDE configuration file
  • ~/.vscode-server/data/Machine/settings.json: VSCode client configuration file
  • ~/.local/share/code-server/User/snippets/*: VSCode related configurations
  • ~/.cnb: Users can add personal environment configuration files to this directory as needed.

About the use of the ~/.cnb directory:

  • Adding Configuration Files: If the repository needs to add a new personal configuration file .env.local, used to store personal environment variables required by the repository, you can add a .env.local file under the ~/.cnb directory.
  • After the environment starts, you can configure script job to copy or softly link ~/.cnb/.env.local to the working directory (default is /workspace), YAML configuration is as follows.
  • Add the ignored file .env.local in .gitignore to avoid submitting personal configuration files to the repository.

1、Example one, copy the file 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 the .env.local file to the working directory (repository root directory)
          # ./ is the working directory, which is /workspace by default
          script: |
            if [ -e "/root/.cnb/.env.local" ]; then
                cp -f /root/.cnb/.env.local ./
            else
                echo "File does not exist"
            fi

2、Example two, soft link the file to the working directory:

To modify the roaming configuration file, you can modify /workspace/.env.local in the working directory (modifying the source file synchronously in soft link mode).

# .cnb.yml
$:
  vscode:
    - name: vscode
      services:
        - vscode
      stages:
        - name: Soft link the .env.local file to the working directory (repository root directory)
          # ./ is the working directory, which is /workspace by default.
          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 a configuration file (e.g., settings.json) in the development environment, the modifications are not immediately roamed. Instead, they are persisted when the development environment is destroyed.

How to Restore Roamed Files:

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

How to Verify Successful Roaming:

If you want to verify the effect of modifications made to roamed files, you need to wait until the development environment is destroyed and then create/rebuild the development environment to see the roaming effect of the modified files.

# Accessing Business Ports

You can use the port forward feature in VSCode/Cursor to expose the ports you need to access.

# Roaming VSCode Configuration Files

# Configuration File Paths

WebIDE Configuration File (settings.json) Paths:

  • User-level: ~/.local/share/code-server/User/settings.json
  • Machine-level: ~/.local/share/code-server/Machine/settings.json
  • Repository-level: .vscode/settings.json. The relative path is the current workspace (default is /workspace), which is the root directory of the repository.

VSCode Client (Remote-SSH) Configuration File (settings.json) Paths:

  • User-level: Stored locally on the user's machine, can be configured manually
  • Machine-level: ~/.vscode-server/data/Machine/settings.json (will be roamed)
  • Repository-level: .vscode/settings.json. The relative path is the current workspace (default is /workspace), which is the root directory of the repository.

# More Sharing Policies

  • User-level Sharing: Allows configuration sharing for the same user while isolating different users

For WebIDE: User-level configuration files (settings.json) will be automatically roamed and only take effect for the user. For VSCode/Cursor client: Since user-level configuration files are stored locally, machine-level configuration files (settings.json) will be automatically roamed and only take effect for the user.

When modifying configurations, creating more development environments will automatically copy the configuration files.

  • Repository-level Sharing: Allows configuration sharing for the same repository while isolating different repositories

How to share configurations within the same repository: Commit the .vscode/settings.json file to the repository.

  • Environment-level Sharing: Allows environment sharing across repositories

Assuming you already have a built development environment image, you can use it directly in the YAML configuration:









 

# .cnb.yml
$:
  vscode:
    - name: vscode
      services:
        - vscode
      docker:
        # Use a custom image as the development environment
        image: groupname/imagename:latest

# Saving Uncommitted Code in the Workspace

If there is uncommitted code in the workspace, there is no need to worry about losing it when the development environment is destroyed.

# How to Save Uncommitted Code

There is no need to worry about losing uncommitted code in the workspace. When the development environment is destroyed, the uncommitted code in the workspace will be automatically committed to a remote branch that is not visible.

# How to Restore the Saved Code to the Workspace

When rebuilding the development environment, the above saved content will be automatically restored to the new development environment.

# How to Install VSCode Extensions

When customizing the development environment, you can install commonly used VSCode extensions in the Dockerfile for easy reuse. There are two installation methods available.

# Installing by Extension ID

code-server --install-extension ${extension_id}

How to find the extension ID: Search for the extension in the WebIDE or open-vsx, and check the extension ID on the extension details page.

# Installing by VSX Extension File

code-server --install-extension ms-python.python.vsx

Note: The WebIDE uses the open-vsx extension source (open-source), not the official Microsoft extension source (closed-source). If certain extensions are missing in open-vsx, you can search for them in the official Microsoft extension source and download the VSX source file for installation from the extension details page.







 
 
 
 
 










# .ide/Dockerfile
FROM node:20

# Install code-server and extensions
# Method 1: Install extensions by ID
RUN curl -fsSL https://code-server.dev/install.sh | sh \
  && code-server --install-extension redhat.vscode-yaml \
  && code-server --install-extension orta.vscode-jest \
  && code-server --install-extension dbaeumer.vscode-eslint \
  && code-server --install-extension eamodio.gitlens \
  && code-server --install-extension tencent-cloud.coding-copilot \
  && echo done

# Install ssh service for supporting Remote-SSH access to the development environment from the VSCode client
RUN apt-get update && apt-get install -y wget unzip openssh-server

# Specify character set to support inputting Chinese characters in the command line
# (choose the appropriate character set based on your needs)
ENV LANG C.UTF-8
ENV LANGUAGE C.UTF-8

# How to Modify Resource Specifications

Customizing the CPU and memory configurations of the development environment is supported.

The default configuration is currently 8 cores and 16GB of memory.

You can modify the CPU and memory configurations by customizing the YAML configuration here.

← Recommended Usage →