Rerun 交互式发布检查清单（Interactive Release Checklist）：机制、运行与扩展实践

Rerun 交互式发布检查清单Interactive Release Checklist机制、运行与扩展实践【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun本篇文章以 tests/python/release_checklist/README.md 为主线深入讲解 Rerun 仓库中用于发布前人工验证的交互式检查清单机制它的设计理念、运行方式、逐条验收流程以及如何在日常开发中为不可自动化测试的功能新增检查项。读完本文你将掌握这套用 Rerun recording 承载测试说明与测试数据的发布门禁流程并能基于仓库源码亲手添加新的 check 模块。什么是 Rerun 的交互式发布检查清单Rerun 是一个用于可视化、查询和流式处理多模态机器人数据的开源项目。其核心产品形态是 Rerun Viewer——一个能够回放、浏览各类时序与空间数据的交互式查看器。正因如此仓库中大量功能如视图交互、面板布局、快捷键、渲染效果很难用纯自动化断言覆盖需要真人点一点、看一看才能确认。tests/python/release_checklist/README.md 描述的正是针对这一痛点设计的交互式发布检查清单Interactive release checklistEach check comes in the form a recording that contains:a markdown document specifying the user actions to be tested, andthe actual data required to test these actions.也就是说每一个检查项check都是一条 Rerun 录制recording它同时包含两部分一份 Markdown 操作说明以 Rerun 的TextDocument视图形式呈现在 Viewer 中逐条告诉测试人员该测什么、怎么测、期望看到什么真实测试数据与操作说明配套的、能够触发被测功能的实际数据确保测试人员不需要额外准备素材打开即可操作。检查人员只需在 Viewer 中一条一条地打开这些 recording按说明执行操作全部通过即代表当前代码处于可发布releasable状态。这套机制把人工回归测试从零散的临时步骤沉淀为仓库内可持续累积、可重复执行的正式流程。如何运行检查清单原文档给出了唯一的启动命令pixi run py-build pixi run uv run tests/python/release_checklist/main.py这条命令由两步组成各自有明确职责第一步pixi run py-build——构建并安装 rerun-sdkRerun 使用 pixiconda 生态的包管理与任务运行器管理开发环境Python 侧的 SDK 则通过 rerun_py/Cargo.toml 用 maturin 构建。查看 pixi.toml 中py-build任务的实际定义py-build { cmd uv run maturin develop --uv --manifest-path rerun_py/Cargo.toml --extrastests,catalog,dataloader,tracing, env { RERUN_ALLOW_MISSING_BIN 1 } }maturin develop以开发模式debug编译 Rust 扩展并安装到当前的 uv 虚拟环境Python 代码直接从rerun_py/rerun_sdk/源码目录导入修改后无需重新安装即可生效--extrastests,catalog,dataloader,tracing同时安装测试、catalog、dataloader 与 tracing 所需的额外依赖RERUN_ALLOW_MISSING_BIN 1允许 maturin 在rerun-sdk包内缺少原生rerun可执行文件的情况下继续构建见 pixi.toml 的注释说明。按 pixi.toml 中的环境说明Python 运行时依赖托管在并行的 uv 环境中pixi run py-build会把 rerun-sdk 安装进该 uv 环境供后续pixi run uv ...使用。第二步运行main.py——生成全部检查 recordingpixi run uv run tests/python/release_checklist/main.py会在当前 uv 环境下执行清单主程序。它不需要任何额外参数核心逻辑集中在 tests/python/release_checklist/main.pydef log_checks(args: argparse.Namespace) - None: modules glob.glob(join(dirname(__file__), *.py)) modules [basename(f)[:-3] for f in modules if isfile(f) and basename(f).startswith(check_)] for module in modules: m importlib.import_module(module) m.run(args) def log_readme() - None: with open(join(dirname(__file__), README.md), encodingutf8) as f: rr.log(readme, rr.TextDocument(f.read(), media_typerr.MediaType.MARKDOWN), staticTrue) def main() - None: parser argparse.ArgumentParser(descriptionInteractive release checklist) rr.script_add_args(parser) args parser.parse_args() log_checks(args) # Log instructions last so thats what people see first. rr.script_setup(args, instructions) log_readme()程序流程可以拆解为三步发现所有检查模块用glob扫描本目录下所有以check_开头的.py文件去掉扩展名得到模块名逐个执行通过importlib.import_module动态导入每个模块并调用其统一的run(args)入口每个模块负责生成自己那条 recording最后展示说明main()在全部 check 生成完毕后才以instructions作为 application id 调用rr.script_setup并把本 README 原文作为静态TextDocument记录写入。代码注释写得很清楚——Log instructions last so thats what people see first先执行检查再写说明是为了让测试人员打开 Viewer 时第一眼看到的就是操作指南。这里体现了main.py的一个重要设计新增一个检查项不需要改动main.py的任何代码只要在目录下新增一个check_xxx.py文件即可符合约定优于配置的思路。查看结果进入 Viewer 逐条验收运行后程序会调用rr.script_setup默认行为是rec.spawn()自动拉起 Rerun Viewer。Viewer 中会出现若干条 recording应用 ID 各不相同其中以instructions为 ID 的那条就是操作说明。检查人员按顺序逐一打开每条 recording对照其中的 Markdown 说明执行操作若一切正常就关闭该 recording进入下一条若全部 recording 均通过则当前代码处于可发布状态releasable state。发布时的使用流程原文档对发布阶段的用法做了精炼约定可归纳为三点每条检查 一条 recording内含要测的用户操作说明Markdown与测这些操作所需的真实数据逐条检查、逐条关闭在 Viewer 中一条一条打开 recording按说明完成操作确认无误后关闭继续下一条全部关闭即达成发布条件只要所有检查项都被验证通过就意味着功能回归层面达到了可发布状态。这套流程的巧妙之处在于它把发布前人工回归变成了数据驱动的过程。每条 recording 既携带说明又携带数据测试人员不需要回忆上次是怎么测的、也不需要四处寻找测试素材打开即测把人为遗漏降到最低。开发时如何沉淀新的检查项原文档强调每次提交 PR 新增功能或修复 bug 时如果该改动无法通过自动化方式测试就应停下来想一想我手动测试时做了哪些操作这些操作是否应该沉淀为一条新检查这是让检查清单持续生长、不被版本迭代淘汰的关键习惯。新增检查项的步骤非常轻量在本目录tests/python/release_checklist/下新建文件命名遵循check_something_something.py参考已有检查项的写法实现run(args)入口main.py会自动发现并执行它——Each recording/check has a dedicated file that gets called frommain.py; thats it.每条 recording/check 都有一个专属文件由main.py统一调用仅此而已。源码剖析一个检查模块长什么样当前仓库自带一个完整的检查示例 tests/python/release_checklist/check_notebook.py它以检查 Google Colab 能否配合最新 RC 版本正常工作为主题是理解检查模块约定最好的范本import os from argparse import Namespace from uuid import uuid4 import rerun as rr import rerun.blueprint as rrb README \ # Notebook Make sure to check that Google Colab works properly with the latest release candidate. To do that, go to https://colab.research.google.com/drive/1R9I7s4o6wydQC_zkybqaSRFTtlEaked_ change the version at the top to the latest alpha/rc and step through the notebook (running all at once might cause some viewers to stay empty). def log_readme() - None: rr.log(readme, rr.TextDocument(README, media_typerr.MediaType.MARKDOWN), staticTrue) def run(args: Namespace) - None: rr.script_setup( args, f{os.path.basename(__file__)}, recording_iduuid4(), ) rr.send_blueprint(rrb.Grid(rrb.TextDocumentView(originreadme)), make_activeTrue, make_defaultTrue) log_readme()从这个示例可以提炼出检查模块的统一约定要素说明示例实现文件命名必须以check_开头check_notebook.py统一入口每个模块导出run(args: Namespace) - Nonedef run(args)独立录制每个 check 用rr.script_setup开启自己的 recordingrr.script_setup(args, os.path.basename(__file__), recording_iduuid4())唯一 ID用uuid4()生成recording_id避免多条 check 相互冲突recording_iduuid4()说明即数据操作说明作为 MarkdownTextDocument写入rr.log(readme, rr.TextDocument(README, media_typerr.MediaType.MARKDOWN), staticTrue)布局定制可选地通过send_blueprint定制 Viewer 布局让说明视图第一时间可见rrb.Grid(rrb.TextDocumentView(originreadme))几点实现细节值得注意staticTrue使说明文档成为静态非时序数据确保它始终存在且不被时间轴过滤recording_iduuid4()由于rr.script_setup默认的 recording_id 基于multiprocessing.current_process().authkey推导见 _script_helpers.py 的注释多个 check 若在同一个进程内顺序执行必须显式传入各自唯一的 UUID否则会被并入同一条 recording。main.py中所有 check 恰好都在同一进程内执行因此check_notebook.py显式指定recording_id是必要而非冗余的防御性写法send_blueprint以make_activeTrue, make_defaultTrue主动激活该检查的布局Grid 中放置一个TextDocumentView指向originreadme保证测试人员打开 recording 时直接看到操作说明视图。底层支撑script_add_args与script_setup检查模块的run(args)之所以能接收统一的args且能根据运行方式自动决定拉起 Viewer / 连接外部 Viewer / 保存为 rrd依赖的是 Rerun SDK 的脚本辅助 API定义在 rerun_py/rerun_sdk/rerun/_script_helpers.pyrr.script_add_args(parser)为脚本注入通用命令行参数参数作用--headless不显示 GUI适合 CI 或无头环境--connect连接到一个外部 Viewer--serve启动 gRPC 与 Web 服务器并打开连接该服务器的 Web Viewer--url指定要连接的 Rerun URL--save将数据保存为.rrd文件到指定路径--stdout将数据输出到标准输出供管道传入 Rerun Viewerrr.script_setup(args, application_id, recording_id..., default_blueprint...)负责初始化录制环境内部调用rr.init(..., default_enabledTrue, strictTrue)然后按优先级处理--stdout/--serve/--connect/--save/ 默认spawn分支见 _script_helpers.py。这意味着发布检查清单在无头场景下同样可用例如用--save checklist.rrd把全部检查录制导出为 rrd 文件再在任意安装了 Rerun 的环境回放验收或配合--headless在 CI 中预生成检查数据。不过要注意原文档明确要求的是真人逐条交互验收自动化手段只能辅助生成数据无法替代人工确认功能正常这一环。小结Rerun 的交互式发布检查清单是一套低成本、高收益的发布门禁实践运行简单一条pixi run py-build pixi run uv run tests/python/release_checklist/main.py命令即可生成全部检查 recording 并拉起 Viewer验收闭环每条检查 Markdown 操作说明 配套真实数据逐条查看关闭全部通过即达到可发布状态易扩展新增check_xxx.py并提供run(args)入口即自动纳入清单main.py无需任何改动依赖清晰底层复用rr.script_add_args/rr.script_setup的通用脚本框架支持--save、--headless等扩展用法。对于任何包含大量只能人肉验证交互功能的项目这套以数据录制承载人工回归的思路都值得借鉴把每次手测的动作固化为可复现的 recording让发布前的每一次人工检查都有据可依、不漏不重。延伸阅读检查清单的说明文档即 tests/python/release_checklist/README.md入口实现见 main.py完整示例见 check_notebook.py底层脚本辅助 API 见 rerun_py/rerun_sdk/rerun/_script_helpers.pypy-build任务定义见 pixi.toml。【免费下载链接】rerunVisualize, query, and stream to train on multimodal robotics data.项目地址: https://gitcode.com/GitHub_Trending/re/rerun创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考