Pact JVM中pactbroker与pact下providerBranch差异及配置咨询

你整理的配置逻辑整体准确率很高，在你使用的 Pact-JVM 4.3.9 + Pact Broker 2.93.2 版本环境下，这套配置是特性分支开发场景的标准可行方案，先把你用到的启动命令贴在下面方便对照：

mvn verify \
   -Dpactbroker.providerBranch=feature/new-rest-endpoint \
   -Dpactbroker.enablePending=true \
   -Dpactbroker.includeWipPactsSince=2022-10-21 \
  '-Dpactbroker.consumerversionselectors.rawjson=[{"mainBranch":true},{"deployedOrReleased":true},{"matchingBranch":true}]' \
   -Dpact.verifier.publishResults=true \
   -Dpact.provider.version=123456 \
   -Dpact.provider.branch=feature/new-rest-endpoint

最容易混淆的两个分支属性区别 #

你一开始提到的两个分支属性作用边界非常清晰，你现在把两个值设成一致的做法是完全正确的，不用纠结不同文档里的释义冲突：

• pactbroker.providerBranch：仅用于Broker侧筛选契约，是matchingBranch选择器的匹配基准值，不参与后续验证结果的上报逻辑
• pact.provider.branch：仅用于验证结果上报，标记当前执行验证的提供者代码所属分支，不参与前期的契约筛选逻辑
  很多人踩坑就是只配置了其中一个参数，要么同分支开发的消费者契约拉不下来，要么把特性分支的验证结果错挂到主分支上，打乱主分支的验证状态。

验证覆盖范围的核对 #

你列的5类契约覆盖范围，只有WIP契约的逻辑有一点小偏差，其余全部正确：

• 待处理（pending）契约逻辑正确：满足配置的消费者版本选择器规则、且从未被当前版本提供者验证通过的契约会被归入此类，验证失败不会打断构建，避免消费者新提交的契约阻塞提供者的特性分支开发
• 开发中（WIP）契约逻辑修正：不是“未被enablePending规则选中的待处理契约”，WIP是独立的筛选规则，会拉取includeWipPactsSince指定日期之后创建的所有消费者新契约，不管是否匹配你配置的三个消费者选择器，只要还没被当前提供者验证通过就会被纳入，验证失败同样不会打断构建。注意实际使用时日期要统一用YYYY-MM-DD格式，你注释里写的06-16-2022格式会被Pact-JVM解析报错
• 消费者主分支最新契约逻辑正确：mainBranch=true选中的是每个消费者配置的主分支（默认main/master）上的最新契约，这类契约不属于pending/WIP范畴时，验证失败会直接打断构建，属于提供者必须兼容的契约范围
• 已部署/已发布版本契约逻辑正确：deployedOrReleased=true会拉取所有标记为部署到任意环境、或者正式发布过的消费者版本对应的最新契约，同样属于必须兼容的范围，验证失败会打断构建
• 同分支匹配契约逻辑正确：matchingBranch=true会拿pactbroker.providerBranch配置的分支名，匹配同名消费者分支上的最新契约，适配消费者和提供者在同一特性分支并行开发的场景，这类契约如果已经被当前提供者版本验证通过，后续验证失败会打断构建，未验证通过的话会自动归入pending范畴

配置注意事项 #

这套配置整体没有逻辑问题，实际放到CI里跑的时候注意两个点就行：

• 不要把pact.provider.version写死成固定值，要替换成每次构建的唯一标识（比如git commit短哈希），不然Broker没法区分不同版本提供者的验证结果，会导致pending、WIP状态判断错乱
• 当前配置下，特性分支的验证结果会正确关联到对应特性分支，不会污染主分支的验证状态，符合分支开发的流程要求
• 你使用的版本组合完全支持所有用到的特性，不存在版本兼容问题

内容的提问来源于stack exchange，提问作者snukone