Make can-i-deploy output more helpful

[bethesque]

At the moment, can-i-deploy output tells you what is wrong, but it doesn't tell you how to fix it. I've been working on some ideas for how this could be improved.

Existing output.

Computer says no ¯\_(ツ)_/¯

CONSUMER     | C.VERSION | PROVIDER     | P.VERSION | SUCCESS? | RESULT#
-------------|-----------|--------------|-----------|----------|--------
foo-consumer | 1         | bar-provider | 1         | true     | 1
foo-consumer | 1         | baz-provider | 4         | false    | 2
foo-consumer | 1         | dog-provider | ???       | ???      |

VERIFICATION RESULTS
--------------------
1. http://localhost:9292/pacts/provider/bar-provider/consumer/foo-consumer/pact-version/a0551481bb93073f7c63b434ae80efe53ab6bc53/verification-results/106 (success)
2. http://localhost:9292/pacts/provider/baz-provider/consumer/foo-consumer/pact-version/3f4e968f76919a4739d3c7feae9783ee350a8ad6/verification-results/107 (failure)

The verification for the pact between version 1 of foo-consumer and the latest version of baz-provider 
with tag prod (4) failed
There is no verified pact between version 1 of foo-consumer and the latest version of dog-provider 
with tag prod (no such version exists)

Potential improved output.

Computer says no ¯\_(ツ)_/¯

CONSUMER     | C.VERSION | PROVIDER     | P.VERSION | SUCCESS? | RESULT#
-------------|-----------|--------------|-----------|----------|--------
foo-consumer | 1         | bar-provider | 1         | true     | 1
foo-consumer | 1         | baz-provider | 4         | false    | 2
foo-consumer | 1         | dog-provider | 5         | ???      | 3


1.  The verification for the pact between version 1 of foo-consumer and the latest version of bar-provider 
with tag prod (4) succeeded
      See http://localhost:9292/pacts/provider/bar-provider/consumer/foo-consumer/pact-version/a0551481bb93073f7c63b434ae80efe53ab6bc53/verification-results/104 (success)

2.  The verification for the pact between version 1 of foo-consumer and the latest version of baz-provider 
with tag prod (4) failed
      See http://localhost:9292/pacts/provider/baz-provider/consumer/foo-consumer/pact-version/3f4e968f76919a4739d3c7feae9783ee350a8ad6/verification-results/105 (failure)
    Next steps:
      Deploy baz-provider version >= 5 to prod as it has successfully verified foo-consumer version 1

3. There is no verified pact between version 1 of foo-consumer and the latest version of dog-provider with tag prod (no such version exists)
    Next steps:
      Add pact verification tests to dog-provider or configure can-i-deploy to ignore dog-provider

[bethesque]

cc: @mefellows

[mefellows]

Love it Beth! If that's doable, especially (2) that will be awesome.

Other things that come to mind:

1. Webhooks - for case (3) it might be that the webhook hasn't fired (or isn't configured). You could say something like "configure a webhook to trigger the provider build" or "add the --retry-while-unknown flag... to wait for a provider result". I can see it getting complicated, but it's
2. where there is a failing build (an alternative 2), I'm assuming where there isn't a compatible provider, the text would be something like "Go and speak with for baz-provider and discuss getting the change implemented"?

[bethesque]

1. Yes, we're already detecting the lack of webhooks when publishing contracts, and suggesting to create one, so we can do it here too.
2. Yes, we can detect the difference between
   1. there is a newer version of the provider that passes (next steps: you need to get the passing version deployed)
   2. there are only failed results (suggests they have the pipeline set up, next steps: just need to implement the change)
   3. There are no verification results for this pact version (next steps: provider needs to set WIP on or explicitly verify the pact)
   4. There are no verifications at all from this provider (next steps: they need to set up their entire pact workflow)

[ulich]

I like that.

Another great improvement would be to have a link to the failing provider build. When the webhook triggers the CI build, most CI servers probably return a reference to the job that was created. But I can imagine its not easy to achieve this in a generic way, the responses from the different CI servers are probably quite different. Maybe you could support the ones which are widely used?

[bethesque]

There's actually a field in the database to store that information, but it's not currently wired up for use. It should be available in the upcoming months, when I release the new "all in one" contract and verification publishing endpoints.