企业官网建设流程全解析

Cockpit 开发实战指南：从环境搭建、构建测试到调试的完整工作流（HACKING.md 深度解读）

【免费下载链接】cockpitCockpit is a web-based graphical interface for servers.项目地址: https://gitcode.com/gh_mirrors/co/cockpit

Cockpit 是一个基于 Web 的服务器图形管理界面，本文围绕仓库根目录的 HACKING.md 展开，系统讲解面向 Cockpit 开发者的完整工作流：从获取源码、搭建官方开发容器，到构建会话页面、运行单元测试与集成测试、调试 Bridge 与 Web 服务，再到提交贡献与发布 release note。读完本文，你将掌握一套可在本地可复现的开发环境（toolbox/distrobox +cockpit/tasks容器）与多种迭代/调试手段，能够独立修改 Cockpit 的 Web 页面、Python Bridge 乃至 C 语言 Web 服务，并把变更安全地提交为 Pull Request。

获取源码与远程仓库的正确姿势

一切开发从克隆仓库开始。HACKING.md 给出的标准操作是：

git clone https://github.com/cockpit-project/cockpit cd cockpit/

后续所有命令都默认在仓库顶层目录执行。

文档特别强调了一个易踩的坑：不要克隆你自己的 fork 作为主 checkout。原因有三：fork 缺少标签（missing tags）、无法正确确定版本号、无法与 CI bot 命令集成。正确做法是保持origin指向只读的上游仓库，把你的 fork 添加为一个独立的、可写的远程仓库：

git remote add my git@github.com:yourgithubid/cockpit.git

这样你可以在my上推送分支、发起 Pull Request，同时origin始终与上游同步，便于持续拉取最新代码。仓库根目录的 AUTHORS 记录了项目的贡献者名单，tools/git-hook-pre-push、tools/git-hook-post-commit、tools/git-hook-pre-rebase 则是后续章节会提到的官方 git 钩子脚本。

使用官方开发容器：toolbox/distrobox + cockpit/tasks

Cockpit 团队维护了ghcr.io/cockpit-project/tasks容器镜像，同时用于本地开发与 CI。HACKING.md 强烈建议你在本机安装 toolbx 或 distrobox 后使用该容器，理由包括：

• 它是 CI 的官方环境，已知可用且结果可复现；
• 避免在主系统上安装一堆开发包；
• 无需把构建/测试依赖映射到各个发行版的包名。

安装与创建

按发行版安装 toolbox：

# Fedora/CentOS/RHEL 系 sudo dnf install toolbox # Debian/Ubuntu 系 sudo apt install podman-toolbox

创建并进入名为cockpit的开发容器：

toolbox create --image ghcr.io/cockpit-project/tasks -c cockpit toolbox enter cockpit

容器与宿主机共享 home 目录、用户 D-Bus 等，因此你依然可以像平常一样用宿主机上的编辑器改代码，构建和测试则在容器内进行；需要额外软件时用sudo dnf install安装即可。

刷新开发容器

Cockpit 团队会不定期刷新tasks镜像。要从最新镜像重建开发容器：

podman pull ghcr.io/cockpit-project/tasks toolbox rm cockpit

然后重复上面的toolbox create与toolbox enter两步即可。

开发会话页面：符号链接 dist + watch 模式

大多数贡献者关心的是 Cockpit 的 Web 部分（HTML、JavaScript、CSS）。其核心技巧是让本机 Cockpit 直接读取你本地构建产物，而不是系统安装的文件。

第一步：先安装 Cockpit

先在本地机器上安装 Cockpit（参考官方 "running" 文档），作为运行载体。

第二步：把构建产物目录链接到用户目录

在仓库顶层执行，并且务必以你稍后登录 Cockpit 所用的同一用户身份运行：

mkdir -p ~/.local/share/ ln -s $(pwd)/dist ~/.local/share/cockpit

执行后，Cockpit 会直接从本地dist/目录读取 JavaScript、HTML、CSS，而不是系统安装的版本。

第三步：用 watch 模式持续构建

推荐的构建方式是针对正在开发的那个页面启用 watch 模式（-w/--watch）。例如想改 pkg/systemd 下的内容：

./build.js -w systemd

如果改动影响多个页面（比如改动了 pkg/lib 下的共享文件），可以构建全部页面：

./build.js -w

