I'm working with a client on their contract testing implementation, and we're currently doing CDCT with Pact. I could use some views on how and where to make the consumer and provider test steps part of the respective pipelines. Services deploy to a DEV environment multiple times a day through a PR build process. At some point, a release candidate is put together for deployment into a QA environment. Not every PR leads to a new artefact version, hell, most of them don't (i.e., the version in the pom.xml), and I'm not even entirely sure that every RC does (but I'm checking that at the moment). I would love to see both consumer contract generation and publishing tests, as well as provider verification tests, run as often as possible, i.e., on every PR build, no matter what the change is. The earlier we can catch integration issues, the better.. However, I'm not sure if it is possible to publish changes to a contract without an artefact version bump? If that's not possible, I think we need to start having a serious talk with the various dev teams to get their versioning in order.. I'd love to hear some experiences from others about the frequency with which they run their contract tests, what that brought them and what things they had to keep in mind. How much do you really shift to the left with your contract tests?

This versioning problem is actually exactly the use case that I wrote absolute-version to solve - it allows you to get between-release version numbers that are both human readable and correct. (some teams just use the git sha, but I found that less nice because they're not really human readable)

However, I’m not sure if it is possible to publish changes to a contract without an artefact version bump? If that’s not possible, I think we need to start having a serious talk with the various dev teams to get their versioning in order..

😆

Thanks @Matt (pactflow.io / pact-js / pact-go) and @Timothy Jones, really appreciate your input. Running the tests (both consumer and provider parts) locally isn't the issue, we're doing that already (yay for Spring and mocking external dependencies). The versioning is the biggest challenge here. I'll bring that input back to the teams. Thanks again!

Ah perfect! then you've already solved the hard technical problems, this should be the easy bit (famous last words)

Yeah, because convincing others to change their ways of working has always been the easy part of consulting 😉 I'll keep you posted.

My original plan was to have absolute-version available natively for the JVM too - so if you would find it useful, but don't want a node tool, let me know what the needs are and I'm happy to build it (it's not a substantial amount of work)

Thanks @Timothy Jones for the offer, I really appreciate it. You're right in that I prefer not to introduce a NodeJS tool (or rather, the runtime itself), but I'm going to try and let them use commit hashes first to make them feel the pain of that, hopefully that'll lead to them doing better on their versioning 🙂

The version number isn’t in the contract file, so it’s not considered for the hash

Ah I think I got it...

<projectVersion>${project.version}-${git.shorthash}</projectVersion>

That… looks like maven, yes 😅

From https://docs.pact.io/implementation_guides/jvm/provider/maven#1-add-the-pact-jvm-provider-maven-plugin-to-your-build-section-of-your-pom-file

Welcome!

Now to test if it actually works but for that I need to wait until the ops people provide me with a working broker 🙂

The contract hash in the broker is a straight up hash of the contract file. The broker is actually pact agnostic- you could use it for any other file

Oh that's nice to know!

I can recommend pactflow for that in good conscience, because I don’t work for them. But my experience is that it is definitely easier than maintaining your own.

I'd be 100% in favour of Pactflow, too, I recommended my client using that but for reasons we're going the OSS route for now

I have no idea sorry Bas, but I reckon @uglyog might. Ron, any ideas? That being said, I like to encourage use of the Pact CLI if you can: https://docs.pact.io/implementation_guides/cli#pact-broker-cli Maven is….not fun

Just reading the comments. I think either Maven doesn't replace the expression if the system property is not defined, or it does not support expressions in that form. The best thing to do would be pass it on the command line (i.e. add

-Dpact.projectVersion=...

)

Ah! That makes sense! Thanks Ron. So basically, define outside of maven however you wish (Bash, Powershell, scripts) and pass as a system property. Does Maven support environment variables in the same places as system props?

Does Maven support environment variables in the same places as system props?

Please refer any Maven questions to the Maven people

https://github.com/git-commit-id/git-commit-id-maven-plugin <-- you can use this to get

git describe

output, which is very similar to what absolute-version does (the main difference is that absolute-version is semver compatible)

Cheers folks! I thought it maybe was a feature I didn't know of. Looks like I'll have to take a closer look at that plugin (or see how to pass it through the CLI). I'd like to stick to Maven (yes, I said that) because so much is managed through Maven in this org I'm working with, probably easier to educate people that way.

I'd like to stick to Maven (yes, I said that)

You don't have to explain yourself to us 😉

Cheers folks! I thought it maybe was a feature I didn’t know of. Looks like I’ll have to take a closer look at that plugin (or see how to pass it through the CLI). I’d like to stick to Maven (yes, I said that) because so much is managed through Maven in this org I’m working with, probably easier to educate people that way.

No judgement 😬