Add contact details for consumer and provider teams

[bethesque]

Having just joined a client company with an existing broker with a heap of pacts, I realise how much more benefit could be gained by publishing contact details for each pacticipant. These details would be included in the HTML view of each pact.

PactBroker::Client::PublicationTask.new do | task |
  task.consumer_version = MyConsumer::VERSION
  task.repository_url = "http://github.com/some-company/my-consumer"
  task.add_contact "My Consumer Team" do | contact |
    contact.add_channel :email, "my-consumer@company.com"
    contact.add_channel :slack, "https://some-company.slack.com/messages/my-consumer-team"
  end
end

(similar config for provider)

Option 1. Include details with every pact/verification

Pro: no separate call Con: can only update info by publishing a pact/verification. If provider is not verifying pact, then provider details cannot be added.

Option 2. Add information to the pacticipant resource

Pro: can update directly via API/UI (if/when we build a UI) Con: need to add new call to all publishing clients and ensure they all PATCH the info. But how do they know when to update? Should the config in the code overwrite the server? Gets messy.

Other design considerations

1. Is "channel" a good term? Is there a better one?
2. Allow multiple contacts or only one? Only allowing one would make option 2 much easier. No difference if going with option 1.

@uglyog @mefellows @neilcampbell your thoughts would be appreciated

[bethesque]

Having thought about this more, I remember that when I was going down this path a while back, I decided that duplication of information was bad, and that we should just store a link to the project repository, which should have (but probably doesn't, sigh) all that information.

[mefellows]

I love this idea.

It does raise some other thought bubbles for me though:

• Is it more appropriate to have this information recorded in the pact itself (for example, in the metadata section or even given a first class property?), and have the broker use this information, rather than have the broker as the source of truth for a pact?
• If so, is it an appropriate time to create an official Json Schema for this (let's not make it a dependency for this work)?

With respect to implementation options I believe that Option 2 is the best.

Aside from it seemingly crossing concerns and conceptually it might be best separated from the verification and publish processes, as you say it is the most flexible for when we add our (unicorn) UI. You can see a situation where this might be manually managed outside of a development lifecycle and so decoupling from the verification and publishing seems prudent. At the very least, it gives some flexibility in its usage.

This of course doesn't preclude client libraries from combining two calls to preserve existing workflow behaviour.

[bethesque]

I guess my fear of having it decoupled from the publishing/verification cycle is that information left in any repository gets outdated. I can imagine a dev modifying a pact and then going, oh wait, that info in the pact publishing task it outdated, I'll update it and commit it now. Until we get a nice UI, I can't see people looking at the info in the broker and then going, that's out of date, I'll just open up the HAL browser and update that information.

If we try and do a middle ground of putting the info in the publishing config, and update it in the pacticipant resource each time, we'll just end up overriding any manual changes.