深入 reth 的 CI 流水线从单元测试到发布打包的完整实践【免费下载链接】rethModular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, in Rust项目地址: https://gitcode.com/GitHub_Trending/re/rethreth 仓库的持续集成体系以 CI 说明文档 为总纲将流水线划分为代码测试、文档构建、元流程Meta、集成测试与 Lint 检查五类工作流全部定义在.github/workflows目录中。本文基于该文档逐条梳理每个工作流的职责与真实实现你会掌握 reth 每类 CI 的触发条件、关键命令如cargo nextest run、reth stage run、make build-native-*与参数含义理解 Docker 镜像变更的规范流程并知道如何用 PR 评论触发性能基准测试从而能够读懂、复用乃至排查 reth 的 CI 行为。CI 工作流全景reth 的 CI 共五类工作流与 docs/repo/ci.md 中的清单一一对应分类工作流对应定义文件Codeunit / integration / bench / sync / stageunit.yml、integration.yml、bench.yml、sync.yml、stage.ymlDocsbookbook.ymlMetarelease / release-dist / dependencies / stale / dockerrelease.yml、release-dist.yml、dependencies.yml、stale.yml、docker.yml集成测试kurtosis / hivekurtosis.yml、hive.ymlLint 与检查lint / lint-actions / label-prlint.yml、lint-actions.yml、label-pr.yml几乎所有工作流都遵循相同的工程约定在仓库为paradigmxyz/reth时使用更高规格的depot-ubuntu-latest*自托管 Runnerfork 仓库回落到ubuntu-latest统一通过rui314/setup-mold安装 mold 链接器、install_llvm.sh安装 LLVM、RUSTC_WRAPPER: sccache配合Swatinem/rust-cache缓存编译产物以压缩构建时间并以concurrency组实现同一 PR 的旧运行自动取消。Code 工作流unit单元测试与文档测试unit.yml 在pull_request、merge_group与 main 分支push时触发包含三个并行 Job 加一个汇总 Jobtest单元测试用cargo nextest run执行全工作区测试关键过滤表达式为cargo nextest run \ --no-fail-fast \ --features asm-keccak --locked \ --workspace \ --exclude ef-tests --no-testswarn \ -E !kind(test) and not binary(e2e_testsuite)其中asm-keccak开启 Keccak 汇编加速特性--exclude ef-tests将以太坊执行规格测试移到独立 Job-E表达式排除 e2e 二进制保证只跑src/内的单元测试与测试目标。stateEthereum state tests额外检出ethereum/tests仓库固定到某个 commit到testing/ef-tests/ethereum-tests并下载 Execution Spec Tests 的 fixture工作流中通过环境变量EEST_TESTS_TAG指定版本标签当前为 v4.5.0随后以--cargo-profile hivetests -p ef-tests --features asm-keccak ef-tests运行 testing/ef-tests 中的状态测试。doc文档测试cargo test --doc --workspace --all-features验证所有 Rust 文档示例可编译运行。unit-success使用re-actors/alls-green汇总上述 Job 的最终状态。integration集成测试integration.yml 在 PR、merge group、main push 之外还增加了每日0 3 * * *UTC 03:00的定时触发。两个测试 Job 按事件区分非定时事件运行testJob先执行.github/scripts/install_geth.sh安装 geth部分集成测试依赖外部客户端然后用 nextest 运行全工作区tests/下的集成测试表达式为kind(test) and not binary(e2e_testsuite)即不跑 e2e 套件但覆盖集成测试目标。定时事件运行era-filesJobcargo nextest run --no-fail-fast --release --package reth-era --test it -- --ignored即对 crates/era 的 era/era1/ere 文件格式执行标记为--ignored的每日集成测试。bench性能基准bench.yml 是 reth CI 中最复杂的工作流之一用于在同一个区块范围内对比 baseline 与候选feature两个二进制的性能。它通过 Engine API 回放真实区块或把交易提交到本地出块节点的 txpool 中节点由 schelk 管理的本地快照支撑。它有两条触发路径PR 评论命令以decofe bench或derek bench开头的评论触发工作流会先校验评论者与 PR 作者均为paradigmxyz组织成员再解析命令参数。以decofe clear开头则把历史基准评论折叠为 OUTDATED。workflow_dispatch 手动触发提供一组显式输入参数核心包括blocks基准区块数默认 500big blocks 模式默认 30modeengineEngine API 区块回放、rpcRPC 交易提交、callRPC call 回放三选一big_blocksfalse/true或目标 gas 值如100M/2Greorgreorg 深度bal是否回放区块访问列表false/true/feature/baselinebaseline/feature对比的 git ref分别默认为 merge-base 与分支头run_pairs运行对数默认 6big blocks 10并自动生成 ABBA 顺序以抵消顺序偏差samply/tracing_chrome/otlp/metrics采样剖析、Chrome trace、OTLP 导出与 VictoriaMetrics 上传cores限制 reth 可用的 CPU 核数0 表示全部。参数解析逻辑对工作流内嵌于 JS 脚本中内置完整的取值校验如wait-time仅限 engine 模式、block-time仅限 rpc 模式解析失败时会在 PR 中回复错误信息与用法说明运行前还会估算排队位置并在 PR 中评论“Benchmark queued”及完整配置摘要。sync同步测试sync.yml 每 6 小时定时运行也可手动触发矩阵中定义了一条 mainnet 同步用例bin: reth。其步骤清晰地演示了一次“同步—校验—回退”的端到端验证# 1. 构建 make install # 2. 同步到指定区块--debug.max-block 限制高度 reth node --chain mainnet \ --debug.tip 0x91c90676cab257a59cd956d7cb0bceb9b1a71d79755c23c7277a0697ccfaf8c4 \ --debug.max-block 100000 \ --debug.terminate # 3. 校验目标区块哈希是否落库 reth db --chain mainnet get static-file headers 100000 | grep tip # 4. 按块数回退 100 个区块 reth stage unwind num-blocks 100 --chain mainnet # 5. 回退到指定区块哈希 reth stage unwind to-block 0x52e0509d33a988ef807058e2980099ee3070187f7333aae12b64d4d675f34c5a --chain mainnet该用例同时覆盖了同步执行正确性哈希校验与 unwind 两条回退路径按块数、按哈希。stage全部 stage run 命令stage.yml 在 merge group 事件中运行避免在 PR 早期阶段消耗大量同步资源以FROM_BLOCK: 0、TO_BLOCK: 50000为范围通过cargo install --locked --path bin/reth安装 CLI 后依次执行reth stage run headers --from 0 --to 50000 --commit --checkpoints reth stage run bodies --from 0 --to 50000 --commit --checkpoints reth stage run senders --from 0 --to 50000 --commit --checkpoints reth stage run execution --from 0 --to 50000 --commit --checkpoints reth stage run merkle --from 0 --to 50000 --commit --checkpoints reth stage run tx-lookup --from 0 --to 50000 --commit --checkpoints reth stage run account-history --from 0 --to 50000 --commit --checkpoints reth stage run storage-history --from 0 --to 50000 --commit --checkpoints工作流注释中特别说明account-hashing / storage-hashing / hashing 三个阶段被有意省略——在 storage v2现为默认下它们是 no-opexecution 阶段直接写入 HashedAccounts/HashedStorages而stage run先 unwind 再执行的语义会导致已写入的哈希状态被回退且无法恢复反而使 merkle 阶段失败。这一注释是对“staged 同步器”行为的重要提示。Docs 工作流bookbook.yml 构建、测试并部署 reth 文档站点基于 Vocs rustdocbuildJob安装 bun 与 Playwright Chromium供 rehype-mermaid 在构建期渲染 Mermaid 图安装 nightly 工具链后执行docs/vocs/scripts/build-cargo-docs.sh生成 rustdoc再bun run build构建 Vocs 站点。随后用一连串test -f/grep断言产物完整性例如docs/dist/public/index.html、docs/reth/index.html存在且 rustdoc 页面包含contentrustdoc。deployJob仅在 main 分支 push 时运行通过actions/configure-pagesactions/deploy-pages将产物发布到 GitHub Pages。此外 lint.yml 中的bookJob 通过./docs/cli/update.sh target/debug/reth重新生成 CLI 帮助文档 并断言git diff --exit-code保证 CLI 文档与二进制输出始终一致。Meta 工作流release发布工作流release.yml 在推送v*标签时触发也可通过workflow_dispatch指定任意 git ref 并开启dry_run只构建、不上传、不创建 Release。流水线为extract-version / check-version从 tag 提取版本号并校验 tag 与cargo metadata中 crate 版本前缀一致允许v1.4.8匹配1.4.8-rc.1。build三平台矩阵均使用maxperfprofilex86_64-unknown-linux-gnuubuntu-24.04RustFLAGS-C target-cpux86-64-v3 -C target-featurepclmulqdqaarch64-unknown-linux-gnuubuntu-24.04-arm 原生构建aarch64-apple-darwinmacos-14 原生构建。通过make ... build-native-target产出二进制打包为reth-VERSION-target.tar.gz含 LICENSES 与 README并用 GPG 私钥签名。draft-release下载全部产物用git log生成 changelog调用gh release create --draft创建带测试清单与二进制下载表的草稿 Release-rc版本自动附加--prerelease标记。release-dist 与 dependencies / stalerelease-dist.yml把 reth 发布到外部包管理器Homebrew、Debian 等渠道仓库内 pkg/reth/debian 目录保留了配套的 Debianreth.service单元文件。dependencies.yml定期执行cargo update保持依赖新鲜配套的依赖机器人配置见.github/dependabot.yml。stale.yml长时间无活动的 issue 自动标记为 stale。docker发布 Docker 镜像docker.yml 的触发与标签策略在文件头部注释中写明推送v*标签构建发布版RC 或 latest非 RC 版本额外打latest标签每日 01:00 UTC 定时构建nightly镜像nightly 构建注入RETH_ENGINE_TXPOOL_PREWARMINGtrue与RETH_ENGINE_SENDER_RECOVERY_CACHEtrue两个构建参数手动workflow_dispatchbuild_type可选git-sha按提交 SHA 打标签或nightly支持dry_run构建但不推送。镜像通过 Depot 远程构建depot/setup-actiondepot/bake-action以 docker-bake.hcl 为输入注入VERGEN_GIT_SHA/DESCRIBE/DIRTY供 vergen 生成版本信息推送到 GHCR随后用.github/scripts/verify_image_arch.sh校验推送镜像的架构完整性夜间构建失败会经 Slack webhook 通知。Docker 工作流变更规范docs/repo/ci.md 用专门一节约束 Docker 相关变更因为一次 Dockerfile 改动往往波及多个工作流。合并 Dockerfile、Docker 构建输入或拷贝进镜像的文件前应检查所有共享同一仓库构建上下文的 Dockerfile 与 bake 目标Dockerfile、Dockerfile.depot、.github/scripts/hive/Dockerfile与docker-bake.hcl保持.dockerignore与所有从仓库上下文拷贝的文件同步——一个文件即使存在于 git也可能因为不在.dockerignore白名单逻辑对应的拷贝列表中而在 Docker 构建中缺失检查这些目标的使用方docker.yml、可复用的 docker-test.yml以及hive.yml、kurtosis.yml等调用者在打开/合并 PR 前若 BuildKit/buildx 可用先做本地语法检查docker build --check -f Dockerfile .、docker build --check -f Dockerfile.depot .、docker buildx bake --print -f docker-bake.hcl对受影响工作流至少跑一次 GitHub Actions dry run发布工作流使用docker.yml的workflow_dispatch参数build_typegit-sha、dry_runtrue更新共享镜像内容时回顾近期的 Docker 相关 PR 与既有运行历史判断故障起始时间与是否波及其他工作流。Integration Testing 工作流kurtosiskurtosis.yml拉起一个 Kurtosis 测试网并在 reth 节点对上运行 Assertoor 测试网络参数配置见.github/assets/kurtosis_network_params.yamlAssertoor 模板见 etc/assertoor。hivehive.yml运行ethereum/hive客户端互操作测试配套脚本集中在.github/scripts/hive目录包括模拟器的构建build_simulators.sh、运行run_simulator.sh、期望失败与忽略清单expected_failures.yaml、ignored_tests.yaml以及日志提取工具。Linting and Checks 工作流lintlint.ymllint 工作流包含十余个并行检查 Job全部以RUSTFLAGS: -D warnings之类的零容忍策略运行clippy-binaries / clippy前者在 stable clippy 下按--workspace --lib --examples --tests --benches --locked并启用asm-keccak jemalloc jemalloc-prof min-*-logs等特性检查后者在 nightly clippy 下以--all-features全量检查。wasm / riscv分别编译wasm32-wasip1与riscv32imac-unknown-none-elf目标脚本为 check_wasm.sh 与 check_rv32imac.sh保障无标准库环境可构建。crate-checks用cargo hack check --workspace --partition N/3做三分区并行 feature 组合编译检查。msrv固定工具链1.95注释标明 MSRV执行cargo build --bin reth --workspace。docsnightly 下cargo docs --document-private-itemsRUSTDOCFLAGS 与 book 工作流保持同步见 lint.yml 中“Keep in sync with ./book.yml:jobs.build”注释。fmtcargo fmt --all --checknightly rustfmt。udepscargo udeps检测未使用的依赖。typos / check-toml拼写检查typos.toml 配置与 dprint.json 驱动的 TOML 格式检查。grafana / no-test-deps / feature-propagation / deny校验 Grafana 看板 JSON 可解析、默认构建不引入arbitrary|proptest测试依赖、用 zepter 校验 feature 传播、以及运行 cargo-deny 策略检查deny.toml。lint-success同样用alls-green汇总全部 Job。lint-actions 与 label-prlint-actions.yml用 actionlint 检查工作流 YAML 本身规则来自.github/actionlint.yaml。label-pr.yml基于.github/scripts/label_pr.js为 PR 自动打标签标签体系说明见 docs/repo/labels.md。小结reth 的 CI 呈现三个鲜明特点其一测试分层清晰——单元测试、集成测试、e2e/状态测试、定时 sync/stage 验证各司其职互不重复其二构建效率优先——mold、sccache、rust-cache、depot 自托管 Runner 与分区编译在所有 Job 中复用同一套加速手段其三发布链路可演练——release 与 docker 工作流均支持dry_run配合文档中给出的docker build --check等本地前置检查使发布类变更可以在真实推送前充分验证。结合 docs/repo/ci.md 与上述工作流文件开发者可以完整回答“某个改动会触发哪些 CI、为什么这样划分、失败时该看哪里”这类问题。【免费下载链接】rethModular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, in Rust项目地址: https://gitcode.com/GitHub_Trending/re/reth创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 深入 reth 的 CI 流水线：从单元测试到发布打包的完整实践
深入 reth 的 CI 流水线从单元测试到发布打包的完整实践【免费下载链接】rethModular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, in Rust项目地址: https://gitcode.com/GitHub_Trending/re/rethreth 仓库的持续集成体系以 CI 说明文档 为总纲将流水线划分为代码测试、文档构建、元流程Meta、集成测试与 Lint 检查五类工作流全部定义在.github/workflows目录中。本文基于该文档逐条梳理每个工作流的职责与真实实现你会掌握 reth 每类 CI 的触发条件、关键命令如cargo nextest run、reth stage run、make build-native-*与参数含义理解 Docker 镜像变更的规范流程并知道如何用 PR 评论触发性能基准测试从而能够读懂、复用乃至排查 reth 的 CI 行为。CI 工作流全景reth 的 CI 共五类工作流与 docs/repo/ci.md 中的清单一一对应分类工作流对应定义文件Codeunit / integration / bench / sync / stageunit.yml、integration.yml、bench.yml、sync.yml、stage.ymlDocsbookbook.ymlMetarelease / release-dist / dependencies / stale / dockerrelease.yml、release-dist.yml、dependencies.yml、stale.yml、docker.yml集成测试kurtosis / hivekurtosis.yml、hive.ymlLint 与检查lint / lint-actions / label-prlint.yml、lint-actions.yml、label-pr.yml几乎所有工作流都遵循相同的工程约定在仓库为paradigmxyz/reth时使用更高规格的depot-ubuntu-latest*自托管 Runnerfork 仓库回落到ubuntu-latest统一通过rui314/setup-mold安装 mold 链接器、install_llvm.sh安装 LLVM、RUSTC_WRAPPER: sccache配合Swatinem/rust-cache缓存编译产物以压缩构建时间并以concurrency组实现同一 PR 的旧运行自动取消。Code 工作流unit单元测试与文档测试unit.yml 在pull_request、merge_group与 main 分支push时触发包含三个并行 Job 加一个汇总 Jobtest单元测试用cargo nextest run执行全工作区测试关键过滤表达式为cargo nextest run \ --no-fail-fast \ --features asm-keccak --locked \ --workspace \ --exclude ef-tests --no-testswarn \ -E !kind(test) and not binary(e2e_testsuite)其中asm-keccak开启 Keccak 汇编加速特性--exclude ef-tests将以太坊执行规格测试移到独立 Job-E表达式排除 e2e 二进制保证只跑src/内的单元测试与测试目标。stateEthereum state tests额外检出ethereum/tests仓库固定到某个 commit到testing/ef-tests/ethereum-tests并下载 Execution Spec Tests 的 fixture工作流中通过环境变量EEST_TESTS_TAG指定版本标签当前为 v4.5.0随后以--cargo-profile hivetests -p ef-tests --features asm-keccak ef-tests运行 testing/ef-tests 中的状态测试。doc文档测试cargo test --doc --workspace --all-features验证所有 Rust 文档示例可编译运行。unit-success使用re-actors/alls-green汇总上述 Job 的最终状态。integration集成测试integration.yml 在 PR、merge group、main push 之外还增加了每日0 3 * * *UTC 03:00的定时触发。两个测试 Job 按事件区分非定时事件运行testJob先执行.github/scripts/install_geth.sh安装 geth部分集成测试依赖外部客户端然后用 nextest 运行全工作区tests/下的集成测试表达式为kind(test) and not binary(e2e_testsuite)即不跑 e2e 套件但覆盖集成测试目标。定时事件运行era-filesJobcargo nextest run --no-fail-fast --release --package reth-era --test it -- --ignored即对 crates/era 的 era/era1/ere 文件格式执行标记为--ignored的每日集成测试。bench性能基准bench.yml 是 reth CI 中最复杂的工作流之一用于在同一个区块范围内对比 baseline 与候选feature两个二进制的性能。它通过 Engine API 回放真实区块或把交易提交到本地出块节点的 txpool 中节点由 schelk 管理的本地快照支撑。它有两条触发路径PR 评论命令以decofe bench或derek bench开头的评论触发工作流会先校验评论者与 PR 作者均为paradigmxyz组织成员再解析命令参数。以decofe clear开头则把历史基准评论折叠为 OUTDATED。workflow_dispatch 手动触发提供一组显式输入参数核心包括blocks基准区块数默认 500big blocks 模式默认 30modeengineEngine API 区块回放、rpcRPC 交易提交、callRPC call 回放三选一big_blocksfalse/true或目标 gas 值如100M/2Greorgreorg 深度bal是否回放区块访问列表false/true/feature/baselinebaseline/feature对比的 git ref分别默认为 merge-base 与分支头run_pairs运行对数默认 6big blocks 10并自动生成 ABBA 顺序以抵消顺序偏差samply/tracing_chrome/otlp/metrics采样剖析、Chrome trace、OTLP 导出与 VictoriaMetrics 上传cores限制 reth 可用的 CPU 核数0 表示全部。参数解析逻辑对工作流内嵌于 JS 脚本中内置完整的取值校验如wait-time仅限 engine 模式、block-time仅限 rpc 模式解析失败时会在 PR 中回复错误信息与用法说明运行前还会估算排队位置并在 PR 中评论“Benchmark queued”及完整配置摘要。sync同步测试sync.yml 每 6 小时定时运行也可手动触发矩阵中定义了一条 mainnet 同步用例bin: reth。其步骤清晰地演示了一次“同步—校验—回退”的端到端验证# 1. 构建 make install # 2. 同步到指定区块--debug.max-block 限制高度 reth node --chain mainnet \ --debug.tip 0x91c90676cab257a59cd956d7cb0bceb9b1a71d79755c23c7277a0697ccfaf8c4 \ --debug.max-block 100000 \ --debug.terminate # 3. 校验目标区块哈希是否落库 reth db --chain mainnet get static-file headers 100000 | grep tip # 4. 按块数回退 100 个区块 reth stage unwind num-blocks 100 --chain mainnet # 5. 回退到指定区块哈希 reth stage unwind to-block 0x52e0509d33a988ef807058e2980099ee3070187f7333aae12b64d4d675f34c5a --chain mainnet该用例同时覆盖了同步执行正确性哈希校验与 unwind 两条回退路径按块数、按哈希。stage全部 stage run 命令stage.yml 在 merge group 事件中运行避免在 PR 早期阶段消耗大量同步资源以FROM_BLOCK: 0、TO_BLOCK: 50000为范围通过cargo install --locked --path bin/reth安装 CLI 后依次执行reth stage run headers --from 0 --to 50000 --commit --checkpoints reth stage run bodies --from 0 --to 50000 --commit --checkpoints reth stage run senders --from 0 --to 50000 --commit --checkpoints reth stage run execution --from 0 --to 50000 --commit --checkpoints reth stage run merkle --from 0 --to 50000 --commit --checkpoints reth stage run tx-lookup --from 0 --to 50000 --commit --checkpoints reth stage run account-history --from 0 --to 50000 --commit --checkpoints reth stage run storage-history --from 0 --to 50000 --commit --checkpoints工作流注释中特别说明account-hashing / storage-hashing / hashing 三个阶段被有意省略——在 storage v2现为默认下它们是 no-opexecution 阶段直接写入 HashedAccounts/HashedStorages而stage run先 unwind 再执行的语义会导致已写入的哈希状态被回退且无法恢复反而使 merkle 阶段失败。这一注释是对“staged 同步器”行为的重要提示。Docs 工作流bookbook.yml 构建、测试并部署 reth 文档站点基于 Vocs rustdocbuildJob安装 bun 与 Playwright Chromium供 rehype-mermaid 在构建期渲染 Mermaid 图安装 nightly 工具链后执行docs/vocs/scripts/build-cargo-docs.sh生成 rustdoc再bun run build构建 Vocs 站点。随后用一连串test -f/grep断言产物完整性例如docs/dist/public/index.html、docs/reth/index.html存在且 rustdoc 页面包含contentrustdoc。deployJob仅在 main 分支 push 时运行通过actions/configure-pagesactions/deploy-pages将产物发布到 GitHub Pages。此外 lint.yml 中的bookJob 通过./docs/cli/update.sh target/debug/reth重新生成 CLI 帮助文档 并断言git diff --exit-code保证 CLI 文档与二进制输出始终一致。Meta 工作流release发布工作流release.yml 在推送v*标签时触发也可通过workflow_dispatch指定任意 git ref 并开启dry_run只构建、不上传、不创建 Release。流水线为extract-version / check-version从 tag 提取版本号并校验 tag 与cargo metadata中 crate 版本前缀一致允许v1.4.8匹配1.4.8-rc.1。build三平台矩阵均使用maxperfprofilex86_64-unknown-linux-gnuubuntu-24.04RustFLAGS-C target-cpux86-64-v3 -C target-featurepclmulqdqaarch64-unknown-linux-gnuubuntu-24.04-arm 原生构建aarch64-apple-darwinmacos-14 原生构建。通过make ... build-native-target产出二进制打包为reth-VERSION-target.tar.gz含 LICENSES 与 README并用 GPG 私钥签名。draft-release下载全部产物用git log生成 changelog调用gh release create --draft创建带测试清单与二进制下载表的草稿 Release-rc版本自动附加--prerelease标记。release-dist 与 dependencies / stalerelease-dist.yml把 reth 发布到外部包管理器Homebrew、Debian 等渠道仓库内 pkg/reth/debian 目录保留了配套的 Debianreth.service单元文件。dependencies.yml定期执行cargo update保持依赖新鲜配套的依赖机器人配置见.github/dependabot.yml。stale.yml长时间无活动的 issue 自动标记为 stale。docker发布 Docker 镜像docker.yml 的触发与标签策略在文件头部注释中写明推送v*标签构建发布版RC 或 latest非 RC 版本额外打latest标签每日 01:00 UTC 定时构建nightly镜像nightly 构建注入RETH_ENGINE_TXPOOL_PREWARMINGtrue与RETH_ENGINE_SENDER_RECOVERY_CACHEtrue两个构建参数手动workflow_dispatchbuild_type可选git-sha按提交 SHA 打标签或nightly支持dry_run构建但不推送。镜像通过 Depot 远程构建depot/setup-actiondepot/bake-action以 docker-bake.hcl 为输入注入VERGEN_GIT_SHA/DESCRIBE/DIRTY供 vergen 生成版本信息推送到 GHCR随后用.github/scripts/verify_image_arch.sh校验推送镜像的架构完整性夜间构建失败会经 Slack webhook 通知。Docker 工作流变更规范docs/repo/ci.md 用专门一节约束 Docker 相关变更因为一次 Dockerfile 改动往往波及多个工作流。合并 Dockerfile、Docker 构建输入或拷贝进镜像的文件前应检查所有共享同一仓库构建上下文的 Dockerfile 与 bake 目标Dockerfile、Dockerfile.depot、.github/scripts/hive/Dockerfile与docker-bake.hcl保持.dockerignore与所有从仓库上下文拷贝的文件同步——一个文件即使存在于 git也可能因为不在.dockerignore白名单逻辑对应的拷贝列表中而在 Docker 构建中缺失检查这些目标的使用方docker.yml、可复用的 docker-test.yml以及hive.yml、kurtosis.yml等调用者在打开/合并 PR 前若 BuildKit/buildx 可用先做本地语法检查docker build --check -f Dockerfile .、docker build --check -f Dockerfile.depot .、docker buildx bake --print -f docker-bake.hcl对受影响工作流至少跑一次 GitHub Actions dry run发布工作流使用docker.yml的workflow_dispatch参数build_typegit-sha、dry_runtrue更新共享镜像内容时回顾近期的 Docker 相关 PR 与既有运行历史判断故障起始时间与是否波及其他工作流。Integration Testing 工作流kurtosiskurtosis.yml拉起一个 Kurtosis 测试网并在 reth 节点对上运行 Assertoor 测试网络参数配置见.github/assets/kurtosis_network_params.yamlAssertoor 模板见 etc/assertoor。hivehive.yml运行ethereum/hive客户端互操作测试配套脚本集中在.github/scripts/hive目录包括模拟器的构建build_simulators.sh、运行run_simulator.sh、期望失败与忽略清单expected_failures.yaml、ignored_tests.yaml以及日志提取工具。Linting and Checks 工作流lintlint.ymllint 工作流包含十余个并行检查 Job全部以RUSTFLAGS: -D warnings之类的零容忍策略运行clippy-binaries / clippy前者在 stable clippy 下按--workspace --lib --examples --tests --benches --locked并启用asm-keccak jemalloc jemalloc-prof min-*-logs等特性检查后者在 nightly clippy 下以--all-features全量检查。wasm / riscv分别编译wasm32-wasip1与riscv32imac-unknown-none-elf目标脚本为 check_wasm.sh 与 check_rv32imac.sh保障无标准库环境可构建。crate-checks用cargo hack check --workspace --partition N/3做三分区并行 feature 组合编译检查。msrv固定工具链1.95注释标明 MSRV执行cargo build --bin reth --workspace。docsnightly 下cargo docs --document-private-itemsRUSTDOCFLAGS 与 book 工作流保持同步见 lint.yml 中“Keep in sync with ./book.yml:jobs.build”注释。fmtcargo fmt --all --checknightly rustfmt。udepscargo udeps检测未使用的依赖。typos / check-toml拼写检查typos.toml 配置与 dprint.json 驱动的 TOML 格式检查。grafana / no-test-deps / feature-propagation / deny校验 Grafana 看板 JSON 可解析、默认构建不引入arbitrary|proptest测试依赖、用 zepter 校验 feature 传播、以及运行 cargo-deny 策略检查deny.toml。lint-success同样用alls-green汇总全部 Job。lint-actions 与 label-prlint-actions.yml用 actionlint 检查工作流 YAML 本身规则来自.github/actionlint.yaml。label-pr.yml基于.github/scripts/label_pr.js为 PR 自动打标签标签体系说明见 docs/repo/labels.md。小结reth 的 CI 呈现三个鲜明特点其一测试分层清晰——单元测试、集成测试、e2e/状态测试、定时 sync/stage 验证各司其职互不重复其二构建效率优先——mold、sccache、rust-cache、depot 自托管 Runner 与分区编译在所有 Job 中复用同一套加速手段其三发布链路可演练——release 与 docker 工作流均支持dry_run配合文档中给出的docker build --check等本地前置检查使发布类变更可以在真实推送前充分验证。结合 docs/repo/ci.md 与上述工作流文件开发者可以完整回答“某个改动会触发哪些 CI、为什么这样划分、失败时该看哪里”这类问题。【免费下载链接】rethModular, contributor-friendly and blazing-fast implementation of the Ethereum protocol, in Rust项目地址: https://gitcode.com/GitHub_Trending/re/reth创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考