feat: support extended verification results#778
Conversation
6be0735 to
1a5fdef
Compare
Optionally the body can contain details about the Pact implementation which performed the verification, and test results, which support arbitrary json
{
"providerApplicationVersion": "1",
"success": true,
"buildUrl": "http://build-url",
"testResults": [],
"verifiedBy": {
"implementation": "Pact-Rust",
"version": "1.0.0",
"clientLanguage": {
"testFramework": "TEST",
"name": "TESTER",
"version": "1.2.3"
}
}
}
1a5fdef to
e745d3e
Compare
|
Are you both able to cast your eyes across this and suggest any improvements? If not, I'd like to merge it, but I do have an outstanding question
|
|
@YOU54F PR LGTM but your point does make sense, having ability store metadata is useful for future. we do have to be cautious in letting users dump whatever they want, currently @mefellows what's your take on this, we could have something like cc @impurist |
|
Making it a key/value store might make the data less query-able. e.g. if I understand correctly, you could find all verifications for a given language or version. This could be useful down the track and in some screens. Having it as a key/value store provides more flexibility, but does mean that users can (and probably will) put all kind of things in there. I think it's OK to start this way, and if we have a strong use case we can move to k/v. I believe a data migration in that direction is doable too, if we decide to. |
|
Thanks team :) |
Optionally the body can contain details about the Pact implementation which performed the verification, and test results, which support arbitrary json
Relates to pact-foundation/pact-go#499
Question -
Would it be better to support arbitrary fields in
clientLanguage, similar to `testResults, to better support extensibility.