Skip to main content

Pact Open Source Update — September 2024

· 10 min read

👋🏽 Welcome to the September Pact Blog, where we'll be covering all the updates in the Pact ecosystem along with events & material you've been sharing across the web.

Pact OSS Updates​

Pact RFCs​

We have two RFC's currently awaiting review, why not take a look and add your review in the spirit of collaboration and open-source. The proposers would really appreciate and value your input.

  1. rfc: configuration and shared files proposed by @JP-Ellis
  2. rfc: Define matching rules for form-urlencoded body by @tienvx

Pact-Plugins​

Back in March, we mentioned an issue when leveraging the Pact-Plugin framework with Pact-Go.

I'm pleased to say that the fix in the pact-plugins repo, was accepted and merged, to change the loading mechanism for plugins, from Tokio tasks, to System threads.

Pact-Plugins - Slack​

Chat with us in: #pact-plugins.

Pact-JS​

Pact-JS-CLI is now smaller, and leaner, with os/arch specific npm packages created for all supported platforms, thanks to this PR. The resolution for packages should be invisible to the end user, resulting in smaller downloads, and less disk-space being used by redundant files.

Available from V16.x - See the release notes for more detail

TL;DR
$ npx --package=@pact-foundation/pact-cli -c 'pact-broker version'
1.76.1

Want to see the same change in pact-js-core? Why not let us know!

Pact-JS - Slack​

Chat with us in: #pact-js

Pact-Go​

The pact-plugin update to switch from tokio tasks, to system threads was accepted, which allowed us to add the change to Pact-Go, hopefully fixing random panics during plugin based tests, highlighted in this issue.

Initial feedback is really positive. If you had this issue before, and it now appears to be resolved, why not let us know?

CGO or not to CGO? - In an infamous post by Dave Cheney, he mentions cgo is not go, and the mandatory requirement of cgo, in pact-go v2 has caused some users issues in initial setup. We have the potential to mitigate this requirement, by leveraging a project called ebitengine/purego, which describes itself as a library for calling C functions from Go, without Cgo. You can track the issue and associated pull request, to find out more.

Alpine Linux - We've been trying to get Pact working across alpine, natively, for all of our supported client languages, GoLang included. Follow the progress here. We are blocked at the moment due to some segfaults during the verification process and would appreciate any extra eyes, if this feature enhancement would be useful to you.

Pact-Go - Slack​

Chat with us in: #pact-go.

Pact-Python​

Some examples using the Pact-Python V3 interface, have now been included in the repo, thanks to Amit S in this PR.

Val Kolovos is also working on a Matcher proof of concept here in order to try and complete this open issue to Implement a Matcher interface, it has just been merged, but is awaiting the release of Python 3.14 (which has been delayed by a few days), before it will be released, however you can build the project locally to try out Val's changes today.

Pact-Python - Slack​

Chat to us in: #pact-python.

Pact-PHP​

Tien has began some incremental improvements in Pact-PHP V10, now that that v10 is now GA.

Two notable additions include

These changes are currently on the master branch and unreleased, so will require to use the dev-master version if you want to pick them up.

Pact-PHP - Slack​

Chat to us in: #pact-php.

Pact Ruby​

@trammel submitted a PR to remove webrick from a dependency to a dev-dep over in pact-ruby, however it will need pact_mock-service to be updated to use an alternative over webrick, and to be able to drop it as a runtime dependency completely. If anyone fancies attempting this, please let us know.

Webrick suffered a round of CVE's recently, so the Pact ruby ecosystem has been updated (pact-ruby-cli, pact-ruby-standalone, pact-broker).

Sbmt-Pact - Pact V3/V4 & Plugin Support​

The Kuper development team recently announced an open-source ruby gem, called sbmt-pact, which builds on the pact-ffi ruby wrapper gem I created.

Yuri, a Senior developer at Cooper, has created a comprehensive blog post (note: written in Russian, so you may need to use your favourite translator) which covers lots of points

  1. general principle of operation of contract tests;
  2. about the problems we encountered when implementing contract testing and how we solved them;
  3. how we developed our solution for contract testing of Ruby applications;
  4. about setting up CI/CD to automate contract tests.

I would wholly recommend reading the article especially as it also explains why sbmt-pact came to be

  1. the official ruby ​​gem only supported V1/V2 specifications, which only allow testing of http interactions;
  2. the grpc/kafka interactions we need are supported in the V3/V4 specifications;
  3. a little earlier, in the process of evolution and support of V3/V4 specifications, pact-foundation decided to rework the architecture and switched to shared rust-core , which assumes that test libraries for different stacks use FFI (foreign-function interface) as a single interface for interacting with the core in rust;
  4. the official ruby ​​gem remained in limbo for a long time and was not developed, in parallel pact-ruby-ffi was created , providing a low-level interface to pact-core;
  5. and only recently plans have emerged to develop an official ruby ​​gem and support V3/V4 - see Pact V3 Tracking Issue and Pact V4 Tracking Issue .

