CI如何影响语义版本控制？ [英] How does CI affect semantic versioning?

问题描述

在陆续交付书中，建议将所有内容（包括CI脚本）保留在版本控制中。实际上，当前的CI系统（例如 gitlab CI ）已经遵循了这一经验法则，并在同一代码库中搜索CI脚本。

另一方面，我们正在对代码库进行版本控制（以及它是内置的工件）。为此，我们遵循语义版本控制； patch 字段用于错误修复， minor 字段用于非破坏性功能，依此类推，以此类推...

并且我们确保版本在两次提交之间递增通过在CI中进行检查。
但是，有些提交仅更改CI脚本；即添加分析工作，优化另一个工作，等等。

在漫长的无聊序言之后，我的问题是，对CI进行此类更改的最佳实践是什么？因为它可能会影响最终构建的工件（例如，更改CI作业中的构建标记以进行优化或...）。

是否可以在此版本中增加版本

In Countinous Delivery book, it's recommended to keep everything - including CI scripts - in the version control. Actually, current CI systems like gitlab CI already follow this rule of thumb and search for CI scripts in the same codebase.
On the other hand, we are versioning our codebase (and it's built artifacts) whenever it changes. And we follow semantic versioning for that; incrementing patch field for bugfixes, minor for non-breaking features, and so on...
And we make sure the version is incremented between commits by checking it in the CI.
But, there are commits that only change the CI scripts; i.e. adding an analysis job, optimizing another, etc.
My question, after this long boring preface, is that what is the best practice to versioning such changes to the CI? Since it possibly can affect the final built artifact (e.g. changing a build flag in the CI job for optimization or ...).
Is it ok to increment the version in this case?

推荐答案

Git是一个版本控制系统。每次您向git repo提交内容时，都会使用表示该版本的repo的内容哈希值标记该repo的内容。 git repo内容的语义版本化是多余且毫无意义的。 SemVer的重点是为生产者提供一种向消费者传达风险的方法。换句话说，语义版本控制用于构建产品标签，而不是用于生成构建的位。

Git is a revision control system. Every time you commit something to a git repo, it labels the content of the repo with a content hash value that represents that version of the repo. Semantic versioning of a git repo's content is redundant and pointless. The whole point of SemVer is to provide a means for producers to communicate risk to consumers. In other words, semantic versioning is intended for build product labeling, not the bits that go into producing the build.

如果您尝试应用 SemVer 语义，您正在标记产品输入，而不是产品本身。在完成所有单元/回归/验收测试之后，才应应用SemVer字符串。您还能如何确定代码/构建脚本的更改是否破坏了任何东西？

If you attempt to apply SemVer semantics to the repo, you are labeling the product inputs, not the product itself. You should not apply a SemVer string until after all unit/regression/acceptance tests have been performed. How else can you have any certainty whether the code/build-script changes have broken anything?

构建前标签不能工作。能够连续两次产生完全相同的输出的构建过程非常罕见，即使有的话也是如此。在世界上拥有多个带有相同SemVer字符串的API /程序包是违反最佳做法的。如果您标记回购内容，然后将该标签转发到构建输出，则每次运行构建时，都会生成一个包含不同内容的包。总是会有这样的风险，即其中的一项或多项产出会被大量释放。许多关注安全性的消费者密切关注他们消费的软件包的内容哈希。检测到某个特定的生产者发布了多个程序包散列而不改变版本号，将引发危险信号，并导致对该生产者内部流程的不信任。

Pre-build labeling cannot work. Build processes that are capable of reproducing the exact same output twice in a row, are extremely rare, if any exist at all. It is a violation of best practice to have multiple API's/packages in the world with the same SemVer string attached to them. If you label the repo content and then forward that label to the build output, every time you run the build, you produce a package with different content. There will always be some risk that more than one of those outputs will be released into the wild. Many security conscious consumers pay close attention to the content hash of packages they consume. Detecting that a particular producer has released multiple package hashes without bumping the version number, will raise red flags and lead to mistrust of that producers internal processes.

这是一个非常深入的主题，此处无法完全涵盖。其他要考虑的问题是OS /编译器/工具链更新。您还会将整个构建工具链提交到同一仓库吗？这是一种站不住脚的方法，充满了我无法完全枚举的危险，如果不花几个月的时间来记录下来，那就是危险。

This is a very deep topic that can't be fully covered here. Other issues to consider are OS/Compiler/Tool chain updates. Will you also be committing the entire build tool chain to the same repo? This is an untenable approach, full of hazards I cannot fully enumerate, without taking a few months off work to document them.

最佳做法：

• 使用语义提交消息清楚地表明开发人员的意图


• 在包装/贴标签之前验证构建输出。


• 对于非预发行出版物，始终让人们处于循环中。

这篇关于CI如何影响语义版本控制？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！