NemoClaw 暂存 Brev Launchable E2E 边界解析可信分发、凭据隔离与清理保证【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址: https://gitcode.com/gh_mirrors/ne/NemoClawExact staging Brev Launchable是 NemoClaw 仓库中用于在 NVIDIA OpenShell / Brev 云工作区上执行真实 E2E 资格验证的受信 CI 作业。本篇指南以维护者 E2E 技能中的 staging-launchable.md 为骨架结合.github/workflows下的真实工作流与测试实现完整说明该作业的运行模式、触发权限、验证清单、凭据边界、产物形态与并发排队语义帮助维护者理解什么情况下可以分发、分发后如何判定成功、失败后如何处置。运行模式Launchable 模式与 Full 模式Exact staging Brev Launchable只会在受信的手动分发trusted manual dispatch且目标分支为main时运行普通推送push触发的 E2E 不会包含该作业。它有两种被选中的方式Launchable 模式分发时只选择该作业本身。在 e2e.yaml 中对应jobs输入为staging-brev-launchable完整作业或staging-brev-launchable-identity显式身份冒烟运行Full 模式在jobs与targets均为空、且勾选include_staging_brev_launchable输入时该作业被并入默认 E2E 选择集成为完整资格运行的一部分。两种模式共享同一个硬性前置条件在作业检出候选源码之前工作流必须验证分发者具备仓库的maintain或admin权限。该检查在 e2e.yaml 的Authorize Launchable E2E maintainer dispatch步骤中实现它对github.actor与github.triggering_actor逐一调用 GitHub API 读取协作者权限仅当role_name为maintain或admin时才放行同时拒绝来自 fork PR 的分发要求源码分支位于NVIDIA/NemoClaw内。配套的独立工作流 staging-launchable-full.yaml 在首个步骤即校验github.repository NVIDIA/NemoClaw github.ref refs/heads/main github.event_name workflow_dispatch并在Authorize maintainer dispatch步骤中对两个 actor 重复做权限判定保证受信工作流身份 受信分发者双重约束。作业完成前必须验证的四类结果该作业会构建候选镜像、部署常驻 Launchablestanding Launchable并且只有以下四类结果全部通过才算成功环境可达性与镜像启动Brev 工作区可访问且启动的镜像符合预期提交身份一致性候选 SHA、镜像仓库 SHA、烘焙baked的源码检出无未提交改动、不存在运行时覆盖runtime overrides推理链路通过预装的完整 E2E 套件验证 hosted 推理与 sandbox 推理清理闭环Brev 工作区被删除并确认其不存在confirmed absence。这些检查在 issue-9880-staging-launchable.test.ts 中体现为四个阶段解析最新暂存交接resolve the latest staging handoff、创建工作区create the staging workspace、证明远程执行就绪prove remote execution readiness、记录就绪证据record remote execution readiness。测试首先通过BrevLaunchableFixture.resolveLatestStagingHandoff()拿到镜像发布者producer产出的bootImage、nemoclawSha、imageRepositorySha、producerRunId随后创建命名形如staging-full-8位随机的工作区等待 SSH 可执行waitForExec最终写出staging-launchable-remote-execution-readiness.json字段包括candidateSha、imageRepositorySha、bootImage、launchableId、producerRunId、workspaceId、workspaceName与remoteExecutionReady: true。镜像身份契约在维护者验证技能 nemoclaw-maintainer-validate-launchable/SKILL.md 中有更严格的字段级要求launchable-e2e.json必须报告candidateSha等于所选提交、producer.status success、具体的boot.bootImageURI、boot.schemaVersion 1、boot.sourceRepository NVIDIA/NemoClaw、boot.sourcePath /opt/nemoclaw-image/NemoClaw、boot.repoSha与boot.provisionSha等于提交 SHA、小写 40 位boot.imageRepositorySha、boot.repoClean true、boot.runtimeOverrides false、fullE2e passed。凭据边界三把钥匙各司其职该作业从仓库 Actions secrets 读取三类凭据每类的暴露范围都经过严格切分凭据用途暴露边界BREV_API_KEY在受信宿主机侧认证 Brev CLI用于工作区生命周期操作组织由BREV_ORG_ID指定候选代码拿不到该 keyNEMOCLAW_IMAGE_DISPATCH_TOKEN以GH_TOKEN形式只暴露给受信宿主脚本授予对brevdev/nemoclaw-image仓库的 Actions 读写权限用于工作流分发、运行检查与产物下载仅受信宿主脚本NVIDIA_API_KEY公共 NVIDIA 端点凭据工作流将其作为NVIDIA_INFERENCE_API_KEY导出进 Brev guest 供完整 E2E 使用烘焙的候选检出中的代码可以读取并使用在 staging-launchable-full.yaml 中可以看到凭据的实际流向Prepare Brev CLI and evidence directory步骤将HOME隔离到$RUNNER_TEMP/staging-launchable-full-home0700权限下载带 SHA256 固定校验的brev-cli版本0.6.334校验和d4aa49db...并执行brev login --api-key $BREV_API_KEY --org-id $BREV_ORG_ID随后Verify staging Launchable remote execution readiness步骤把BREV_LAUNCHABLE_ID来自vars.NEMOCLAW_STAGING_LAUNCHABLE_ID、NEMOCLAW_IMAGE_DISPATCH_TOKEN、NEMOCLAW_RUN_LIVE_E2E1注入测试环境。brev login会把BREV_API_KEY与BREV_ORG_ID写入宿主机上的$HOME/.brev/credentials.json此处即上述隔离的临时 HOME 目录。工作流不会显式删除该文件而是依赖 GitHub-hosted runner 的临时文件系统在任务结束时随环境销毁同时工作流的Remove Brev credentials步骤if: always()会rm -rf该 HOME 目录并断言其不存在作为纵深防御。凭据的失效与事后处置凭据的有效期持续到过期或管理员在签发服务中吊销为止。若出现清理失败场景维护者需要移除已记录recorded的 Brev 工作区避免残留计费实例对每个凭据执行轮换rotate或吊销revoke以移除后续访问能力。这与验证技能中的处置要求一致推理 API key 应在运行结束后轮换/吊销仅当签发服务无法轮换时才可申请绑定候选提交 SHA 与选定运行 ID 的维护者豁免waiver。Launchable 选择与一致性约定NEMOCLAW_STAGING_LAUNCHABLE_ID是仓库级别的 Actions变量variable用于选定常驻 Launchable。其取值必须始终等于 nemoclaw-maintainer-validate-launchable 所拥有的默认部署 URL 中的 Launchable ID——即https://brev.nvidia.com/launchable/deploy/now?launchableIDenv-3I2w334slP4GKSce9kKK0hGerjJ中的 ID 部分。保持一致性的意义在于自动化作业与人工咨询式验证始终针对同一个常驻 Launchable避免自动化测 A、人工验 B的身份漂移。产物契约与失败形态一个成功的作业会保留三类产物launchable-e2e.json结构化证据承载候选 SHA、producer 运行信息、boot 镜像与烘焙检出身份、完整 E2E 结论full-e2e.log完整 E2E 运行日志cleanup.json清理记录且只有在作业确认工作区不存在之后才会产生——这是清理闭环的证据本身。失败形态按发生阶段区分准备阶段失败可能完全不产生任何产物后续阶段失败只会保留lane.log以及退出前已创建的各阶段phase产物。这一点与脚本实现吻合tools/e2e/brev-launchable-e2e.sh将每步日志追加写入$WORK_DIR/lane.log并用write_workspace_ownership维护记录工作区名、创建状态pending/accepted/reconciled与删除尝试次数的所有权凭据文件。工作流上传产物步骤的if条件为always() steps.prepare.outputs.work_dir ! 即只要准备步骤成功就尝试上传该目录下已有的一切证据。并发组与排队语义作业使用staging-brev-launchable-cpu并发组且不取消正在运行的作业cancel-in-progress: false这避免了并发分发时相互打断对方的工作区生命周期。所有 Launchable 消费方统一使用queue: max该策略允许队列中保留最多100条待处理条目当队列已满时GitHub 会取消新进入的条目。因此必须强调一个处于 queued、waiting 或 accepted 状态的分发都不是成功结果——只有作业真正执行完毕并产出上述证据才算数。等待中的分发可能被队列上限取消这也解释了为什么维护者技能要求以最新成功的Exact staging Brev Launchable作业为证据源。与维护者验证技能的衔接该边界文档属于 nemoclaw-maintainer-e2e 技能的一部分任何包含Exact staging Brev Launchable的分发在操作前都必须先阅读本边界而普通 E2E 请求不授权该作业。与之互补的 nemoclaw-maintainer-validate-launchable 技能则负责咨询式人工验证advisory manual validation其结论不能替代自动化 E2E 证据最终按complete pass / failed / partially blocked / not run四档归类并区分Web 部署流程由 Codex 执行与not run by Codex。仓库中的实现证据清单如需深入阅读实现可沿以下路径继续独立工作流.github/workflows/staging-launchable-full.yaml分发条件、权限校验、Brev CLI 固定版本、HOME 隔离、清理与上传步骤主 E2E 套件.github/workflows/e2e.yamlinclude_staging_brev_launchable输入与维护者授权步骤远程执行就绪测试test/e2e/live/issue-9880-staging-launchable.test.ts工作区清理验证测试test/e2e/live/brev-workspace-cleanup.test.ts宿主脚本实现tools/e2e/brev-launchable-e2e.sh人工验证契约.agents/skills/nemoclaw-maintainer-validate-launchable/SKILL.md【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址: https://gitcode.com/gh_mirrors/ne/NemoClaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考