在 Devin 中试用 DeepWiki 处理私有仓库
DeepWiki

coder/code-server

菜单

构建与发布流程

相关源文件

本文档概述了用于构建、打包和发布 code-server 的自动化和手动流程。它涵盖了持续集成流水线、发布创建工作流程、针对不同平台的包生成以及向各种分发渠道的发布。

有关 CI/CD 流水线的具体信息，请参阅CI/CD 流水线。

1. 构建和发布概述

code-server 的构建和发布流程包含多个阶段：

  1. 构建：编译 TypeScript 代码库并将 VS Code 打包。
  2. 打包：创建特定平台的包（npm、独立存档、deb/rpm）。
  3. 发布：创建带有构建工件的 GitHub 发布。
  4. 发布：将包分发到各种渠道（npm、Docker、Homebrew、AUR）。

此流程通过 GitHub Actions 工作流高度自动化，但在需要时也可以手动执行。

来源：.github/workflows/build.yaml .github/workflows/release.yaml .github/workflows/publish.yaml docs/MAINTAINING.md

2. 构建流水线

构建流水线是流程的第一阶段，负责编译 code-server 源代码并为打包做准备。

2.1 构建工作流架构

来源：.github/workflows/build.yaml164-226

2.2 构建系统组件

构建过程包含以下主要组件：

  1. 源代码准备：检出代码、安装依赖项并应用补丁。
  2. 编译：构建 code-server 和 VS Code。
  3. 测试：运行单元测试和端到端测试。
  4. 工件创建：为后续阶段打包已构建的代码。

build.yaml 工作流协调这些步骤，并在以下情况下触发：

  • 推送到主分支
  • 推送到主分支的拉取请求
  • 手动工作流分派

来源：.github/workflows/build.yaml .github/workflows/build.yaml164-226

2.3 VS Code 集成

构建系统的关键部分是与 VS Code 的集成。code-server 打包了 VS Code 的一个已修改版本，该版本是在整个过程的一部分中构建的。

  1. VS Code 作为 Git 子模块包含在 lib/vscode 中。
  2. 使用 quilt 系统应用补丁来修改 VS Code。
  3. 使用已缓存的 VS Code 构建以提高构建性能。

来源：.github/workflows/build.yaml192-215

3. 发布流水线

发布流水线接收已构建的代码，并创建特定平台的包和存档。

3.1 发布流程架构

来源：.github/workflows/release.yaml

3.2 特定平台打包

code-server 为各种平台和架构打包：

平台架构包类型
Linuxx64、arm64、armv7l.tar.gz、.deb、.rpm
macOSx64，arm64.tar.gz
npm平台无关.tar.gz

不同平台的打包过程通过具有矩阵配置的 GitHub Actions 作业进行管理。

  1. Linux 包使用交叉编译创建。
  2. macOS 包在 macOS 运行器上构建。
  3. NPM 包是平台无关的。

来源：.github/workflows/release.yaml .github/workflows/release.yaml .github/workflows/release.yaml

3.3 包转换流程

每种包类型都有不同的转换路径。

来源：ci/build/build-release.sh ci/build/build-standalone-release.sh ci/build/build-packages.sh

4. 发布流程

一旦发布草稿被批准并发布，自动化工作流会将包分发到各种渠道。

4.1 发布渠道

code-server 发布到多个分发渠道：

来源：.github/workflows/publish.yaml docs/MAINTAINING.md

4.2 NPM 发布

npm 包通过以下过程发布到 npm 注册中心：

  1. 从 GitHub 发布下载 npm 包工件。
  2. 提取版本号。
  3. 使用适当的身份验证发布到 npm。

来源：.github/workflows/publish.yaml docs/MAINTAINING.md

4.3 Docker 镜像发布

Docker 镜像构建并发布到 Docker Hub 和 GitHub Container Registry。

  1. 从 GitHub 发布下载 deb/rpm 工件。
  2. 设置 Docker Buildx 以进行多架构构建。
  3. 与 Docker Hub 和 GitHub Container Registry 进行身份验证。
  4. 使用适当的标签构建和推送镜像。

Docker 镜像同时带有特定版本和“latest”标签。

来源：.github/workflows/publish.yaml docs/MAINTAINING.md

4.4 Homebrew 和 AUR 发布

Homebrew 和 AUR 包通过自动化流程更新。

  • Homebrew：Homebrew 核心仓库中的公式通过拉取请求进行更新。
  • AUR：在 code-server-aur 仓库中创建拉取请求。

两个流程都涉及：

  1. 检出相应的仓库。
  2. 更新版本信息。
  3. 创建拉取请求以供审查。

来源：.github/workflows/publish.yaml docs/MAINTAINING.md

5. 手动发布流程

尽管大部分发布流程是自动化的，但某些步骤仍需要手动干预。

5.1 发布准备

在开始发布之前：

  1. 更新 Changelog，包含所有重要更改。
  2. 确保 VS Code 版本正确。
  3. 更新 Changelog，包含发布日期。

来源：docs/MAINTAINING.md26-44

5.2 发布候选版本 (RC)

对于重大更改，会在最终发布前创建发布候选版本。

  1. 将 -rc.<number> 后缀添加到版本号。
  2. 将 GitHub 发布标记为“预发布”。
  3. 不对预发布版本进行自动发布。
  4. Chart 版本和 Changelog 仅在最终发布时更新。

来源：docs/MAINTAINING.md45-54

5.3 安全注意事项

code-server 发布流程包含安全扫描。

  1. Dependabot 监控依赖项是否存在漏洞。
  2. CodeQL 提供语义代码分析。
  3. Trivy 扫描仓库代码和 Docker 镜像。
  4. npm audit 检查 Node.js 依赖项。

来源： .github/workflows/security.yaml .github/workflows/trivy-docker.yaml docs/SECURITY.md

6. 构建和发布脚本

构建和发布流程依赖于几个关键脚本

脚本目的
build-release.sh从构建的代码-server和VS Code创建通用的NPM包
build-standalone-release.sh将npm包与Node.js捆绑以供独立使用
build-packages.sh创建特定平台的包和存档
npm-postinstall.sh在npm install后运行以设置依赖项
code-server.sh独立包的启动脚本

这些脚本负责将源代码转换为各种分发格式。

来源： ci/build/build-release.sh ci/build/build-standalone-release.sh ci/build/build-packages.sh ci/build/npm-postinstall.sh ci/build/code-server.sh