SpringCloud/spring-cloud-contract
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Adding a mechanism to disable the local vs remote stub location

Browse Source 
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
This commit is contained in:
Marcin Grzejszczak
2018-02-16 13:35:56 +01:00
parent 5de9959561
commit d87e669a23
5 changed files with 147 additions and 139 deletions
Download Patch File Download Diff File Expand all files Collapse all files

80
docs/src/main/asciidoc/verifier_setup.adoc
View File

@@ -393,7 +393,6 @@ following sections:
* <<maven-different-base>>
* <<maven-invoking-generated-tests>>
* <<maven-sts>>
* <<maven-consumer>>
[[maven-add-plugin]]
==== Add maven plugin
@@ -767,67 +766,6 @@ In order to fix this issue, provide the following section in your `pom.xml`:
</build>
----
[[maven-consumer]]
==== Spring Cloud Contract Verifier on the Consumer Side
You can also use the Spring Cloud Contract Verifier for the consumer side. To do so, use
the plugin so that it only converts the contracts and generates the stubs. To achieve
that, you need to configure Spring Cloud Contract Verifier plugin in exactly the same way
as you would for a provider. You need to copy contracts stored in
`src/test/resources/contracts` and generate WireMock JSON stubs using the
`mvn generateStubs` command. By default, the generated WireMock mapping is stored in a
directory named `target/mappings`. From these generated mappings, your project should
create additional artifacts with a classifier of `stubs` for easy deployment to the maven
repository.
Here is a sample configuration:
[source,xml,indent=0]
----
<plugin>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-contract-maven-plugin</artifactId>
<version>${verifier-plugin.version}</version>
<executions>
<execution>
<goals>
<goal>convert</goal>
<goal>generateStubs</goal>
</goals>
</execution>
</executions>
</plugin>
----
When present, JSON stubs can be used in consumer automated tests, as shown here:
[source,groovy,indent=0]
----
@RunWith(SpringTestRunner.class)
@SpringBootTest
@AutoConfigureStubRunner
public class LoanApplicationServiceTests {
@Autowired
LoanApplicationService service;
@Test
public void shouldSuccessfullyApplyForLoan() {
//given:
LoanApplication application =
new LoanApplication(new Client("12345678901"), 123.123);
//when:
LoanApplicationResult loanApplication = service.loanApplication(application);
// then:
assertThat(loanApplication.loanApplicationStatus).isEqualTo(LoanApplicationStatus.LOAN_APPLIED);
assertThat(loanApplication.rejectionReason).isNull();
}
}
----
`LoanApplication` makes a call to the `FraudDetection` service. This request is handled
by a WireMock server configured with stubs generated by the Spring Cloud Contract
Verifier.
=== Stubs and Transitive Dependencies
The Maven and Gradle plugin that add the tasks that create the stubs jar for you. One
@@ -872,6 +810,24 @@ For example, you might decide to have no dependencies at all.
As a consumer, if you add the stub dependency to your classpath, you can explicitly
exclude the unwanted dependencies.
=== CI Server setup
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.
=== Scenarios
You can handle scenarios with Spring Cloud Contract Verifier. All you need to do is to