如何通过持续部署触发发布管道？

Posted 2023-03-07

【中文标题】如何通过持续部署触发发布管道？

【英文标题】：How do I trigger release pipeline with continuous deployment?

【发布时间】：2021-12-03 14:20:47

【问题描述】：

标题不是最好的，我同意，请阅读更多细节以理解我的意思......

我有一个具有以下属性的项目/存储库：

提交消息跟随Conventional Commits 上述结果：存储库中没有一个位置具有版本号。版本是根据提交历史自动计算的。 过去“发布”的历史基本上是git标签历史（当发布完成并出现1.2.3版本时，相应的提交被标记） CI 是“简单的”/与 Github 集成，每次合并/推送到 master 都会触发完整的管道，包括 deploy/release 部分（生成新版本，推送标签，“使简而言之） 我没有办法（或者，我认为我没有办法，或者我不想）手动触发 CI 以从 CI 本身释放。每个触发器都应该来自 git/github。

虽然这通常工作得很好，但我的问题是通常 repo 是不变的并且没有收到真正的新提交，但是在某些活跃的日子里，我可能有 2-3-4-10 个新的拉取请求要合并。

使用当前方法，10 个合并的拉取请求将导致 10 个版本增加 10 个版本。但我更愿意首先合并所有 10 个，然后然后有一个版本和一个版本增加。

任何建议，我该如何实现，这里最先进的建议是什么？

我的一个想法是有一些 pre-release 或 develop 分支，我可以首先合并 PR，并且只有在发布时才将 develop 合并到 master。但这看起来有点麻烦，并没有真正让贡献者的生活更轻松（他们需要以开发为目标，然后我需要创建从开发到主的 PR 等......）

更新：

我相信，答案应该与 CI 无关。在这里使用哪个确切的 CI 系统并不重要，重要的是 我不想去 CI 来触发作业，所有交互都应该通过存储库进行。 repo 和 CI 之间的 Webhook/连接当然可用并且可以正常工作。 当然，我所说的“简单”CI 并不是说​​它的配置是固定的。当然，我可以以任何我想要的方式更新它，这没有问题（触发来自存储库、不同分支等的不同事件）

【问题讨论】：

触发任何类型的 CI 构建取决于 CI 系统。对此没有通用的 Git 范围的答案。选择您正在使用的 CI 系统并相应地更新标签。

@torek 我认为没关系。重要的是先决条件“我不想去 CI 并手动触发工作/我不能这样做”。所有交互都应该发生在存储库中（并且 CI 系统已经配置为接受来自 repo 的 webhook，并且可以配置为我想要的任何内容）

GitHub 的 CI 系统使用 GitHub Actions。 Bitbucket 的 CI 系统使用 Bitbucket 管道。两者都使用 YAML 语法，但您放入 .yml 文件的内容不同。所以它肯定是依赖于 CI 系统的。 （如果你使用 Travis，你会写一个 .travis.yml 并将其提交到你的存储库......使用 Travis 的 YML 和文件名等）（我看到你提到了 GitHub，所以我会为你编辑标签.)

@torek 你误解了他们的问题。我不是在问“在 YAML 文件中写什么”/“如何配置或触发我的 CI 系统”。我问的是一般方法和现有的最先进标准。不，我没有使用 Github 操作（我的问题也不是特定于给定 CI 系统的，正如我已经说过的），所以我正在恢复您的编辑。

【参考方案1】：

有多种方法可以实现您的愿望。

你自己已经提到的一个想法：

我的一个想法是有一些预发布或开发分支，我可以首先合并 PR，并且只有在发布时才合并开发到 master。

这是迄今为止最省力的方法。 其他一切都需要您更改管道。 如果您对此感到满意，那么考虑到您当前的结构，这里有一些不难实现的想法：

将管道更改为不在master 分支中的每次更改时发布，而是在release 分支中的每次更改时发布。这样，所有开发人员仍然可以定位master，然后您可以压缩所有提交并将它们介绍给release。这种方法很简单，但根据项目的不同，可能会导致 git 结构出现问题和/或混淆。 将管道更改为不在master 分支中的每个更改上发布，而是在推送的每个新标签上发布。这样，您可以收集master 分支中的所有提交，一旦您决定它已准备好发布，只需手动推送一个 git 标签。如果您想更进一步，将管道配置为仅当您（或其他受信任的维护者）有一个包含 version bump to vX.Y.Z 之类的 signed commit message 时才自动创建一个 git 标签。这种方法是一种更现代的方法，提供了更大的灵活性，但与以前的方法相比，它需要对管道进行更多的更改（请记住，更改管道是一次性的）。

【讨论】：

是的，你的第一个子弹与我的建议有点像，只是不知何故“颠倒了”。实际上，现在我认为这种方式（主/发布）会比我最初想的（开发/主）更容易/更简单。我肯定改变管道没有问题。关于推送标签 - 这与我的第一个项目相矛盾，即不要手动弄乱版本。一般来说，我不知道下一个版本号是哪个（比如，我知道，如果我分析自上一个标签以来的常规提交，但这是发布自动化的工作），所以我不能手动推送标签。