Why does Spring Cloud Contract stub runner have local and remote attributes?

1
votes

The Spring Cloud Contract docs say "Use the REMOTE stubsMode when downloading stubs from an online repository and LOCAL for Offline work".

Why does Spring Cloud Contract stub runner need local and remote attributes?

I would expect instead that it should respect the normal Maven lifecycle... If I do a mvn clean install on the contract module it should publish locally. If I do a mvn clean deploy there, it should publish to my remote. Same for the test verifier... If there is a copy of the binaries in my local repo use that. Otherwise pull it from remote

So I am not getting why we have to include local and remote in the stub runner.

This also seems dangerous because you might accidentally check in code with local when you meant to change it to remote on the build server

1
spring-cloud-contract

1 Answers

1
votes

Why does Spring Cloud Contract stub runner need local and remote attributes?

We've described it in the docs that you quote. When you work offline, then you want to automatically pick the stubs from your local .m2. Otherwise you want to pick it from a different location.

I would expect instead that it should respect the normal Maven lifecycle... If I do a mvn clean install on the contract module it should publish locally. If I do a mvn clean deploy there, it should publish to my remote. Same for the test verifier... If there is a copy of the binaries in my local repo use that. Otherwise pull it from remote

You're mixing stub runner with verifier. When you're on the producer side, you're using the Spring Cloud Contract verifier and it follows the maven lifecycle fully. That's because we produce a stub jar and we attach it to the standard maven flow. With Stub Runner, it's completely unrelated to your maven flow.

This also seems dangerous because you might accidentally check in code with local when you meant to change it to remote on the build server

If you check in code with local then indeed you can have a false positive. That's why you should take care of what you're doing. When you're on the consumer side and doing ./mvnw clean install/deploy then Stub Runner just follows your test setup. If in the test setup you've messed up your configuration then Stub Runner can't do much about it.