From 23420d7da8d2cb251a5d18b0a73fdf7a5a568437 Mon Sep 17 00:00:00 2001 From: buildmaster Date: Thu, 28 Mar 2019 11:07:54 +0000 Subject: [PATCH] Sync docs from 2.1.x to gh-pages --- .../multi__spring_cloud_contract_faq.html | 2 +- ...ti__spring_cloud_contract_stub_runner.html | 2 +- ..._cloud_contract_verifier_introduction.html | 8 ++--- ..._spring_cloud_contract_verifier_setup.html | 4 +-- ...multi__spring_cloud_contract_wiremock.html | 4 +-- 2.1.x/multi/multi_contract-dsl.html | 4 +-- .../multi_stub-runner-for-messaging.html | 4 +-- 2.1.x/single/spring-cloud-contract.html | 28 ++++++++-------- .../configs.html | 2 +- 2.1.x/spring-cloud-contract.xml | 32 +++++++++---------- 10 files changed, 45 insertions(+), 45 deletions(-) diff --git a/2.1.x/multi/multi__spring_cloud_contract_faq.html b/2.1.x/multi/multi__spring_cloud_contract_faq.html index c7601cec52..863cdd094f 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_faq.html +++ b/2.1.x/multi/multi__spring_cloud_contract_faq.html @@ -67,7 +67,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi body: "bar" ]) } -}
[Important]Important

Please read the Groovy docs related to JSON to understand how to +}

[Important]Important

Please read the Groovy docs related to JSON to understand how to properly structure the request / response bodies.

3.4 How to do Stubs versioning?

3.4.1 API Versioning

Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are different approaches.

  • use Hypermedia, links and do not version your API by any means
  • pass versions through headers / urls

I will not try to answer a question which approach is better. Whatever suits your needs and allows you to generate business value should be picked.

Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support. diff --git a/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html b/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html index 668ecc65ad..fcf0d6b529 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html +++ b/2.1.x/multi/multi__spring_cloud_contract_stub_runner.html @@ -761,7 +761,7 @@ the Stub Runner server. It will be available at port 8750< }

As you can see we want to start a Stub Runner Boot server @EnableStubRunnerServer, enable Eureka client @EnableEurekaClient and we want to have the stub runner feature turned on @AutoConfigureStubRunner.

Now let’s assume that we want to start this application so that the stubs get automatically registered. We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where - ${SYSTEM_PROPS} would contain the following list of properties

* -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1)
+ ${SYSTEM_PROPS} would contain the following list of properties
* -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1)
 * -Dstubrunner.cloud.stubbed.discovery.enabled=false (2)
 * -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org.
 * springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework.
