feat: add endpoint to create pacts, pacticipant, version, tags in one request

[bethesque]

No description provided.

[bethesque]

Example of how it will work here.

[bethesque]

Not sure about the field "role". We need some way of saying "is this a consumer defined contract or a provider defined contract". "Type" is such an overloaded, non-descriptive term. "contractAuthor" sounds like it's a person. "contractSpecifier" also. "contractSource"?

[bethesque]

@mefellows @TimothyJones thoughts?

[uglyog]

role made sense to me, it was clear was what it was when I saw the value for it

[uglyog]

role made sense to me, it was clear was what it was when I saw the value for it

[bethesque]

After chatting with Tim, I've dropped the "role" field in favour of just explicitly setting the consumer name and provider name for each contract. I prefer this because it doesn't introduce any new terminology.

It does seem redundant to set the consumer and provider names in the contract metadata as well as in the content, but this endpoint will be modified to allow publication of OAS documents and other types in the future, where the contract content will not contain the consumer and provider names.

[bethesque]

@uglyog I've base64 encoded the content for various reasons, one of which is so that we can publish non-utf8 contracts if need be. Can you see this being useful? Or is that covered by encoding the interaction/message contents in the contract itself?

[uglyog]

@uglyog I've base64 encoded the content for various reasons, one of which is so that we can publish non-utf8 contracts if need be. Can you see this being useful? Or is that covered by encoding the interaction/message contents in the contract itself?

I can't see a need for it, all the forms I know of will either be JSON or YAML. Even SCC is Groovy code, I think. But it doesn't hurt.

[bethesque]

Ok. Sorry, this is another big one @uglyog, but feel free to gloss over the implementation. The important things to know are:

• Using this endpoint is required to publish pacts with a branch property set for the version
• If you're interested in making the output the same across implementations, I'm printing out the logs in the Ruby client with red for error (I'm lazy and just print out the whole body if there's an error response), yellow for warning, green for info, and no colour for debug.
• Here are the docs: lib/pact_broker/doc/views/index/publish-contracts.markdown
• Here is an example of the request and response: spec/fixtures/approvals/publish_contract_nothing_exists_with_webhook.approved.json
• Here is an example of the response when validation fails spec/fixtures/approvals/publish_contract_with_validation_error.approved.json

[bethesque]

Output from Ruby client