从 build.js 的源码可以看到，该脚本基于 esbuild 打包：它先调用tools/node-modules make_package_lock_json确保node_modules就绪，通过-r/--rsync指定构建后同步到的 SSH 目标，-w/--watch开启监听模式，onlydir参数则限定只构建pkg/<DIRECTORY>。开发模式下会输出 linked sourcemap，并把产物输出到./dist目录（QUnit 测试产物则输出到./qunit）。注意 watch 模式在非 x64 架构（使用 esbuild-wasm）时不受支持，脚本会直接报错。

构建完成后，用与桌面登录相同的用户名密码访问http://localhost:9090即可看到效果。watch 模式会在源文件变更时自动重建，刷新浏览器就能看到改动；按Ctrl-C停止监听。

测试到 VM：RSYNC 环境变量

很多场景需要把改动拿到测试 VM 里验证。设置$RSYNC环境变量即可把构建好的页面复制到指定 SSH 目标的/usr/local/share/cockpit/目录。如果你按 test/README.md 配置了 SSHc别名（指向测试 VM），可以直接用：

RSYNC=c ./build.js -w kdump RSYNC=c ./build.js -w

配合 build.js 中-r/--rsync参数的实现，构建完成后会自动把 bundle 同步到目标主机。

回到系统安装包

想撤销本地覆盖、恢复使用系统安装的 Cockpit 文件，删除符号链接并重新登录即可：

rm ~/.local/share/cockpit

构建与单元测试：autotools 工作流

Cockpit 使用 autotools，因此有熟悉的./configure脚本和 Makefile 目标。

初始化构建树

克隆源码后第一次构建需要运行autogen.sh：

./autogen.sh --prefix=/usr --enable-debug

从 autogen.sh 源码可见：它会先用git describe --tags --abbrev=0生成版本号写入version.m4，然后执行autoreconf -i --warnings obsolete，最后用给定参数调用configure；同时它还会下载各种 nodejs 依赖（node_modules）。文档建议在 git 克隆环境下始终使用./autogen.sh而不是直接./configure。

构建与测试

make # 构建全部内容 make check # 运行单元测试

Cockpit 采用单一非递归 Makefile：只能在顶层执行make，而且总是重建整个项目。make check应该很快完成，建议高频执行。

针对个别测试的调试方法：

• 编译出的二进制位于构建目录中；
• 对于 QUnit（JavaScript）测试，运行./test-server，它会输出一个可浏览器访问的 URL，例如http://localhost:8765/qunit/base1/test-dbus.html，调整路径可访问不同测试并查看结果；
• QUnit 测试是作为一个名为test_browser的 pytest 测试运行的，可用pytest -k筛选，例如pytest -k test-fsinfo.html。

JavaScript 代码覆盖率：

pytest -k test_browser --js-cov # 汇总表 pytest -k test-fsinfo.html --js-cov-files='*/fsinfo.ts' # 指定文件未覆盖明细

覆盖率信息无论是否加覆盖率参数都会收集到 pytest 的 tmpdir，事后可不下重跑测试直接用 test/common/js_coverage.py 分析：

