尧图网页设计 
openpilot 如何按 release 流程把 staging 分支推进到正式发布【免费下载链接】openpilotopenpilot is an operating system for robotics. Currently, it upgrades the driver assistance system on 300 supported cars.项目地址: https://gitcode.com/GitHub_Trending/op/openpilotopenpilot 的每次正式发版都遵循同一套流程:先把 master 上冻结好的版本推到 staging 分支做设备端构建和测试,确认通过后在 staging 构建结果上打 tag,再创建 GitHub release 并更新线上安装入口。这套流程的官方清单在 tools/release/README.md 中,分为 “Go to staging” 和 “Go to release” 两个阶段。本文按该清单给出完整的操作路径、每一步用到的构建脚本实际做了什么,以及脚本内置的硬性校验条件。前提:操作者在 openpilot 仓库中拥有推送权限(包括向devel-staging和发布 tag 推送),Jenkins 与测试设备侧由 CI 自动完成。清单中涉及的设备端构建、test_onroad测试均由 Jenkins 触发,操作者本地只需执行推送、打 tag 等 git 操作。release 流程的两个阶段tools/release/README.md 定义的清单结构是:Go to staging:创建 release 分支并回退风险提交 → 用build_stripped.sh推送到devel-staging→ Jenkins 自动在设备上构建 staging 并运行test_onroad→ 在 master 上把版本号 bump 到下一个开发版本。Go to release:完成升级/回退/全新安装等测试清单 → 把本地对齐到origin/release-mici-staging构建分支 → 打 tag 并推送 → 创建 GitHub release → 在openpilot.comma.ai做最终测试安装并更新 factory provisioning → 关闭 milestone 和 issue。仓库的 Jenkinsfile 中,分支名匹配devel-staging、release-tizi-staging、release-mici-staging等分支时会跳过常规测试流水线(它们出现在excludeBranches列表中),devel-staging分支则单独触发设备端 release 构建,这与清单中 “Jenkins will then automatically build staging on device” 对应。阶段一:创建 release 分支并推送到 staging创建并推送 release master 分支清单要求先建一个 GitHub issue 用该 checklist 跟踪本次 release,然后:从 upstream master 创建一个 release master 分支。清单给出的示例是:为 releasev0.10.2创建名为zerotentwo的分支。在该分支上回退风险提交(revert risky commits),清单注明需要与 autonomy team 双重确认。推送这个新分支。运行 build_stripped.sh 推送到 devel-staging确认当前所在分支是刚创建的 release 分支后,在仓库根目录执行:BRANCHdevel-staging tools/release/build_stripped.sh这条命令会向远端force push覆盖devel-staging分支,属于破坏性操作,只在 release 分支上运行。tools/release/build_stripped.sh 的实际行为:用mktemp -d创建一个临时目标目录,把仓库的.git复制进去,创建一个 orphan 分支tmp;按 tools/release/release_files.py 输出的文件清单把源码复制到临时目录,并删除.git/modules/;对openpilot/selfdrive/modeld/models下大于 95M 的*.onnx文件用openpilot/common/file_chunker.py切块;从openpilot/common/version.h读取版本号,连同源 commit hash 与构建时间写入提交信息(提交身份由 tools/release/identity.sh 设置为Vehicle Researcher usercomma.ai);依次做三项硬性校验,任一不满足就exit 1:存在 submodule、存在 LFS 文件(git lfs ls-files非空)、存在超过 95M 的文件(脚本注释说明是为满足 GitHub 的 100MB 限制);最后以pack.window0 pack.depth0 pack.compression0的参数执行git push -f origin tmp:$BRANCH,即把构建好的 stripped 树推到devel-staging。$BRANCH未设置时脚本只生成本地临时目录不推送;本场景必须显式传BRANCHdevel-staging。Jenkins 自动构建设备端 staging 分支推送到devel-staging后不需要人工干预:Jenkinsfile 在env.BRANCH_NAME devel-staging时,锁定tizi-needs-can设备执行RELEASE_BRANCHrelease-tizi-staging,release-mici-staging $SOURCE_DIR/tools/release/build_release.sh其中$SOURCE_DIR是 CI 环境中的 openpilot 源码路径(Jenkinsfile 中设置为/data/openpilot_source/)。tools/release/build_release.sh 在设备上完成:未设置RELEASE_BRANCH时直接exit 1,所以上面的环境变量必须带;在/data/openpilot建 worktree,按release_files.py文件清单复制源码;把 CPU 频率上限提到cpuinfo_max_freq,然后执行scons全量构建;若设置了INCLUDE_BIG_MODEL,会检查openpilot/selfdrive/modeld/models/big_driving_tinygrad.pkl.chunkmanifest存在;未设置PANDA_DEBUG_BUILD时用CERT/data/pandaextra/certs/release RELEASE1 scons panda/构建 release 版 panda 固件;校验 release 中不存在 submodule,否则退出;清理.a/.o/.os/.pyc/__pycache__及Jenkinsfile、tools/release/等文件,touch prebuilt标记为预构建版本;运行RELEASE1 ./openpilot/selfdrive/test/test_onroad.py;把构建结果分支release-mici-stagingforce push 到RELEASE_BRANCH逗号分隔的每个分支,即release-tizi-staging和release-mici-staging。这就是清单里 “Jenkins will then automatically build staging on device, runtest_onroadand update the staging branch” 的具体实现。构建与测试通过即表示 staging 侧就绪,清单最后一步是在 Discord 上 release crew 通知。在 master 上更新版本号staging 推送完成后,清单要求在 master 上 bump 版本,涉及两处:openpilot/common/version.h,当前内容为#define COMMA_VERSION 0.11.2,构建脚本从这一行提取版本号写入 release 提交信息;RELEASES.md,按既有格式在文件头部追加一条版本记录,例如已有条目形如Version 0.11.2 (2026-08-12)后跟功能与车型支持的项目符号列表。阶段二:从 staging 推进到正式发布正式发布前的测试清单清单在 “Go to release” 一节列出的必测项,全部通过后才继续:从上一个 release 升级到新 release;从新 release 降级回上一个 release;使用openpilot-test.comma.ai全新安装;在全新安装上实际驾驶验证;release 中没有 submodule 或 LFS(对应build_stripped.sh的校验项);检查 MTBF 等指标;production 上的 stress test 通过。对齐构建分支、打 tag 并创建 GitHub release测试通过后,清单给出的命令依次是(两条命令中的v0.X.X替换为本次发布的版本号,如v0.10.2;commit-hash替换为本次 release 对应的 commit hash):git reset --hard origin/release-mici-staginggit reset --hard会丢弃当前分支上的本地改动,执行前先确认工作区没有未提交内容。该命令把本地 HEAD 对齐到 Jenkins 构建并推送的release-mici-staging分支,即发布对象必须是设备端实际构建、跑过test_onroad的那份树。git tag v0.X.X commit-hash git push origin v0.X.Xtag 打在 release 对应的 commit 上并推送到远端,这是正式发布版本号的标记。随后在 GitHub 上创建对应的 GitHub release。收尾动作清单剩余步骤:在openpilot.comma.ai上做最终测试安装,确认线上安装入口指向新 release;更新 factory provisioning;关闭本次 release 的 milestone 和跟踪 issue;在 Discord、X 等渠道发布公告(清单同时要求在正式 release 前发布 blog post)。构建链路上的硬性校验与失败信号整条流程的自动校验点,出现以下信号即视为构建失败:校验点所在位置失败条件无 submodule、无 LFS、无大于 95M 的文件build_stripped.sh任一条件不满足即exit 1,staging 分支不会被更新RELEASE_BRANCH必须设置build_release.sh未设置直接exit 1release 中不得包含 submodulebuild_release.shgit submodule--helper list非空则退出并打印列表test_onroad通过build_release.sh运行RELEASE1 ./openpilot/selfdrive/test/test_onroad.py,脚本带set -e,失败则不会执行后续的 push构建后工作区干净check-dirty.shgit status --porcelain非空则失败(Jenkins 常规流水线的 onroad 阶段使用)流程到此以实际验证结果收尾:staging 分支更新成功说明设备端构建与test_onroad已通过,tag 与 GitHub release 创建完成、openpilot.comma.ai最终测试安装通过、factory provisioning 更新后,本次 release 即按 tools/release/README.md 清单闭环。【免费下载链接】openpilotopenpilot is an operating system for robotics. Currently, it upgrades the driver assistance system on 300 supported cars.项目地址: https://gitcode.com/GitHub_Trending/op/openpilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 openpilot 如何按 release 流程把 staging 分支推进到正式发布？
openpilot 如何按 release 流程把 staging 分支推进到正式发布【免费下载链接】openpilotopenpilot is an operating system for robotics. Currently, it upgrades the driver assistance system on 300 supported cars.项目地址: https://gitcode.com/GitHub_Trending/op/openpilotopenpilot 的每次正式发版都遵循同一套流程:先把 master 上冻结好的版本推到 staging 分支做设备端构建和测试,确认通过后在 staging 构建结果上打 tag,再创建 GitHub release 并更新线上安装入口。这套流程的官方清单在 tools/release/README.md 中,分为 “Go to staging” 和 “Go to release” 两个阶段。本文按该清单给出完整的操作路径、每一步用到的构建脚本实际做了什么,以及脚本内置的硬性校验条件。前提:操作者在 openpilot 仓库中拥有推送权限(包括向devel-staging和发布 tag 推送),Jenkins 与测试设备侧由 CI 自动完成。清单中涉及的设备端构建、test_onroad测试均由 Jenkins 触发,操作者本地只需执行推送、打 tag 等 git 操作。release 流程的两个阶段tools/release/README.md 定义的清单结构是:Go to staging:创建 release 分支并回退风险提交 → 用build_stripped.sh推送到devel-staging→ Jenkins 自动在设备上构建 staging 并运行test_onroad→ 在 master 上把版本号 bump 到下一个开发版本。Go to release:完成升级/回退/全新安装等测试清单 → 把本地对齐到origin/release-mici-staging构建分支 → 打 tag 并推送 → 创建 GitHub release → 在openpilot.comma.ai做最终测试安装并更新 factory provisioning → 关闭 milestone 和 issue。仓库的 Jenkinsfile 中,分支名匹配devel-staging、release-tizi-staging、release-mici-staging等分支时会跳过常规测试流水线(它们出现在excludeBranches列表中),devel-staging分支则单独触发设备端 release 构建,这与清单中 “Jenkins will then automatically build staging on device” 对应。阶段一:创建 release 分支并推送到 staging创建并推送 release master 分支清单要求先建一个 GitHub issue 用该 checklist 跟踪本次 release,然后:从 upstream master 创建一个 release master 分支。清单给出的示例是:为 releasev0.10.2创建名为zerotentwo的分支。在该分支上回退风险提交(revert risky commits),清单注明需要与 autonomy team 双重确认。推送这个新分支。运行 build_stripped.sh 推送到 devel-staging确认当前所在分支是刚创建的 release 分支后,在仓库根目录执行:BRANCHdevel-staging tools/release/build_stripped.sh这条命令会向远端force push覆盖devel-staging分支,属于破坏性操作,只在 release 分支上运行。tools/release/build_stripped.sh 的实际行为:用mktemp -d创建一个临时目标目录,把仓库的.git复制进去,创建一个 orphan 分支tmp;按 tools/release/release_files.py 输出的文件清单把源码复制到临时目录,并删除.git/modules/;对openpilot/selfdrive/modeld/models下大于 95M 的*.onnx文件用openpilot/common/file_chunker.py切块;从openpilot/common/version.h读取版本号,连同源 commit hash 与构建时间写入提交信息(提交身份由 tools/release/identity.sh 设置为Vehicle Researcher usercomma.ai);依次做三项硬性校验,任一不满足就exit 1:存在 submodule、存在 LFS 文件(git lfs ls-files非空)、存在超过 95M 的文件(脚本注释说明是为满足 GitHub 的 100MB 限制);最后以pack.window0 pack.depth0 pack.compression0的参数执行git push -f origin tmp:$BRANCH,即把构建好的 stripped 树推到devel-staging。$BRANCH未设置时脚本只生成本地临时目录不推送;本场景必须显式传BRANCHdevel-staging。Jenkins 自动构建设备端 staging 分支推送到devel-staging后不需要人工干预:Jenkinsfile 在env.BRANCH_NAME devel-staging时,锁定tizi-needs-can设备执行RELEASE_BRANCHrelease-tizi-staging,release-mici-staging $SOURCE_DIR/tools/release/build_release.sh其中$SOURCE_DIR是 CI 环境中的 openpilot 源码路径(Jenkinsfile 中设置为/data/openpilot_source/)。tools/release/build_release.sh 在设备上完成:未设置RELEASE_BRANCH时直接exit 1,所以上面的环境变量必须带;在/data/openpilot建 worktree,按release_files.py文件清单复制源码;把 CPU 频率上限提到cpuinfo_max_freq,然后执行scons全量构建;若设置了INCLUDE_BIG_MODEL,会检查openpilot/selfdrive/modeld/models/big_driving_tinygrad.pkl.chunkmanifest存在;未设置PANDA_DEBUG_BUILD时用CERT/data/pandaextra/certs/release RELEASE1 scons panda/构建 release 版 panda 固件;校验 release 中不存在 submodule,否则退出;清理.a/.o/.os/.pyc/__pycache__及Jenkinsfile、tools/release/等文件,touch prebuilt标记为预构建版本;运行RELEASE1 ./openpilot/selfdrive/test/test_onroad.py;把构建结果分支release-mici-stagingforce push 到RELEASE_BRANCH逗号分隔的每个分支,即release-tizi-staging和release-mici-staging。这就是清单里 “Jenkins will then automatically build staging on device, runtest_onroadand update the staging branch” 的具体实现。构建与测试通过即表示 staging 侧就绪,清单最后一步是在 Discord 上 release crew 通知。在 master 上更新版本号staging 推送完成后,清单要求在 master 上 bump 版本,涉及两处:openpilot/common/version.h,当前内容为#define COMMA_VERSION 0.11.2,构建脚本从这一行提取版本号写入 release 提交信息;RELEASES.md,按既有格式在文件头部追加一条版本记录,例如已有条目形如Version 0.11.2 (2026-08-12)后跟功能与车型支持的项目符号列表。阶段二:从 staging 推进到正式发布正式发布前的测试清单清单在 “Go to release” 一节列出的必测项,全部通过后才继续:从上一个 release 升级到新 release;从新 release 降级回上一个 release;使用openpilot-test.comma.ai全新安装;在全新安装上实际驾驶验证;release 中没有 submodule 或 LFS(对应build_stripped.sh的校验项);检查 MTBF 等指标;production 上的 stress test 通过。对齐构建分支、打 tag 并创建 GitHub release测试通过后,清单给出的命令依次是(两条命令中的v0.X.X替换为本次发布的版本号,如v0.10.2;commit-hash替换为本次 release 对应的 commit hash):git reset --hard origin/release-mici-staginggit reset --hard会丢弃当前分支上的本地改动,执行前先确认工作区没有未提交内容。该命令把本地 HEAD 对齐到 Jenkins 构建并推送的release-mici-staging分支,即发布对象必须是设备端实际构建、跑过test_onroad的那份树。git tag v0.X.X commit-hash git push origin v0.X.Xtag 打在 release 对应的 commit 上并推送到远端,这是正式发布版本号的标记。随后在 GitHub 上创建对应的 GitHub release。收尾动作清单剩余步骤:在openpilot.comma.ai上做最终测试安装,确认线上安装入口指向新 release;更新 factory provisioning;关闭本次 release 的 milestone 和跟踪 issue;在 Discord、X 等渠道发布公告(清单同时要求在正式 release 前发布 blog post)。构建链路上的硬性校验与失败信号整条流程的自动校验点,出现以下信号即视为构建失败:校验点所在位置失败条件无 submodule、无 LFS、无大于 95M 的文件build_stripped.sh任一条件不满足即exit 1,staging 分支不会被更新RELEASE_BRANCH必须设置build_release.sh未设置直接exit 1release 中不得包含 submodulebuild_release.shgit submodule--helper list非空则退出并打印列表test_onroad通过build_release.sh运行RELEASE1 ./openpilot/selfdrive/test/test_onroad.py,脚本带set -e,失败则不会执行后续的 push构建后工作区干净check-dirty.shgit status --porcelain非空则失败(Jenkins 常规流水线的 onroad 阶段使用)流程到此以实际验证结果收尾:staging 分支更新成功说明设备端构建与test_onroad已通过,tag 与 GitHub release 创建完成、openpilot.comma.ai最终测试安装通过、factory provisioning 更新后,本次 release 即按 tools/release/README.md 清单闭环。【免费下载链接】openpilotopenpilot is an operating system for robotics. Currently, it upgrades the driver assistance system on 300 supported cars.项目地址: https://gitcode.com/GitHub_Trending/op/openpilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考