I particularly like these two quotes from the summary

Pact turned out to be not just a framework, but an entire ecosystem ready for any challenges of modern microservice architecture. With support for various languages ​​and protocols, it becomes an indispensable ally in the fight for code quality.

and

Ruby developers are especially pleased: even when official support lags behind, the community will always find a way out. Our experience with sbmt-pact is a vivid confirmation of this. This once again proves that there are no unsolvable problems in the open-source world.

I totally agree with you Yuri. 🙌

Why not try out sbmt-pact, and give the authors some feedback?

Pact-Ruby - Slack​

Chat to us in: #pact-ruby.

Pact Broker​

Deprecation notices

The Pact Broker image was updated to leverage Ruby 3.3.5 in v2.122.0.

Pact Broker Chart​

Shane Hull added the ability to set svc annotations, check out his PR here. It was merged and released this month.

Pact-Broker - Slack​

Chat to us in: #pact-broker.

Pact Net​

Pact-Net V5 Beta 3 has now been released. It contains several fixes and features, including leveraging the latest pact ffi 0.4.23

V5 of pact-net is considered to be pretty stable, and is being used in a few production workflows and we expect it to become GA very soon. If you want to leverage the Pact V4 Specification, which will allow you to have multiple interaction types in a single Pact file, you should upgrade now!

Pact-Net - Slack​

Chat to us in: #pact-broker.

Community Events​

Are you talking about Pact or contract-testing this year at an event? Why not let us know and get yourself featured!

Murat K Ozcan - A triple whammy of contract testing posts​

Murat has recently been taking an adventure in the world of Pact, after picking up Marie & Lewis' Contract testing in Action book. He has written 3 posts which are well worth a read.

Pact & AI​

Generative AI, has become a dining room table topic and you may be wondering how it may impact the world of contract testing.

Both Matt and I take you through a 3-part journey, where we explore the importance of contract testing, the potential of Generative AI, and how PactFlow have turned a concept into reality, harnessing the power of GenAI, Pact best practice, and up to date knowledge of our consumer DSL's in order to allow you to unlock the value potential of contract testing sooner.

Pact & AsyncAPI​

The PactFlow team support a tool, called swagger-mock-validator, which allows you to compare a Pact file containing HTTP interactions, against an OpenAPI document. Originally created by Atlassian, it opened up broader use-cases than the traditional consumer driven approach with Pact, of replaying the interactions against a running provider, however does not offer as strong a guarantee, as it is reliant on the actual implemented provider, not drifting from the api description that is presented to consumers.

Whilst provider drift, is something that the industry has not fully addressed, (the ability to ensure a provider implementation completely honours its API description), the demand for static comparison tools to compare Pact files, is still there.

There is potential to couple both approaches, using API design documents as central points of truth. Using Pacts powerful DSL to generate consumer contracts. Using static comparison tools to ensure they honour the API description. If they differ, a proposal must be made in the documentation to reflect this. Pact plays a role in the verification of the provider, by replaying the Pact interactions, it mitigates provider drift from the consumer contract perspective, which with a static comparison tool, has been proven to adhere to the API description, eliminating provider drift for the known consumed endpoints in use.

Maybe in the future, we will see Pact being API description aware, in order to verify the implementation adheres to the API description.

However in the interim, one of the most requested comparison features, was Pact vs AsyncAPI.

AsyncAPI, for those who are unaware, is an API description format that covers event-driven systems, which consume or send messages, with a particular content format. The messages themselves may be transmitted over any number of different protocols, described as bindings in the AsyncAPI.

Message Pact, allows for the contract testing of service messages, without being interested in how the messages themselves are transmitted.

A recent introduction to the Pact ecosystem, exposed a plugin mechanism, which allows users to create their own custom content-type matcher & transport capabilities, which allows Pact users to consider content-types and transport capabilities not currently available in Pact, but leveraged in AsyncAPI based descriptions.

In order to try and progress momentum in providing a way to users to leverage AsyncAPI in their Pact journeys, I have created pact-asyncapi-comparator.

npx pact-asyncapi-comparator <Pact File Location> <AsyncAPI File Location>

It will allow for the comparison of application/json message content, in a V3 or V4 specification Pact file, against a valid AsyncAPI 2.x/3.x document.

I'd love for message pact users, to give it a go, and if it doesn't cover your use case, let me know in the issues section.

Thats a wrap​

Want to carry on the conversation? Sign up here to join our Slack community, where you will be amongst over 5.8K other users. It's a safe place to ask questions, and a great place to share the awesome work you are doing in the Pact ecosystem.

Whatever you are up to, let us know, and we can look to get you featured in the Pact post.

See you next month folks!

Cheers, Saf