问题描述
在持续构建过程中，我们通常习惯于每次将源代码推送到版本控制系统时，都会触发构建系统（如Jenkins、GitLab CI/CD等）上的构建作业，以构建源代码。构建生成工件，通常是库（jar文件、dll文件等），然后将这些工件推送到工件存储（Nexus、Artifactory、GitLab软件包仓库等）。然后，这些构建会触发依赖于刚刚创建的工件的其他组件的构建，进而在软件依赖层次结构中触发进一步的构建。
Q: 为什么只有源代码的更新会触发构建作业，而工件存储中的工件更新则不会？是否有具体的原因？
至少在我熟悉的环境中（Jenkins、GitLab CI/CD、Nexus、GitLab软件包仓库），工作方式就是这样的。
Q: 是否有其他环境（构建自动化系统、工件存储等）会通过任何工件的更新来触发作业？
解决方案
目前在许多构建自动化系统中，构建作业的触发通常是基于源代码的更新。但是，近年来，随着软件供应链安全成为热门话题，一些工具和方法正在逐渐出现，以支持基于工件更新的作业触发。
一个相关的概念是：当工件更新后，自动触发对依赖该工件的项目的构建。这个概念类似于源代码的提交触发构建的方式，但是针对工件的变化。
在这个领域，出现了一些新的工具和方法，例如 GitHub 的 Dependabot。Dependabot 可以为依赖项的更新提交拉取请求。尽管需要手动审核这些拉取请求，但它已经接近了你提到的概念。
Dependabot会检查你的所有依赖项，它可以更新内部和外部依赖项。拉取请求过程帮助你审核它所做的更改。你可以设置它以达到你想要的噪音级别（例如，每周运行一次），所以它并不完全是“在工件变更时”触发。
随着软件供应链安全的重要性逐渐凸显，我相信这个概念还会进一步发展，未来可能会出现更多类似的工具和解决方案。
在探索这些新方法和工具时，请确保它们符合你的项目需求和安全标准。工件更新的自动触发构建可能会在某些情况下提供更高的效率，但也需要谨慎处理，以免引入潜在的问题。
请注意，本文中提到的工具和方法可能随着时间的推移而有所变化。在实际使用时，建议查阅相关文档以获取最新信息和指导。