当前的git repo包含以下项目：
╔═════════════╗
║ projects ║
╠═════════════╣
║ A ║
║ B ║
║ C ║
║ D ║
║ E ║
╚═════════════╝
有三种不同的管道，即
x，y和z 如果monorepo中的某个项目发生更改，则应触发不同的管道，即：
如果在文件夹
a中进行了提交，则管道x应该如果目录
a --> x或b中发生更改，则应运行管道c（y），如果b || c > y或dir d发生更改，则管道应开始运行（e）。如何实现？大多数配置项是由存储库中的更改触发的，例如一个提交回购并触发管道。有一对一的关系。如果将其转换为monorepo，则意味着1个更改将导致3个管道触发，而在某些情况下，仅应触发1个管道。
#1 楼
如果将其翻译为monorepo，则意味着在3个管道触发器中产生1个更改结果
，而在某些情况下，应该仅触发1个管道。
我肯定会进一步考虑这一点。使用monorepo的最令人信服的原因之一是，它不会造成项目的技术分离。只有逻辑上的区别，唯一的技术区别可能就是您的版本控制（除非您具有通用版本号）。这意味着，您不能100％保证任何一个项目都不依赖于另一个项目。因此，最终的管道在某个时候应该包括存储库中的所有项目。这样，您可以保证对一个项目的更改不会对存储库中的任何其他项目产生负面影响（以耗时最长的构建，发布等项目为代价）。
话虽如此，如果您的管道中有一些步骤需要单独运行（lint，语法，编译等），则大多数CI都应该有一种方法可以过滤您的仓库特定的文件夹/项目。如果不是这样，并且您仍然不想在所有项目上运行，则可能需要考虑将您的存储库重构为单独的存储库或更改CI工具以符合您的工作流程。
#2 楼
您需要缩小范围并使用Monorepos工具。实际上，Github上有各种很棒的monorepo列表（这是最近的列表），哪种工具最适合您的用例（您使用的是哪种编程语言？）。如果您您的存储库中有完全隔离的项目，您可以使用
git diff输出来整理一些bash脚本，或者更好地使用许多可用的支持monorepo的内置实用程序之一（请参见上面的示例）。
评论
要么在流水线触发器上添加一个过滤器（高度依赖于CI系统），要么以正确的方式进行操作并拆分这些回购，所以项目B没有理由获得项目A，C，D和E的所有历史记录，这只是噪音而已跟踪B的历史更加困难，因为它使提交与它无关。