CodeWhale 腾讯云轻量服务器LighthouseCNB 发布与部署指南从 GitHub 单向镜像到一键部署按钮【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale导读本文以仓库deploy/tencent-lighthouse/cnb/目录下的部署文档为主线讲解 CodeWhale 如何把「GitHub 源码 → CNBcnb.cool镜像与 CI → 腾讯云轻量服务器Tencent Lighthouse」这条远端运行remote-first路径以流水线与部署按钮方式打通。读完本文你将掌握根目录.cnb.yml单向镜像的维护铁律、v*标签触发的 Linux x64 发布资产流水线、CNB 机密变量的配置清单以及如何在已手工就绪的 Lighthouse 实例上启用一键部署按钮。适用前提本文描述的是当前仓库中真实存在的部署管线与模板文件部署对象是维护方maintainer已通过自有服务端流程装好运行目录、环境文件与 systemd 服务的 Lighthouse 实例。一、为什么根目录的.cnb.yml必须放在 GitHub 仓库里CNB 从 GitHub 仓库做单向镜像one-way mirrorGitHub 侧的内容会被定期/按事件同步到 CNB而 CNB 侧的改动会在下一次同步时被覆盖。因此仓库根目录的 .cnb.yml 被刻意纳入 GitHub 版本控制不得只改 CNB 侧的.cnb.yml否则下一次 GitHub 同步会直接覆盖你的修改需要调整发布/CI 流水线时一律修改 GitHub 上的根文件让镜像机制把它带到 CNB。这正是 README 中「当前生效的根.cnb.yml做两件事」的前提也是deploy/tencent-lighthouse/cnb/cnb.yml.example被标注为 Historical历史模板的原因早期管线配置曾直接放在该目录下如今主流水线已上移到仓库根目录避免 GitHub → CNB 镜像把「仅存在于 CNB 的管线编辑」抹掉。二、当前生效的根.cnb.yml它实际负责什么阅读仓库根目录 .cnb.yml 可以看到当前生效的流水线比 README 概括的职责更细2.1main分支 pushCI 与门禁当 CNB 收到main分支的推送时流水线并行执行事件内容说明main: pushFeishu bridge 测试进入integrations/feishu-bridge执行npm ci、npm run check、npm test对应 README 所述 runs Feishu bridge ... checksmain: pushRust workspace 门禁运行./scripts/release/check-versions.sh、cargo fmt --check、cargo clippy -D warnings、全 workspacecargo test以及codewhale-protocol/codewhale-state的 parity 测试并在endStages通过scripts/ci/cnb-github-checkrun.mjs把 CNB 判定以-cnb后缀 shadow Check Run 回报到 GitHubREADME 中的 version-drift checks 即版本漂移校验实现在check-versions.sh中2.2v*标签 push构建 Linux x64 发布资产并创建 CNB ReleaseREADME 中描述的「builds Linux x64 release assets fromv*tags, creates the CNB release, and uploads ...」在根 .cnb.yml 中由$: tag_push阶段完成安装musl-tools并添加x86_64-unknown-linux-musl目标随后cargo build --release --target x86_64-unknown-linux-musl -p codewhale-cli做静态全 LTO 单二进制构建把同一个可执行文件复制为三个发布文件名codewhale-linux-x64当前主命令codew-linux-x64主命令的codew名字codewhale-tui-linux-x64README 与流水线注释中明确的v0.9.4 兼容别名仅供旧安装兼容使用strip后用sha256sum生成codewhale-artifacts-sha256.txt从 CHANGELOG.md 抽取对应## [vX.Y.Z]段落生成CNB_RELEASE.md并做「标签版本 Cargo.toml 版本」的一致性校验创建 CNB Releaselatest: true上传上述 4 个文件作为附件。一句话总结README 里说的根.cnb.yml两件事落到代码上是main 门禁 标签发布两条互补路径。三、cnb/目录的角色Lightning 部署按钮模板仓库内 deploy/tencent-lighthouse/cnb/ 目录保留的文件是面向**腾讯云轻量服务器Tencent Lighthouse**的部署按钮模板目录内容为文件作用README.md部署说明即本文主体文档tag_deploy.yml.example部署按钮的环境environment定义模板cnb.yml.example历史 CNB 管线模板展示web_trigger_lighthouse部署阶段的完整 SSH 部署脚本3.1 什么时候需要这些模板README 强调在 Lighthouse 实例已经手工跑通之后才复制部署环境文件。也就是说模板不负责从零建服务器只负责把已经就绪的实例纳入可重复触发的部署流程。启用步骤只有两条命令mkdir -p .cnb cp deploy/tencent-lighthouse/cnb/tag_deploy.yml.example .cnb/tag_deploy.yml这里的.cnb/是 CNB 侧才有的目录用来放置只存在于 CNB 的部署环境定义——它与根.cnb.yml不同不属于镜像内容因此可以也只能在 CNB 侧维护。如果你还需要定制.cnb.yml本身仍然要回到 GitHub 编辑根文件让单向镜像把它带到 CNB。3.2 部署按钮定义的结构复制后得到的.cnb/tag_deploy.yml内容对应 tag_deploy.yml.example结构如下environments: - name: lighthouse-hk description: Deploy CodeWhale to Tencent Lighthouse Hong Kong. env: name: lighthouse-hk button: - name: Deploy Lighthouse description: Update /opt/whalebro/codewhale, restart services, and run the Lighthouse doctor. event: web_trigger_lighthouse isDefault: true permissions: roles: - master要点解读environments[].name: lighthouse-hk示例命名提示该环境对应香港地域的轻量服务器可替换为你自己的地域/实例命名button.event: web_trigger_lighthouse部署按钮触发的事件名它必须与历史模板cnb.yml.example中的web_trigger_lighthouse阶段名对应见下文第五节isDefault: true该按钮被标记为默认一键部署入口permissions.roles: [master]只有仓库 master 角色的成员可点击降低误触风险。README 中的提示「Start with a manual deploy button」正是针对该按钮先用人工点击的方式验证整条链路再考虑后续是否配置每次mainpush 的自动部署。四、CNB 侧必须配置的机密变量部署阶段运行在 CNB 构建容器里而部署动作需要通过 SSH 登录 Lighthouse。因此 README 要求把这些变量配置为CNB 的受保护环境变量或 Secrets变量是否必需说明LIGHTHOUSE_HOST必需Lighthouse 实例的公网 IP 或 DNS 名称LIGHTHOUSE_SSH_TARGET必需SSH 登录目标例如ubuntu203.0.113.10LIGHTHOUSE_SSH_PRIVATE_KEY必需允许更新服务器的私有部署密钥deploy keyCODEWHALE_REPO_BRANCH必需要部署的分支或标签例如mainCODEWHALE_REPO_URL可选默认值为 CNB 镜像仓库地址https://cnb.cool/codewhale.net/codewhale.gitLIGHTHOUSE_SSH_PORT可选默认22从历史模板 cnb.yml.example 的脚本开头可以看出这些变量的强制检查方式不满足即中止例如: ${LIGHTHOUSE_HOST:?Set LIGHTHOUSE_HOST in CNB secrets} : ${LIGHTHOUSE_SSH_TARGET:?Set LIGHTHOUSE_SSH_TARGET in CNB secrets} : ${LIGHTHOUSE_SSH_PRIVATE_KEY:?Set LIGHTHOUSE_SSH_PRIVATE_KEY in CNB secrets}以及可选变量的默认值兜底LIGHTHOUSE_SSH_PORT${LIGHTHOUSE_SSH_PORT:-22} CODEWHALE_REPO_BRANCH${CODEWHALE_REPO_BRANCH:-main} CODEWHALE_REPO_URL${CODEWHALE_REPO_URL:-https://cnb.cool/codewhale.net/codewhale.git}五、部署按钮背后到底执行了什么虽然 README 正文没有展开脚本但仓库里的历史模板 cnb.yml.example 完整保留了web_trigger_lighthouse阶段的部署逻辑可作为点击按钮后发生了什么的权威依据。整体分三段5.1 构建容器侧的 SSH 准备if ! command -v ssh /dev/null 21 || ! command -v ssh-keyscan /dev/null 21; then apt-get update apt-get install -y openssh-client fi install -m 700 -d ~/.ssh printf %s\n $LIGHTHOUSE_SSH_PRIVATE_KEY ~/.ssh/id_ed25519 chmod 600 ~/.ssh/id_ed25519 ssh-keyscan -p $LIGHTHOUSE_SSH_PORT -H $LIGHTHOUSE_HOST ~/.ssh/known_hosts先探测容器内是否已有ssh/ssh-keyscan缺失时安装openssh-client用LIGHTHOUSE_SSH_PRIVATE_KEY落地私钥默认按 Ed25519 处理权限收紧为600用ssh-keyscan把主机指纹写入known_hosts配合-H做哈希化避免首次登录的指纹交互卡住流水线。5.2 远端 git 更新先拒绝脏检出再快进/切标签通过ssh携带环境变量执行远端 heredoc 脚本核心是保护/opt/whalebro/codewhale这个运行检出目录if [ ! -d /opt/whalebro/codewhale/.git ]; then sudo -u codewhale git clone --branch $CODEWHALE_REPO_BRANCH $CODEWHALE_REPO_URL /opt/whalebro/codewhale fi cd /opt/whalebro/codewhale if [ -n $(sudo -u codewhale git status --porcelain) ]; then echo Refusing to deploy over a dirty /opt/whalebro/codewhale checkout. 2 sudo -u codewhale git status --short exit 1 fi随后依据CODEWHALE_REPO_BRANCH的值做三种分支切换若远端存在同名分支refs/remotes/origin/branchgit checkout -B branch origin/branch快进对齐若存在同名标签refs/tags/branchgit checkout --detach branch切换到标签的游离 HEAD否则直接git checkout该引用并git pull --ff-only仅快进拒绝合并式拉取。5.3 编译、安装与重启服务sudo -iu codewhale bash -lc set -euo pipefail . $HOME/.cargo/env cd /opt/whalebro/codewhale cargo install --path crates/cli --locked --force ln -sf codewhale $HOME/.cargo/bin/codew 以codewhale系统用户身份、锁定--locked依赖并--force安装 crates/cli 工作区成员产出codewhale主命令通过ln -sf让codew命令软链指向codewhale与第四节发布资产中codew-linux-x64的命名相互印证最后重启 systemd 服务并做健康检查调用维护方工具scripts/tencent-lighthouse/install-services.sh与doctor.sh。注意这两个脚本属于维护方自有服务端流程的一部分当前仓库快照中并未包含实际使用时应以你的 Lighthouse 实例上已就绪的服务端工具为准。部署方向提示该脚本在远端服务器上cargo install编译安装的是构建容器里的 CNB 镜像/流水线所对应的源码版本而不是上传已构建好的 musl 二进制与根.cnb.yml的tag_push发布路线用途不同一条走源码部署到服务器一条走构建发布资产到 CNB Release。六、Lighthouse 服务端应已就绪的组成部分README 明确指出服务端应该已经由维护方装好运行检出、环境文件与 systemd 服务。仓库内保留了这些文件的可对照参考6.1 systemd 服务单元codewhale-runtime.service以codewhale用户运行 CLI 的 HTTP 服务端ExecStart调用codewhale serve --http --host 127.0.0.1 --port ... --workers ... --auth-token ...。这是runtime checkout、systemd services中 runtime 侧的核心codewhale-feishu-bridge.service飞书Feishu/Lark手机桥接Wants/After依赖codewhale-runtime.servicecodewhale-telegram-bridge.serviceTelegram 手机桥接同样依赖 runtime。三个单元都体现了 README「/etc/codewhale 优先」的原则EnvironmentFile-/etc/deepseek/*.env先加载兼容旧安装EnvironmentFile-/etc/codewhale/*.env后加载并覆盖。6.2 环境文件模板runtime.env.exampleCODEWHALE_RUNTIME_TOKEN、CODEWHALE_RUNTIME_PORT7878、CODEWHALE_RUNTIME_WORKERS2、CODEWHALE_PROVIDERdeepseek等feishu-bridge.env.exampleFEISHU_APP_ID/FEISHU_APP_SECRET并引用CODEWHALE_RUNTIME_URLhttp://127.0.0.1:7878、相同的CODEWHALE_RUNTIME_TOKEN等telegram-bridge.env.exampleTELEGRAM_BOT_TOKEN等。从部署按钮的descriptionUpdate/opt/whalebro/codewhale, restart services, and run the Lighthouse doctor与 systemd 单元可见服务端布局为运行检出在/opt/whalebro/codewhale运行目录在/opt/whalebro令牌密钥类环境文件在/etc/codewhale/*.env桥接状态写入/var/lib/codewhale-*-bridge/。七、三条必须遵守的安全红线README 用 Safety Notes 明确提出以下运维纪律部署前务必逐条核对不要把飞书 App Secret 或模型供应商 API Key 放进 CNB。这些机密属于 Lighthouse 服务器上的/etc/codewhale/*.env对应仓库内的 runtime.env.example 等模板其中DEEPSEEK_API_KEY、FEISHU_APP_SECRET等字段应只存在于服务器侧。CNB 只保存连接服务器所需的 SSH 相关机密不要让127.0.0.1:7878暴露到公网。systemd 单元中codewhale serve --host 127.0.0.1绑定回环地址该端口是 runtime 内部 API不要通过 EdgeOne、安全组或公共反向代理对外暴露它桥接进程通过CODEWHALE_RUNTIME_URLhttp://127.0.0.1:7878走本机访问先用人工部署按钮再考虑自动部署。每次mainpush 都自动部署虽然方便但会消耗 CNB 配额且可能在对话轮次进行中重启手机桥接服务bridge 单元与 runtime 是独立进程重启会中断进行中的远端会话。八、总结一条可复制的远端服务器一键部署范式回顾整条链路CodeWhale 的腾讯云轻量服务器 CNB 部署方案可以归纳为清晰的三层范式GitHub 是唯一真相源根 .cnb.yml 源控在 GitHub利用 CNB 单向镜像同步保证 CI 门禁与发布流水线可审计、可回滚CNB 承接 CI/发布/部署触发mainpush 跑门禁v*tag 构建并发布 Linux x64 资产web_trigger_lighthouse事件承载部署按钮Lighthouse 只做已就绪实例的更新服务端预置 systemd 单元与/etc/codewhale/*.env部署脚本只负责 git 更新、cargo install、软链codew、重启服务与 doctor 检查。对于希望复用这套方案的团队最小实践路径是先在服务器上手工跑通 runtime 与手机桥接参照 systemd 单元 与 env 示例再在 GitHub 侧维护好根.cnb.yml最后在 CNB 上配置四个必需 Secrets 并复制 tag_deploy.yml.example 到.cnb/tag_deploy.yml——从此更新远端 CodeWhale就退化为一次点击。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
CodeWhale 腾讯云轻量服务器（Lighthouse）CNB 发布与部署指南：从 GitHub 单向镜像到一键部署按钮
CodeWhale 腾讯云轻量服务器LighthouseCNB 发布与部署指南从 GitHub 单向镜像到一键部署按钮【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale导读本文以仓库deploy/tencent-lighthouse/cnb/目录下的部署文档为主线讲解 CodeWhale 如何把「GitHub 源码 → CNBcnb.cool镜像与 CI → 腾讯云轻量服务器Tencent Lighthouse」这条远端运行remote-first路径以流水线与部署按钮方式打通。读完本文你将掌握根目录.cnb.yml单向镜像的维护铁律、v*标签触发的 Linux x64 发布资产流水线、CNB 机密变量的配置清单以及如何在已手工就绪的 Lighthouse 实例上启用一键部署按钮。适用前提本文描述的是当前仓库中真实存在的部署管线与模板文件部署对象是维护方maintainer已通过自有服务端流程装好运行目录、环境文件与 systemd 服务的 Lighthouse 实例。一、为什么根目录的.cnb.yml必须放在 GitHub 仓库里CNB 从 GitHub 仓库做单向镜像one-way mirrorGitHub 侧的内容会被定期/按事件同步到 CNB而 CNB 侧的改动会在下一次同步时被覆盖。因此仓库根目录的 .cnb.yml 被刻意纳入 GitHub 版本控制不得只改 CNB 侧的.cnb.yml否则下一次 GitHub 同步会直接覆盖你的修改需要调整发布/CI 流水线时一律修改 GitHub 上的根文件让镜像机制把它带到 CNB。这正是 README 中「当前生效的根.cnb.yml做两件事」的前提也是deploy/tencent-lighthouse/cnb/cnb.yml.example被标注为 Historical历史模板的原因早期管线配置曾直接放在该目录下如今主流水线已上移到仓库根目录避免 GitHub → CNB 镜像把「仅存在于 CNB 的管线编辑」抹掉。二、当前生效的根.cnb.yml它实际负责什么阅读仓库根目录 .cnb.yml 可以看到当前生效的流水线比 README 概括的职责更细2.1main分支 pushCI 与门禁当 CNB 收到main分支的推送时流水线并行执行事件内容说明main: pushFeishu bridge 测试进入integrations/feishu-bridge执行npm ci、npm run check、npm test对应 README 所述 runs Feishu bridge ... checksmain: pushRust workspace 门禁运行./scripts/release/check-versions.sh、cargo fmt --check、cargo clippy -D warnings、全 workspacecargo test以及codewhale-protocol/codewhale-state的 parity 测试并在endStages通过scripts/ci/cnb-github-checkrun.mjs把 CNB 判定以-cnb后缀 shadow Check Run 回报到 GitHubREADME 中的 version-drift checks 即版本漂移校验实现在check-versions.sh中2.2v*标签 push构建 Linux x64 发布资产并创建 CNB ReleaseREADME 中描述的「builds Linux x64 release assets fromv*tags, creates the CNB release, and uploads ...」在根 .cnb.yml 中由$: tag_push阶段完成安装musl-tools并添加x86_64-unknown-linux-musl目标随后cargo build --release --target x86_64-unknown-linux-musl -p codewhale-cli做静态全 LTO 单二进制构建把同一个可执行文件复制为三个发布文件名codewhale-linux-x64当前主命令codew-linux-x64主命令的codew名字codewhale-tui-linux-x64README 与流水线注释中明确的v0.9.4 兼容别名仅供旧安装兼容使用strip后用sha256sum生成codewhale-artifacts-sha256.txt从 CHANGELOG.md 抽取对应## [vX.Y.Z]段落生成CNB_RELEASE.md并做「标签版本 Cargo.toml 版本」的一致性校验创建 CNB Releaselatest: true上传上述 4 个文件作为附件。一句话总结README 里说的根.cnb.yml两件事落到代码上是main 门禁 标签发布两条互补路径。三、cnb/目录的角色Lightning 部署按钮模板仓库内 deploy/tencent-lighthouse/cnb/ 目录保留的文件是面向**腾讯云轻量服务器Tencent Lighthouse**的部署按钮模板目录内容为文件作用README.md部署说明即本文主体文档tag_deploy.yml.example部署按钮的环境environment定义模板cnb.yml.example历史 CNB 管线模板展示web_trigger_lighthouse部署阶段的完整 SSH 部署脚本3.1 什么时候需要这些模板README 强调在 Lighthouse 实例已经手工跑通之后才复制部署环境文件。也就是说模板不负责从零建服务器只负责把已经就绪的实例纳入可重复触发的部署流程。启用步骤只有两条命令mkdir -p .cnb cp deploy/tencent-lighthouse/cnb/tag_deploy.yml.example .cnb/tag_deploy.yml这里的.cnb/是 CNB 侧才有的目录用来放置只存在于 CNB 的部署环境定义——它与根.cnb.yml不同不属于镜像内容因此可以也只能在 CNB 侧维护。如果你还需要定制.cnb.yml本身仍然要回到 GitHub 编辑根文件让单向镜像把它带到 CNB。3.2 部署按钮定义的结构复制后得到的.cnb/tag_deploy.yml内容对应 tag_deploy.yml.example结构如下environments: - name: lighthouse-hk description: Deploy CodeWhale to Tencent Lighthouse Hong Kong. env: name: lighthouse-hk button: - name: Deploy Lighthouse description: Update /opt/whalebro/codewhale, restart services, and run the Lighthouse doctor. event: web_trigger_lighthouse isDefault: true permissions: roles: - master要点解读environments[].name: lighthouse-hk示例命名提示该环境对应香港地域的轻量服务器可替换为你自己的地域/实例命名button.event: web_trigger_lighthouse部署按钮触发的事件名它必须与历史模板cnb.yml.example中的web_trigger_lighthouse阶段名对应见下文第五节isDefault: true该按钮被标记为默认一键部署入口permissions.roles: [master]只有仓库 master 角色的成员可点击降低误触风险。README 中的提示「Start with a manual deploy button」正是针对该按钮先用人工点击的方式验证整条链路再考虑后续是否配置每次mainpush 的自动部署。四、CNB 侧必须配置的机密变量部署阶段运行在 CNB 构建容器里而部署动作需要通过 SSH 登录 Lighthouse。因此 README 要求把这些变量配置为CNB 的受保护环境变量或 Secrets变量是否必需说明LIGHTHOUSE_HOST必需Lighthouse 实例的公网 IP 或 DNS 名称LIGHTHOUSE_SSH_TARGET必需SSH 登录目标例如ubuntu203.0.113.10LIGHTHOUSE_SSH_PRIVATE_KEY必需允许更新服务器的私有部署密钥deploy keyCODEWHALE_REPO_BRANCH必需要部署的分支或标签例如mainCODEWHALE_REPO_URL可选默认值为 CNB 镜像仓库地址https://cnb.cool/codewhale.net/codewhale.gitLIGHTHOUSE_SSH_PORT可选默认22从历史模板 cnb.yml.example 的脚本开头可以看出这些变量的强制检查方式不满足即中止例如: ${LIGHTHOUSE_HOST:?Set LIGHTHOUSE_HOST in CNB secrets} : ${LIGHTHOUSE_SSH_TARGET:?Set LIGHTHOUSE_SSH_TARGET in CNB secrets} : ${LIGHTHOUSE_SSH_PRIVATE_KEY:?Set LIGHTHOUSE_SSH_PRIVATE_KEY in CNB secrets}以及可选变量的默认值兜底LIGHTHOUSE_SSH_PORT${LIGHTHOUSE_SSH_PORT:-22} CODEWHALE_REPO_BRANCH${CODEWHALE_REPO_BRANCH:-main} CODEWHALE_REPO_URL${CODEWHALE_REPO_URL:-https://cnb.cool/codewhale.net/codewhale.git}五、部署按钮背后到底执行了什么虽然 README 正文没有展开脚本但仓库里的历史模板 cnb.yml.example 完整保留了web_trigger_lighthouse阶段的部署逻辑可作为点击按钮后发生了什么的权威依据。整体分三段5.1 构建容器侧的 SSH 准备if ! command -v ssh /dev/null 21 || ! command -v ssh-keyscan /dev/null 21; then apt-get update apt-get install -y openssh-client fi install -m 700 -d ~/.ssh printf %s\n $LIGHTHOUSE_SSH_PRIVATE_KEY ~/.ssh/id_ed25519 chmod 600 ~/.ssh/id_ed25519 ssh-keyscan -p $LIGHTHOUSE_SSH_PORT -H $LIGHTHOUSE_HOST ~/.ssh/known_hosts先探测容器内是否已有ssh/ssh-keyscan缺失时安装openssh-client用LIGHTHOUSE_SSH_PRIVATE_KEY落地私钥默认按 Ed25519 处理权限收紧为600用ssh-keyscan把主机指纹写入known_hosts配合-H做哈希化避免首次登录的指纹交互卡住流水线。5.2 远端 git 更新先拒绝脏检出再快进/切标签通过ssh携带环境变量执行远端 heredoc 脚本核心是保护/opt/whalebro/codewhale这个运行检出目录if [ ! -d /opt/whalebro/codewhale/.git ]; then sudo -u codewhale git clone --branch $CODEWHALE_REPO_BRANCH $CODEWHALE_REPO_URL /opt/whalebro/codewhale fi cd /opt/whalebro/codewhale if [ -n $(sudo -u codewhale git status --porcelain) ]; then echo Refusing to deploy over a dirty /opt/whalebro/codewhale checkout. 2 sudo -u codewhale git status --short exit 1 fi随后依据CODEWHALE_REPO_BRANCH的值做三种分支切换若远端存在同名分支refs/remotes/origin/branchgit checkout -B branch origin/branch快进对齐若存在同名标签refs/tags/branchgit checkout --detach branch切换到标签的游离 HEAD否则直接git checkout该引用并git pull --ff-only仅快进拒绝合并式拉取。5.3 编译、安装与重启服务sudo -iu codewhale bash -lc set -euo pipefail . $HOME/.cargo/env cd /opt/whalebro/codewhale cargo install --path crates/cli --locked --force ln -sf codewhale $HOME/.cargo/bin/codew 以codewhale系统用户身份、锁定--locked依赖并--force安装 crates/cli 工作区成员产出codewhale主命令通过ln -sf让codew命令软链指向codewhale与第四节发布资产中codew-linux-x64的命名相互印证最后重启 systemd 服务并做健康检查调用维护方工具scripts/tencent-lighthouse/install-services.sh与doctor.sh。注意这两个脚本属于维护方自有服务端流程的一部分当前仓库快照中并未包含实际使用时应以你的 Lighthouse 实例上已就绪的服务端工具为准。部署方向提示该脚本在远端服务器上cargo install编译安装的是构建容器里的 CNB 镜像/流水线所对应的源码版本而不是上传已构建好的 musl 二进制与根.cnb.yml的tag_push发布路线用途不同一条走源码部署到服务器一条走构建发布资产到 CNB Release。六、Lighthouse 服务端应已就绪的组成部分README 明确指出服务端应该已经由维护方装好运行检出、环境文件与 systemd 服务。仓库内保留了这些文件的可对照参考6.1 systemd 服务单元codewhale-runtime.service以codewhale用户运行 CLI 的 HTTP 服务端ExecStart调用codewhale serve --http --host 127.0.0.1 --port ... --workers ... --auth-token ...。这是runtime checkout、systemd services中 runtime 侧的核心codewhale-feishu-bridge.service飞书Feishu/Lark手机桥接Wants/After依赖codewhale-runtime.servicecodewhale-telegram-bridge.serviceTelegram 手机桥接同样依赖 runtime。三个单元都体现了 README「/etc/codewhale 优先」的原则EnvironmentFile-/etc/deepseek/*.env先加载兼容旧安装EnvironmentFile-/etc/codewhale/*.env后加载并覆盖。6.2 环境文件模板runtime.env.exampleCODEWHALE_RUNTIME_TOKEN、CODEWHALE_RUNTIME_PORT7878、CODEWHALE_RUNTIME_WORKERS2、CODEWHALE_PROVIDERdeepseek等feishu-bridge.env.exampleFEISHU_APP_ID/FEISHU_APP_SECRET并引用CODEWHALE_RUNTIME_URLhttp://127.0.0.1:7878、相同的CODEWHALE_RUNTIME_TOKEN等telegram-bridge.env.exampleTELEGRAM_BOT_TOKEN等。从部署按钮的descriptionUpdate/opt/whalebro/codewhale, restart services, and run the Lighthouse doctor与 systemd 单元可见服务端布局为运行检出在/opt/whalebro/codewhale运行目录在/opt/whalebro令牌密钥类环境文件在/etc/codewhale/*.env桥接状态写入/var/lib/codewhale-*-bridge/。七、三条必须遵守的安全红线README 用 Safety Notes 明确提出以下运维纪律部署前务必逐条核对不要把飞书 App Secret 或模型供应商 API Key 放进 CNB。这些机密属于 Lighthouse 服务器上的/etc/codewhale/*.env对应仓库内的 runtime.env.example 等模板其中DEEPSEEK_API_KEY、FEISHU_APP_SECRET等字段应只存在于服务器侧。CNB 只保存连接服务器所需的 SSH 相关机密不要让127.0.0.1:7878暴露到公网。systemd 单元中codewhale serve --host 127.0.0.1绑定回环地址该端口是 runtime 内部 API不要通过 EdgeOne、安全组或公共反向代理对外暴露它桥接进程通过CODEWHALE_RUNTIME_URLhttp://127.0.0.1:7878走本机访问先用人工部署按钮再考虑自动部署。每次mainpush 都自动部署虽然方便但会消耗 CNB 配额且可能在对话轮次进行中重启手机桥接服务bridge 单元与 runtime 是独立进程重启会中断进行中的远端会话。八、总结一条可复制的远端服务器一键部署范式回顾整条链路CodeWhale 的腾讯云轻量服务器 CNB 部署方案可以归纳为清晰的三层范式GitHub 是唯一真相源根 .cnb.yml 源控在 GitHub利用 CNB 单向镜像同步保证 CI 门禁与发布流水线可审计、可回滚CNB 承接 CI/发布/部署触发mainpush 跑门禁v*tag 构建并发布 Linux x64 资产web_trigger_lighthouse事件承载部署按钮Lighthouse 只做已就绪实例的更新服务端预置 systemd 单元与/etc/codewhale/*.env部署脚本只负责 git 更新、cargo install、软链codew、重启服务与 doctor 检查。对于希望复用这套方案的团队最小实践路径是先在服务器上手工跑通 runtime 与手机桥接参照 systemd 单元 与 env 示例再在 GitHub 侧维护好根.cnb.yml最后在 CNB 上配置四个必需 Secrets 并复制 tag_deploy.yml.example 到.cnb/tag_deploy.yml——从此更新远端 CodeWhale就退化为一次点击。【免费下载链接】CodewhaleOpen-source coding agent for your terminal, built in Rust and on a journey of continuous community improvement. Issues and PRs welcome.项目地址: https://gitcode.com/GitHub_Trending/de/Codewhale创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
