when stubsMode is set to LOCAL or REMOTE, and repositoryRoot starts with git:// we can clone the provided git repository, and search for the folder with stubs for the given artifact. So if the git repo has a folder structure of groupid/artifactid/version (where group id is either dot or slash separated), then we will provide a path to that repository for the stub runner to harvest the stubs
- externalized versions
- added more debugging messages
- added ContractProjectUpdater that updates the project containing contracts from SCM. ATM supports only git
- added ResourceResolver that retrieves the ProtocolResolvers. It does it via spring.factories entries containing StubDownloaderBuilder. SDP extends ProtocolResovler.
added StubRunner.properties map, that will contain any properties that will be later used by any StubDownloader implementations
- added PUBLISH_STUBS_TO_SCM env var for Docker, so that publishStubsToScm task gets called
- updated docs
Breaking:
- StubDownloaderBuilder extends ProtocolResovler. By default the ProtocolResolver methods return null.
- stubRunnerOptions.stubRepositoryRoot is a Resource not a String
- generateWireMockClientStubs Gradle task got removed
- if folder with contracts has a subfolder called contracts, we will pick contracts from the subfolder
fixes#580
with this change there are numerous helper methods that should provide a more descriptive DSL for the response status. Instead of a numerical status you can now call a method e.g. instead of 200 call OK()
fixes gh-575
* Fix links to contract-dsl section.
* Add three second tour.
* Add consumer side info in the three second tour.
* Add three-minute tour.
* Generate readme changes.
When fetching stubs / contracts in a CI, shared environment, what might happen is that
both the producer and the consumer reuse the same local Maven repository. Due to this,
the framework, responsible for downloading a stub JAR from remote location,
can't decide which JAR should be picked, local or remote one. That caused
the `"The artifact was found in the local repository but you have explicitly
stated that it should be downloaded from a remote one"` exception
and failed the build.
For such cases we're introducing the property mechanism:
- via `stubrunner.snapshot-check.skip` system property
- via `STUBRUNNER_SNAPSHOT_CHECK_SKIP` environment variable
if either of these values is set to `true`, then the stub downloader will not
verify the origin of the downloaded JAR.
fixes gh-545
with this change we're adding generation of 2 docker images - verifier and stub runner
we also added a project `spring-cloud-contract-stub-runner-boot` which contains a far jar with stub runner boot
fixes gh-526, gh-516
* Introduces explicit mode of stub downloading
you have to explicitly provide the mode [CLASSPATH, REMOTE, LOCAL] of how you want to fetch and register stubs
fixes gh-287
without this feature we're missing an option to print all mappings registered for servers
with this feature it will be much easier to debug what was registered in which http server stub. The mappings will be dumped to files with name artifactName_registeredPort
fixes#355
without this change we're very strict in terms of the number of called send methods on the rabbittemplate
with this change we accept that the method could have been called more than once
fixes#332
