scala-pact
scala-pact copied to clipboard
ITV
Update documentation
It seems like the documentation at http://io.itv.com/scala-pact/ is pretty out of date in terms of the latest published versions of this project. At the very least, misleading information should be cleaned up or removed.
In particular I'm wondering about this snippet on http://io.itv.com/scala-pact/basics/sbt-commands.html:
By default, Scala-Pact does not allow you to publish pact files from SNAPSHOT versions of your project (but takes into account the pactContractVersion if set). This is because it can confuse pact brokers understanding of the latest contract.
Is this still accurate and will it cause problems even when tagging the consumer/provider with the branch when building off of CI? I ask because during CI we don't actually know what the next version of our application might be, it gets determined when the code is merged by providing a hint in the merge commit message (like "bump patch" or "bump minor"). So in our CI the best we can do is either set the contract version to a SNAPSHOT of what we think the next version would be (for example, if the current version is 1.0.0 we may do 1.0.1-SNAPSHOT+commit_sha), or we can just ignore the version entirely and do something like SNAPSHOT+commit_sha or even just commit_sha). Because I don't understand the details of this advice I'm not sure which of these options is best or which may cause problems.
Hi! Yes, the docs do need updating. As to your particular concern, scala-pact does default to not allowing publishing versions with SNAPSHOT in them. I am not sure whether this still messes with the versioning in the broker though.
The default behaviour can be turned off with the sbt setting allowSnapshotPublish := true
Looking at the pact-broker docs I think the logic around snapshot versions in scala-pact is no longer applicable https://docs.pact.io/getting_started/versioning_in_the_pact_broker. Pacts in the broker are organised by creation date, not by using the pacticipant version - which I assume used to be the case.
@jbwheatley great, that makes sense to me as well. Thanks for clarifying.