Hello everyone, everything good? Is there an examp...
# pact-jvmc
Charlan Bettiol
11/07/2023, 1:00 PMHello everyone, everything good? Is there an example of contract versioning anywhere? because I'm having the following problem, there are developers making contracts in different branches and when trying to publish I'm getting the error below, I would like to know how to get around this:
Cannot change the content of the pact for subscription version 1.0 and provider subscription, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. Some Pact libraries generate random data when a concrete value for a type matcher is not specified, and this can cause the contract to mutate - ensure you have given example values for all type matchers. For more information see <https://docs.pact.io/go/versioning>y
Yousaf Nabi (pactflow.io)
11/07/2023, 3:40 PM
See https://docs.pact.io/getting_started/versioning_in_the_pact_broker#best-practices
if you are using a static value for your consumer version (1.0 in your example), and the data is not changing due to random data, it is changing because you are changing the contents on the pact, and thusly must change the version number.
This is normally taken care of, by the Pact broker by utilising commit hashes which uniquely identify a contract to the code that produced that contract. if the published contract content has not changed, and it has already been verified, it will be preverified.
Yousaf Nabi (pactflow.io)
11/07/2023, 3:41 PM
the link in the error message provides additional information as well
> 1. Have the application version number include something that identifies the point in your version control repository that will build this application. For git, it is ideal if you either use the git commit sha (short or long), or include the git commit sha in your version number (for example 0.0.10+76a39e5). This has several advantages:
> ◦ The consumer version will definitely change whenever the pact contract changes (satisfying rule 1 above)
> ◦ Feature branches will automatically have different versions to master branch versions (satisfying rule 2 above)
> ◦ Versions can always be known at deploy time (satisfying rule 3 above)
> ◦ You can also identify and checkout the production version of the provider.
>
c
Charlan Bettiol
11/07/2023, 4:52 PMI understant, Thank you for the explanation.
🙌 1