开发工具CI/CDDevOps【免费下载链接】release-pleasegenerate release PRs based on the conventionalcommits.org spec项目地址https://gitcode.com/gh_mirrors/re/release-please点击查看免费下载导读本文以本仓库 README.md 为核心骨架系统讲解 release-please 的核心工作机制——解析 git 历史中的 Conventional Commits 提交、持续维护发布 PRRelease PR并在合并后自动更新 CHANGELOG、打标签、创建 GitHub Release。你将掌握提交规范写法、Release-As强制指定版本、BEGIN_COMMIT_OVERRIDE修正发布说明、排障三步法以及全部受支持的 release type语言/框架策略与 CLI 配置方式并深入源码层理解其版本推导逻辑。什么是 Release PR与每有代码合并到默认分支就立即发布的做法不同release-please 采用持续维护发布 PR的模式它会在目标分支上创建一个或多个专门用于发布的 Pull Request并在后续有新工作被合并时自动保持该 PR 与最新代码同步更新。当你准备好发布某个版本时只需要合并这个发布 PR即可。发布 PR 对 squash-merge 和普通 merge commit 两种合并方式都兼容。合并发布 PR 之后release-please 会自动执行以下三步更新 changelog 文件例如CHANGELOG.md以及其他与语言相关的版本文件例如 Node.js 项目的package.json为合并提交打上版本号标签git tag基于该标签创建 GitHub Release。从源码看这三步对应的职责被拆分为buildReleasePullRequest负责生成候选发布 PR 的内容src/strategies/base.tsbuildRelease/buildReleases负责在 PR 合并后根据 PR 标题、分支名与 PR body 还原出候选 Releasesrc/strategies/base.ts最终由github-release命令把 Release 落到 GitHub 上。发布 PR 的状态标签你可以通过发布 PR 上的状态标签label判断它处于生命周期的哪个阶段标签含义autorelease: pending发布 PR 的初始状态即合并之前autorelease: tagged发布 PR 已被合并且版本已在 GitHub 上打好标签autorelease: snapshot快照版本号提升时的特殊状态autorelease: published已基于该发布 PR 发布了 GitHub Releaserelease-please 不会自动添加此标签但官方建议发布工具链以此作为约定提交信息该怎么写release-please 假定你正在使用Conventional Commits 规范。需要重点记住的前缀有三类它们与 SemVer 的对应关系如下提交前缀含义对应的版本号变动fix:缺陷修复patch如1.0.0 → 1.0.1feat:新功能minor如1.0.1 → 1.1.0feat!:、fix!:、refactor!:等带!破坏性变更breaking changemajor如1.1.0 → 2.0.0这套映射关系在源码中可直接验证DefaultVersioningStrategy.determineReleaseType会遍历提交统计breaking破坏性与feat/feature新功能提交的数量再决定采用MajorVersionUpdate、MinorVersionUpdate还是PatchVersionUpdatesrc/versioning-strategies/default.ts三种更新器定义在 src/versioning-strategy.ts。其中breaking标记由解析器根据BREAKING CHANGEnote 或!标记识别src/commit.ts。建议使用 squash-merge 保持线性历史官方强烈推荐在合并 PR 时使用 squash-merge线性 git 历史会带来以下好处易于追踪历史提交按合并时间排序不会在不同 PR 之间交错混杂便于定位与回滚 buggit bisect能更有效地找出引入 bug 的那次变更更好地控制 changelog合并 PR 时PR 内部那些在 PR 语境下有意义、但在主分支上毫无意义的提交信息例如先feat: introduce feature A后fix: some bugfix会被收敛避免把与主分支发布无关的修复写进发布说明保持主分支干净如果采用 red/green 开发提交 A 写一个失败测试、提交 B 修复直接 merge 或 rebase-merge 会在主分支上留下测试不通过的中间状态。一个提交里包含多个 fix/feat 怎么办release-please 允许在单个提交中表达多次变更方法是使用 footer脚注块feat: adds v4 UUID to crypto This adds support for v4 UUIDs to the library. fix(utils): unicode no longer throws exception PiperOrigin-RevId: 345559154 BREAKING-CHANGE: encode method no longer throws. Source-Link: googleapis/googleapis5e0dcb2 feat(utils): update encode to support unicode PiperOrigin-RevId: 345559182 Source-Link: googleapis/googleapise5eef86上面这条提交信息最终会被解析出以下内容一条adds v4 UUID to crypto的 feature 条目一条unicode no longer throws exception的 fix 条目并附带它是破坏性变更的说明一条update encode to support unicode的 feature 条目。重要额外的提交消息必须附加在提交信息的底部。这一机制在 src/commit.ts 中有完整实现解析器先把提交信息解析成 AST再通过toConventionalChangelogFormat将 AST 转换成 conventional-changelog 格式其中会把形如fix(utils): ...的 footer 递归地再解析为独立提交src/commit.tssplitMessages则负责把单个 commit message 拆分为多个消息src/commit.ts。如何强制指定版本号当主分支上的某个提交在其commit body中包含Release-As: x.x.x不区分大小写时release-please 会为该指定版本打开一个新的发布 PR。空提交示例git commit --allow-empty -m chore: release 2.0.0 -m Release-As: 2.0.0生成的提交信息如下chore: release 2.0.0 Release-As: 2.0.0在源码层面Release-As被解析为一条标题为RELEASE AS的 notesrc/commit.tsbuildNewVersion会优先查找带RELEASE ASnote 的提交并直接用其文本构造版本号src/strategies/base.tsDefaultVersioningStrategy同样会在遍历提交时优先命中RELEASE AS并返回CustomVersionUpdatesrc/versioning-strategies/default.ts。此外CLI 的release-pr命令也提供了--release-as参数用于在命令行直接覆盖语义化推导出的版本号见 docs/cli.md。如何修正已合并 PR 的发布说明如果你已经合并了一个 PR并想修改用于生成该提交发布说明的 commit message可以编辑已合并 PR 的 body加入如下格式的覆盖段BEGIN_COMMIT_OVERRIDE feat: add ability to override merged commit message fix: another message chore: a third message END_COMMIT_OVERRIDE下次运行 release-please 时它会优先使用覆盖段中的内容作为该提交的 commit message而不是合并时实际使用的 commit message。重要此功能不适用于普通 mergeplain merge因为 release-please 无法确定该 override 应应用到哪个哪些提交。建议改用 squash-merge见上文建议使用 squash-merge 保持线性历史一节。该功能在 src/commit.ts 的preprocessCommitMessage中实现如果提交关联了 PR则会截取 PR body 中BEGIN_COMMIT_OVERRIDE与END_COMMIT_OVERRIDE之间的文本作为待解析的提交信息没有覆盖段时才回退到原始的 commit message。仓库测试夹具 test/fixtures/commit-messages/meta.txt 中也有多提交、带分隔符等场景的样例可对照参考。Release Please 没有创建发布 PR为什么如果 release-please 迟迟没有创建发布 PR请按下述三个步骤排查。步骤 1确认存在可发布单元releasable unitsrelease-please 只有在注意到默认分支自上次发布以来包含可发布单元时才会创建发布 PR。可发布单元是指带有以下前缀之一的提交feat、fix、deps。chore或build提交不是可发布单元。部分语言有自己特定的可发布单元配置例如在 Java 和 Python 中docs也是可发布单元前缀。changelog 默认分组与隐藏规则可在 src/util/filter-commits.ts 中看到feat/fix/perf/revert默认显示而chore/docs/style/refactor/test/build/ci默认隐藏hidden: true除非它们携带 BREAKING CHANGE notesrc/util/filter-commits.ts。步骤 2确认旧的 PR 上没有残留autorelease: pending或autorelease: triggered标签检查现有 PR 是否带有autorelease: pending或autorelease: triggered标签。由于 GitHub API 失败上一次发布时标签可能没有被正确移除release-please 会误以为上一次发布仍然 pending。如果你确信没有未完成的发布请手动移除autorelease: pending或autorelease: triggered标签。对于 GitHub Application 用户如果已存在标记为autorelease: pending的 PRrelease-please 将不会创建新的 PR。请搜索带此标签的 PR 确认很可能就是最新的那个发布 PR。如果该发布 PR 不会再发布或已经发布请移除autorelease: pending标签并重新运行 release-please。步骤 3重新运行 release-please如果你认为带可发布单元的 PR 合并后 release-please 漏掉了发布 PR请重新运行release-please使用GitHub Application时给已合并的 PR 添加release-please:force-run标签使用GitHub Action时找到失败的那次调用并重试对应 workflow 运行。release-please 会立即处理该 PR 以查找可发布单元。支持的策略语言类型release-please 为以下类型的仓库自动化发布流程release type说明bazel带MODULE.bazel和CHANGELOG.md的 Bazel 模块dart带pubspec.yaml和CHANGELOG.md的仓库elixir带mix.exs和CHANGELOG.md的仓库go带CHANGELOG.md的仓库helm带Chart.yaml和CHANGELOG.md的仓库java每次发布后生成 SNAPSHOT 版本的策略见 docs/java.mdkrm-blueprint带 1 个或多个 KRM 文件及CHANGELOG.md的 kpt 包maven面向 Maven 项目的策略每次发布后生成 SNAPSHOT 版本并自动更新pom.xml见 docs/java.mdnode带package.json和CHANGELOG.md的 Node.js 仓库expo带package.json、app.json和CHANGELOG.md的基于 Expo 的 React Native 仓库ocaml含 1 个或多个 opam 或 esy 文件及CHANGELOG.md的 OCaml 仓库php带composer.json和CHANGELOG.md的仓库python带pyproject.toml、project/__init__.py、CHANGELOG.md或可选的setup.py、setup.cfg的 Python 仓库R带DESCRIPTION和NEWS.md的仓库ruby带version.rb和CHANGELOG.md的仓库rust带Cargo.tomlcrate 或 workspaceworkspace 需配合 manifest 驱动发布 与cargo-workspace插件和CHANGELOG.md的 Rust 仓库sfdx带sfdx-project.json和CHANGELOG.md的仓库simple带version.txt和CHANGELOG.md的仓库terraform-moduleREADME.md 中含版本信息、带CHANGELOG.md的 terraform 模块在源码中这些策略统一注册在src/factory.ts的releasers注册表中src/factory.ts由buildStrategy依据releaseType字符串查表实例化对应的 Strategy 类src/factory.ts表中还能看到dotnet-yoshi、java-yoshi、java-backport、java-bom、java-lts、go-yoshi、php-yoshi、ruby-yoshi、python-librarian等更多内部策略变体。每个策略的核心职责——决定发布 PR 中需要更新哪些文件——定义在Strategy接口中src/strategy.ts。如何部署 Release Please部署方式有多种官方推荐使用 GitHub Action。GitHub Action推荐最简单的方式是把 release-please 作为 GitHub Action 运行具体安装与配置说明见googleapis/release-please-action项目本仓库未包含其源码可前往该独立仓库查阅。以 CLI 方式运行所有配置选项详见 docs/cli.md。核心命令如下全局安装npm i release-please -g全局选项所有命令可用选项类型说明--tokenstring必填。具备仓库写权限的 GitHub token--repo-urlstring必填。owner/repo格式的 GitHub 仓库--api-urlstringREST API 请求的 Base URI默认https://api.github.com--graphql-urlstringGraphQL 请求的 Base URI默认https://api.github.com--target-branchstring发布 PR 基于的分支、打标签的分支默认为仓库默认分支--dry-runboolean设置后只报告将要发生的操作不实际执行--debugboolean设置后日志级别 DEBUG--traceboolean设置后日志级别 TRACEBootstrapping初始化仓库release-please bootstrap \ --token$GITHUB_TOKEN \ --repo-urlowner/repo \ --release-typerelease-type [extra options]该命令用于生成初始的release-please-config.json和.release-please-manifest.json或用附加配置更新它们并会针对目标分支打开一个包含新配置的 PR。常用附加选项包括--config-file默认release-please-config.json、--manifest-file默认.release-please-manifest.json、--path组件路径默认.、--package-name、--component、--release-type、--initial-version默认0.0.0、--versioning-strategy默认default、--bump-minor-pre-major、--bump-patch-for-minor-pre-major、--prerelease-type、--draft、--prerelease、--force-tag-creation、--draft-pull-request、--label默认autorelease: pending、--release-label默认autorelease: tagged、--changelog-path默认CHANGELOG.md、--changelog-type默认default、--changelog-sections、--changelog-host默认https://github.com、--include-commit-authors、--pull-request-title-pattern默认chore${scope}: release${component} ${version}、--pull-request-header默认:robot: I have created a release *beep* *boop*、--pull-request-footer、--component-no-space、--extra-files、--version-fileRuby 专用完整表格见 docs/cli.md。创建/更新发布 PRrelease-please release-pr --token$GITHUB_TOKEN \ --repo-urlowner/repo [extra options]使用manifest 配置时仓库中存在 manifest config 文件发布配置直接从 manifest config 文件中读取附加选项包括--config-file、--manifest-file、--path从 monorepo manifest 发布单个组件/包、--release-as、--draft-pull-request、--fork、--skip-labeling不使用 manifest 配置时需要显式指定发布选项--path默认.、--package-name、--component、--release-type、--release-as、--initial-version、--versioning-strategy、--bump-minor-pre-major、--bump-patch-for-minor-pre-major、--prerelease-type、--draft-pull-request、--label、--changelog-path、--changelog-type、--changelog-sections、--changelog-host、--include-commit-authors、--monorepo-tags、--pull-request-title-pattern、--pull-request-header、--pull-request-footer、--signoff、--extra-files、--version-file、--skip-labeling、--include-v-in-tags默认true完整表格见 docs/cli.md。在 GitHub 上创建 Releaserelease-please github-release \ --token$GITHUB_TOKEN --repo-urlowner/repo [extra options]manifest 与无 manifest 两种模式下的选项同上--config-file、--manifest-file、--path、--package-name、--component、--release-type、--monorepo-tags、--pull-request-title-pattern、--pull-request-header、--pull-request-footer、--draft、--prerelease、--force-tag-creation、--label、--release-label、--include-v-in-tags完整表格见 docs/cli.md。注旧的manifest-pr/manifest-release命令已标记为deprecated分别由release-pr/github-release以相同选项替代仅保留向后兼容将在下一个 major 版本中移除详见 docs/cli.md。初始化Bootstrapping你的仓库release-please 会查看自上个发布标签以来的提交但它不一定能发现你之前的发布记录。让仓库平滑上线的最简方式是使用 bootstrap 一个 manifest 配置上文已给出命令示例。bootstrap 会生成release-please-config.json与.release-please-manifest.json两个文件本仓库根目录下即有实际样例release-please-config.json对应 JSON Schema 见 schemas/config.json 与 schemas/manifest.json。自定义 Release Pleaserelease-please 提供了多项配置选项用于定制你的发布流程包括 changelog 类型、版本策略如always-bump-major、always-bump-minor、always-bump-patch、prerelease、service-pack等实现位于 src/versioning-strategies/、插件机制如 src/plugins/workspace.ts、src/plugins/linked-versions.ts、src/plugins/merge.ts 等以及策略工厂与 changelog 工厂。完整说明见 docs/customizing.md。通过 Manifest 配置支持 Monoreporelease-please 同样支持从同一个仓库发布多个构件组件/包即 monorepo 场景。配置方式与组件划分规则详见 docs/manifest-releaser.mdrust workspace 等场景需要配合cargo-workspace插件实现见 src/plugins/cargo-workspace.ts。支持的 Node.js 版本与版本策略本仓库的客户端库遵循 Node.js 发布节奏兼容所有当前active与maintenance状态的 Node.js 版本从 package.json 可以看到当前engines.node要求为22.0.0。面向部分已 EOL 的 Node.js 版本也提供了客户端库可通过 npm dist-tag 安装命名约定为legacy-(version)。Legacy 版本按尽力而为支持不在 CI 中测试部分安全补丁可能无法 backport依赖不会持续更新功能也不会 backport。目前提供的 legacy tag 为legacy-8兼容 Node.js 8。版本策略与许可证本库自身遵循Semantic Versioning当前版本为17.11.2见 package.json。贡献指南见 CONTRIBUTING.md设计文档见 docs/design.md常见问题排查见 docs/troubleshooting.md。代码基于Apache 2.0许可发布见 LICENSE。免责声明本仓库不是 Google 官方产品。赞分享开发工具CI/CDDevOps【免费下载链接】release-pleasegenerate release PRs based on the conventionalcommits.org spec项目地址https://gitcode.com/gh_mirrors/re/release-please点击查看免费下载相关推荐release-please 完全指南从 Conventional Commits 到 GitHub Releasesrelease please 完全指南从 Conventional Commits 到 GitHub Releases 想要自动化管理 GitHub 项目版本开发工具CI/CDDevOpsbrowserless 发布自动化全流程指南release-please 与 Conventional Commits 驱动的 npm 与 Docker 协同发布browserless 发布自动化全流程指南release please 与 Conventional Commits 驱动的 npm 与 Docker 协同后端API网关为什么PDF补丁丁能成为你处理PDF文档的终极解决方案为什么PDF补丁丁能成为你处理PDF文档的终极解决方案 在日常工作中你是否经常遇到这样的困扰PDF文档没有书签导航、多个文档合并后格式混乱、扫描版PDF无桌面应用文档上一篇探索游戏开发新领域基于Bevy引擎的游戏模板下一篇探索未来网页自动化sparticuz/chromium创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考