我读过这样的文章，建议在提供者端验证存在于消费者功能分支中的合约，实际上允许合约在合并到master之前进行"预先验证"。但是，我已经阅读了 Pact 团队的其他文档，说明相反的情况。在《达成公约涅槃的步骤》中，它指出"为了在提供者的CI中保持绿色构建，而不是验证最新的整体协议，它应该验证CI中标记为"master"的最新版本的协议。在这里，我假设"最新整体协议"一词是指发布到 Pact 代理的消费者功能分支中可能存在的协议。
我很困惑。为了不像《达成契约涅槃的步骤》中所述的"让提供者团队不高兴"，如果提供者永远不会验证该协议，而只验证"主"和"生产"协议，那么从消费者的功能分支发布协议的目的是什么？问这个问题的另一种方法是，何时/应该从功能分支发布/验证协议，而不是针对"主"和"生产"协议的消费者和提供者的主分支？
只是注意到这是关于"有效协议设置"的最新指南：https://docs.pact.io/best_practices/pact_nirvana。希望这更清楚。
但如果不是，预验证功能分支绝对是经纪人的核心功能，也是我们想要做的事情。一旦在 master 中进行更改，在 99% 的情况下它应该是一帆风顺的(即兼容(。标准做法是 a( 有一个 webhook，可以触发提供程序构建的协议验证步骤来验证新功能，或者 b( 在推送更改时让提供程序中的相应功能分支在 CI 中验证协议。
还有一项即将推出的新功能称为"待定协议"，它也将大大改善这种情况，有效地允许任何新合同不会破坏提供商的构建，但如果更改得到支持，仍然可以向消费者提供反馈。