Closed mefellows closed 4 years ago
Did you miss a word at the end of "stub out the API from"?
Is this any different from doing a curl to get an existing pact file from the broker and then starting it up? Or is there some extra magic in there?
Did you miss a word at the end of "stub out the API from"?
Yes, I must have truncated that line - fixed.
Is this any different from doing a curl to get an existing pact file from the broker and then starting it up? Or is there some extra magic in there?
Not really, just some nice sugar and improves the dev experience. I see it as the reverse of the publish command - the ability to pull down a contract based on tags etc. would be useful, and saves people from having to understand the broker API.
...I wouldn't put this at the top of the list either, just seemed a relatively straightforward thing we could implement and something worth doing given time.
It would be an easy "first issue" for someone.
If anyone is volunteering to implement this, please use the existing code in: https://github.com/pact-foundation/pact-support/blob/master/lib/pact/consumer_contract/pact_file.rb
I've updated it to be able to read from a URL. Next step would be to give it broker credentials.
Just noting that we should now support the --broker-token
flag as per our other CLIs.
Which packing unit needs updating Matt? (docker, ruby standalone?)
I think the Ruby Standalone CLI tools as a first cut would be perfect. Most teams will have the tools bundled with their language (e.g. Node/Go) so can use it from the CLI.
AS A new consumer of an existing API I would like to be able to stub out the API from an existing contract SO that I can understand how it works and rapidly develop prototypes against it, without having to first write consumer tests and publish a contract
Particularly for provider-driven workflows where an API is well established (e.g. Identity or core services), being able to quickly discover and develop against an API is really useful to understand if it's going to suit your need.
Having the pact files locally available pre-supposes the consumer-driven workflow, where the tests generate the file that can then be used as a stub, which is not helpful in this scenario.