How do you see this project working with a pact broker in the future?

[travi]

I've been trying to follow along with the continued progression, but I'm still getting my head wrapped around the workflow. To help me paint the proper picture, I figured picking your brain about the longer-term vision would be beneficial. I'm planning to use the pact-proker to manage my pacts and hope to verify against both a production tag as well as specific versions for "future work".

I'm curious if you have plans for how this interaction might work beyond having a previous build step pull the pact file to the local filesystem. I'd love to see something like how the sbt plugin pulls all of the latest pacts for that provider (although I'd like the flexibility to pull all based on a tag, like above).

If something like this were in place, would the providerState defined in the pact need to be handled any differently from the current design as the list of pacts was looped over?

I have a pact file published to my broker that I'd love to be able to verify with this project, but I'm having a hard time seeing the planned path forward and where I might be able to jump in and help out.

[elliottmurray]

I'll have to check if the ruby plugin will do a http instead of local look up. I just pass the pact file location through as is. I can probably do something quick if that isn't working over http. So in theory if that works you should be able to use Pact Broker (even if it is maybe not the most efficient solution)

I haven't fully got my head around the SBT or Java builds yet either! I've used the Maven once before - I'll have to get a more detailed overview from Ron and see what we can do with Grunt or Gulp but they are slightly different beasts so I'm not sure it will ever be like that. I've modelled this a lot closer to the ruby version with tests that have a setup.

I could look at having a setup url as part of the dsl. Might make it simpler to use but I'll have to think about how to do it.

As for the tags on Pact Broker - probably best to find out how that works at Pact Broker! I don't actually know. I had assumed it would give you some different url/params which you can manage in your code base?

As I said if this is an issue putting in a js http request instead of a file look up shouldn't be too hard.

[travi]

While interacting with a broker may not be the most efficient solution at runtime, it does seem to be the most efficient way to share pacts, so I would see big value if the process of pulling them in and verifying them could be simplified.

I haven't gotten incredibly deep with the sbt versions, but I did find this particular feature valuable. Having the stateChangeUrl available seemed to be a fairly elegant solution to decoupling the the fixture that sets up the providers data state from the process of looping over the pacts that need to be verified.

Regarding the tags, I mostly mentioned that detail because it seemed to be a shortcoming of the sbt plugin. While it made it simple to pull all of the pacts for the provider, it didn't give the ability to choose between the list of pacts tagged as production vs latest. Regardless of what that query needs to look like in the request to the broker, I just think that the api for getting pact-js-provider to pull pacts from the broker should enable that choice.

As a side note since you mentioned Grunt, I am a Grunt user, so having something available to wrap the verification process into a grunt plugin is something that I would find valuable.

Thanks for your work moving this project forward. Let me know if there is something I can do to help build this out or at least help test it once you get a chance to make progress with it.