【免费下载链接】OpenShellOpenShell is the safe, private runtime for autonomous AI agents.项目地址https://gitcode.com/gh_mirrors/op/OpenShell点击查看免费下载OpenShell 的 Release Canary工作流定义位于 .github/workflows/release-canary.yml配套操作手册为 .agents/skills/test-release-canary/SKILL.md是一套针对已发布dev工件的自动化冒烟测试体系每次Release Dev发布成功后自动触发在 macOS、Ubuntu、Fedora、Ubuntu Snap 和 kind Kubernetes 五类环境上真实安装、启动并执行一次沙箱生命周期确认“发布出去的包能在干净环境里跑起来”。读完本篇你可以独立理解 Canary 各 Job 的验证边界、掌握手动 dispatch 与本地 kind 复现的完整命令并在 Canary 红灯时按图索骥定位问题。发布流水线中的定位为什么需要 CanaryOpenShell 的发布链路由三段组成Release Dev.github/workflows/release-dev.yml负责在main分支推送到构建并产出各平台工件正式 tag 发布Release Tag负责面向用户发布而 Release Canary 夹在两者之间是打正式 tag 前的最后一道自动化检查点。从 release-canary.yml 的on:段可以直接看到它的触发与门禁逻辑on: workflow_dispatch: inputs: release-dev-run-id: description: Successful Release Dev run ID whose Snap artifact to test required: false type: string workflow_run: workflows: [Release Dev] types: [completed]自动触发路径下每个 Job 都带有一个if表达式例如macosJobif: ${{ github.event_name workflow_dispatch || github.event.workflow_run.conclusion success }}即只有Release Dev整条流水线包括二进制构建、Docker/VM E2E、集成测试、deb/RPM/Snap 打包全部成功Canary 才会运行。失败的Release Dev不会启动 Canary——避免把上游构建失败误报成安装问题。五个 Canary Job 的验证矩阵JobRunner验证内容macosmacos-latest-xlarge安装 dev Homebrew 工件连上 VM gateway创建、执行并删除一个沙箱ubuntuubuntu-latest安装 dev Debian 包连上 Docker gateway创建、执行并删除一个沙箱fedorafedora:latest容器安装 dev RPM 包连上 Podman gateway创建、执行并删除一个沙箱ubuntu-snapubuntu-latest安装 Release Dev Snap、连接接口连上 Docker gateway创建、执行并删除一个沙箱kubernetesubuntu-latest kind安装 dev Helm chart连上集群内 gateway使用已发布运行时镜像创建、执行并删除一个沙箱下面结合工作流源码说明各 Job 的实际做法。macOSHomebrewJob核心步骤只有两步release-canary.yml#L32-L43launchctl setenv OPENSHELL_COMPUTE_DRIVER vm launchctl setenv OPENSHELL_TELEMETRY_ENABLED $OPENSHELL_TELEMETRY_ENABLED curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh | sh openshell --version openshell status注意源码注释里写明的一个事实GitHub 托管的 macOS runner 不暴露 libkrun 所需的 Hypervisor.framework因此沙箱启动本身由 VM E2E 泳道覆盖Canary 在 macOS 上只验证“安装成功且 gateway 可达”。失败时的诊断步骤会打印brew services info openshell以及$(brew --prefix)/var/log/openshell/下两个 gateway 日志的最后 300 行。UbuntuDebian DockerJobEnsure Docker步骤在缺少 Docker 时自动安装docker.io并启动然后写入 gateway 环境文件release-canary.yml#L67-L87mkdir -p ${HOME}/.config/openshell printf OPENSHELL_COMPUTE_DRIVERdocker\nOPENSHELL_TELEMETRY_ENABLED%s\n \ $OPENSHELL_TELEMETRY_ENABLED ${HOME}/.config/openshell/gateway.env安装后执行完整的沙箱生命周期curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh | sh openshell status sandboxrc-${GITHUB_RUN_ID} openshell sandbox create --name $sandbox --detach openshell sandbox exec --name $sandbox --no-tty -- true openshell sandbox delete $sandbox沙箱名带GITHUB_RUN_ID前缀rc-便于在多次运行间区分残留资源。FedoraRPM Podman systemdJob这是最“重”的 Job因为它要在linux-amd64-cpu8runner 上用 Docker 拉起一个以 systemd 为 PID 1 的 Fedora 容器release-canary.yml#L97-L157原因来自 install.sh 的行为RPM 安装器把 gateway 注册为systemd user unit需要真实的 user session 才能测试“服务重启 gateway 注册”而不是安装器的“稍后重启”降级路径。步骤包括docker run --privileged --cgroupnshost启动fedora:latest容器exec /usr/sbin/init轮询 120 秒等待 systemd 可达显式启动 root 的 user managersystemctl start user-runtime-dir0.service、systemctl start user0.service在容器内写入OPENSHELL_COMPUTE_DRIVERpodman然后走install.sh完成 RPM 安装执行与 Ubuntu Job 相同的沙箱生命周期。容器名使用openshell-fedora-canary-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}并在always()步骤里清理。Ubuntu Snap Job该 Job 有一个特殊前提它消费的是Release Dev的Snap 工件通过actions/download-artifact从指定 run 下载snap-linux-amd64而不是从商店安装因此条件表达式为if: ${{ github.event.workflow_run.conclusion success || inputs.release-dev-run-id ! }}即自动路径要求 Release Dev 成功手动路径则必须显式传入release-dev-run-id指定哪个成功的 Release Dev 提供了 Snap 工件否则该 Job 被跳过。安装流程为安装 snapd → 安装 docker snap →sudo snap install ./release/*.snap --dangerous→ 连接docker、log-observe、system-observe三个接口 → 注册 gatewayopenshell gateway add http://127.0.0.1:17670 --local --name snap-docker openshell gateway select snap-docker注意这里轮询openshell status的上限是 30 秒for _ in $(seq 1 30)因为 Snap 场景下 Docker 接口连接后 gateway 需要恢复。失败诊断步骤会转储 Snap 服务/连接/变更状态、gateway 与 snapd 的 journal、snap logs以及 17670 端口的监听情况release-canary.yml#L256-L267。KubernetesHelm kindJobJob 环境固定了若干变量KIND_CLUSTER_NAME带 run_id 避免冲突、RELEASE_NAMEopenshell、RELEASE_NAMESPACEopenshell、KIND_GATEWAY_NAMEkind、AGENT_SANDBOX_VERSIONv1.0.3。执行链为sparse-checkout 拉取 e2e/support/install-agent-sandbox.sh 并安装上游 Agent Sandbox CRD 与 controller该脚本会等待sandboxes.agents.x-k8s.ioCRD 变为Established并轮询 controller rollout从 GHCR OCI 安装浮动 dev charthelm install $RELEASE_NAME oci://ghcr.io/nvidia/openshell/helm-chart \ --version 0.0.0-dev \ --namespace $RELEASE_NAMESPACE --create-namespace \ --set server.disableTlstrue \ --set server.auth.allowUnauthenticatedUserstrue \ --set server.telemetryEnabled${OPENSHELL_TELEMETRY_ENABLED} \ --set supervisor.sandboxRuntime.networkPolicyEnforcedtrue \ --wait --timeout 5mkubectl wait --forconditionReady等待 gateway Pod300 秒超时selector 为app.kubernetes.io/nameopenshell,app.kubernetes.io/instanceopenshellkubectl port-forward svc/openshell 8080:8080并轮询/dev/tcp/127.0.0.1/8080可达性用install.sh安装 CLI然后注册 gateway 并走沙箱生命周期openshell gateway add http://127.0.0.1:8080 --local --name $KIND_GATEWAY_NAME openshell status openshell sandbox create --name $sandbox --detach openshell sandbox exec --name $sandbox --no-tty -- true openshell sandbox delete $sandbox失败时的Diagnostics on failure步骤if: failure()按固定顺序输出helm status→ 渲染后的 manifest →kubectl get all→ Pod describe → 每容器 200 行 Pod 日志 →port-forward.log→openshell gateway list→ CLI 版本。按顺序读下来多数失败在 manifest 或 Pod 日志处就能定位。版本约定与遥测隔离Canary 在整个 workflow 层面设置两个环境变量release-canary.yml#L22-L24env: OPENSHELL_VERSION: dev OPENSHELL_TELEMETRY_ENABLED: falseOPENSHELL_VERSIONdevinstall.sh 在开头读取RELEASE_TAG${OPENSHELL_VERSION:-}其帮助文本明确说明“SetOPENSHELL_VERSIONdevto install the rolling dev build”因此所有install.shJob 消费的都是触发本次 Canary 的那次Release Dev产出的滚动 dev 发布Kubernetes Job 则对应 pin 住0.0.0-devchart 与:dev镜像。遥测全量关闭宿主包 Job 通过 service 环境注入OPENSHELL_TELEMETRY_ENABLEDfalsemacOS 用launchctl setenvLinux 写入~/.config/openshell/gateway.envSnap 用systemctl set-environmentKubernetes Job 用--set server.telemetryEnabledfalse确保冒烟流量不进入产品用量指标。三个边界限制值得在解读 Canary 结果时牢记只测全新安装宿主包 Job 验证的是 fresh install不覆盖从持久化的 schema-v1 gateway 配置升级的场景Homebrew 与 RPM 的精确默认值迁移要靠 release-tooling 和 package 生命周期测试来兜底。不覆盖 TypeScript SDKCanary 不安装也不导入nvidia/openshell-sdk其验证在TypeScript SDK分支检查里含 publish dry-runtag 发布工作流负责把包发布到 GitHub PackagesSDK 发布失败时应直接看那个 Job。macOS 不验证沙箱启动受 runner 的 Hypervisor.framework 限制仅验证 gateway 可达。触发路径详解Canary 有两条触发路径自动main上的Release Dev推送到或手动 dispatchRelease Dev只要其最终结论为success就会 fire Canary。手动workflow_dispatch允许对任意分支的工作流定义按需运行。要包含ubuntu-snapJob需传入该分支上某次成功 Release Dev 的 run ID 作为release-dev-run-id不传则跳过 Snap Job没有可用工件。一个容易踩到的细节手动 dispatch 时github.event.workflow_run.head_sha为空工作流表达式github.event.workflow_run.head_sha || github.sha会回落到github.sha分支尖端install.sh的 URL 因此取的是分支最新版本的安装脚本。手动 dispatch 操作在当前分支原样运行 Canarygh workflow run release-canary.yml --ref $(git branch --show-current)要覆盖 Ubuntu Snap Job加上 Release Dev run IDgh workflow run release-canary.yml --ref $(git branch --show-current) \ -f release-dev-run-idrelease-dev-run-id跟踪启动的这次运行先等 GitHub 注册 dispatchsleep 5 # let GitHub register the dispatch gh run list --workflow release-canary.yml --limit 1 gh run watch $(gh run list --workflow release-canary.yml --limit 1 --json databaseId --jq .[0].databaseId)运行完成后只看失败 Job 的日志gh run view run-id --log-failed迭代 Canary 工作流本身时的语义当你在分支上修改release-canary.yml并手动 dispatch 时测试的是你分支上的工作流逻辑 × main 上已发布的 dev 工件0.0.0-devchart、:dev镜像、dev GitHub Release。这正是迭代 Canary 想要的语义——验证改动后的 Canary 在“已知良好”的工件上依然能工作而不是把你的分支构建也带进来分支构建由Release Dev负责。另一个容易误解的点install.sh本身是从raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh拉取的所以你分支上对install.sh的改动会被真实执行到尽管它下载的二进制来自最新公开发布。换句话说改install.sh后跑一次手动 Canary就是在验证安装脚本回归。测试特定 SHA 的 Helm chartRelease Dev为每个 dev 构建发布两个 chart 版本这在自定义 action .github/actions/release-helm-oci/action.yml 中实现oci://ghcr.io/nvidia/openshell/helm-chart:0.0.0-dev— 浮动 tag每次 main 推送都会覆盖oci://ghcr.io/nvidia/openshell/helm-chart:0.0.0-dev.sha— 不可变appVersion同步设为同一 SHA从而拉取匹配的gateway、sandbox、supervisor镜像。action 中的pin-sha输入说明action.yml#L22-L31确认了这一机制dev 发布设置pin-sha后会额外复制两份 chartdeploy/helm/openshell与deploy/helm/openshell-workspace把Chart.yaml的version改写为0.0.0-dev.sha、appVersion改写为该 SHA重新打包后推送到 GHCR OCI。要冒烟测试某个特定 dev 构建的 chart正确顺序是先在该分支 dispatch 一次Release Dev产出并推送 SHA-pinned chart 与镜像然后在本地按下一节的 kind 流程执行把 chart 版本指向0.0.0-dev.sha。注意 release-canary 工作流本身目前没有暴露chart_version/image_tag输入SHA 级验证只能走本地复现。本地 kind 复现kubernetesJob 可以在任何装有 Docker 与mise提供的kubectlhelm的机器上复现完整流程见 SKILL.mdkind create cluster --name release-canary-local bash e2e/support/install-agent-sandbox.sh helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart \ --version 0.0.0-dev \ --namespace openshell --create-namespace \ --set server.disableTlstrue \ --set server.telemetryEnabledfalse \ --set supervisor.sandboxRuntime.networkPolicyEnforcedtrue \ --wait --timeout 5m kubectl wait --namespace openshell \ --forconditionReady pod \ --selectorapp.kubernetes.io/nameopenshell,app.kubernetes.io/instanceopenshell \ --timeout300s kubectl port-forward --namespace openshell svc/openshell 8080:8080 openshell gateway add http://127.0.0.1:8080 --local --name kind openshell status本地复现时与 CI 版本的两个差异值得注意本地版没有--set server.auth.allowUnauthenticatedUserstrueCI 中因为是无凭据的 CI runner 环境才开启本地脚本的install-agent-sandbox.sh调用不带--context参数因为默认上下文就是刚创建的 kind 集群。三条来自原文档的重要操作约束保持pkiInitJob.enabledtruechart 默认值即使server.disableTlstrue也不要关——该 hook 同时生成 sandbox JWT 签名密钥而 gateway Pod 始终会挂载它要 pin 特定 dev 构建把0.0.0-dev换成0.0.0-dev.shaloopback 注册在省略--name时会自动推导 gateway 名为openshell与install.sh安装的本地 gateway 撞名——如果机器上已有本地安装注册 kind gateway 时务必传--name kind或别的唯一名称。清理kind delete cluster --name release-canary-local失败诊断速查表症状可能原因排查位置macos/ubuntu/fedoraJob 在install.sh步骤失败dev Release 缺工件、校验和失配、或本分支install.sh回归Job 日志中curl … install.sh \| sh步骤附近沙箱创建或 exec 失败发布的 sandbox/supervisor 工件缺失、不兼容或无法建立受保护运行时通道gateway 日志 该 Job 的 Docker/Podman/VM/Snap/Kubernetes 运行时诊断macos/ubuntu/fedoraJob 在openshell status失败本地 gateway 服务未启动systemd/brew/podman常见于 driver 问题Job 日志中的 service 日志Ensure … 步骤里的OPENSHELL_COMPUTE_DRIVER环境变量ubuntu-snap在接口连接后失败Docker 可用后 gateway 未恢复或 30 秒内未达到可达状态失败诊断步骤会转储 Snap 服务/连接/变更状态、gateway 与 snapd journal、Snap 日志、17670 端口监听kubernetesJob 在helm install --wait失败chart 5 分钟内未部署完成——通常是镜像拉取失败或 readiness 探针不过Diagnostics on failure 步骤转储helm status、manifest、Pod describe、Pod 日志kubernetesJob 在kubectl wait失败gateway Pod 卡在CrashLoopBackOff或ImagePullBackOff诊断转储确认ghcr.io/nvidia/openshell/gateway上:dev镜像是否存在kubernetesJob 在openshell gateway add或status失败port-forward 不可达或 CLI/gateway proto 不匹配诊断转储中的port-forward.log与openshell gateway list阅读 Kubernetes 诊断转储的建议顺序先helm get manifest配置层问题往往一目了然再看 Pod describe 与 Pod 日志最后才回到 port-forward 日志与openshell gateway list。相关资源helm-dev-environment skill.agents/skills/helm-dev-environment/SKILL.md基于 k3d 的本地开发环境功能比 Canary 的 kind 集群更丰富但使用 Skaffold 构建的本地镜像而非已发布工件——两者用途不同不要混用结论。watch-github-actions skill.agents/skills/watch-github-actions/SKILL.md通用的gh run工作流监控。debug-openshell-cluster skillskills/debug-openshell-cluster/SKILL.md运行时 gateway/沙箱诊断可与 kind Job 的诊断转储配合使用。发布链上游.github/workflows/release-dev.yml工件产出方、.github/workflows/release-tag.yml正式 tag 发布、.github/actions/release-helm-oci/action.ymlchart 打包与 SHA pin 逻辑。一句话总结Release Canary 不测试“功能多”只回答一个问题——“这份刚发布的 dev 工件在标准环境里能不能装得上、连得上、跑一次沙箱”。它红灯时发布链路必须停它绿灯时你才有底气去打正式 tag。赞分享【免费下载链接】OpenShellOpenShell is the safe, private runtime for autonomous AI agents.项目地址https://gitcode.com/gh_mirrors/op/OpenShell点击查看免费下载相关推荐一条命令跑起 OpenAI 兼容的本地推理服务LocalAI 完全上手指南一条命令跑起 OpenAI 兼容的本地推理服务LocalAI 完全上手指南 如果你想在 自己电脑上免费跑大模型 还希望它能无缝替换现有的 OpenAI 接口人工智能AI 应用交互助手AI AgentImpeccable polish 精修实战指南发布前最后一个质量关卡Impeccable polish 精修实战指南发布前最后一个质量关卡 Impeccable 的 polish 是 Refine精修类别下的收尾命令定位AI 技能前端CLIdsh-pluginCC GUI供应商管理教程cc-switch兼容配置与中转API Key接入实战CC GUI供应商管理教程cc switch兼容配置与中转API Key接入实战 idea claude code gui 是一个功能强大的 IntelliJ开发工具AI 应用代码智能体上一篇MONAI 可视化模块完全指南CAM/Grad-CAM、遮挡敏感性与 TensorBoard 医学影像可视化下一篇SeekStorm入门指南5分钟构建你的第一个高性能搜索引擎创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenShell Release Canary 实战指南：发布工件的最后一道冒烟关卡
【免费下载链接】OpenShellOpenShell is the safe, private runtime for autonomous AI agents.项目地址https://gitcode.com/gh_mirrors/op/OpenShell点击查看免费下载OpenShell 的 Release Canary工作流定义位于 .github/workflows/release-canary.yml配套操作手册为 .agents/skills/test-release-canary/SKILL.md是一套针对已发布dev工件的自动化冒烟测试体系每次Release Dev发布成功后自动触发在 macOS、Ubuntu、Fedora、Ubuntu Snap 和 kind Kubernetes 五类环境上真实安装、启动并执行一次沙箱生命周期确认“发布出去的包能在干净环境里跑起来”。读完本篇你可以独立理解 Canary 各 Job 的验证边界、掌握手动 dispatch 与本地 kind 复现的完整命令并在 Canary 红灯时按图索骥定位问题。发布流水线中的定位为什么需要 CanaryOpenShell 的发布链路由三段组成Release Dev.github/workflows/release-dev.yml负责在main分支推送到构建并产出各平台工件正式 tag 发布Release Tag负责面向用户发布而 Release Canary 夹在两者之间是打正式 tag 前的最后一道自动化检查点。从 release-canary.yml 的on:段可以直接看到它的触发与门禁逻辑on: workflow_dispatch: inputs: release-dev-run-id: description: Successful Release Dev run ID whose Snap artifact to test required: false type: string workflow_run: workflows: [Release Dev] types: [completed]自动触发路径下每个 Job 都带有一个if表达式例如macosJobif: ${{ github.event_name workflow_dispatch || github.event.workflow_run.conclusion success }}即只有Release Dev整条流水线包括二进制构建、Docker/VM E2E、集成测试、deb/RPM/Snap 打包全部成功Canary 才会运行。失败的Release Dev不会启动 Canary——避免把上游构建失败误报成安装问题。五个 Canary Job 的验证矩阵JobRunner验证内容macosmacos-latest-xlarge安装 dev Homebrew 工件连上 VM gateway创建、执行并删除一个沙箱ubuntuubuntu-latest安装 dev Debian 包连上 Docker gateway创建、执行并删除一个沙箱fedorafedora:latest容器安装 dev RPM 包连上 Podman gateway创建、执行并删除一个沙箱ubuntu-snapubuntu-latest安装 Release Dev Snap、连接接口连上 Docker gateway创建、执行并删除一个沙箱kubernetesubuntu-latest kind安装 dev Helm chart连上集群内 gateway使用已发布运行时镜像创建、执行并删除一个沙箱下面结合工作流源码说明各 Job 的实际做法。macOSHomebrewJob核心步骤只有两步release-canary.yml#L32-L43launchctl setenv OPENSHELL_COMPUTE_DRIVER vm launchctl setenv OPENSHELL_TELEMETRY_ENABLED $OPENSHELL_TELEMETRY_ENABLED curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh | sh openshell --version openshell status注意源码注释里写明的一个事实GitHub 托管的 macOS runner 不暴露 libkrun 所需的 Hypervisor.framework因此沙箱启动本身由 VM E2E 泳道覆盖Canary 在 macOS 上只验证“安装成功且 gateway 可达”。失败时的诊断步骤会打印brew services info openshell以及$(brew --prefix)/var/log/openshell/下两个 gateway 日志的最后 300 行。UbuntuDebian DockerJobEnsure Docker步骤在缺少 Docker 时自动安装docker.io并启动然后写入 gateway 环境文件release-canary.yml#L67-L87mkdir -p ${HOME}/.config/openshell printf OPENSHELL_COMPUTE_DRIVERdocker\nOPENSHELL_TELEMETRY_ENABLED%s\n \ $OPENSHELL_TELEMETRY_ENABLED ${HOME}/.config/openshell/gateway.env安装后执行完整的沙箱生命周期curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh | sh openshell status sandboxrc-${GITHUB_RUN_ID} openshell sandbox create --name $sandbox --detach openshell sandbox exec --name $sandbox --no-tty -- true openshell sandbox delete $sandbox沙箱名带GITHUB_RUN_ID前缀rc-便于在多次运行间区分残留资源。FedoraRPM Podman systemdJob这是最“重”的 Job因为它要在linux-amd64-cpu8runner 上用 Docker 拉起一个以 systemd 为 PID 1 的 Fedora 容器release-canary.yml#L97-L157原因来自 install.sh 的行为RPM 安装器把 gateway 注册为systemd user unit需要真实的 user session 才能测试“服务重启 gateway 注册”而不是安装器的“稍后重启”降级路径。步骤包括docker run --privileged --cgroupnshost启动fedora:latest容器exec /usr/sbin/init轮询 120 秒等待 systemd 可达显式启动 root 的 user managersystemctl start user-runtime-dir0.service、systemctl start user0.service在容器内写入OPENSHELL_COMPUTE_DRIVERpodman然后走install.sh完成 RPM 安装执行与 Ubuntu Job 相同的沙箱生命周期。容器名使用openshell-fedora-canary-${GITHUB_RUN_ID}-${GITHUB_RUN_ATTEMPT}并在always()步骤里清理。Ubuntu Snap Job该 Job 有一个特殊前提它消费的是Release Dev的Snap 工件通过actions/download-artifact从指定 run 下载snap-linux-amd64而不是从商店安装因此条件表达式为if: ${{ github.event.workflow_run.conclusion success || inputs.release-dev-run-id ! }}即自动路径要求 Release Dev 成功手动路径则必须显式传入release-dev-run-id指定哪个成功的 Release Dev 提供了 Snap 工件否则该 Job 被跳过。安装流程为安装 snapd → 安装 docker snap →sudo snap install ./release/*.snap --dangerous→ 连接docker、log-observe、system-observe三个接口 → 注册 gatewayopenshell gateway add http://127.0.0.1:17670 --local --name snap-docker openshell gateway select snap-docker注意这里轮询openshell status的上限是 30 秒for _ in $(seq 1 30)因为 Snap 场景下 Docker 接口连接后 gateway 需要恢复。失败诊断步骤会转储 Snap 服务/连接/变更状态、gateway 与 snapd 的 journal、snap logs以及 17670 端口的监听情况release-canary.yml#L256-L267。KubernetesHelm kindJobJob 环境固定了若干变量KIND_CLUSTER_NAME带 run_id 避免冲突、RELEASE_NAMEopenshell、RELEASE_NAMESPACEopenshell、KIND_GATEWAY_NAMEkind、AGENT_SANDBOX_VERSIONv1.0.3。执行链为sparse-checkout 拉取 e2e/support/install-agent-sandbox.sh 并安装上游 Agent Sandbox CRD 与 controller该脚本会等待sandboxes.agents.x-k8s.ioCRD 变为Established并轮询 controller rollout从 GHCR OCI 安装浮动 dev charthelm install $RELEASE_NAME oci://ghcr.io/nvidia/openshell/helm-chart \ --version 0.0.0-dev \ --namespace $RELEASE_NAMESPACE --create-namespace \ --set server.disableTlstrue \ --set server.auth.allowUnauthenticatedUserstrue \ --set server.telemetryEnabled${OPENSHELL_TELEMETRY_ENABLED} \ --set supervisor.sandboxRuntime.networkPolicyEnforcedtrue \ --wait --timeout 5mkubectl wait --forconditionReady等待 gateway Pod300 秒超时selector 为app.kubernetes.io/nameopenshell,app.kubernetes.io/instanceopenshellkubectl port-forward svc/openshell 8080:8080并轮询/dev/tcp/127.0.0.1/8080可达性用install.sh安装 CLI然后注册 gateway 并走沙箱生命周期openshell gateway add http://127.0.0.1:8080 --local --name $KIND_GATEWAY_NAME openshell status openshell sandbox create --name $sandbox --detach openshell sandbox exec --name $sandbox --no-tty -- true openshell sandbox delete $sandbox失败时的Diagnostics on failure步骤if: failure()按固定顺序输出helm status→ 渲染后的 manifest →kubectl get all→ Pod describe → 每容器 200 行 Pod 日志 →port-forward.log→openshell gateway list→ CLI 版本。按顺序读下来多数失败在 manifest 或 Pod 日志处就能定位。版本约定与遥测隔离Canary 在整个 workflow 层面设置两个环境变量release-canary.yml#L22-L24env: OPENSHELL_VERSION: dev OPENSHELL_TELEMETRY_ENABLED: falseOPENSHELL_VERSIONdevinstall.sh 在开头读取RELEASE_TAG${OPENSHELL_VERSION:-}其帮助文本明确说明“SetOPENSHELL_VERSIONdevto install the rolling dev build”因此所有install.shJob 消费的都是触发本次 Canary 的那次Release Dev产出的滚动 dev 发布Kubernetes Job 则对应 pin 住0.0.0-devchart 与:dev镜像。遥测全量关闭宿主包 Job 通过 service 环境注入OPENSHELL_TELEMETRY_ENABLEDfalsemacOS 用launchctl setenvLinux 写入~/.config/openshell/gateway.envSnap 用systemctl set-environmentKubernetes Job 用--set server.telemetryEnabledfalse确保冒烟流量不进入产品用量指标。三个边界限制值得在解读 Canary 结果时牢记只测全新安装宿主包 Job 验证的是 fresh install不覆盖从持久化的 schema-v1 gateway 配置升级的场景Homebrew 与 RPM 的精确默认值迁移要靠 release-tooling 和 package 生命周期测试来兜底。不覆盖 TypeScript SDKCanary 不安装也不导入nvidia/openshell-sdk其验证在TypeScript SDK分支检查里含 publish dry-runtag 发布工作流负责把包发布到 GitHub PackagesSDK 发布失败时应直接看那个 Job。macOS 不验证沙箱启动受 runner 的 Hypervisor.framework 限制仅验证 gateway 可达。触发路径详解Canary 有两条触发路径自动main上的Release Dev推送到或手动 dispatchRelease Dev只要其最终结论为success就会 fire Canary。手动workflow_dispatch允许对任意分支的工作流定义按需运行。要包含ubuntu-snapJob需传入该分支上某次成功 Release Dev 的 run ID 作为release-dev-run-id不传则跳过 Snap Job没有可用工件。一个容易踩到的细节手动 dispatch 时github.event.workflow_run.head_sha为空工作流表达式github.event.workflow_run.head_sha || github.sha会回落到github.sha分支尖端install.sh的 URL 因此取的是分支最新版本的安装脚本。手动 dispatch 操作在当前分支原样运行 Canarygh workflow run release-canary.yml --ref $(git branch --show-current)要覆盖 Ubuntu Snap Job加上 Release Dev run IDgh workflow run release-canary.yml --ref $(git branch --show-current) \ -f release-dev-run-idrelease-dev-run-id跟踪启动的这次运行先等 GitHub 注册 dispatchsleep 5 # let GitHub register the dispatch gh run list --workflow release-canary.yml --limit 1 gh run watch $(gh run list --workflow release-canary.yml --limit 1 --json databaseId --jq .[0].databaseId)运行完成后只看失败 Job 的日志gh run view run-id --log-failed迭代 Canary 工作流本身时的语义当你在分支上修改release-canary.yml并手动 dispatch 时测试的是你分支上的工作流逻辑 × main 上已发布的 dev 工件0.0.0-devchart、:dev镜像、dev GitHub Release。这正是迭代 Canary 想要的语义——验证改动后的 Canary 在“已知良好”的工件上依然能工作而不是把你的分支构建也带进来分支构建由Release Dev负责。另一个容易误解的点install.sh本身是从raw.githubusercontent.com/NVIDIA/OpenShell/${head_sha}/install.sh拉取的所以你分支上对install.sh的改动会被真实执行到尽管它下载的二进制来自最新公开发布。换句话说改install.sh后跑一次手动 Canary就是在验证安装脚本回归。测试特定 SHA 的 Helm chartRelease Dev为每个 dev 构建发布两个 chart 版本这在自定义 action .github/actions/release-helm-oci/action.yml 中实现oci://ghcr.io/nvidia/openshell/helm-chart:0.0.0-dev— 浮动 tag每次 main 推送都会覆盖oci://ghcr.io/nvidia/openshell/helm-chart:0.0.0-dev.sha— 不可变appVersion同步设为同一 SHA从而拉取匹配的gateway、sandbox、supervisor镜像。action 中的pin-sha输入说明action.yml#L22-L31确认了这一机制dev 发布设置pin-sha后会额外复制两份 chartdeploy/helm/openshell与deploy/helm/openshell-workspace把Chart.yaml的version改写为0.0.0-dev.sha、appVersion改写为该 SHA重新打包后推送到 GHCR OCI。要冒烟测试某个特定 dev 构建的 chart正确顺序是先在该分支 dispatch 一次Release Dev产出并推送 SHA-pinned chart 与镜像然后在本地按下一节的 kind 流程执行把 chart 版本指向0.0.0-dev.sha。注意 release-canary 工作流本身目前没有暴露chart_version/image_tag输入SHA 级验证只能走本地复现。本地 kind 复现kubernetesJob 可以在任何装有 Docker 与mise提供的kubectlhelm的机器上复现完整流程见 SKILL.mdkind create cluster --name release-canary-local bash e2e/support/install-agent-sandbox.sh helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart \ --version 0.0.0-dev \ --namespace openshell --create-namespace \ --set server.disableTlstrue \ --set server.telemetryEnabledfalse \ --set supervisor.sandboxRuntime.networkPolicyEnforcedtrue \ --wait --timeout 5m kubectl wait --namespace openshell \ --forconditionReady pod \ --selectorapp.kubernetes.io/nameopenshell,app.kubernetes.io/instanceopenshell \ --timeout300s kubectl port-forward --namespace openshell svc/openshell 8080:8080 openshell gateway add http://127.0.0.1:8080 --local --name kind openshell status本地复现时与 CI 版本的两个差异值得注意本地版没有--set server.auth.allowUnauthenticatedUserstrueCI 中因为是无凭据的 CI runner 环境才开启本地脚本的install-agent-sandbox.sh调用不带--context参数因为默认上下文就是刚创建的 kind 集群。三条来自原文档的重要操作约束保持pkiInitJob.enabledtruechart 默认值即使server.disableTlstrue也不要关——该 hook 同时生成 sandbox JWT 签名密钥而 gateway Pod 始终会挂载它要 pin 特定 dev 构建把0.0.0-dev换成0.0.0-dev.shaloopback 注册在省略--name时会自动推导 gateway 名为openshell与install.sh安装的本地 gateway 撞名——如果机器上已有本地安装注册 kind gateway 时务必传--name kind或别的唯一名称。清理kind delete cluster --name release-canary-local失败诊断速查表症状可能原因排查位置macos/ubuntu/fedoraJob 在install.sh步骤失败dev Release 缺工件、校验和失配、或本分支install.sh回归Job 日志中curl … install.sh \| sh步骤附近沙箱创建或 exec 失败发布的 sandbox/supervisor 工件缺失、不兼容或无法建立受保护运行时通道gateway 日志 该 Job 的 Docker/Podman/VM/Snap/Kubernetes 运行时诊断macos/ubuntu/fedoraJob 在openshell status失败本地 gateway 服务未启动systemd/brew/podman常见于 driver 问题Job 日志中的 service 日志Ensure … 步骤里的OPENSHELL_COMPUTE_DRIVER环境变量ubuntu-snap在接口连接后失败Docker 可用后 gateway 未恢复或 30 秒内未达到可达状态失败诊断步骤会转储 Snap 服务/连接/变更状态、gateway 与 snapd journal、Snap 日志、17670 端口监听kubernetesJob 在helm install --wait失败chart 5 分钟内未部署完成——通常是镜像拉取失败或 readiness 探针不过Diagnostics on failure 步骤转储helm status、manifest、Pod describe、Pod 日志kubernetesJob 在kubectl wait失败gateway Pod 卡在CrashLoopBackOff或ImagePullBackOff诊断转储确认ghcr.io/nvidia/openshell/gateway上:dev镜像是否存在kubernetesJob 在openshell gateway add或status失败port-forward 不可达或 CLI/gateway proto 不匹配诊断转储中的port-forward.log与openshell gateway list阅读 Kubernetes 诊断转储的建议顺序先helm get manifest配置层问题往往一目了然再看 Pod describe 与 Pod 日志最后才回到 port-forward 日志与openshell gateway list。相关资源helm-dev-environment skill.agents/skills/helm-dev-environment/SKILL.md基于 k3d 的本地开发环境功能比 Canary 的 kind 集群更丰富但使用 Skaffold 构建的本地镜像而非已发布工件——两者用途不同不要混用结论。watch-github-actions skill.agents/skills/watch-github-actions/SKILL.md通用的gh run工作流监控。debug-openshell-cluster skillskills/debug-openshell-cluster/SKILL.md运行时 gateway/沙箱诊断可与 kind Job 的诊断转储配合使用。发布链上游.github/workflows/release-dev.yml工件产出方、.github/workflows/release-tag.yml正式 tag 发布、.github/actions/release-helm-oci/action.ymlchart 打包与 SHA pin 逻辑。一句话总结Release Canary 不测试“功能多”只回答一个问题——“这份刚发布的 dev 工件在标准环境里能不能装得上、连得上、跑一次沙箱”。它红灯时发布链路必须停它绿灯时你才有底气去打正式 tag。赞分享【免费下载链接】OpenShellOpenShell is the safe, private runtime for autonomous AI agents.项目地址https://gitcode.com/gh_mirrors/op/OpenShell点击查看免费下载相关推荐一条命令跑起 OpenAI 兼容的本地推理服务LocalAI 完全上手指南一条命令跑起 OpenAI 兼容的本地推理服务LocalAI 完全上手指南 如果你想在 自己电脑上免费跑大模型 还希望它能无缝替换现有的 OpenAI 接口人工智能AI 应用交互助手AI AgentImpeccable polish 精修实战指南发布前最后一个质量关卡Impeccable polish 精修实战指南发布前最后一个质量关卡 Impeccable 的 polish 是 Refine精修类别下的收尾命令定位AI 技能前端CLIdsh-pluginCC GUI供应商管理教程cc-switch兼容配置与中转API Key接入实战CC GUI供应商管理教程cc switch兼容配置与中转API Key接入实战 idea claude code gui 是一个功能强大的 IntelliJ开发工具AI 应用代码智能体上一篇MONAI 可视化模块完全指南CAM/Grad-CAM、遮挡敏感性与 TensorBoard 医学影像可视化下一篇SeekStorm入门指南5分钟构建你的第一个高性能搜索引擎创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考