test/common/js_coverage.py -m '*/fsinfo.ts' /tmp/pytest-of-*/pytest-current/js-coverage/*

此外还有静态代码与语法检查，建议经常运行：

test/common/static-code

git 钩子：把检查前置到提交/推送

强烈建议设置 pre-push 钩子，避免推送出会被平凡错误卡住的 PR：

ln -s ../../tools/git-hook-pre-push .git/hooks/pre-push

该钩子会对每个待推送的 commit 调用test/common/static-code。同样可以设置 post-commit 钩子（每次提交后执行相同检查）：

ln -s ../../tools/git-hook-post-commit .git/hooks/post-commit

还有一个缓解 git submodule 痛点（防止误提交子模块的陈旧指针）的钩子：

ln -s ../../tools/git-hook-pre-rebase .git/hooks/pre-rebase

理解并调试 Bridge：Cockpit 会话的核心进程

Bridge 的定位

Bridge 是 Cockpit Linux 会话中启动的第一个程序：它的 stdin/stdout 连接到 web socket（进而连接到页面中的 JavaScript），在上面说一种 JSON 协议——该协议把“channels”复用在一起，channel 是操作系统 API 的抽象，页面借助它们实现功能。这个协议最终被翻译为实际的操作系统调用，如打开/写文件、D-Bus 调用、HTTP 查询。文档中有一个形象的类比：Bridge 之于 Cockpit 页面，就像 "bash" 之于人的 SSH 会话。

从源码看，Bridge 的实现位于 src/cockpit/bridge.py：Bridge类继承自Router并实现PackagesListener，组装了ChannelRoutingRule、PeersRoutingRule、HostRoutingRule、SuperuserRoutingRule等路由规则，把协议消息分发到具体的 channel 实现（src/cockpit/channels 目录下即各类 channel）。该目录被选作src/cockpit，是因为它符合 Python 包的标准 "src layout" 约定——每个包（cockpit）都是src的子目录。

从源码树直接运行 Bridge

PYTHONPATH=src python3 -m cockpit.bridge

为了免去手写协议消息的麻烦，可以用cockpit.misc.print工具来模拟协议帧。它在 src/cockpit/misc/print.py 中实现：Printer.json()负责把 JSON 消息打包成"长度前缀 + channel 名 + 载荷"的帧格式，Printer.control()发送控制消息，还有open、data等便捷方法。例如打开一个fsinfochannel 读取/etc目录：

PYTHONPATH=src python3 -m cockpit.misc.print open fsinfo path=/etc 'attrs=["type", "entries"]' | PYTHONPATH=src python3 -m cockpit.bridge

两个便于实验协议的 shell 别名：

alias cpy='PYTHONPATH=src python3 -m cockpit.bridge' alias cpf='PYTHONPATH=src python3 -m cockpit.misc.print'

例如跑一个内部 metrics channel，每隔 1000ms 上报一次 CPU 使用率：

cpf open metrics1 source=internal interval=1000 metrics='[{"name": "cpu.basic.user", "derive": "rate"}]' : wait | cpy

在测试镜像上启用 journal 调试日志，可以在image-prepare时传--debug，它会把COCKPIT_DEBUG=all写入/etc/environment；如果只想看 channel 级调试消息，把all改成cockpit.channel。

借助 ws 容器迭代 Bridge

fedora-coreos 与 -bootc 镜像用cockpit/ws容器替代cockpit-bridge.rpm。要做 "改 Bridge → 跑集成测试" 的快速循环，可以修改 test/common/testlib.py 的MachineCase.login_and_go()，把本地开发树的 bridge 代码上传进 VM，再拷入运行中的容器并 bind-mount 到正确路径：

--- test/common/testlib.py +++ test/common/testlib.py @@ -1933,6 +1933,14 @@ class MachineCase(unittest.TestCase): if enable_root_login: self.enable_root_login() self.machine.start_cockpit(tls=tls) + + m = self.machine + m.execute("umount /usr/lib/python3.14/site-packages/cockpit || true") + m.upload(["../src/cockpit"], "/tmp/") + m.execute("podman cp /tmp/cockpit ws:/tmp/") + m.execute("podman exec ws mount -o bind /tmp/cockpit /usr/lib/python3.14/site-packages/cockpit") + # first load after starting cockpit tends to take longer, due to on-demand service start with self.browser.wait_timeout(30): self.browser.login_and_go(path, user=user, password=password, host=host, superuser=superuser,

其中3.14需要替换为当时的 Python 版本。

测试 Bridge

针对 bridge 代码的 pytest 测试在持续增加，用以下命令运行：

make pytest # 或 make pytest-cov

这两个 make 规则的作用是确保在源码目录运行 pytest 前，先检出systemd_ctypes子模块。测试至少需要 pytest 7.0.0 以上版本。

代码风格检查：ESLint 与 Stylelint

ESLint

Cockpit 用 ESLint 自动检查.js与.jsx文件的代码风格，它是test/common/static-code的一部分。也可以显式运行：

npm run eslint # 检查 npm run eslint:fix # 自动修复大部分违规

从 package.json 可以看到，eslint脚本实际执行的是对pkg/与test/common/下.js/.jsx/.ts/.tsx文件的检查。规则配置位于.eslintrc.json。在快速迭代时，可以用./build.js的-e/--no-eslint选项跳过 ESLint，加快构建并避免因格式不当的注释、未使用的标识符等导致构建失败。

Stylelint

类似地，Cockpit 用 Stylelint 检查.css与.scss文件风格：

npm run stylelint # 检查 npm run stylelint:fix # 自动修复部分违规

注意npm run stylelint只覆盖pkg/下的文件，而test/common/static-code覆盖 git 跟踪的全部(S)CSS 文件。规则配置位于.stylelintrc.json。快速迭代时可使用./build.js的-s/--no-stylelint选项跳过检查。

在本机安全地测试改动：systemd-sysext

如果你想直接在本地机器上安全地测试改动，Cockpit 支持以 systemd-sysext 方式安装。它覆盖 Cockpit 的所有部分（ws、tls、session、bridge、登录页、systemd unit、PAM 配置、会话页面），唯独不含 SELinux 策略。由于安装到/run/extensions/（内存文件系统），不会写盘，也适用于只读安装（CoreOS、OSTree、bootc）。

一行命令搞定：

tools/make-sysext

从 tools/make-sysext 源码可见：脚本按发行版选择 PAM 配置（Fedora/CentOS/RHEL 用 tools/cockpit.pam，Debian/Ubuntu 用 tools/cockpit.debian.pam，Arch 用 tools/arch/cockpit.pam），必要时先运行./autogen.sh，然后make install DESTDIR=tmp/sysext装到临时目录，再拷贝到/run/extensions/cockpit-git并执行systemd-sysext refresh，最后启动cockpit.socket。完成后访问http://localhost:9090即可。

卸载只需重启，或运行：

tools/make-sysext stop

注意：该方式目前与 enforcing 模式下的 SELinux 不兼容，如有需要请先禁用：

sudo setenforce 0

本机 Web 服务器联调：bind mount 方案

如果 sysext 方案不可行，还可以用 bind mount 测试改动。

测试登录页改动——把构建树dist/覆盖到系统目录：

sudo mount -o bind dist /usr/share/cockpit

测试品牌（branding）改动：

sudo mount -o bind src/branding/ /usr/share/cockpit/branding/

如果两条命令同时执行，需要先mkdir dist/branding。之后执行systemctl stop cockpit.service，确保下次浏览器请求时 Web 服务器重启加载新文件。恢复系统安装版本：

sudo umount /usr/share/cockpit /usr/share/cockpit/branding/ systemctl stop cockpit.service

改动cockpit-ws本身时，可以让 systemd（unit、cockpit-tls 等）使用你的构建产物：

sudo mount -o bind cockpit-ws /usr/libexec/cockpit-ws

Debian 系（含 Ubuntu）的路径是/usr/lib/cockpit/cockpit-ws。在 Fedora、CentOS、RHEL 及相关发行版上，由于本地构建树没有预期的 SELinux 类型，还需要先sudo setenforce 0。

另外，部分 cockpit 二进制依赖/usr/share或 libexecdir 下的特定路径，默认值被设为/usr/local。RPM 系系统可通过 autogen.sh 参数设置，之后需要重新构建：

./autogen.sh rpm

从 autogen.sh 源码可见，rpm参数会走rpmbuild --build-in-place -bc tools/cockpit.spec分支，用与构建 RPM 相同的 flag 进行配置。

从上游源码安装与构建发行包

直接安装：

make sudo make install

这会安装 Cockpit 及所有支持文件。Fedora/RHEL/CentOS 系还需安装 PAM 配置：

sudo cp tools/cockpit.pam /etc/pam.d/cockpit

Debian/Ubuntu 系安装对应配置：

sudo cp tools/cockpit.debian.pam /etc/pam.d/cockpit

其他发行版需要自行创建 PAM 配置。如果想安装到其他--prefix且希望make install不写入 prefix 之外，可给autogen.sh指定--enable-prefix-only选项（得到的是不经调整无法运行的安装，仅供高级用户使用）。

相比直接make install，构建发行包通常更健壮——升级/卸载干净，且不会与/usr中的发行版包冲突：

# Fedora/RHEL 构建环境：二进制 RPM tools/make-rpms --quick # Debian/Ubuntu 构建环境：deb 包 tools/make-debs --quick

管理 node_modules

git 检出后的常规构建会自动从一个独立的 git 仓库缓存的node_modules解包。可以强制解包：

tools/node-modules checkout

通常无需手动执行。如果需要修改package.json（例如安装新模块），则要运行tools/node-modules install，从新package.json执行npm install的结果创建新缓存。你本地对node_modules的重建不会被其他人使用——打开 PR 后由 GitHub workflow 生成新版本。

tools/node-modules脚本会检查GITHUB_BASE环境变量以确定拉取/推送的目标仓库：它去掉仓库名（保留项目/用户名），使用该命名空间下的node-cache.git；若GITHUB_BASE未设置，则默认cockpit-project/node-cache.git。本地缓存维护在~/.cache/cockpit-dev。

贡献一个变更：PR 工作流与发布说明

Pull Request 流程

在 github.com 上为你的改动发起 Pull Request，所有变更都会经过评审、测试与迭代。整体工作流在项目 wiki 中描述。你需要熟悉 git：在分支上工作，每个 commit 只包含一个单一、逻辑简单、可评审的变更，且不得包含与 commit message 无关的修改。

评审中来回修改是常态。评审意见下来后，直接force-push 到你的分支即可自动更新 PR——不要关闭旧 PR 再开新的，那会丢失对话与评审记录。

Cockpit 是一个有设计流程的项目：凡是用户可见的东西，都要先完成设计（在 wiki 和邮件列表上进行）。较大的改动建议先在#cockpit:fedoraproject.orgMatrix 频道或cockpit-devel@lists.fedoraproject.org邮件列表讨论，避免投入过多精力后才返工。功能变更应附上视频和/或截图，视频可直接上传到 GitHub 的 PR/issue，或上传到允许嵌入的服务。

录制包含浏览器边框的视频示例（仅 X11，需要recordmydesktop）：

recordmydesktop -x 1 -y 200 --width 1024 --height 576 \ --fps 24 --freq 44100 --v_bitrate 2000000

也可以先调整浏览器窗口位置再录屏——Firefox 中打开 Scratchpad（Shift+F4）输入：

window.resizeTo(1024, 576); window.moveTo(1, 200);

在浏览器显示空标签页（如about:newtab）时用Ctrl+R运行，坐标可按环境调整。

在 PR 中附带 release note

Cockpit 有一套自动化的 release note 流程：任何带release-note标签且描述中包含 release note 片段的 PR，其内容会被用于生成 cockpit-project.org 的发布博客。格式要求是在 PR 描述末尾加一个 h2 标题，标题之下的所有内容（含上传的图片、视频）都会被自动化抓取，例如：

[...truncated PR description...] ## Release note title Release note text that will be picked up by automation <img for release note>

调试日志体系

系统侧：journal 与 G_MESSAGES_DEBUG

Cockpit 各进程的消息都写入 journal，可实时查看：

sudo journalctl -f

Cockpit Web 服务器有冗长的内部调试日志，排查问题时可按如下步骤开启：

sudo mkdir -p /etc/systemd/system/cockpit-wsinstance-http.service.d sudo sh -c 'printf "[Service]\nEnvironment=G_MESSAGES_DEBUG=all\n" > /etc/systemd/system/cockpit-wsinstance-http.service.d/debug.conf' sudo systemctl daemon-reload sudo systemctl stop cockpit

除all外，也可以指定具体日志域（log domain）：

• cockpit-protocol：极详细的底层流量日志
• cockpit-ws：Cockpit Web 服务的详细调试消息
• WebSocket：底层 WebSocket 详细日志

撤销以上改动：

sudo rm /etc/systemd/system/cockpit-wsinstance-http.service.d/debug.conf sudo systemctl daemon-reload sudo systemctl stop cockpit

调试 HTTPS 连接时，把上面命令中的http换成https@。注意bridge 运行在用户会话而非 systemd 服务中，其调试日志开启方式见前文 "Running the bridge" 一节（COCKPIT_DEBUG环境变量）。

前端：window.debugging 与浏览器存储

Cockpit 的多个 JavaScript 方法支持调试消息，通过设置全局window.debugging或浏览器存储中的debugging属性开启。在 JS 控制台执行：

>> sessionStorage.debugging = "all"

这会输出大量消息；更精细的取值如下：

"all" // 所有可用调试消息 "channel" // 发往服务器的所有 channel 消息 "dbus" // DBus 相关调试消息 "http" // HTTP（经由服务器）相关调试消息 "spawn" // 与执行进程相关的调试消息

还有与具体代码相关的取值，例如 metrics 页面用metrics显示调试信息。在仓库中执行git grep window.debugging pkg即可找到全部可用取值——实测 pkg/apps/utils.tsx、pkg/lib/cockpit/_internal/common.ts 等文件中都有使用。

如果希望调试设置在浏览器刷新或 Cockpit 登出后依然生效，用 localStorage：

>> localStorage.debugging = "spawn"

使用 React Developer Tools

Cockpit 前端使用 React。由于页面加载在独立的 iframe 中，React Developer Tools 开箱即用无法检查组件。解决办法是直接内嵌加载页面，例如系统概览页：

http://localhost:9090/cockpit/@localhost/system/index.html

这会以独立页面加载系统概览，从而允许 React Developer Tools 检查其 state。

在调试器下运行 Cockpit 进程

可以以普通用户身份在 gdb 或 valgrind 下运行 cockpit-ws，但这样无法调试全部认证逻辑。前提是 Cockpit 已正确安装——虽然我们从构建树运行cockpit-ws，但仍依赖正确的系统软件（PAM 栈、UI 文件、cockpit-bridge 等）。

gdb 下运行：

export G_DEBUG=fatal-criticals export G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper,cockpit-bridge gdb --args ./cockpit-ws --port 10000 --no-tls

valgrind 下运行 cockpit-ws 与 cockpit-bridge：

export G_DEBUG=fatal-criticals export G_MESSAGES_DEBUG=cockpit-ws,cockpit-wrapper,cockpit-bridge valgrind --trace-children=yes --trace-children-skip='*unix_chkpwd*' \ ./cockpit-ws --port 10000 --no-tls

注意 cockpit-session 与 cockpit-bridge 会从已安装的 prefix 运行，而不是你的构建树。

调试难以捕获的 UI 元素

大多数场景可以直接用浏览器调试器给感兴趣的元素打断点，但对弹出菜单等响应mouseenter/mouseleave的元素行不通。技巧是在开发者控制台运行：

setTimeout(() => { debugger }, 5000)

然后执行鼠标操作（如悬停），等待超时触发断点即可。

用 curl 手动建立登录会话与 WebSocket

迭代登录 / websocket ←→ bridge 集成时，下面这条命令会登录标准的测试 VM（https://127.0.0.2:9091）并建立 websocket 连接与用户会话：

curl -ksS -D- -u admin:foobar --cookie-jar /tmp/cookie https://127.0.0.2:9091/cockpit/login --no-buffer -H"Connection: Upgrade" -H"Upgrade: websocket" -H"Host: 127.0.0.2:9091" -H"Origin: https://127.0.0.2:9091" -H"Sec-Websocket-Key: 3sc2c9IzwRUc3BlSIYwtSA==" -H"Sec-WebSocket-Version: 13" https://127.0.0.2:9091/cockpit/socket

返回类似：

{"csrf-token":"e3074fc5e06cb3804ad8c3463fc6727c67ac245dd3c39590e486644759a42818"}HTTP/1.1 101 Switching Protocols

其中的 csrf-token 就是会话令牌。可用--cookie-jar继续发起需要认证的 HTTP 请求。注意由于没有浏览器保持连接，会话在约 10 秒不活跃后超时。

手动安装开发依赖（备用方案）

如果可能，请优先使用上文 toolbox/distrobox +cockpit/tasks容器方案。在主机手动安装全部开发依赖侵入性强、易出错、难调试。以下仅作备用。

至少需要 node.js 与 npm：

# Fedora/CentOS (>= 9) sudo dnf install npm # Debian/Ubuntu sudo apt install npm

运行测试所需依赖：

sudo dnf install curl expect xz rpm-build chromium-headless dbus-daemon \ libvirt-daemon-driver-storage-core libvirt-daemon-driver-qemu libvirt-client python3-libvirt \ python3-pyyaml

编译 C 部分需要包的构建依赖：

sudo dnf install dnf-utils python-srpm-macros sudo dnf builddep --spec tools/cockpit.spec

延伸阅读

• 集成测试的完整说明见 test/README.md：包括test/image-prepare准备镜像、test/verify/check-metrics TestCurrentMetrics.testCPU运行单个用例、TEST_OS/TEST_BROWSER/TEST_SHOW_BROWSER等环境变量、@nondestructive测试约定、bots/vm-run手动测试，以及像素测试（pixel tests）的更新流程；架构细节在 test/ARCHITECTURE.md。
• Bridge 所讲 JSON 协议 的完整规范，可对照 src/cockpit/protocol.py 中的CockpitProblem等协议实现一起阅读。
• 构建脚本 build.js 与 autogen.sh 是理解构建流程的第一手材料；package.json 定义了全部 lint 与测试脚本。

【免费下载链接】cockpitCockpit is a web-based graphical interface for servers.项目地址: https://gitcode.com/gh_mirrors/co/cockpit