数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载Apache OpenDAL 的 Rust 发布不是一个简单的cargo publish而是涉及 99 个 crates 的依赖排序、包名预留、可信发布Trusted Publishing与多阶段 CI 校验的完整流程。本篇指南以官方发布技能文档.agents/skills/opendal-release/references/rust.md为核心骨架结合仓库中的发布辅助脚本与工作流源码系统讲解 Rust 发布就绪检查的每一步如何检查发布计划、满足五条发布安全要求、以及如何诊断与修复发布辅助 CI 失败。读完本文你将掌握 Apache OpenDAL 从发布计划到crates.io 全量发布的完整核查方法并能在正式发布与投票前独立完成 Rust 发布就绪检查。Rust 发布就绪检查概览发布技能文档定义了 Rust 发布就绪检查的定位在官方发布之前最好在投票之前检查 Rust 发布计划publish plan。其核心命令为python3 .github/scripts/release_rust/plan.py该命令输出按依赖拓扑排序的待发布 crate 路径列表JSON 格式。在此基础上0.56.0 发布周期沉淀了五条发布安全要求是就绪检查必须逐条核对的硬性门槛顶层opendal通过testsfeature 引用core/testkit即opendal-testkit时该 crate 必须出现在 Rust 发布计划中发布辅助脚本必须使用cargo publish --package name而不能依赖 workspace 默认行为仓库内部的dev-dependencies即使在cargo publish --no-verify下也会破坏打包必须使用.github/scripts/release_rust/publish.py并保持其测试为绿色bootstrap 工作流必须在 RC 打标签之前成功且发布计划之后若新增 crate必须重跑 bootstrap正式发布工作流只能使用 Trusted Publishing每次发布尝试包括重试都要获取并吊销一个新的 OIDC 派生的 crates.io token。下文逐一展开。需要说明的是文档中的经验来自 0.56.0 周期而当前仓库 core/Cargo.toml 的 crate 版本已演进到0.59.4但发布安全要求与工具链结构保持不变。第一步检查 Rust 发布计划为什么要有一个发布计划脚本在仓库拆分之后OpenDAL 的 Rust crates 不再由一份手工维护的简短列表表示。release_rust 目录说明 明确指出发布工作流需要做到四件事发现core/与integrations/下所有可发布的 Rust crates排除publish false的 crate按依赖顺序发布保证本地 path 依赖在发布时已存在于 crates.io打包时剔除仓库内部 dev-dependencies避免同版本 dev-dependency 循环阻塞发布。把这些逻辑独立成脚本既便于单元测试也让 workflow YAML 保持简洁可读。plan.py 的扫描范围与排序原理plan.py 中定义了七类扫描根core/Cargo.toml core/core/Cargo.toml core/testkit/Cargo.toml core/http-transports/*/Cargo.toml core/layers/*/Cargo.toml core/services/*/Cargo.toml integrations/*/Cargo.toml对每个 manifest脚本先读取package段跳过没有 package 或publish false的 crate然后读取dependencies、build-dependencies以及各[target.*]下的对应表构建本地依赖图最后通过经典的 Kahn 拓扑排序按路径字典序稳定出队生成确定性的发布顺序。若排序结果与包总数不一致脚本会抛出failed to resolve publish order for Rust crates错误。实际运行 plan.py在当前仓库根目录运行python3 .github/scripts/release_rust/plan.py输出为 JSON 数组例如当前仓库的实际输出以[core/core, core/http-transports/reqwest, core/layers/async-backtrace, ...]开头以[core, integrations/object_store, integrations/parquet, integrations/unftp-sbe]收尾共99 个可发布包。注意排序特征core/coreopendal-core永远在最前顶层coreopendal位于依赖它的服务/layer 之后三个集成 crateobject_store、parquet、unftp-sbe依赖顶层opendal而排在最后。若需要把计划写入 GitHub Actions 输出供下游 job 消费python3 .github/scripts/release_rust/plan.py --github-output该模式会将packagesjson追加写入GITHUB_OUTPUT环境变量指定的文件见 plan.py#L142-L148。测试如何保障计划正确性test_plan.py 覆盖了三个关键场景临时 fixture 中按 path 依赖排序含publish false的排除、真实仓库计划必须包含core/core、core/testkit、core与集成 crate 且排除bindings/python等非发布路径、以及仓库真实计划的相对顺序约束core/core先于corecore先于所有集成 crate。这也是文档要求保持 helper 测试绿色的验证基础。发布安全要求一opendal-testkit 必须进入发布计划顶层opendalcrate 通过testsfeature 引用测试基础设施opendal-testkit。在 core/Cargo.toml#L223 中可以看到tests [opendal-testkit]而在 core/Cargo.toml#L339opendal-testkit { path testkit, version 0.59.4, optional true }也就是说core/testkitcrates.io 上名为opendal-testkit是顶层opendal的本地 path 依赖。当opendal发布时如果opendal-testkit尚未在 crates.io 上就位cargo publish会因为找不到同版本的本地依赖而失败。因此发布就绪检查的第一条是确认core/testkit出现在 plan.py 的输出中且其发布顺序早于顶层core。当前仓库的运行结果满足这一点core/testkit排在core之前。排障参考也印证了这一要求troubleshooting.md 中的 opendal-testkit is missing from crates.io plan 条目明确写道当opendal通过testsfeature 引用它时必须把core/testkit设为可发布并在顶层opendal之前发布。发布安全要求二按包发布使用 cargo publish --package不要依赖 workspace 默认值来发布。原因在于OpenDAL 仓库根目录是 workspace若直接cargo publish可能发布到错误的目标或带上错误的包集合而明确指定包名可以确保发布的是计划中的那一个 crate。release_rust.yml 的publishjob 中发布命令由 publish.py 执行其核心命令构造为cmd [cargo, publish, --package, name, --no-verify]其中name来自目标包自身 manifest 的package.name而非目录名推断从而保证 workspace 中每个包都以自己的身份发布。--no-verify跳过本地构建验证以节省时间代价是本地打包问题只能靠 manifest 处理来规避——这正是下一条要求存在的原因。发布安全要求三剥离仓库内部 dev-dependencies为什么 dev-dependencies 会破坏打包即使加了--no-verifycargo publish仍会执行打包packaging步骤它会读取 manifest 中的依赖并校验它们是否可解析。仓库内部的 dev-dependencies 指向本仓库其他目录例如../local-dev打包后这些 path 依赖并不存在从而触发解析失败同版本的 dev-dependency 循环也会在发布时造成阻塞。文档因此强调仓库内部 dev-dependencies 可以破坏打包即使使用cargo publish --no-verify。publish.py 的处理方式publish.py 实现了完整的剥离—发布—恢复流程local_dev_dependency_names扫描 manifest 的[dev-dependencies]与各[target.*.dev-dependencies]只收集 path 指向本仓库目录(manifest_dir / path).resolve().is_dir()的依赖名strip_local_dev_dependencies按行解析 manifest识别 dev-dependency section删除命中的依赖条目支持跨行{ ... }与[ ... ]结构发布前通过prepare_manifest记录原始 manifest 与全仓库所有Cargo.lock排除 target 目录发布后通过restore完整还原不污染工作区。剥离发生在cargo publish之前且由于 manifest 被临时修改命令会附带--allow-dirty。发布结束后无论成功失败finally都会执行restore(patch)。测试佐证test_publish.py 的test_strip_local_dev_dependencies构造了一个包含普通本地依赖、外部 dev-dependency、本地 dev-dependency含多行 features 写法与 target 级本地 dev-dependency 的 fixture验证剥离后普通本地依赖与外部 dev-dependency 保留而所有本地 dev-dependency 条目被删除。发布安全要求四bootstrap 工作流在 RC 打标签前成功为什么需要 bootstrapOpenDAL 的 Rust crate 名散布在core/与integrations/下需要确保每个计划中的 crate 名都已在 crates.io 上被正确预留并只允许 OpenDAL 通过可信发布方式发布。bootstrap 工作流bootstrap_rust_crates.yml完成这一使命对缺失的包名发布一个无依赖的0.0.0命名预留包并配置唯一的 Trusted Publisher。文档明确强调0.0.0包是对外的、不可逆的命名空间预留不是 ASF 软件发布或发布制品。bootstrap 的触发与状态流转发布经理在计划发布前约三天选定预留时间后运行仓库内的辅助脚本.agents/skills/opendal-release/scripts/bootstrap-rust-crates.sh脚本 bootstrap-rust-crates.sh 的执行步骤与文档一致校验 checkout 干净且位于apache/opendalmain的最新提交通过gh api校验rust-bootstrapGitHub 环境存在required_reviewers保护规则不存在则直接失败gh workflow run bootstrap_rust_crates.yml --ref main触发工作流解析出对应 run按标题、headSha、创建时间匹配校验headSha后gh run watch --exit-status等待完成完成后执行python3 .github/scripts/release_rust/bootstrap.py verify做公开校验。该工作流本身由两个 job 组成discoverjob 运行bootstrap.py discover报告缺失与占位 cratebootstrapjob 运行在受保护的rust-bootstrap环境中使用CARGO_REGISTRY_BOOTSTRAP_TOKEN执行bootstrap.py apply。rust-bootstrap 环境的保护配置.asf.yaml#L44-L64 中 ASF Infrastructure 为该环境配置了environments: rust-bootstrap: required_reviewers: [Xuanwo, dentiny, erickguan, tisonkun, koushiro, PsiACE] wait_timer: 0 prevent_self_review: true deployment_branch_policy: protected_branches: false policies: - name: main type: branch即每次运行都需要 PMC 成员审核批准prevent_self_review 禁止自审且只允许从main部署。此外PMC 发布经理必须在环境中配置CARGO_REGISTRY_BOOTSTRAP_TOKEN密钥该 token 只应拥有publish-new与trusted-publishing端点权限crate 范围仅限 OpenDAL 包名并且绝不能暴露给正常发布工作流。bootstrap.py 的审计与对账逻辑bootstrap.py 提供三个子命令discover无凭据读取 crates.io 公共元数据报告缺失包名与现有0.0.0占位包apply使用受保护的 bootstrap token 执行完整流程——先对所有计划 crate 做认证预检校验 crate 名、repository 归属、占位包描述、Trusted Publisher 配置与trustpub_only状态再对缺失名发布无依赖的0.0.0占位包、创建唯一的 Trusted Publisherapache/opendalrelease_rust.ymlrelease环境、启用trustpub_only并修复部分完成的占位包最后做一次认证终检verify读取公共元数据确认所有计划 crate 都存在且要求 Trusted Publishing。关键设计是bootstrap 永不修改已建立的 crate。若某个名字在发现后已变成正式 cratereconcile_crate会直接拒绝修改。已存在 crate 的一次性 Trusted Publishing 迁移是独立的管理性前置条件必须预先完成——bootstrap 会审计但不会改写这些 crate迁移未完成时工作流直接失败。计划新增 crate 时必须重跑文档明确指出bootstrap 工作流总是从它的main提交扫描发布计划。如果成功预留之后发布计划又新增了一个 crate发布经理需在选定的时间再次运行辅助脚本重跑会对每个占位包做对账确保新增名字同样被预留并配置好 Trusted Publisher。发布安全要求五正式发布仅使用 Trusted Publishing工作流侧的配置release_rust.yml 中publishjob 的关键配置触发条件if: startsWith(github.ref, refs/tags/) !contains(github.ref, -)即仅在正式 tag不含-从而排除 RC tag上执行environment: release权限id-token: write——这是 GitHub OIDC 的前提发布命令python3 .github/scripts/release_rust/publish.pyPACKAGES来自上游planjob 的输出。同时planjob 在每次运行前都会执行python3 -m unittest discover -s .github/scripts/release_rust -p test_*.py把 helper 测试作为发布流水线的第一道门禁——这正是保持 publish.py 测试绿色要求在工作流中的落地。每次发布尝试都换发并吊销 OIDC tokentrusted_publishing.py 实现了完整的换取—使用—吊销协议从ACTIONS_ID_TOKEN_REQUEST_URL/ACTIONS_ID_TOKEN_REQUEST_TOKEN读取 GitHub OIDC 端点请求 audience 为crates.io的 OIDC tokenJWTPOST 到 crates.io 的/api/v1/trusted_publishing/tokens把 JWT 换成一个短期 crates.io Trusted Publishing token通过temporary_trusted_publishing_token上下文管理器使用该 token 执行cargo publish并在finally中调用revoke_trusted_publishing_token立即吊销。两个细节值得注意token 在输出时会通过::add-mask::打码防止泄露每次发布尝试都会走一遍换取—吊销协议——包括限流后的重试重试时绝不复用旧 token。这正是文档它获取并吊销一个新的 OIDC 派生 crates.io token用于每次发布尝试包括重试的源码实现。对应测试 test_trusted_publishing.py 验证了OIDC 请求保留既有 query 并追加audiencecrates.io、token 交换使用 GETPOST 且携带 Bearer 头、吊销使用 DELETE、以及temporary_trusted_publishing_token在异常路径下也会保证吊销。此外test_publish.py 的test_live_publish_fetches_a_new_token_for_every_attempt用一个返回两次不同 token 的 provider 模拟限流重试断言两次cargo publish各拿到一个新 token、且两个 token 都被释放test_dry_run_does_not_request_a_trusted_publishing_token则确认--dry-run模式不会请求 OIDC token。限流与已发布识别publish_package对 crates.io 的三种响应分别处理成功returncode 0返回输出含already uploaded/already exists/is already uploaded判定已发布跳过输出含Too many requests/rate limit/you have published too many crates解析服务端返回的Please try again after ...时间支持 RFC 日期与 ISO 日期至少等待 60 秒默认 610 秒后重试。因此Rust 发布耗时很长本身不一定是异常——99 个 crate 按计划顺序逐个发布辅以限流退避运行数十分钟甚至更久都属正常troubleshooting.md 对此有专门说明。诊断与修复发布辅助 CI 失败总原则当发布辅助 helper 的 CI 失败时文档给出明确的处置纪律从失败的 job 直接诊断根因而不是盲目重跑或改配置仅在失败确实需要更新的 base 时才 rebase仅在证据指向代码或依赖问题时才更新代码或依赖针对受影响的特定行为运行针对性测试当相关代码、依赖与环境未变化时复用已通过的测试结果不要无意义重跑。常见失败模式与处置结合 troubleshooting.md 的 Rust 相关条目就绪检查中常见的问题与处置如下失败现象根因处置cargo publish因 dev-dependencies 失败仓库内部 path dev-dependency 打包后不可解析不要盲目改 workflow YAML使用并测试 publish.py它负责剥离与恢复opendal-testkit不在计划中顶层opendal的testsfeature 引用了它让 core/testkit 可发布并在顶层opendal之前发布publish job 长时间运行99 个 crate 按拓扑顺序逐个发布 限流退避查看 plan.py 输出观察工作流日志逐个确认 crate 渐进发布而非误判为卡死crates.io 稀疏索引抖动如no matching package named ... found注册表瞬时故障先重跑失败的 job再考虑开代码修复 PR本地运行 helper 测试发布就绪检查的收尾是让 helper 测试保持绿色python3 -m unittest discover -s .github/scripts/release_rust -p test_*.py在当前仓库实际运行该命令30 个测试中 29 个通过唯一失败项test_placeholder_can_be_packaged_offline是因为本机未安装cargoFileNotFoundError: cargo与脚本逻辑无关——这恰好印证了文档保持测试绿色的前提是相关环境就绪。在 CI 的planjob 中该测试集作为发布流水线的门禁在每次运行时都会执行。总结完整的 Rust 发布就绪检查清单将上文内容归纳为一张可执行的检查清单检查发布计划运行python3 .github/scripts/release_rust/plan.py确认输出包含core/core、core/testkit、core与全部integrations/*且顺序满足依赖拓扑核对 testkit确认core/testkit可发布且排在顶层opendal之前对应 core/Cargo.toml#L223 的testsfeature核对发布方式发布统一经 publish.py 的cargo publish --package name执行仓库内 dev-dependencies 被自动剥离并恢复核对 bootstrapbootstrap_rust_crates.yml已在 RC 打标签前于最新main上成功所有计划 crate 名存在、Trusted Publisher 唯一且trustpub_only已启用发布计划新增 crate 后已重跑核对可信发布正式发布工作流 release_rust.yml 仅依赖 OIDC 派生的临时 tokenid-token: writeenvironment: release每次尝试换取并吊销核对测试与诊断.github/scripts/release_rust下的单元测试为绿色任何 helper CI 失败都从失败 job 定位根因仅在证据充分时才 rebase 或改代码并在代码、依赖、环境不变时复用既有通过结果。通过以上六步发布经理即可在投票与正式发布前确认 Apache OpenDAL 的 Rust 发布处于就绪状态避免在 RC 阶段才发现opendal-testkit缺失、dev-dependency 打包失败或 Trusted Publisher 配置错误等最后一公里问题。延伸阅读若需深入了解本文引用的完整流程可继续阅读仓库内的相关文档Rust crate bootstrap 参考、发布技能总览、发布辅助脚本说明以及 发布排障参考。赞分享数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载相关推荐Apache OpenDAL Release CandidateRC发布全流程实战指南从每周 ATR 候选到 Nexus 投票就绪Apache OpenDAL Release CandidateRC发布全流程实战指南从每周 ATR 候选到 Nexus 投票就绪 Apache Open数据存储后端Apache DataFusion 发布流程全指南从 RC 构件、社区投票到 crates.io 发布Apache DataFusion 发布流程全指南从 RC 构件、社区投票到 crates.io 发布 Apache DataFusion 作为 Apache大数据数据分析后端Apache OpenDAL Go Binding 发布就绪检查独立 Go Module 的 RC 标签与服务制品验证指南Apache OpenDAL Go Binding 发布就绪检查独立 Go Module 的 RC 标签与服务制品验证指南 导读 本文聚焦 Apache O数据存储后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载Apache OpenDAL 的 Rust 发布不是一个简单的cargo publish而是涉及 99 个 crates 的依赖排序、包名预留、可信发布Trusted Publishing与多阶段 CI 校验的完整流程。本篇指南以官方发布技能文档.agents/skills/opendal-release/references/rust.md为核心骨架结合仓库中的发布辅助脚本与工作流源码系统讲解 Rust 发布就绪检查的每一步如何检查发布计划、满足五条发布安全要求、以及如何诊断与修复发布辅助 CI 失败。读完本文你将掌握 Apache OpenDAL 从发布计划到crates.io 全量发布的完整核查方法并能在正式发布与投票前独立完成 Rust 发布就绪检查。Rust 发布就绪检查概览发布技能文档定义了 Rust 发布就绪检查的定位在官方发布之前最好在投票之前检查 Rust 发布计划publish plan。其核心命令为python3 .github/scripts/release_rust/plan.py该命令输出按依赖拓扑排序的待发布 crate 路径列表JSON 格式。在此基础上0.56.0 发布周期沉淀了五条发布安全要求是就绪检查必须逐条核对的硬性门槛顶层opendal通过testsfeature 引用core/testkit即opendal-testkit时该 crate 必须出现在 Rust 发布计划中发布辅助脚本必须使用cargo publish --package name而不能依赖 workspace 默认行为仓库内部的dev-dependencies即使在cargo publish --no-verify下也会破坏打包必须使用.github/scripts/release_rust/publish.py并保持其测试为绿色bootstrap 工作流必须在 RC 打标签之前成功且发布计划之后若新增 crate必须重跑 bootstrap正式发布工作流只能使用 Trusted Publishing每次发布尝试包括重试都要获取并吊销一个新的 OIDC 派生的 crates.io token。下文逐一展开。需要说明的是文档中的经验来自 0.56.0 周期而当前仓库 core/Cargo.toml 的 crate 版本已演进到0.59.4但发布安全要求与工具链结构保持不变。第一步检查 Rust 发布计划为什么要有一个发布计划脚本在仓库拆分之后OpenDAL 的 Rust crates 不再由一份手工维护的简短列表表示。release_rust 目录说明 明确指出发布工作流需要做到四件事发现core/与integrations/下所有可发布的 Rust crates排除publish false的 crate按依赖顺序发布保证本地 path 依赖在发布时已存在于 crates.io打包时剔除仓库内部 dev-dependencies避免同版本 dev-dependency 循环阻塞发布。把这些逻辑独立成脚本既便于单元测试也让 workflow YAML 保持简洁可读。plan.py 的扫描范围与排序原理plan.py 中定义了七类扫描根core/Cargo.toml core/core/Cargo.toml core/testkit/Cargo.toml core/http-transports/*/Cargo.toml core/layers/*/Cargo.toml core/services/*/Cargo.toml integrations/*/Cargo.toml对每个 manifest脚本先读取package段跳过没有 package 或publish false的 crate然后读取dependencies、build-dependencies以及各[target.*]下的对应表构建本地依赖图最后通过经典的 Kahn 拓扑排序按路径字典序稳定出队生成确定性的发布顺序。若排序结果与包总数不一致脚本会抛出failed to resolve publish order for Rust crates错误。实际运行 plan.py在当前仓库根目录运行python3 .github/scripts/release_rust/plan.py输出为 JSON 数组例如当前仓库的实际输出以[core/core, core/http-transports/reqwest, core/layers/async-backtrace, ...]开头以[core, integrations/object_store, integrations/parquet, integrations/unftp-sbe]收尾共99 个可发布包。注意排序特征core/coreopendal-core永远在最前顶层coreopendal位于依赖它的服务/layer 之后三个集成 crateobject_store、parquet、unftp-sbe依赖顶层opendal而排在最后。若需要把计划写入 GitHub Actions 输出供下游 job 消费python3 .github/scripts/release_rust/plan.py --github-output该模式会将packagesjson追加写入GITHUB_OUTPUT环境变量指定的文件见 plan.py#L142-L148。测试如何保障计划正确性test_plan.py 覆盖了三个关键场景临时 fixture 中按 path 依赖排序含publish false的排除、真实仓库计划必须包含core/core、core/testkit、core与集成 crate 且排除bindings/python等非发布路径、以及仓库真实计划的相对顺序约束core/core先于corecore先于所有集成 crate。这也是文档要求保持 helper 测试绿色的验证基础。发布安全要求一opendal-testkit 必须进入发布计划顶层opendalcrate 通过testsfeature 引用测试基础设施opendal-testkit。在 core/Cargo.toml#L223 中可以看到tests [opendal-testkit]而在 core/Cargo.toml#L339opendal-testkit { path testkit, version 0.59.4, optional true }也就是说core/testkitcrates.io 上名为opendal-testkit是顶层opendal的本地 path 依赖。当opendal发布时如果opendal-testkit尚未在 crates.io 上就位cargo publish会因为找不到同版本的本地依赖而失败。因此发布就绪检查的第一条是确认core/testkit出现在 plan.py 的输出中且其发布顺序早于顶层core。当前仓库的运行结果满足这一点core/testkit排在core之前。排障参考也印证了这一要求troubleshooting.md 中的 opendal-testkit is missing from crates.io plan 条目明确写道当opendal通过testsfeature 引用它时必须把core/testkit设为可发布并在顶层opendal之前发布。发布安全要求二按包发布使用 cargo publish --package不要依赖 workspace 默认值来发布。原因在于OpenDAL 仓库根目录是 workspace若直接cargo publish可能发布到错误的目标或带上错误的包集合而明确指定包名可以确保发布的是计划中的那一个 crate。release_rust.yml 的publishjob 中发布命令由 publish.py 执行其核心命令构造为cmd [cargo, publish, --package, name, --no-verify]其中name来自目标包自身 manifest 的package.name而非目录名推断从而保证 workspace 中每个包都以自己的身份发布。--no-verify跳过本地构建验证以节省时间代价是本地打包问题只能靠 manifest 处理来规避——这正是下一条要求存在的原因。发布安全要求三剥离仓库内部 dev-dependencies为什么 dev-dependencies 会破坏打包即使加了--no-verifycargo publish仍会执行打包packaging步骤它会读取 manifest 中的依赖并校验它们是否可解析。仓库内部的 dev-dependencies 指向本仓库其他目录例如../local-dev打包后这些 path 依赖并不存在从而触发解析失败同版本的 dev-dependency 循环也会在发布时造成阻塞。文档因此强调仓库内部 dev-dependencies 可以破坏打包即使使用cargo publish --no-verify。publish.py 的处理方式publish.py 实现了完整的剥离—发布—恢复流程local_dev_dependency_names扫描 manifest 的[dev-dependencies]与各[target.*.dev-dependencies]只收集 path 指向本仓库目录(manifest_dir / path).resolve().is_dir()的依赖名strip_local_dev_dependencies按行解析 manifest识别 dev-dependency section删除命中的依赖条目支持跨行{ ... }与[ ... ]结构发布前通过prepare_manifest记录原始 manifest 与全仓库所有Cargo.lock排除 target 目录发布后通过restore完整还原不污染工作区。剥离发生在cargo publish之前且由于 manifest 被临时修改命令会附带--allow-dirty。发布结束后无论成功失败finally都会执行restore(patch)。测试佐证test_publish.py 的test_strip_local_dev_dependencies构造了一个包含普通本地依赖、外部 dev-dependency、本地 dev-dependency含多行 features 写法与 target 级本地 dev-dependency 的 fixture验证剥离后普通本地依赖与外部 dev-dependency 保留而所有本地 dev-dependency 条目被删除。发布安全要求四bootstrap 工作流在 RC 打标签前成功为什么需要 bootstrapOpenDAL 的 Rust crate 名散布在core/与integrations/下需要确保每个计划中的 crate 名都已在 crates.io 上被正确预留并只允许 OpenDAL 通过可信发布方式发布。bootstrap 工作流bootstrap_rust_crates.yml完成这一使命对缺失的包名发布一个无依赖的0.0.0命名预留包并配置唯一的 Trusted Publisher。文档明确强调0.0.0包是对外的、不可逆的命名空间预留不是 ASF 软件发布或发布制品。bootstrap 的触发与状态流转发布经理在计划发布前约三天选定预留时间后运行仓库内的辅助脚本.agents/skills/opendal-release/scripts/bootstrap-rust-crates.sh脚本 bootstrap-rust-crates.sh 的执行步骤与文档一致校验 checkout 干净且位于apache/opendalmain的最新提交通过gh api校验rust-bootstrapGitHub 环境存在required_reviewers保护规则不存在则直接失败gh workflow run bootstrap_rust_crates.yml --ref main触发工作流解析出对应 run按标题、headSha、创建时间匹配校验headSha后gh run watch --exit-status等待完成完成后执行python3 .github/scripts/release_rust/bootstrap.py verify做公开校验。该工作流本身由两个 job 组成discoverjob 运行bootstrap.py discover报告缺失与占位 cratebootstrapjob 运行在受保护的rust-bootstrap环境中使用CARGO_REGISTRY_BOOTSTRAP_TOKEN执行bootstrap.py apply。rust-bootstrap 环境的保护配置.asf.yaml#L44-L64 中 ASF Infrastructure 为该环境配置了environments: rust-bootstrap: required_reviewers: [Xuanwo, dentiny, erickguan, tisonkun, koushiro, PsiACE] wait_timer: 0 prevent_self_review: true deployment_branch_policy: protected_branches: false policies: - name: main type: branch即每次运行都需要 PMC 成员审核批准prevent_self_review 禁止自审且只允许从main部署。此外PMC 发布经理必须在环境中配置CARGO_REGISTRY_BOOTSTRAP_TOKEN密钥该 token 只应拥有publish-new与trusted-publishing端点权限crate 范围仅限 OpenDAL 包名并且绝不能暴露给正常发布工作流。bootstrap.py 的审计与对账逻辑bootstrap.py 提供三个子命令discover无凭据读取 crates.io 公共元数据报告缺失包名与现有0.0.0占位包apply使用受保护的 bootstrap token 执行完整流程——先对所有计划 crate 做认证预检校验 crate 名、repository 归属、占位包描述、Trusted Publisher 配置与trustpub_only状态再对缺失名发布无依赖的0.0.0占位包、创建唯一的 Trusted Publisherapache/opendalrelease_rust.ymlrelease环境、启用trustpub_only并修复部分完成的占位包最后做一次认证终检verify读取公共元数据确认所有计划 crate 都存在且要求 Trusted Publishing。关键设计是bootstrap 永不修改已建立的 crate。若某个名字在发现后已变成正式 cratereconcile_crate会直接拒绝修改。已存在 crate 的一次性 Trusted Publishing 迁移是独立的管理性前置条件必须预先完成——bootstrap 会审计但不会改写这些 crate迁移未完成时工作流直接失败。计划新增 crate 时必须重跑文档明确指出bootstrap 工作流总是从它的main提交扫描发布计划。如果成功预留之后发布计划又新增了一个 crate发布经理需在选定的时间再次运行辅助脚本重跑会对每个占位包做对账确保新增名字同样被预留并配置好 Trusted Publisher。发布安全要求五正式发布仅使用 Trusted Publishing工作流侧的配置release_rust.yml 中publishjob 的关键配置触发条件if: startsWith(github.ref, refs/tags/) !contains(github.ref, -)即仅在正式 tag不含-从而排除 RC tag上执行environment: release权限id-token: write——这是 GitHub OIDC 的前提发布命令python3 .github/scripts/release_rust/publish.pyPACKAGES来自上游planjob 的输出。同时planjob 在每次运行前都会执行python3 -m unittest discover -s .github/scripts/release_rust -p test_*.py把 helper 测试作为发布流水线的第一道门禁——这正是保持 publish.py 测试绿色要求在工作流中的落地。每次发布尝试都换发并吊销 OIDC tokentrusted_publishing.py 实现了完整的换取—使用—吊销协议从ACTIONS_ID_TOKEN_REQUEST_URL/ACTIONS_ID_TOKEN_REQUEST_TOKEN读取 GitHub OIDC 端点请求 audience 为crates.io的 OIDC tokenJWTPOST 到 crates.io 的/api/v1/trusted_publishing/tokens把 JWT 换成一个短期 crates.io Trusted Publishing token通过temporary_trusted_publishing_token上下文管理器使用该 token 执行cargo publish并在finally中调用revoke_trusted_publishing_token立即吊销。两个细节值得注意token 在输出时会通过::add-mask::打码防止泄露每次发布尝试都会走一遍换取—吊销协议——包括限流后的重试重试时绝不复用旧 token。这正是文档它获取并吊销一个新的 OIDC 派生 crates.io token用于每次发布尝试包括重试的源码实现。对应测试 test_trusted_publishing.py 验证了OIDC 请求保留既有 query 并追加audiencecrates.io、token 交换使用 GETPOST 且携带 Bearer 头、吊销使用 DELETE、以及temporary_trusted_publishing_token在异常路径下也会保证吊销。此外test_publish.py 的test_live_publish_fetches_a_new_token_for_every_attempt用一个返回两次不同 token 的 provider 模拟限流重试断言两次cargo publish各拿到一个新 token、且两个 token 都被释放test_dry_run_does_not_request_a_trusted_publishing_token则确认--dry-run模式不会请求 OIDC token。限流与已发布识别publish_package对 crates.io 的三种响应分别处理成功returncode 0返回输出含already uploaded/already exists/is already uploaded判定已发布跳过输出含Too many requests/rate limit/you have published too many crates解析服务端返回的Please try again after ...时间支持 RFC 日期与 ISO 日期至少等待 60 秒默认 610 秒后重试。因此Rust 发布耗时很长本身不一定是异常——99 个 crate 按计划顺序逐个发布辅以限流退避运行数十分钟甚至更久都属正常troubleshooting.md 对此有专门说明。诊断与修复发布辅助 CI 失败总原则当发布辅助 helper 的 CI 失败时文档给出明确的处置纪律从失败的 job 直接诊断根因而不是盲目重跑或改配置仅在失败确实需要更新的 base 时才 rebase仅在证据指向代码或依赖问题时才更新代码或依赖针对受影响的特定行为运行针对性测试当相关代码、依赖与环境未变化时复用已通过的测试结果不要无意义重跑。常见失败模式与处置结合 troubleshooting.md 的 Rust 相关条目就绪检查中常见的问题与处置如下失败现象根因处置cargo publish因 dev-dependencies 失败仓库内部 path dev-dependency 打包后不可解析不要盲目改 workflow YAML使用并测试 publish.py它负责剥离与恢复opendal-testkit不在计划中顶层opendal的testsfeature 引用了它让 core/testkit 可发布并在顶层opendal之前发布publish job 长时间运行99 个 crate 按拓扑顺序逐个发布 限流退避查看 plan.py 输出观察工作流日志逐个确认 crate 渐进发布而非误判为卡死crates.io 稀疏索引抖动如no matching package named ... found注册表瞬时故障先重跑失败的 job再考虑开代码修复 PR本地运行 helper 测试发布就绪检查的收尾是让 helper 测试保持绿色python3 -m unittest discover -s .github/scripts/release_rust -p test_*.py在当前仓库实际运行该命令30 个测试中 29 个通过唯一失败项test_placeholder_can_be_packaged_offline是因为本机未安装cargoFileNotFoundError: cargo与脚本逻辑无关——这恰好印证了文档保持测试绿色的前提是相关环境就绪。在 CI 的planjob 中该测试集作为发布流水线的门禁在每次运行时都会执行。总结完整的 Rust 发布就绪检查清单将上文内容归纳为一张可执行的检查清单检查发布计划运行python3 .github/scripts/release_rust/plan.py确认输出包含core/core、core/testkit、core与全部integrations/*且顺序满足依赖拓扑核对 testkit确认core/testkit可发布且排在顶层opendal之前对应 core/Cargo.toml#L223 的testsfeature核对发布方式发布统一经 publish.py 的cargo publish --package name执行仓库内 dev-dependencies 被自动剥离并恢复核对 bootstrapbootstrap_rust_crates.yml已在 RC 打标签前于最新main上成功所有计划 crate 名存在、Trusted Publisher 唯一且trustpub_only已启用发布计划新增 crate 后已重跑核对可信发布正式发布工作流 release_rust.yml 仅依赖 OIDC 派生的临时 tokenid-token: writeenvironment: release每次尝试换取并吊销核对测试与诊断.github/scripts/release_rust下的单元测试为绿色任何 helper CI 失败都从失败 job 定位根因仅在证据充分时才 rebase 或改代码并在代码、依赖、环境不变时复用既有通过结果。通过以上六步发布经理即可在投票与正式发布前确认 Apache OpenDAL 的 Rust 发布处于就绪状态避免在 RC 阶段才发现opendal-testkit缺失、dev-dependency 打包失败或 Trusted Publisher 配置错误等最后一公里问题。延伸阅读若需深入了解本文引用的完整流程可继续阅读仓库内的相关文档Rust crate bootstrap 参考、发布技能总览、发布辅助脚本说明以及 发布排障参考。赞分享数据存储后端【免费下载链接】opendalApache OpenDAL: One Layer, All Storage.项目地址https://gitcode.com/gh_mirrors/op/opendal点击查看免费下载相关推荐Apache OpenDAL Release CandidateRC发布全流程实战指南从每周 ATR 候选到 Nexus 投票就绪Apache OpenDAL Release CandidateRC发布全流程实战指南从每周 ATR 候选到 Nexus 投票就绪 Apache Open数据存储后端Apache DataFusion 发布流程全指南从 RC 构件、社区投票到 crates.io 发布Apache DataFusion 发布流程全指南从 RC 构件、社区投票到 crates.io 发布 Apache DataFusion 作为 Apache大数据数据分析后端Apache OpenDAL Go Binding 发布就绪检查独立 Go Module 的 RC 标签与服务制品验证指南Apache OpenDAL Go Binding 发布就绪检查独立 Go Module 的 RC 标签与服务制品验证指南 导读 本文聚焦 Apache O数据存储后端创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
