Allow version number validation to be completely disabled

[bethesque]

Since we recommend using git SHAs instead of semantic versions now, and versions are ordered by date, there is no reason to validate the contents of a version number at all any more, apart from the fact that it must not be empty and should not contain any new lines.

Backwards compatibility should be maintained for existing users.

[kyrielia]

This would be super useful for Pact adoption at the company that I work at. Our dev environment uses Git SHAs of our microservices as the versions, and then we use Git Tags with GitOps to manage our deployments to staging/preprod/prod. We don't really use semantic versioning at all.

As Git tags have a 1 to 1 relationship with SHAs, this would allow us to match up what's in all of our environments with the SHAs in the broker.

Currently it still seems the broker uses the semver Gem, and there are no in-built alternatives.

[bethesque]

You can do it already - people have been publishing versions with git shas for years. It's what's recommended by the docs now. You just need to have config.order_versions_by_date = true (see docs) (which is the default for the docker image). It seems the version number validation will accept anything as long as it has a number in it, and the chances of a git sha not having a number in it are so infinitesimally small that it has never happened. The only reason it's been raised as an issue at all is that someone was doing some testing with some hardcoded words that didn't have any numbers at all, and this caused the validation (that I thought was turned off) to fail.

[bethesque]

PS. Perhaps you are on a very old version of the Pact Broker? We're up to 2.50.1 now.

[kyrielia]

Thanks @bethesque for clarifying! I checked with our dev ops team on our version - we're on a very, very old version...

[bethesque]

Do upgrade! There are many performance improvements, functionality improvements, and also there was a vulnerability in the earlier webhooks implementations that you should upgrade to fix. There have been no backwards-incompatible changes introduced, so it should just be matter of installing the new version code, and everything should auto-update.

There is an outstanding issue in the ordering when updating from really old versions that I'm trying to get someone to help me reproduce. For some people, it doesn't seem to switch over automatically (and it should). You can find details here: #330

[garry-jeromson]

and the chances of a git sha not having a number in it are so infinitesimally small that it has never happened.

Perhaps it's worth stressing in the docs that the full Git hash should be used, as opposed to the short hash - a short hash with no numbers happens regularly. For example, today 😁:

pact_verifier_1_4d6f89e5e214 | Pact::Provider::VerificationResults::PublicationError: Error returned from verification results publication 400 {"errors"=>{"provider_version"=>["Version number 'feadaab' cannot be parsed to a version number. The expected format (unless this configuration has been overridden) is a semantic version. eg. 1.3.0 or 2.0.4.rc1"]}}

[mefellows]

You guys are just... hitting all of the errors today. You don't happen to be testers do you?

[garry-jeromson]

Nope, just devs in need of a beer. 😄

[bethesque]

Wow - during the discussion we had before this ticket was raised, someone calculated that it would take a millionty publications to create a sha with no numbers. Guess you were the milliontyth.

I'll see if I can get on to this.