diff --git a/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html b/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
index 263549d427..06a5e4824c 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_verifier_introduction.html
@@ -10,7 +10,7 @@ own integrations.
  • Acceptance tests (in JUnit 4, JUnit 5
 of the API is compliant with the contract (server tests). A full test is generated by
 Spring Cloud Contract Verifier.

    • 2.1 History

    Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -from (codearte.io.

    The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

    2.2 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.2.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can +from (Codearte.

    The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

    2.2 Why a Contract Verifier?

    Assume that we have a system consisting of multiple microservices:

    Microservices Architecture

    2.2.1 Testing issues

    If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

    • Deploy all microservices and perform end-to-end tests.
    • Mock other microservices in unit/integration tests.

    Both have their advantages but also a lot of disadvantages.

    Deploy all microservices and perform end to end tests

    Advantages:

    • Simulates production.
    • Tests real communication between services.

    Disadvantages:

    • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
    • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
    • They take a long time to run.
    • The feedback comes very late in the process.
    • They are extremely hard to debug.

    Mock other microservices in unit/integration tests

    Advantages:

    • They provide very fast feedback.
    • They have no infrastructure requirements.

    Disadvantages:

    • The implementor of the service creates stubs that might have nothing to do with @@ -647,7 +647,7 @@ different ranges of values. To enable ranges of values, you can set regular expr matching those values for the consumer side. You can provide the body by means of either a map notation or String with interpolations. Consult the Chapter 8, Contract DSL section for more information. We highly recommend using the map notation!

      [Tip]Tip

      You must understand the map notation in order to set up contracts. Please read the -Groovy docs regarding JSON.

      The previously shown contract is an agreement between two sides that:

      • if an HTTP request is sent with all of

        • a PUT method on the /fraudcheck endpoint,
        • a JSON body with a client.id that matches the regular expression [0-9]{10} and +Groovy docs regarding JSON.

    The previously shown contract is an agreement between two sides that:

    Once you are ready to check the API in practice in the integration tests, you need to install the stubs locally.

    Add the Spring Cloud Contract Verifier plugin.

    We can add either a Maven or a Gradle plugin. In this example, you see how to add Maven. @@ -742,7 +742,7 @@ make the name of the base test class. In our case, the contracts were placed und src/test/resources/contracts/fraud. Since you do not have two packages starting from the contracts folder, pick only one, which should be fraud. Add the Base suffix and capitalize fraud. That gives you the FraudBase test class name.

    All the generated tests extend that class. Over there, you can set up your Spring Context -or whatever is necessary. In this case, use Rest Assured MVC to +or whatever is necessary. In this case, use Rest Assured MVC to start the server side FraudDetectionController.

    /*
  * Copyright 2013-2019 the original author or authors.
  *
@@ -839,5 +839,5 @@ achieving the same thing by changing the properties.
      repositoryRoot: https://repo.spring.io/libs-snapshot
    That’s it!
    2.6 Dependencies
    The best way to add dependencies is to use the proper starter dependency.
    For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add
 spring-cloud-starter-contract-verifier.
    2.7 Additional Links
    Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note
 that some may be outdated, because the Spring Cloud Contract Verifier project is under
-constant development.
    2.7.1 Spring Cloud Contract video
    You can check out the video from the Warsaw JUG about Spring Cloud Contract:
    2.7.2 Readings
    2.8 Samples
    You can find some samples at
+constant development.
    2.7.1 Spring Cloud Contract video
    You can check out the video from the Warsaw JUG about Spring Cloud Contract:
    2.7.2 Readings
    2.8 Samples
    You can find some samples at
 samples.
    Prev   Next
    1. Spring Cloud Contract Home 3. Spring Cloud Contract FAQ
    
\ No newline at end of file
diff --git a/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html b/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html
index fe31a18910..1afb2e5d91 100644
--- a/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html
+++ b/2.1.x/multi/multi__spring_cloud_contract_verifier_setup.html
@@ -613,7 +613,7 @@ requires including an order number followed by an underscore. This will work reg
     2_showCart.groovy
     3_logout.groovy

    Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a name of scenario1 and the three following steps:

    1. login marked as Started pointing to…​
    2. showCart marked as Step1 pointing to…​
    3. logout marked as Step2 which will close the scenario.

    More details about WireMock scenarios can be found at -http://wiremock.org/docs/stateful-behaviour/

    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

    4.5 Docker Project

    We’re publishing a springcloud/spring-cloud-contract Docker image +https://wiremock.org/docs/stateful-behaviour/

    Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

    4.5 Docker Project

    We’re publishing a springcloud/spring-cloud-contract Docker image that contains a project that will generate tests and execute them in EXPLICIT mode against a running application.

    [Tip]Tip

    The EXPLICIT mode means that the tests generated from contracts will send real requests and not the mocked ones.

    4.5.1 Short intro to Maven, JARs and Binary storage

    Since the Docker image can be used by non JVM projects, it’s good to @@ -647,7 +647,7 @@ or Nexus/spring-cloud-contract/build folder (it’s useful for debugging purposes).

    It’s enough for you to mount your contracts, pass the environment variables - and the image will:

    • generate the contract tests
    • execute the tests against the provided URL
    • generate the WireMock stubs
    • (optional - turned on by default) publish the stubs to a Artifact Manager

    Environment Variables

    The Docker image requires some environment variables to point to + and the image will:

    • generate the contract tests
    • execute the tests against the provided URL
    • generate the WireMock stubs
    • (optional - turned on by default) publish the stubs to a Artifact Manager

    Environment Variables

    The Docker image requires some environment variables to point to your running application, to the Artifact manager instance etc.

    • PROJECT_GROUP - your project’s group id. Defaults to com.example
    • PROJECT_VERSION - your project’s version. Defaults to 0.0.1-SNAPSHOT
    • PROJECT_NAME - artifact id. Defaults to example
    • REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to http://localhost:8081/artifactory/libs-release-local which is the default URL of Artifactory running locally
    • REPO_WITH_BINARIES_USERNAME - (optional) username when the Artifact Manager is secured
    • REPO_WITH_BINARIES_PASSWORD - (optional) password when the Artifact Manager is secured
    • PUBLISH_ARTIFACTS - if set to true then will publish artifact to binary storage. Defaults to true.

    These environment variables are used when contracts lay in an external repository. To enable this feature you must set the EXTERNAL_CONTRACTS_ARTIFACT_ID environment variable.

    • EXTERNAL_CONTRACTS_GROUP_ID - group id of the project with contracts. Defaults to com.example
    • EXTERNAL_CONTRACTS_ARTIFACT_ID- artifact id of the project with contracts.
    • EXTERNAL_CONTRACTS_CLASSIFIER- classifier of the project with contracts. Empty by default
    • EXTERNAL_CONTRACTS_VERSION - version of the project with contracts. Defaults to +, equivalent to picking the latest
    • EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to value of REPO_WITH_BINARIES_URL env var. diff --git a/2.1.x/multi/multi__spring_cloud_contract_wiremock.html b/2.1.x/multi/multi__spring_cloud_contract_wiremock.html index 2c0a108feb..8ba9456064 100644 --- a/2.1.x/multi/multi__spring_cloud_contract_wiremock.html +++ b/2.1.x/multi/multi__spring_cloud_contract_wiremock.html @@ -1,6 +1,6 @@ - 11. Spring Cloud Contract WireMock
      11. Spring Cloud Contract WireMock
      Prev   Next

      11. Spring Cloud Contract WireMock

      The Spring Cloud Contract WireMock modules let you use WireMock in a + 11. Spring Cloud Contract WireMock

      11. Spring Cloud Contract WireMock
      Prev   Next

      11. Spring Cloud Contract WireMock

      The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details.

      If you have a Spring Boot application that uses Tomcat as an embedded server (which is @@ -157,7 +157,7 @@ visit WireMock website.

      Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as +WireMock website.

      Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native Wiremock dependencies and exclude the Spring Boot container (if there is one).

      11.6 Customization of WireMock configuration

      You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type diff --git a/2.1.x/multi/multi_contract-dsl.html b/2.1.x/multi/multi_contract-dsl.html index fc66f2c2a0..d18b98950c 100644 --- a/2.1.x/multi/multi_contract-dsl.html +++ b/2.1.x/multi/multi_contract-dsl.html @@ -859,7 +859,7 @@ optional parameters only for the following:

        'abc@abc.com')), - callback_url: $(consumer(regex(hostname())), producer('http://partners.com')) + callback_url: $(consumer(regex(hostname())), producer('https://partners.com')) ) } response { @@ -876,7 +876,7 @@ expression that must be present 0 or more times.

        If you use Spock for, the given: def request = given() .header("Content-Type", "application/json") - .body('''{"email":"abc@abc.com","callback_url":"http://partners.com"}''') + .body('''{"email":"abc@abc.com","callback_url":"https://partners.com"}''') when: def response = given().spec(request) diff --git a/2.1.x/multi/multi_stub-runner-for-messaging.html b/2.1.x/multi/multi_stub-runner-for-messaging.html index 7f3afc58db..856e677935 100644 --- a/2.1.x/multi/multi_stub-runner-for-messaging.html +++ b/2.1.x/multi/multi_stub-runner-for-messaging.html @@ -171,9 +171,9 @@ classpath. Remember to annotate your test class with @Auto xmlns:beans="http://www.springframework.org/schema/beans" xmlns="http://www.springframework.org/schema/integration" xsi:schemaLocation="http://www.springframework.org/schema/beans - http://www.springframework.org/schema/beans/spring-beans.xsd + https://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/integration - http://www.springframework.org/schema/integration/spring-integration.xsd"> + https://www.springframework.org/schema/integration/spring-integration.xsd"> <!-- REQUIRED FOR TESTING --> diff --git a/2.1.x/single/spring-cloud-contract.html b/2.1.x/single/spring-cloud-contract.html index 899c55c0b5..ff81f2c08b 100644 --- a/2.1.x/single/spring-cloud-contract.html +++ b/2.1.x/single/spring-cloud-contract.html @@ -15,7 +15,7 @@ own integrations.

      • Acceptance tests (in JUnit 4, JUnit 5 of the API is compliant with the contract (server tests). A full test is generated by Spring Cloud Contract Verifier.

      2.1 History

      Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -from (codearte.io.

      The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

      2.2 Why a Contract Verifier?

      Assume that we have a system consisting of multiple microservices:

      Microservices Architecture

      2.2.1 Testing issues

      If we wanted to test the application in top left corner to determine whether it can +from (Codearte.

      The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.

      2.2 Why a Contract Verifier?

      Assume that we have a system consisting of multiple microservices:

      Microservices Architecture

      2.2.1 Testing issues

      If we wanted to test the application in top left corner to determine whether it can communicate with other services, we could do one of two things:

      • Deploy all microservices and perform end-to-end tests.
      • Mock other microservices in unit/integration tests.

      Both have their advantages but also a lot of disadvantages.

      Deploy all microservices and perform end to end tests

      Advantages:

      • Simulates production.
      • Tests real communication between services.

      Disadvantages:

      • To test one microservice, we have to deploy 6 microservices, a couple of databases, etc.
      • The environment where the tests run is locked for a single suite of tests (nobody else would be able to run the tests in the meantime).
      • They take a long time to run.
      • The feedback comes very late in the process.
      • They are extremely hard to debug.

      Mock other microservices in unit/integration tests

      Advantages:

      • They provide very fast feedback.
      • They have no infrastructure requirements.

      Disadvantages:

      • The implementor of the service creates stubs that might have nothing to do with @@ -652,7 +652,7 @@ different ranges of values. To enable ranges of values, you can set regular expr matching those values for the consumer side. You can provide the body by means of either a map notation or String with interpolations. Consult the Chapter 8, Contract DSL section for more information. We highly recommend using the map notation!

        [Tip]Tip

        You must understand the map notation in order to set up contracts. Please read the -Groovy docs regarding JSON.

        The previously shown contract is an agreement between two sides that:

        • if an HTTP request is sent with all of

          • a PUT method on the /fraudcheck endpoint,
          • a JSON body with a client.id that matches the regular expression [0-9]{10} and +Groovy docs regarding JSON.

          The previously shown contract is an agreement between two sides that:

          • if an HTTP request is sent with all of

            • a PUT method on the /fraudcheck endpoint,
            • a JSON body with a client.id that matches the regular expression [0-9]{10} and loanAmount equal to 99999,
            • and a Content-Type header with a value of application/vnd.fraud.v1+json,

          • then an HTTP response is sent to the consumer that

            • has status 200,
            • contains a JSON body with the fraudCheckStatus field containing a value FRAUD and the rejectionReason field having value Amount too high,
            • and a Content-Type header with a value of application/vnd.fraud.v1+json.

          Once you are ready to check the API in practice in the integration tests, you need to install the stubs locally.

          Add the Spring Cloud Contract Verifier plugin.

          We can add either a Maven or a Gradle plugin. In this example, you see how to add Maven. @@ -747,7 +747,7 @@ make the name of the base test class. In our case, the contracts were placed und src/test/resources/contracts/fraud. Since you do not have two packages starting from the contracts folder, pick only one, which should be fraud. Add the Base suffix and capitalize fraud. That gives you the FraudBase test class name.

        All the generated tests extend that class. Over there, you can set up your Spring Context -or whatever is necessary. In this case, use Rest Assured MVC to +or whatever is necessary. In this case, use Rest Assured MVC to start the server side FraudDetectionController.

        /*
  * Copyright 2013-2019 the original author or authors.
  *
@@ -844,7 +844,7 @@ achieving the same thing by changing the properties.
          repositoryRoot: https://repo.spring.io/libs-snapshot
        That’s it!

      2.6 Dependencies

      The best way to add dependencies is to use the proper starter dependency.

      For stub-runner, use spring-cloud-starter-stub-runner. When you use a plugin, add spring-cloud-starter-contract-verifier.

      2.7 Additional Links

      Here are some resources related to Spring Cloud Contract Verifier and Stub Runner. Note that some may be outdated, because the Spring Cloud Contract Verifier project is under -constant development.

      2.7.1 Spring Cloud Contract video

      You can check out the video from the Warsaw JUG about Spring Cloud Contract:

      2.7.2 Readings

      2.8 Samples

      You can find some samples at +constant development.

      2.7.1 Spring Cloud Contract video

      You can check out the video from the Warsaw JUG about Spring Cloud Contract:

      2.7.2 Readings

      2.8 Samples

      You can find some samples at samples.

      3. Spring Cloud Contract FAQ

      3.1 Why use Spring Cloud Contract Verifier and not X ?

      For the time being Spring Cloud Contract is a JVM based tool. So it could be your first pick when you’re already creating software for the JVM. This project has a lot of really interesting features but especially quite a few of them definitely make Spring Cloud Contract Verifier stand out on the "market" of Consumer Driven Contract (CDC) tooling. Out of many the most interesting are:

      • Possibility to do CDC with messaging
      • Clear and easy to use, statically typed DSL
      • Possibility to copy paste your current JSON file to the contract and only edit its elements
      • Automatic generation of tests from the defined Contract
      • Stub Runner functionality - the stubs are automatically downloaded at runtime from Nexus / Artifactory
      • Spring Cloud integration - no discovery service is needed for integration tests
      • Spring Cloud Contract integrates with Pact out of the box and provides easy hooks to extend its functionality
      • Via Docker adds support for any language & framework used

      3.2 I don’t want to write a contract in Groovy!

      No problem. You can write a contract in YAML!

      3.3 What is this value(consumer(), producer()) ?

      One of the biggest challenges related to stubs is their reusability. Only if they can be vastly used, will they serve their purpose. @@ -912,7 +912,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi body: "bar" ]) } -}

      [Important]Important

      Please read the Groovy docs related to JSON to understand how to +}

      [Important]Important

      Please read the Groovy docs related to JSON to understand how to properly structure the request / response bodies.

      3.4 How to do Stubs versioning?

      3.4.1 API Versioning

      Let’s try to answer a question what versioning really means. If you’re referring to the API version then there are different approaches.

      • use Hypermedia, links and do not version your API by any means
      • pass versions through headers / urls

      I will not try to answer a question which approach is better. Whatever suits your needs and allows you to generate business value should be picked.

      Let’s assume that you do version your API. In that case you should provide as many contracts as many versions you support. @@ -2157,7 +2157,7 @@ requires including an order number followed by an underscore. This will work reg 2_showCart.groovy 3_logout.groovy

      Such a tree causes Spring Cloud Contract Verifier to generate WireMock’s scenario with a name of scenario1 and the three following steps:

      1. login marked as Started pointing to…​
      2. showCart marked as Step1 pointing to…​
      3. logout marked as Step2 which will close the scenario.

      More details about WireMock scenarios can be found at -http://wiremock.org/docs/stateful-behaviour/

      Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

      4.5 Docker Project

      We’re publishing a springcloud/spring-cloud-contract Docker image +https://wiremock.org/docs/stateful-behaviour/

      Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.

      4.5 Docker Project

      We’re publishing a springcloud/spring-cloud-contract Docker image that contains a project that will generate tests and execute them in EXPLICIT mode against a running application.

      [Tip]Tip

      The EXPLICIT mode means that the tests generated from contracts will send real requests and not the mocked ones.

      4.5.1 Short intro to Maven, JARs and Binary storage

      Since the Docker image can be used by non JVM projects, it’s good to @@ -2191,7 +2191,7 @@ or Nexus/spring-cloud-contract/build folder (it’s useful for debugging purposes).

      It’s enough for you to mount your contracts, pass the environment variables - and the image will:

      • generate the contract tests
      • execute the tests against the provided URL
      • generate the WireMock stubs
      • (optional - turned on by default) publish the stubs to a Artifact Manager

      Environment Variables

      The Docker image requires some environment variables to point to + and the image will:

      • generate the contract tests
      • execute the tests against the provided URL
      • generate the WireMock stubs
      • (optional - turned on by default) publish the stubs to a Artifact Manager

      Environment Variables

      The Docker image requires some environment variables to point to your running application, to the Artifact manager instance etc.

      • PROJECT_GROUP - your project’s group id. Defaults to com.example
      • PROJECT_VERSION - your project’s version. Defaults to 0.0.1-SNAPSHOT
      • PROJECT_NAME - artifact id. Defaults to example
      • REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to http://localhost:8081/artifactory/libs-release-local which is the default URL of Artifactory running locally
      • REPO_WITH_BINARIES_USERNAME - (optional) username when the Artifact Manager is secured
      • REPO_WITH_BINARIES_PASSWORD - (optional) password when the Artifact Manager is secured
      • PUBLISH_ARTIFACTS - if set to true then will publish artifact to binary storage. Defaults to true.

      These environment variables are used when contracts lay in an external repository. To enable this feature you must set the EXTERNAL_CONTRACTS_ARTIFACT_ID environment variable.

      • EXTERNAL_CONTRACTS_GROUP_ID - group id of the project with contracts. Defaults to com.example
      • EXTERNAL_CONTRACTS_ARTIFACT_ID- artifact id of the project with contracts.
      • EXTERNAL_CONTRACTS_CLASSIFIER- classifier of the project with contracts. Empty by default
      • EXTERNAL_CONTRACTS_VERSION - version of the project with contracts. Defaults to +, equivalent to picking the latest
      • EXTERNAL_CONTRACTS_REPO_WITH_BINARIES_URL - URL of your Artifact Manager. Defaults to value of REPO_WITH_BINARIES_URL env var. @@ -3253,7 +3253,7 @@ the Stub Runner server. It will be available at port 8750< }

        As you can see we want to start a Stub Runner Boot server @EnableStubRunnerServer, enable Eureka client @EnableEurekaClient and we want to have the stub runner feature turned on @AutoConfigureStubRunner.

        Now let’s assume that we want to start this application so that the stubs get automatically registered. We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where - ${SYSTEM_PROPS} would contain the following list of properties

        * -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1)
+ ${SYSTEM_PROPS} would contain the following list of properties
        * -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1)
 * -Dstubrunner.cloud.stubbed.discovery.enabled=false (2)
 * -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org.
 * springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework.
@@ -3528,9 +3528,9 @@ classpath. Remember to annotate your test class with @Auto
 			 xmlns:beans="http://www.springframework.org/schema/beans"
 			 xmlns="http://www.springframework.org/schema/integration"
 			 xsi:schemaLocation="http://www.springframework.org/schema/beans
-			http://www.springframework.org/schema/beans/spring-beans.xsd
+			https://www.springframework.org/schema/beans/spring-beans.xsd
 			http://www.springframework.org/schema/integration
-			http://www.springframework.org/schema/integration/spring-integration.xsd">
+			https://www.springframework.org/schema/integration/spring-integration.xsd">
 
 
 	<!-- REQUIRED FOR TESTING -->
@@ -4573,7 +4573,7 @@ optional parameters only for the following:
          'abc@abc.com')),
-				callback_url: $(consumer(regex(hostname())), producer('http://partners.com'))
+				callback_url: $(consumer(regex(hostname())), producer('https://partners.com'))
 		)
 	}
 	response {
@@ -4590,7 +4590,7 @@ expression that must be present 0 or more times.
          If you use Spock for, the
  given:
   def request = given()
     .header("Content-Type", "application/json")
-    .body('''{"email":"abc@abc.com","callback_url":"http://partners.com"}''')
+    .body('''{"email":"abc@abc.com","callback_url":"https://partners.com"}''')
 
  when:
   def response = given().spec(request)
@@ -6601,7 +6601,7 @@ to fetch the Pact contract definitions from the Pact Broker.
 Whatever is set after pact:// will be parsed as the Pact Broker URL.
          Either via environment variables, system properties, properties set
 inside the plugin or contracts repository configuration you can
 tweak the downloader’s behaviour. Below you can find the list of
-properties
          Table 10.2. SCM Stub Downloader properties
          Name of a property
          Default
          Description
          * pactbroker.host (plugin prop)
          * stubrunner.properties.pactbroker.host (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)
          Host from URL passed to repositoryRoot
          What is the URL of Pact Broker
          * pactbroker.port (plugin prop)
          * stubrunner.properties.pactbroker.port (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_PORT (env prop)
          Port from URL passed to repositoryRoot
          What is the port of Pact Broker
          * pactbroker.protocol (plugin prop)
          * stubrunner.properties.pactbroker.protocol (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL (env prop)
          Protocol from URL passed to repositoryRoot
          What is the protocol of Pact Broker
          * pactbroker.tags (plugin prop)
          * stubrunner.properties.pactbroker.tags (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_TAGS (env prop)
          Version of the stub, or latest if version is +
          What tags should be used to fetch the stub
          * pactbroker.auth.scheme (plugin prop)
          * stubrunner.properties.pactbroker.auth.scheme (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME (env prop)
          Basic
          What kind of authentication should be used to connect to the Pact Broker
          * pactbroker.auth.username (plugin prop)
          * stubrunner.properties.pactbroker.auth.username (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME (env prop)
          The username passed to contractsRepositoryUsername (maven) or contractRepository.username (gradle)
          Username used to connect to the Pact Broker
          * pactbroker.auth.password (plugin prop)
          * stubrunner.properties.pactbroker.auth.password (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop)
          The password passed to contractsRepositoryPassword (maven) or contractRepository.password (gradle)
          Password used to connect to the Pact Broker
          * pactbroker.provider-name-with-group-id (plugin prop)
          * stubrunner.properties.pactbroker.provider-name-with-group-id (system prop)
          * STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID (env prop)
          false
          When true, the provider name will be a combination of groupId:artifactId. If false, just artifactId is used

      11. Spring Cloud Contract WireMock

      The Spring Cloud Contract WireMock modules let you use WireMock in a +properties

      Table 10.2. SCM Stub Downloader properties

      Name of a property

      Default

      Description

      * pactbroker.host (plugin prop)

      * stubrunner.properties.pactbroker.host (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_HOST (env prop)

      Host from URL passed to repositoryRoot

      What is the URL of Pact Broker

      * pactbroker.port (plugin prop)

      * stubrunner.properties.pactbroker.port (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_PORT (env prop)

      Port from URL passed to repositoryRoot

      What is the port of Pact Broker

      * pactbroker.protocol (plugin prop)

      * stubrunner.properties.pactbroker.protocol (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_PROTOCOL (env prop)

      Protocol from URL passed to repositoryRoot

      What is the protocol of Pact Broker

      * pactbroker.tags (plugin prop)

      * stubrunner.properties.pactbroker.tags (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_TAGS (env prop)

      Version of the stub, or latest if version is +

      What tags should be used to fetch the stub

      * pactbroker.auth.scheme (plugin prop)

      * stubrunner.properties.pactbroker.auth.scheme (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_SCHEME (env prop)

      Basic

      What kind of authentication should be used to connect to the Pact Broker

      * pactbroker.auth.username (plugin prop)

      * stubrunner.properties.pactbroker.auth.username (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_USERNAME (env prop)

      The username passed to contractsRepositoryUsername (maven) or contractRepository.username (gradle)

      Username used to connect to the Pact Broker

      * pactbroker.auth.password (plugin prop)

      * stubrunner.properties.pactbroker.auth.password (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_AUTH_PASSWORD (env prop)

      The password passed to contractsRepositoryPassword (maven) or contractRepository.password (gradle)

      Password used to connect to the Pact Broker

      * pactbroker.provider-name-with-group-id (plugin prop)

      * stubrunner.properties.pactbroker.provider-name-with-group-id (system prop)

      * STUBRUNNER_PROPERTIES_PACTBROKER_PROVIDER_NAME_WITH_GROUP_ID (env prop)

      false

      When true, the provider name will be a combination of groupId:artifactId. If false, just artifactId is used


      11. Spring Cloud Contract WireMock

      The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details.

      If you have a Spring Boot application that uses Tomcat as an embedded server (which is @@ -6758,7 +6758,7 @@ visit WireMock website.

      Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as +WireMock website.

      Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native Wiremock dependencies and exclude the Spring Boot container (if there is one).

      11.6 Customization of WireMock configuration

      You can register a bean of org.springframework.cloud.contract.wiremock.WireMockConfigurationCustomizer type diff --git a/2.1.x/spring-cloud-contract-maven-plugin/configs.html b/2.1.x/spring-cloud-contract-maven-plugin/configs.html index 83ccb2132c..587126aa9e 100644 --- a/2.1.x/spring-cloud-contract-maven-plugin/configs.html +++ b/2.1.x/spring-cloud-contract-maven-plugin/configs.html @@ -317,7 +317,7 @@ contracts got deployed.

      <configuration> <contractsMode>REMOTE</contractsMode> <contractsRepositoryUrl> - http://link/to/your/nexus/or/artifactory/or/sth + https://link/to/your/nexus/or/artifactory/or/sth </contractsRepositoryUrl> <contractDependency> <groupId>com.example.standalone</groupId> diff --git a/2.1.x/spring-cloud-contract.xml b/2.1.x/spring-cloud-contract.xml index a495d55d33..664fc10de5 100644 --- a/2.1.x/spring-cloud-contract.xml +++ b/2.1.x/spring-cloud-contract.xml @@ -47,7 +47,7 @@ Spring Cloud Contract Verifier. History Before becoming Spring Cloud Contract, this project was called Accurest. It was created by Marcin Grzejszczak and Jakub Kubrynski -from (codearte.io. +from (Codearte. The 0.1.0 release took place on 26 Jan 2015 and it became stable with 1.0.0 release on 29 Feb 2016.
      @@ -1053,7 +1053,7 @@ a map notation or String with interpolations. Consult the section for more information. We highly recommend using the map notation! You must understand the map notation in order to set up contracts. Please read the -Groovy docs regarding JSON. +Groovy docs regarding JSON. The previously shown contract is an agreement between two sides that: @@ -1233,7 +1233,7 @@ the contracts folder, pick only one, which should be fraud. That gives you the FraudBase test class name. All the generated tests extend that class. Over there, you can set up your Spring Context -or whatever is necessary. In this case, use Rest Assured MVC to +or whatever is necessary. In this case, use Rest Assured MVC to start the server side FraudDetectionController. /* * Copyright 2013-2019 the original author or authors. @@ -1378,13 +1378,13 @@ constant development. Slides from Marcin Grzejszczak’s talk about Accurest -Accurest related articles from Marcin Grzejszczak’s blog +Accurest related articles from Marcin Grzejszczak’s blog -Spring Cloud Contract related articles from Marcin Grzejszczak’s blog +Spring Cloud Contract related articles from Marcin Grzejszczak’s blog -Groovy docs regarding JSON +Groovy docs regarding JSON
      @@ -1527,7 +1527,7 @@ for time and UUID are simplified and most likely invalid but we want to keep thi } } -Please read the Groovy docs related to JSON to understand how to +Please read the Groovy docs related to JSON to understand how to properly structure the request / response bodies. @@ -3648,7 +3648,7 @@ name of scenario1 and the three following steps: More details about WireMock scenarios can be found at -http://wiremock.org/docs/stateful-behaviour/ +https://wiremock.org/docs/stateful-behaviour/ Spring Cloud Contract Verifier also generates tests with a guaranteed order of execution.
      @@ -3728,7 +3728,7 @@ purposes). execute the tests against the provided URL -generate the WireMock stubs +generate the WireMock stubs (optional - turned on by default) publish the stubs to a Artifact Manager @@ -5401,7 +5401,7 @@ and we want to have the stub runner feature turned on @AutoConfigureStu Now let’s assume that we want to start this application so that the stubs get automatically registered. We can do it by running the app java -jar ${SYSTEM_PROPS} stub-runner-boot-eureka-example.jar where ${SYSTEM_PROPS} would contain the following list of properties -* -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshots (1) +* -Dstubrunner.repositoryRoot=https://repo.spring.io/snapshot (1) * -Dstubrunner.cloud.stubbed.discovery.enabled=false (2) * -Dstubrunner.ids=org.springframework.cloud.contract.verifier.stubs:loanIssuance,org. * springframework.cloud.contract.verifier.stubs:fraudDetectionServer,org.springframework. @@ -5972,9 +5972,9 @@ classpath. Remember to annotate your test class with @AutoConfigureStub xmlns:beans="http://www.springframework.org/schema/beans" xmlns="http://www.springframework.org/schema/integration" xsi:schemaLocation="http://www.springframework.org/schema/beans - http://www.springframework.org/schema/beans/spring-beans.xsd + https://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/integration - http://www.springframework.org/schema/integration/spring-integration.xsd"> + https://www.springframework.org/schema/integration/spring-integration.xsd"> <!-- REQUIRED FOR TESTING --> @@ -7476,7 +7476,7 @@ optional parameters only for the following: } body( email: $(consumer(optional(regex(email()))), producer('abc@abc.com')), - callback_url: $(consumer(regex(hostname())), producer('http://partners.com')) + callback_url: $(consumer(regex(hostname())), producer('https://partners.com')) ) } response { @@ -7496,7 +7496,7 @@ expression that must be present 0 or more times. given: def request = given() .header("Content-Type", "application/json") - .body('''{"email":"abc@abc.com","callback_url":"http://partners.com"}''') + .body('''{"email":"abc@abc.com","callback_url":"https://partners.com"}''') when: def response = given().spec(request) @@ -10344,7 +10344,7 @@ properties Spring Cloud Contract WireMock -The Spring Cloud Contract WireMock modules let you use WireMock in a +The Spring Cloud Contract WireMock modules let you use WireMock in a Spring Boot application. Check out the samples for more details. @@ -10542,7 +10542,7 @@ visit https://example.org/< than one stub pattern can be specified, and each one can be a directory (for a recursive list of all ".json"), a fixed filename (as in the example above), or an Ant-style pattern. The JSON format is the normal WireMock format, which you can read about in the -WireMock website. +WireMock website. Currently, the Spring Cloud Contract Verifier supports Tomcat, Jetty, and Undertow as Spring Boot embedded servers, and Wiremock itself has "native" support for a particular version of Jetty (currently 9.2). To use the native Jetty, you need to add the native