spring-cloud-contract
spring-cloud-contract copied to clipboard
spring-cloud
Analyse stub dependencies in project(s)
Collecting Data
Script classpath convention based
Assuming that all projects define their stubs via a dependency entry in a pom.xml / build.gradle we can retrieve all information related to who is using who.
Dump info from Stub Runner
When a stub is fetched by stub runner (either via classpath or whatever else), then such information can be dumped to a file. That file can later be processed.
Displaying dependencies
Static page
Previous points can serve as an input for a static page sketching a graph of dependencies
- [x] manually create the page and data (done via #615)
- [ ] create a plugin that provides the data?
Send to Pact Broker
We can inverse the way Pact broker is used. From consumer contract to proper consumer-driven contracts with contracts being in ownership by the producer. The producer could use Spring Cloud Contract contracts as input, generate test, then we could convert it to Pact files which we would send to the Pact broker. Then the consumers could fetch the stubs from the Pact broker, dump info about which stubs in which versions got used, and upload those to Pact broker again.
cc @jkubrynski @OlgaMaciaszek @Fitzoh @TYsewyn
Currently the stubs are all present in annotations/config and not the pom/build.gradle, right?
You probably don't strictly need them to be present there, would it make sense for a plugin to add a listener or something and generated the dependency info when tests are run?
You probably don't strictly need them to be present there, would it make sense for a plugin to add a listener or something and generated the dependency info when tests are run?
that would be the Dump info from Stub Runner. When Stub Runner fetches a stub it would dump that as a json somewhere. Stub Runner is the ultimate source of truth.
cool, so it's basically
Script classpath convention based OR Dump info from Stub Runner
and
Static page OR Send to Pact Broker
right?
Why not both for exposing the contracts/stubs? We could have an actuator endpoint that exposes the contracts/stubs based on a at-build-time statically generated file that will be packaged with the jar, AND upload it to a Pact broker during build/compile time? Just thinking out loud here though.
We could, I think I had chat with Andreas that the Boot dashboard harvests those endpoints to retrieve data. We had sth similar in the micro-infra-spring project too. The small problem I see is that contracts are a test resource. We would have to convert them to e.g. YAML and then dump them somewhere for the Spring Boot plugin to package somehow. We'll have to give it another thought I guess.