如何运行 VS Code 发布版 sanity 测试以验证已发布的构建

如何运行 VS Code 发布版 sanity 测试以验证已发布的构建【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode当你发布了一个 VS Code 构建stable、insider 或 exploration 质量需要确认它在各平台上的下载、安装和基本运行是否符合预期时可以使用仓库test/sanity目录下的 Release Sanity Check 测试。这套端到端测试会从更新服务解析指定 commit 的已发布构建逐平台下载、校验并安装验证关键功能。本文以 Ubuntu 上运行本地测试和用 Docker 测试其他 Linux 发行版为主路径说明完整的运行条件和验证方式。测试范围与前提先明确这套测试能做什么、不能做什么测试针对已发布的构建。默认通过update.code.visualstudio.com解析目标该服务只提供已发布构建。从未发布的构建如 canary 验证构建要用--artifacts-dir指向已下载的流水线产物见 test/sanity/README.md 的 Testing Unpublished Builds 一节。很多测试会安装并运行真实的 VS Code必须在对应的目标操作系统或虚拟机上运行在非目标平台上运行会失败。跨平台跑 CLI 类测试时用-gMocha grep或-fMocha fgrep把测试过滤到与宿主平台匹配的范围。每个测试用例默认超时 600 秒--timeout可调。两个必选参数--commit commit-c要测试的已发布构建的 commit SHA--quality quality-qstable、insider或exploration。在 Ubuntu 上运行本地测试仓库在 test/sanity/scripts/ 提供了平台脚本负责搭建环境并调用测试运行器node test/sanity/out/index.js比直接拼 node 命令省事。副作用说明run-ubuntu.sh会以 root 身份修改系统——用sed把/etc/apt/sources.list的源改为 Azure 镜像、apt-get install安装dbus-x11、x11-utils、xvfb、用snap install chromium安装浏览器、启动snapd服务和 XvfbDISPLAY:99。请确认这台机器是专用测试机或容器且你有sudo权限。步骤编译 sanity 测试。进入test/sanity目录安装依赖并编译cd test/sanity npm install npm run compile从仓库根目录运行测试。下面的命令是 test/sanity/README.md 中的示例用文档示例的 commit 对所有平台的 CLI 测试跑 Insiders 构建npm run sanity-test -- --commit 19228f26df517fecbfda96c20956f7c521e072be --quality insider -g cli*其中19228f26df517fecbfda96c20956f7c521e072be是文档中的示例 commit替换成你要验证的已发布构建 commit-g cli*只匹配 CLI 测试避免在当前平台不适用的测试上失败。如果你直接调用脚本而非 npm 入口对应命令为./test/sanity/scripts/run-ubuntu.sh -c commit -q insider -g cli*按需调整常用选项完整列表可用--help查看也可参考 test/sanity/README.md 的 Command-Line Options 表格选项用途--no-cleanup每个测试后不清理已下载的文件便于事后检查--no-signing-check跳过 Authenticode 和 codesign 签名检查--no-headless桌面测试以可见 UI 运行--no-detection不做平台能力探测启用所有测试但跳过可执行文件运行只做下载验证--test-results path-t以 JUnit 格式输出测试结果--screenshots-dir path-s保存失败时的截图--verbose-v输出详细日志例如 CI 里常用组合与 sanity-tests.yml 中各平台的调用一致./test/sanity/scripts/run-ubuntu.sh -c commit -q insider -t results.xml -s screenshots -d crash-dumps -v用 Docker 测试其他 Linux 发行版要在 Alpine、Debian 10/12、Fedora、openSUSE、Red Hat UBI 9、CentOS Stream 9 等发行版上验证已发布构建用 run-docker.sh它构建容器并在容器内运行测试。容器定义在test/sanity/containers/目录内置 Node.js 22.x、Xvfb、D-Bus 和 VS Code 所需架构相关依赖部分容器还带 Web 浏览器用于验证 web server 目标。副作用说明该脚本会拉取/构建 Docker 镜像、创建并运行容器容器内测试会以 root 身份执行安装操作只影响容器自身。# Ubuntu 24.04 on amd64README 文档示例 ./test/sanity/scripts/run-docker.sh --container ubuntu --base-image ubuntu:24.04 -c commit -q insider # Alpine on arm64README 文档示例 ./test/sanity/scripts/run-docker.sh --container alpine --arch arm64 -c commit -q stable脚本选项--container name必填如ubuntu、alpine、--arch archamd64、arm64 或 arm默认 amd64、--base-image image覆盖基础镜像如ubuntu:24.04。其余参数透传给 sanity 测试运行器。验证测试结果判断一轮运行是否通过看以下几个信号进程退出码运行器把 Mocha 的失败数映射为退出码——0 表示全部通过非 0 表示存在失败用例实现见 index.ts。详细日志加--verbose后每个用例开始/通过/失败都会打印如Passed: 测试名、Failed: 测试名 - 错误运行结束打印Mocha test run finished: N failure(s)。JUnit 结果传了--test-results path时结果写入该 JUnit XML 文件可用于在 CI 中归档。失败现场--screenshots-dir收集失败截图--crash-dumps-dir收集桌面应用运行的崩溃转储CI 模板 sanity-tests.yml 会检查这两个目录并把非空目录标记为流水线附件。内置的完整性检查也在结果里体现默认模式下下载的文件会校验 SHA-256与更新服务元数据比对Windows 目标会验证 Authenticode 签名macOS 目标会验证 codesign 与公证逻辑见 context.ts。校验失败会以错误形式让对应用例失败。边界与已知行为--artifacts-dir模式未发布构建目标按 context.ts 中的targetArtifacts映射从artifacts-dir/artifact-name/file解析未映射的目标会直接报错而不会回退到更新服务所以必须用-g/-f把运行范围限定到实际下载了的产物该模式下跳过 SHA-256 检查因为没有更新服务元数据可比对。部分平台只做下载验证CI 矩阵中 macOS x64 只验证下载不做安装/运行时验证见 test/sanity/README.md Test Matrix。Linux DEB 安装冲突如果/usr/share下已存在上一轮残留的 VS Code 安装DEB 用例会直接报错提示检查上次被中断的运行而不是静默跳过。CI 集成官方在 Azure Pipelines 中通过 product-sanity-tests.yml 运行这套测试管道参数为buildQualityexploration/insider/stable、buildCommit已发布构建 commit SHA、可选的npmRegistry可复用任务模板为 sanity-tests.yml。本地想复现 CI 的某一平台行为直接参照模板里对应平台的脚本调用方式即可。完成一轮运行后如果所有匹配的用例通过且退出码为 0则该 commit 的已发布构建在你运行的平台范围内通过了 sanity 验证失败的用例名、--verbose输出和失败截图就是排查起点。【免费下载链接】vscodeVisual Studio Code项目地址: https://gitcode.com/GitHub_Trending/vscode6/vscode创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考