NemoClaw 受信任 main 分支 E2E 分发全流程：运行模式、凭据边界与结果核验

【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址https://gitcode.com/gh_mirrors/ne/NemoClaw点击查看免费下载本文基于仓库维护者技能 .agents/skills/nemoclaw-maintainer-e2e/references/main-runs.md完整讲解如何在 NemoClaw 的 GitHub Actions 流水线.github/workflows/e2e.yaml上为维护者请求的受信任main提交分发一次 E2E 运行。读完本文你将掌握四种运行模式的选取规则、分发前后的凭据与资源清理边界、以ghCLI 完成“解析提交 → 单次分发 → 有界轮询 → 结果核验”的完整操作闭环并理解Release qualification聚合作业的严格语义——它只报告运行结果绝不替代发布决策。适用范围只有维护者请求受信任的main分发时才使用本流程不是通用 E2E 入口。它只在维护者明确请求一次新的受信任maindispatch 时启用对应技能路由表见 SKILL.md中的“Run the currentmaincommit on GitHub”分支。与之并列的其他入口各自独立请求类型对应流程运行工作区源码或指定本地提交Local Runs在 GitHub 上运行最新 PR 提交含失败后与精确 base 的对比Manual PR Runs在 GitHub 上运行当前main提交本文Main Runs及 Launchable 边界仅为发布决策检查既有证据Release Context关键约束一次新的 GitHub 候选运行只能测试“最新的 PR 提交”或“当前的main提交”任意历史提交的选择不被支持。所有 GitHub 侧运行都必须使用来自受信任main的.github/workflows/e2e.yaml不得用本地活体 E2E 代替 GitHub 运行除非维护者明确要求本地执行。此外通用 E2E 请求并不自动授权Exact staging Brev Launchable路径在分发任何包含该作业的运行之前必须先阅读 Staging Launchable它拥有该作业的凭据、部署、清理、产物与队列边界。第一步选择运行模式分发动作由请求语义决定而不是由“all”“complete”这类宽泛措辞推断。下表是请求到RUN_MODE、jobs、targets三个输入的权威映射请求RUN_MODEjobstargets是否包含 Launchable E2E“Run the E2E suite”ordinary空空否“Run focused E2E”focused具名 ID 或空具名 ID 或空否“Run the Launchable E2E”launchablestaging-brev-launchable空仅此作业“Run the full E2E suite”full空空是“deploy pre-release full E2E”full空空是“run pre-tag full E2E”full空空是“run release-candidate E2E”full空空是四种模式的选择器语义必须精确理解ordinary 模式选择默认 E2E 套件不包含Exact staging Brev Launchable。这是“跑一遍常规 E2E”的默认回答。focused 模式选择具名作业jobs或按类型选择目标targets但只能设置一个选择器输入。两者同时非空、或两者同时为空都会被拒绝。launchable 模式只运行staging-brev-launchable这一个作业即预装完整 E2E 套件的 Brev Launchable 校验。full 模式在默认套件之上追加Launchable 作业也就是“完整套件 Exact staging Brev Launchable”。容易踩的两个坑其一通用 E2E 请求绝不能擅自授权 Brev Launchable 路径不要因为请求里出现 “all” 或 “complete” 就推断为 full 模式只有当请求中出现互相冲突的模式表述时才需要追问澄清。其二full模式会发布严格聚合的Release qualification作业这个作业不放宽任何失败作业——每个 release-required 作业都必须成功。它的职责只是“报告这次运行的结果”不决定发布是否可以继续。第二步分发前的凭据与资源边界检查在分发之前必须阅读 Push and Manual PR E2E 章节确认所选作业涉及的凭据位置、访问方式、生命周期与移除/清理边界。普通、focused 与 full 运行都可能把凭据暴露给被选中的候选作业这些凭据可能提供推理、Brave Search、消息渠道或受作用域限制的 GitHub 访问能力。分发前必须完成的四项检查审查受信任的main修订——确认要测试的提交本身可接受检查失败运行的产物——从上一轮失败中提取诊断信息移除未清理的外部资源——目标清理流程未能移除的临时资源必须手动删除轮换或撤销任何候选代码可能复制过的凭据——只要候选代码有机会接触过某个凭据就要假定它已被复制。Launchable 作业的凭据边界Exact staging Brev Launchable作业的凭据边界非常明确细节同样记录在 test/e2e/README.mdBREV_API_KEY与BREV_ORG_ID仅在受信任主机的准备阶段使用用于在指定组织中执行 Brev 工作区操作候选代码永远接触不到这对凭据。NEMOCLAW_IMAGE_DISPATCH_TOKEN只以GH_TOKEN的形式暴露给受信任主机脚本用于列出brevdev/nemoclaw-image中成功的生产者运行并下载选定的 staging handoff 产物。NVIDIA_API_KEY作为公开的 NVIDIA 端点凭据在 full E2E 中被以NVIDIA_INFERENCE_API_KEY的名称导出到 Brev guest。guest 中的候选代码可以读取并使用这个推理密钥——这一点必须在分发前明确告知维护者。该工作流在源码检出之前就要求仓库maintain或admin权限。如果清理失败必须删除记录的 workspace并对仍然可能可访问的凭据执行轮换或撤销。两个相邻作业的边界值得一提受保护的托管镜像资质managed-image-protected-runtime只把NVIDIA_API_KEY提供给受信任的资质代码如果其已验证的清理拒绝移除临时 NIM 容器需要人工检查该容器并轮换密钥。而显式专用的staging-brev-launchable-identity作业验证真实的 Launchable 启动、SSH 访问、镜像与烘焙运行时身份但不运行 onboarding 或推理也不满足发布资质见 test/e2e/README.md。Jetson 与 DGX Spark 默认保持禁用标准命令中allow_jetson_dispatchfalseJetson 和 DGX Spark 均不启用。只有获得工作流文档规定的操作员与 runner 批准后才可启用。完整的 Jetson 分发控制契约见 Jetson Dispatch Controller——NemoClaw 拥有受信任的 GitHub Actions 控制器、HTTP 契约 2.0.0、OIDC 令牌流程与证据边界而设备侧服务属于操作员自有基础设施。另外在 DGX Spark 资质开始前GitHub 可能要求一个经授权的环境审查者。第三步解析待测提交分发前先确认 GitHub CLI 已认证并解析出待测试的origin/main提交gh auth status git fetch --prune origin main CANDIDATE_SHA$(git rev-parse origin/main)这里解析出的origin/main提交就是新分发的测试对象。本流程无法选择任意历史提交如果调用方提供了其他候选 SHA应当如实报告本路径无法测试该提交绝不派发不同的提交也不代为决定发布结果。第四步只分发一次设置所选模式与选择器并用一个case语句在本地完成参数校验RUN_MODEordinary|focused|launchable|full E2E_JOBS E2E_TARGETS INCLUDE_LAUNCHABLEfalse case $RUN_MODE in ordinary) ;; focused) if [[ -n $E2E_JOBS -n $E2E_TARGETS ]] || [[ -z $E2E_JOBS -z $E2E_TARGETS ]]; then echo Focused E2E requires jobs or targets, but not both 2 exit 1 fi ;; launchable) E2E_JOBSstaging-brev-launchable ;; full) INCLUDE_LAUNCHABLEtrue ;; *) echo Unknown E2E mode: $RUN_MODE 2; exit 1 ;; esac然后生成一个关联 IDcorrelation ID并只分发一次工作流CORRELATION_ID$(python3 -c import uuid; print(uuid.uuid4())) gh workflow run .github/workflows/e2e.yaml \ --repo NVIDIA/NemoClaw \ --ref main \ -f targets${E2E_TARGETS} \ -f jobs${E2E_JOBS} \ -f inference_modemock \ -f include_staging_brev_launchable${INCLUDE_LAUNCHABLE} \ -f allow_jetson_dispatchfalse \ -f correlation_id${CORRELATION_ID}要点inference_modemock是分发固定的推理模式allow_jetson_dispatchfalse保持 Jetson 禁用。correlation_id用于在运行列表中唯一定位本次分发且 full 模式的运行标题会带上它E2E full main (id)方便维护者无需逐个扫描作业即可找到最新的完整手动运行。不要因为运行迟迟不出现就再次分发。工作流分发后到显示在列表中存在延迟应使用下面的有界轮询来定位。第五步有界轮询定位运行用有界读取最多 30 次、每次间隔 10 秒在运行列表中查找本次分发产生的运行并校验它测试的提交与CANDIDATE_SHA一致set -euo pipefail RUN_TITLEE2E main (${CORRELATION_ID}) if [[ $RUN_MODE full ]]; then RUN_TITLEE2E full main (${CORRELATION_ID}) fi for POLL_INDEX in $(seq 1 30); do RUNS$(gh run list --repo NVIDIA/NemoClaw --workflow e2e.yaml \ --event workflow_dispatch --branch main --limit 50 \ --json databaseId,displayTitle,headSha,status,url) MATCHES$(jq -c --arg title $RUN_TITLE \ [.[] | select(.displayTitle $title)] $RUNS) test $(jq length $MATCHES) -le 1 RUN_ID$(jq -r .[0].databaseId // empty $MATCHES) test -z $RUN_ID || break sleep 10 done test -n ${RUN_ID:-} RUN_SHA$(jq -r .[0].headSha $MATCHES) test $RUN_SHA $CANDIDATE_SHA这段脚本同时实现了三个约束通过标题精确匹配找到本次分发$RUN_TITLE内含 correlation ID且最多允许一条匹配length 1防止同名运行干扰轮询次数有界30 次 × 10 秒不会无限等待headSha与CANDIDATE_SHA的相等性比较证明了所选运行实际测试的提交。需要注意SHA 比较是“验证测试对象”的手段不是标签授权规则。如果运行在有界搜索窗口内没有出现应直接去 GitHub Actions 中按 correlation ID 人工排查不要再次分发。定位后等待运行完成gh run watch $RUN_ID --repo NVIDIA/NemoClawLaunchable 并发组语义Launchable 并发组staging-brev-launchable-cpu同时被两个 Launchable 作业与.github/workflows/staging-launchable-full.yaml共享采用queue: max与cancel-in-progress: false同一时刻只运行一个条目最多保留 100 个待处理条目条目按进入顺序执行该顺序可能与工作流分发顺序不同队列满时 GitHub 会取消新进入的条目。此外每次 full/focused Launchable 分发都使用github.run_id作为工作流并发身份因此等待期间不会有其他分发将其取代。第六步核验与报告运行完成后把运行与最新尝试的作业保存到私有证据目录模式0700读取时使用 GitHub API 而不是浏览器EVIDENCE_DIR$(mktemp -d) chmod 700 $EVIDENCE_DIR trap rm -rf $EVIDENCE_DIR EXIT gh api repos/NVIDIA/NemoClaw/actions/runs/$RUN_ID $EVIDENCE_DIR/run.json gh api repos/NVIDIA/NemoClaw/actions/runs/$RUN_ID/jobs?filterlatestper_page100 \ $EVIDENCE_DIR/jobs.json核验标准所选运行必须报告head_sha等于CANDIDATE_SHA且status等于completedordinary、focused、Launchable 或 full 运行的成功标志是工作流结论conclusion为success否则需要逐个返回每个 failed、cancelled、skipped 或 running 的作业及其 URLlaunchable 模式额外要求存在一个完成且成功的Exact staging Brev Launchable作业并保留launchable-e2e.json、full-e2e.log与cleanup.json三类诊断产物的链接full 模式额外要求存在一个完成且成功的Release qualification作业。被跳过skipped、取消cancelled、排队queued或失败failed的聚合结果都不算通过的 full 运行。最终向维护者返回模式与选择器RUN_MODE、jobs、targets被测 SHA工作流状态、结论、尝试次数与 URL相关作业 URL。Release qualification的严格语义源码级印证“严格”不是一句口号仓库里有一组专门的单元测试约束它的行为。在 test/e2e/support/release-qualification.test.ts 中可以看到任何 release-required 作业失败都会让聚合失败测试rejects a failure in any release-required E2E job把staging-brev-launchable置为failure后断言抛错Release qualification did not pass: staging-brev-launchable非 success 状态一律不算通过failure、cancelled、skipped、甚至缺失undefined都被归为unknown状态记录到签收receipt中聚合只做报告assertReleaseQualification输出签收并返回状态但流程语义明确“它不授权或拒绝一个 tag”同一文件的测试还验证了无效作业 ID 列表、空选择视为成功的控制器级 no-op、以及重复写签收文件时抛出EEXIST防止覆盖证据。这与 test/e2e/README.md 的说明一致Release qualification等待每一个不需要单独 opt-in 的 E2E 作业包括Exact staging Brev Launchable报告 full 运行是否通过但不授权、不拒绝发布。做出发布决策时应报告最新可识别的 full 运行的时间戳、被测提交 SHA、工作流结果、Release qualification结果以及每个未成功的作业并将被测 SHA 与发布候选对比——但不要求二者必须匹配也不施加陈旧性阈值。维护者可以基于报告继续推进、重跑 focused 作业或请求另一次 full 运行。操作红线总结只分发一次不因运行出现慢而重复分发定位失败就按 correlation ID 去 Actions 里查。不越权选择只能测origin/main当前提交不测历史提交不替维护者决定发布结果。不推断模式通用 E2E 请求不授权 Launchable只有请求包含冲突模式表述时才追问。分发前清账审查修订、检查失败产物、移除残留资源、轮换可能被复制的凭据。报告即终点返回模式、SHA、状态/结论/尝试/URL 与作业 URL 后收尾Release qualification只报告运行nemoclaw-maintainer-cut-release-tag技能才拥有常规 E2E 决策权并会在签署的发布简报中记录任何“在异常状态下继续推进”的理由。赞分享【免费下载链接】NemoClawRun agents like Hermes, LangChain Deep Agents, and OpenClaw more securely inside NVIDIA OpenShell with managed inference项目地址https://gitcode.com/gh_mirrors/ne/NemoClaw点击查看免费下载相关推荐NemoClaw Maintainer E2E受信任 E2E 运行、PR 精确对照与发布证据核查指南NemoClaw Maintainer E2E受信任 E2E 运行、PR 精确对照与发布证据核查指南 导读 本指南以 NemoClaw 仓库中维护者专用的 nNemoClaw 暂存 Brev Launchable E2E 边界解析可信分发、凭据隔离与清理保证NemoClaw 暂存 Brev Launchable E2E 边界解析可信分发、凭据隔离与清理保证 Exact staging Brev LaunchablNemoClaw 持续 E2E 失败维护面向 main 分支的根因队列化自动化修复工作流NemoClaw 持续 E2E 失败维护面向 main 分支的根因队列化自动化修复工作流 导读 本文围绕 NemoClaw 仓库中面向 main 分支自动 E上一篇Termbox-Go 项目推荐下一篇Go-Restful构建RESTful API的轻量级Go框架终极指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考