Define stub version in stub runner

[pmendelski]

Hi

I can see that there is no possibility to define a specific version of a stub dependency in a stub runner.

Stub id consists of (no version):

groupId:artifactId:classifier:port

Hardcoded any version in dependency resolver:
https://github.com/Codearte/accurest/blob/accurest-1.0.6/stub-runner/stub-runner/src/main/groovy/io/codearte/accurest/stubrunner/GrapeStubDownloader.groovy#L62

I would like to prove a team that develops other service that my tests worked with their previous stubs. How can I do that?

[marcingrzejszczak]

At the time being we are assuming that you always want the latest stub.

In our approach with Consumer Driven Contracts we assumed that you always publish the latest contracts to some Nexus / Artifactory. If you support different versions of the API then you should define them in the contracts inside the latest jar.

Maybe you could provide more information about how you version your stubs?

[marcingrzejszczak]

So with the current version in master you can pass the stub to download in the following notation:

groupId:artifactId:version:classifier:port

[pmendelski]

Thanks for adding so quickly a version number to the stub id notation.

You asked how I version my stubs. The answer is "it depends" :) but mostly it is a straight forward process. Every time CI creates a release jar it also creates a release jar with stubs, then both are published to artifactory.

I can see a problem with dropping a version number in a stub id in following scenarios:

• Services are not backward compatible. Backward compatibility is supported by running service instances in previous versions.
• There is a change in a service developed by other team. They made a mistake and changed the contract and broke backward compatibility. All CI builds of dependent services are marked red but their code base did not change.

[marcingrzejszczak]

You asked how I version my stubs. The answer is "it depends" :) but mostly it is a straight forward process. Every time CI creates a release jar it also creates a release jar with stubs, then both are published to artifactory.

We had the same approach

Services are not backward compatible. Backward compatibility is supported by running service instances in previous versions.

In that case we just published a new jar with stubs - the version remained the same.

There is a change in a service developed by other team. They made a mistake and changed the contract and broke backward compatibility. All CI builds of dependent services are marked red but their code base did not change.

Yup that was the case. Even better they could go to production even though they broke everyvody else's tests

Our approach was described her in more depth: http://toomuchcoding.com/blog/2015/09/27/microservice-deployment/

As for backwards compatibility check we have an idea of how to do it: #225