在Countinous Delivery book中，建议将所有内容（包括CI脚本）保留在版本控制中。实际上，当前的CI系统（例如gitlab CI）已经遵循了这一经验法则，并在同一代码库中搜索CI脚本。另一方面，只要代码库发生更改，我们就会对代码库（及其构建的构件）进行版本控制。为此，我们遵循语义版本控制；为错误修正递增patch字段，为非破坏性功能递增minor，依此类推...并且我们通过在CI中检查来确保版本在两次提交之间递增。但是，有一些提交仅更改了CI脚本。即添加分析工作，优化其他工作等。经过漫长而无聊的序言之后，我的问题是，对CI进行此类更改的最佳实践是什么？因为它可能会影响最终构建的工件（例如，更改CI作业中的构建标记以进行优化或...）。在这种情况下可以增加版本吗？
Git是一个修订控制系统。每次您向git repo提交内容时，它都会使用表示该版本的repo的内容哈希值标记该repo的内容。 git repo内容的语义版本化是多余且毫无意义的。 SemVer的重点是为生产者提供一种向消费者传达风险的方法。换句话说，语义版本控制用于构建产品标签，而不是用于生成构建的位。
如果您尝试将SemVer语义应用于仓库，则将标记产品输入，而不是产品本身。在完成所有单元/回归/验收测试之后，才应应用SemVer字符串。您还能如何确定代码/构建脚本的更改是否破坏了任何内容？
构建前标签无法使用。能够连续两次产生完全相同的输出的构建过程非常罕见，即使有的话也是如此。在世界上拥有多个带有相同SemVer字符串的API /程序包是违反最佳实践的。如果您标记回购内容，然后将该标签转发到构建输出，则每次运行构建时，都会生成一个包含不同内容的包。总是会有这样的风险，即其中的一项或多项产出会被大量释放。许多注重安全性的消费者密切关注他们消费的软件包的内容哈希。检测到特定生产者释放了多个程序包哈希而没有增加版本号，将引发危险信号并导致对该生产者内部流程的不信任。
这是一个非常深入的主题，此处无法完全涵盖。其他要考虑的问题是OS /编译器/工具链更新。您还会将整个构建工具链提交到同一仓库吗？这是一种站不住脚的方法，充满了我无法完全枚举的危险，如果不花几个月的时间来记录它们，那就是危险。
最佳做法：