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

coder/code-server

菜单

CI/CD 流水线

相关源文件

本文档详细介绍了用于测试、构建和发布 code-server 的自动化工作流。它解释了代码更改如何被测试，以及如何创建和打包发布版，并将其发布到各种分发平台。

有关特定发布包格式的信息，请参阅 发布包。有关 npm 发布详情，请参阅 NPM 发布。

概述

code-server 项目采用强大的 CI/CD 流水线，构建于 GitHub Actions 之上，以实现自动化测试、构建和发布流程。此流水线可确保代码质量，促进一致性发布，并发布到多个分发渠道。

来源

构建工作流

构建工作流是 CI/CD 流水线的基石，它在每次拉取请求和推送到主分支时运行。

来源

构建工作流的关键组件

  1. 变更检测：工作流使用 dorny/paths-filter@v3 来确定已更改的文件，从而允许它有选择性地运行与这些更改相关的作业。

  2. 代码质量检查:

    • Prettier 格式化
    • TypeScript 代码检查
    • GitHub Actions 工作流验证
    • Helm Chart 检查

  3. 测试:

    • 单元测试（带 Codecov 覆盖率报告）
    • 使用 Playwright 进行端到端测试
    • 带代理配置的端到端测试

  4. 构建流程:

    • 构建 VS Code（或使用缓存版本）
    • 构建 code-server
    • 创建 npm 包工件以供后续作业使用

VS Code 集成

构建过程包含 VS Code 的缓存机制，以避免在可能的情况下重新构建

来源

发布工作流

发布工作流会创建包含不同平台包的草稿发布。它通过指定版本号手动触发。

来源

发布工作流的关键组件

  1. 版本管理:

    • 接受版本输入（例如，“v4.9.1”）
    • 更新 package.json 中的版本
    • 更新 VS Code product.json 中的版本

  2. 跨平台打包:

    • Linux 包（x86_64、arm64、armv7l）
    • macOS 包（x86_64、arm64）
    • npm 包准备

  3. 包格式:

    • 适用于 Debian 系列发行的 .deb 包
    • 适用于 Red Hat 系列发行的 .rpm 包
    • 用于独立安装的 .tar.gz 归档
    • 用于通过 npm 安装的 npm 包

  4. GitHub 发布:

    • 创建草稿 GitHub 发布
    • 上传所有包到发布
    • 设置讨论类别

发布工作流

发布工作流将发布的包分发到各个平台。它在 GitHub 发布被发布或手动触发时触发。

来源

发布工作流的关键组件

  1. NPM 发布:

    • 将 npm 包发布到 npm 注册表
    • 使用 NPM_TOKEN 密钥进行身份验证

  2. Homebrew 更新:

    • 使用新版本更新 Homebrew 公式
    • 如有必要，运行脚本以创建对 Homebrew 存储库的 PR

  3. AUR 更新:

    • 更新 AUR（Arch 用户存储库）包
    • 创建到 code-server-aur 存储库的 PR

  4. Docker 镜像发布:

    • 从 GitHub 发布下载 .deb 和 .rpm 包
    • 使用 Buildx 构建多架构 Docker 镜像
    • 将镜像推送到 Docker Hub 和 GitHub Container Registry
    • 使用版本和 latest 标签进行标记

安全扫描

安全扫描已集成到 CI/CD 流水线中，以识别和处理漏洞。

来源

安全扫描的关键组件

  1. 依赖项扫描:

    • npm audit 检查 JavaScript 依赖项中的漏洞
    • 在 package.json 更改时运行，并按计划运行

  2. 代码分析:

    • CodeQL 执行静态分析以识别潜在的安全问题
    • 使用自定义配置文件进行配置

  3. 容器扫描:

    • Trivy 扫描 Docker 镜像中的漏洞
    • 每晚运行一次
    • 专注于高危和严重漏洞

  4. 报告:

    • 结果上传到 GitHub 安全仪表板
    • 使用 SARIF 格式进行结构化报告

发布流程中的手动步骤

虽然 CI/CD 流水线自动化了大部分发布流程，但仍需要一些手动步骤。

步骤描述
1检查变更日志是否列出了所有重要更改
2使用发布日期更新变更日志
3使用版本号手动触发草稿发布工作流
4更新草稿发布描述中的变更日志内容
5发布 GitHub 发布
6在 Docker 镜像发布后，更新 Helm Chart 版本

对于发布候选版本

  • 在版本号后添加 -rc.<数字> 后缀
  • 发布时选择“预发布”
  • 在最终发布之前，不要更新 Chart 版本或合并变更日志

来源

端到端发布流程

从代码更改到发布包的完整发布流程遵循此序列

来源

这个端到端流程确保 code-server 经过彻底测试，正确版本化，并通过多个渠道分发，以满足不同的用户安装偏好。