第一段引用上面的摘要：Pact Broker 升级至 2.107.1 版本后，Pact 文件覆盖功能失效，导致使用相同版本号推送 Pact 文件时出现问题。本文将介绍该问题的原因，并提供启用 allow_dangerous_contract_modification 功能的解决方案，同时强调该方案的风险和替代方案。
问题原因
升级 Pact Broker 到 2.107.1 版本后，之前在 Consumer 配置中使用的 pactFileWriteMode: overwrite 属性不再生效。这是因为 pactFileWriteMode 是 Pact 本地库的配置，而非 Broker 端的配置。该属性在 Pact JS 10.x.x 版本中已被移除，具体可参考官方迁移文档。
解决方案：启用 allow_dangerous_contract_modification
要解决 Pact 文件覆盖问题，可以在 Pact Broker 中启用 allow_dangerous_contract_modification 功能。该功能允许修改现有 Consumer 版本的 Pact 内容。
配置方法：
在 Pact Broker 的配置中，将 allow_dangerous_contract_modification 设置为 true。
示例（以环境变量配置为例）：
PACT_BROKER_ALLOW_DANGEROUS_CONTRACT_MODIFICATION=true
注意事项：
- 强烈不建议启用此功能。 允许修改现有合约会使 can-i-deploy 命令的结果变得不可靠，可能导致错误的部署决策。
- 启用此功能后，每次尝试修改现有合约时，不会再返回 HTTP 409 状态码。
风险提示
启用 allow_dangerous_contract_modification 会带来以下风险：
- 破坏合约一致性： 允许修改现有合约可能导致 Consumer 和 Provider 之间的合约不一致，从而导致集成测试失败或运行时错误。
- 影响 can-i-deploy 的可靠性： can-i-deploy 命令依赖于 Pact 文件的版本控制来确定服务是否可以安全部署。允许修改现有合约会破坏版本控制，导致 can-i-deploy 命令返回错误的结果。
替代方案：使用唯一的版本号
最佳实践是为每次提交发布具有唯一版本号的 Pact 文件。 这可以确保合约的一致性，并使 can-i-deploy 命令能够可靠地工作。
以下是一些生成唯一版本号的常用方法：
- 使用 Git 提交 SHA： 将 Git 提交 SHA 作为 Pact 文件的版本号。
- 使用 CI/CD 构建 ID： 将 CI/CD 构建 ID 作为 Pact 文件的版本号。
- 使用时间戳： 将时间戳作为 Pact 文件的版本号。
示例（使用 Git 提交 SHA）：
git rev-parse HEAD
将上述命令的输出作为 Pact 文件的版本号，并将其传递给 Pact 客户端。
总结
虽然启用 allow_dangerous_contract_modification 可以解决 Pact 文件覆盖问题，但强烈建议避免使用此方法，因为它会带来严重的风险。最佳实践是为每次提交发布具有唯一版本号的 Pact 文件，以确保合约的一致性并使 can-i-deploy 命令能够可靠地工作。
