Enhancement: enable API compatibility on consumer side #686
Labels
Comments
|
@arnaud-deprez Thanks for submitting this issue. With |
|
Hi @OlgaMaciaszek, thanks for your reply. @AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.LOCAL, ids = "com.powple.poc:beer-api-producer:${stubs.beer-api-producer.version +}:stubs")
@AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.LOCAL, ids = "com.powple.poc:beer-api-producer:#{stubs.beer-api-producer.version}:stubs")For each, I got : So it does not resolve the system property. @AutoConfigureStubRunner(stubsMode = StubRunnerProperties.StubsMode.LOCAL, ids = "com.powple.poc:beer-api-producer:#{systemProperty['stubs.beer-api-producer.version'] ?: '+'}:stubs")And there I got If you have another way, I can try. |
|
Is this still a problem? |
|
I think it's still a nice to have unless it has already been resolved. The idea behind is to validate that a new api consumer use a valid contract with the existing provider. One concrete use case I see is when a consumer is using a new API on which the producer has agreed at some point (so latest contract tests pass) but has still not implemented it (in production for example). |
|
@arnaud-deprez could you verify if the problem also exists in Greenwich + 2.1.x? |
|
I'm on vacations. Will be back on Tue 20. |
|
Hi, As you requested, I've tested with latest version and it still does not work. So this is working with junit rule where I can specify the stub version to use via system property or environment variable like this: https://github.com/arnaud-deprez/spring-cloud-contract-howto/blob/feature/consumer-check/beer-api-consumer/src/test/java/com/powple/poc/BeerControllerWithJUnitTest.java#L40-L43 However this does not work: https://github.com/arnaud-deprez/spring-cloud-contract-howto/blob/feature/consumer-check/beer-api-consumer/src/test/java/com/powple/poc/BeerControllerYamlTest.java#L34 It could be solved if JUnit rule or extension (Junit 5) works with contract messaging as well but it's not (as per doc and I also double check it). That's why I think it's better if the |
|
I agree. I think i started some work on this but then i had to migrate to sth else. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi,
Currently
spring-cloud-contractsupports this test matrix:Not Ok(ensure consumer is backwards compatible)Consumer Prod against Producer Head:
It is easily achievable by configuring the
Spring Cloud Contract Verifierviaspring-cloud-contract-maven-pluginorspring-cloud-contract-gradle-pluginlike in apiCompatibility profile in maven or in apiCompatibility gradle task.The idea of this task is to re-run the
Spring Cloud Contract Verifiertests but with contracts from production so we can check if the consumers running in production will be compatible with the new provider.Producer Prod against Consumer Head:
It is not easy to customise or override the behaviour of
@AutoConfigureStubRunnerto retrieve stubs from other version so we can test the consumer backward compatibility before deploying the new consumer to the target environment.So the intent of this scenario is not to test the consumer backward compatibility at build time but before deployment to prevent the consumer to use unsupported service interactions.
It should be possible to do such operation by playing with the combination of
StubRunnerRuleJUnit rule and somemavenorgradleconfiguration, but then it is linked to the JUnit way. I don't know yet how to do it inSpockfor instance.Moreover, the JUnit rule does not play well with
@SpringBootTestinitializing phase so the@AutoConfigureMessageVerifierdoes not work here and you have to define your ownMessageVerifier.I was thinking about using a
mavenandgradleplugin for such use case so it is also easier to manage it from a CI/CD pipeline.Although, I'm not sure how to do it as I have to learn the design of
spring-cloud-contract. I'm just sharing a desired feature :)WDYT ?
The text was updated successfully, but these errors were encountered: