我正在为基于微服务的应用程序创建代码管道。我想为这个 CICD 使用一个管道和代码构建项目。 我有一个特定的情况，我在源阶段使用两个以上的操作。每个操作都会从不同的 github 存储库获取代码并生成不同的输出工件。然后在下一阶段，我创建了多个构建操作，该操作从映射源操作的受尊重的输出工件中获取输入工件。 我面临的问题是，其中一个存储库中的代码更改会触发启动完整管道的每一项操作，从而导致每个微服务的新部署。 我正在使用 terraform 来创建这一切。
当Source-dm中的代码发生更改时，只有 Source Stage 和 DM-Build 的 source-dm 应该运行，并且部署仅发生在 DM 微服务中。 请帮助我快速修复。 提前致谢。
最佳答案
我不相信你可以用一个 CodePipeline 来完成这个任务，至少你不能在本地完成它。
一般来说，您要么启用 PollForSourceChanges 或 webhook，要么不启用。正如我从屏幕截图中看到的那样，您正在使用 Github Version 2 Connection，任一存储库中的更改都将触发您所描述的管道。
我可以想到一些可以解决您的问题的选项，您可以根据您的用例进行选择。
- 显而易见的是，每个存储库都有一个管道(一个用于 dm，一个用于采样 - 在这种情况下，每当其中之一发生更改时，您只需构建并部署到相应的微服务(您将需要承担该地区额外一条管道 1 美元的成本)
- 您可以在第二步中生成构建的哈希值，然后在部署之前添加检查，以查看校验和是否匹配，如果匹配，则不要为此服务部署新构建。
- 您可以在构建的构建规范中添加一个检查，以查看当前执行的提交 ID 是否与前一个匹配，如果是这种情况，则默默地忽略它并且不生成构建。然后再检查一下部署微服务的微服务，看看是否有新的构建，如果答案是否定的，则不要部署。
- 您仍然可以使用此管道进行构建，但随后将其级联到另一个管道(或部署过程的另一个作业)。在该作业(可能是 lambda)中，您可以检查每个存储库的提交 ID 是否与上一个执行的提交版本匹配，然后仅部署到实际更改的版本。
如果是我，并且万一我们缺少一些上下文(正如您没有提到的那样)，最好的方法是选项 1，只需创建两个单独的管道，因为其他选项会增加不必要的复杂性。
关于terraform - 具有多个源和构建操作的 AWS Codepipeline，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/69283483/