我正在尝试将数十个服务更新为au.com.dius:pact-jvm-consumer-junit_2.12:3.5.12
from,au.com.dius:pact-jvm-consumer-junit_2.11:3.2.13
但似乎新的消费者版本正在生成旧提供者版本 ( au.com.dius:pact-jvm-provider-junit_2.11:3.2.13
) 无法处理的协议。
旧协议有一个哈希映射,其中在根目录添加了匹配规则,如下所示
{
"consumer": {
"name": "consumer-amqp"
},
"provider": {
"name": "prodvider-amqp"
},
"messages": [
{
"description": "amqp contract",
"contents": {
"body": {
"guidProperty": "795ecfd5-a3a5-430f-a0cd-1569df61bff6"
}
},
"matchingRules": {
"$.body.body.guidProperty": {
"regex": "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
}
}
}
],
"metadata": {
"pact-specification": {
"version": "3.0.0"
},
"pact-jvm": {
"version": "3.2.13"
}
}
}
新的消费者添加和包装body
匹配器。以下是使用新消费者版本生成的相同协议的示例
{
"consumer": {
"name": "consumer-amqp"
},
"provider": {
"name": "prodiver-amqp"
},
"messages": [
{
"description": "contract",
"contents": {
"body": {
"guidProperty": "e2490de5-5bd3-43d5-b7c4-526e33f71304"
}
},
"matchingRules": {
"body": {
"$.guidProperty": {
"matchers": [
{
"match": "regex",
"regex": "[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}"
}
],
"combine": "AND"
}
}
}
}
],
"metadata": {
"pact-specification": {
"version": "3.0.0"
},
"pact-jvm": {
"version": "3.5.12"
}
}
}
由于该更改,提供程序无法解析匹配规则并出现以下错误:
body
^
10:21:24.526 [main] DEBUG au.com.dius.pact.matchers.JsonBodyMatcher - compareValues: No matcher defined for path List($, body, body, guidProperty), using equality
10:21:24.527 [main] WARN au.com.dius.pact.matchers.Matchers$ - Path expression body is invalid, ignoring: [1.1] failure: `$' expected but `b' found
java.lang.AssertionError:
comparison
{$.body.body.guidProperty=Expected 'e2490de5-5bd3-43d5-b7c4-526e33f71304' but received 'aff876f5-5014-937c-6855-c099f9857437'
查看 v3规范,新消息似乎是有效的,旧的提供程序库(v3.2.13)不支持它吗?我查看了代码并发现了这个提交,在我看来它是在哪里引入了更改。
根据我的测试,新的提供程序库(3.5.12)可以处理新旧格式,但是如果类路径中存在新的提供程序库和旧的消费者库,则 http 合同测试会因运行时错误而失败。
问题:
1)有没有办法强制新消费者以旧方式创建协议,并且该表单规范是否符合?
2)有没有办法将提供者更新到新版本,并且路径中仍然有旧的消费者库并且不会失败?