Aim

• Identify all Ruby codebases which need updating to Ruby 3.1 or higher
• Identify all consumers of ruby codebases
• Document "Rube Goldberg" machine for
  • Pact Ruby Reference Core as referenced here in the dependency graph of doom
  • Pact Rust Reference Core
• Update to at least, Ruby 3.1, preferably Ruby 3.2 across all affected repos
• Update all affected repos
• Test all affected repos

Why?

• Users of our pact-ruby-standalone project, have been stuck on a packaged Ruby 2.4 run-time due to the build system traveling-ruby, being out-of-maintainence. It has been revived by your very own Devo Avo, into the 21st century with
  • Update to Ruby 3.1.2 & 3.2.2
  • Support for Arm64 Darwin
  • Support for Aarch64 Linux
  • Support for x86 and x64 windows

What happened?

• pact-ruby-standlaone 2.0.0 was released
• Issues identified by users / maintainers
  • Requirement to install libyaml-dev for debian based users
• Error when writing pact files for pact-go-v1 where users are asked to pin the version of the standalone, but provided a script which returns the latest.

Root cause?

• An error in pact_mock-service was reproducible in CI, when using Ruby 3.2.2
  • Downgrading to Ruby 3.1.2 resolved the issue.

What are we doing about it?

• Set pact-ruby-standalone 2.0.0 release to pre-release rather than latest to avoid breaking existing users scripts
• Updated pact-ruby-standalone install.sh script to allow users to fix to particular tag when downloading, over its previous behaviour of using latest
• Updating all ruby gems to be tested from 2.7 through to 3.2 in CI across
  • macOS / windows / linux
    • x86_64 versions
  • macOS / linux
    • arm64 versions
• Identifying the root cause of the error above, stopping us moving to 3.2 and looking to help resolve
• Releasing pact-ruby-standalone with ruby 3.1.2
• Releasing homebrew-pact-ruby-standalone with versioned revisions so you can switch between or pin in your CI

But aren't we moving to the rust core?

Yes! But we understand not all languages are there right now, and we don't have 100% feature parity in the pact-ruby-standalone package compared to the Rust reference core. There is actually very little, with potentially the only limitation being the pact_broker-client functionality.

Happy to be shown otherwise! If anyone is interested in build out CLI tools in Rust, we have some examples you can follow, if anyone wanted to make a Rust based implementation of the pact_broker-client. Whilst we know it has value, the core maintainers are busy delivering other features, and fixes to users, and therefore it isn't something we are likely to pick up soon, but we are always happy to guide.

Related issues

• rapid7/metasploit-framework#17593

Repositories affected and associated PR's

• Pact Broker Client
  • pact-foundation/pact_broker-client#134
• Pact Provider Verifier
  • pact-foundation/pact-provider-verifier#103
• Pact Support
  • pact-foundation/pact-support#98
• Pact Message Ruby
  • pact-foundation/pact-message-ruby#22
• Pact Mock Service
  • pact-foundation/pact-mock_service#141
• Pact Ruby
  • pact-foundation/pact-ruby#292
  • pact-foundation/pact-ruby#293
• Pact Ruby Standalone
  • Pact Ruby Stadalone
    • Ruby 3.1
    • Ruby 3.2 pact-foundation/pact-ruby-standalone#100
  • Homebrew Pact Ruby Standalone
    • pact-foundation/homebrew-pact-ruby-standalone#92
  • Pact-Js-Core
    • 9.x
    • https://github.com/pact-foundation/pact-js-core/tree/pact-node
    • 13.x
      • pact-foundation/pact-js-core#445
  • Pact-Python
    • pact-foundation/pact-python#342
  • Pact-PHP
    • pact-foundation/pact-php#309
  • Pact-Net 3.x
    • https://github.com/pact-foundation/pact-net/tree/release/3.x
  • Pact-Go 1.x
    • https://github.com/pact-foundation/pact-go

Dependency chain releasing instructions

Note Some of these are out of date, or don't have release note pages, so will be captured for snagging

• pact-support gem

  • pact-mock_service gem
    • pact-ruby-standalone
  • pact gem
    • pact-ruby-standalone
    • pact-provider-verifier gem
    • pact-cli-docker

• pact ruby standalone package

  • pact-python
  • pact-net
  • pact-php
  • pact-js-core
    • pact-js
  • pact-go
  • pact-consumer-swift

Ruby Goldberg Machine

graph TD;
    pact-support;
    pact-support-->pact-mock_service;
    pact-support-->pact-message;
    pact-mock_service-->pact-message;
    pact-message-->pact-provider-verifier;
    pact-->pact-provider-verifier;
    pact_broker-client;
    pact-->pact-ruby-standalone;
    pact-mock_service-->pact-ruby-standalone;
    pact-support-->pact-ruby-standalone;
    pact-provider-verifier-->pact-ruby-standalone;
    pact_broker-client-->pact-ruby-standalone;
    pact-message-->pact-ruby-standalone;
    pact-->pact-ruby-cli;
    pact-ruby-standalone-->homebrew-pact-ruby-standalone;
    pact-ruby-standalone-->pact-python;
    pact-ruby-standalone-->pact-php;
    pact-ruby-standalone-->pact-node-->pact-js-v9;
    pact-ruby-standalone-->pact-js-core-->pact-js-v10
    pact-js-v9-->jest-pact;
    pact-js-v9-->mocha-pact;
    pact-js-v9-->nestjs-pact;
    pact-js-v10-->jest-pact;
    pact-js-v10-->nestjs-pact;
    pact-ruby-standalone-->pact-go-v1;
    pact-ruby-standalone-->pact-net;
    pact-ruby-standalone-->pact-consumer-swift;

Ruby Standalone Consumers Goldberg Machine

graph TD;
    pact-->pact-ruby-standalone;
    pact-mock_service-->pact-ruby-standalone;
    pact-support-->pact-ruby-standalone;
    pact-provider-verifier-->pact-ruby-standalone;
    pact_broker-client-->pact-ruby-standalone;
    pact-message-->pact-ruby-standalone;
    pact-ruby-standalone-->homebrew-pact-ruby-standalone;
    pact-ruby-standalone-->pact-python;
    pact-ruby-standalone-->pact-php;
    pact-ruby-standalone-->pact-node-->pact-js-v9;
    pact-ruby-standalone-->pact-js-core-->pact-js-v10
    pact-js-v9-->jest-pact;
    pact-js-v9-->mocha-pact;
    pact-js-v9-->nestjs-pact;
    pact-js-v10-->jest-pact;
    pact-js-v10-->nestjs-pact;
    pact-ruby-standalone-->pact-go-v1;
    pact-ruby-standalone-->pact-net;
    pact-ruby-standalone-->pact-consumer-swift;

Rust Goldberg machine

graph TD;
    pact_cli;
    pact_models-->pact_cli;
    pact_matching-->pact_cli;
    pact_consumer;
    pact_models-->pact_consumer;
    pact_matching-->pact_consumer;
    pact_mock_server-->pact_consumer;
    pact_ffi;
    pact_matching-->pact_ffi;
    pact_models-->pact_ffi;
    pact_mock_server-->pact_ffi;
    pact_verifier-->pact_ffi;
    pact_matching;
    pact_models-->pact_matching;
    pact_mock_server;
    pact_matching-->pact_mock_server;
    pact_models-->pact_mock_server;
    pact_mock_server_cli;
    pact_matching-->pact_mock_server_cli;
    pact_models-->pact_mock_server_cli;
    pact_mock_server-->pact_mock_server_cli;
    pact_models;
    pact_verifier;
    pact_matching-->pact_verifier;
    pact_models-->pact_verifier;
    pact-plugin-driver-->pact_verifier;
    pact_verifier_cli;
    pact_models-->pact_verifier_cli;
    pact_verifier-->pact_verifier_cli;
    pact_wasm;
    pact_models-->pact_wasm;
    pact-plugin-driver;
    pact_models-->pact-plugin-driver;
    pact_ffi-->pact-js-core-->pact-js-v10;
    pact-js-v10-->jest-pact;
    pact_ffi-->pact-net-v4;
    pact_ffi-->pact-go-v2;
    pact_ffi-->pact-swift-->pact-swift-examples;
    pact_ffi-->pact-dart;
    pact_ffi-->pact-cplusplus;
    pact_mock_server-->pact_elixir;

Rust FFI Consumers Goldberg machine

graph TD;
    pact_ffi;
    pact_ffi-->pact-js-core-->pact-js-v10;
    pact-js-v10-->jest-pact;
    pact_ffi-->pact-net-v4;
    pact_ffi-->pact-go-v2;
    pact_ffi-->pact-swift-->pact-swift-examples;
    pact_ffi-->pact-dart;
    pact_ffi-->pact-cplusplus;

Java Goldberg machine

graph TD;
    pact_jvm;
    pact_jvm-->pact4s;

Pact Ruby Standalone Consumers

Versions

Tested using

• traveling ruby release https://github.com/YOU54F/traveling-ruby/releases/tag/rel-20230504
  • with Ruby 3.1.2
• pact-ruby-standalone release https://github.com/YOU54F/pact-ruby-standalone/releases/tag/v2.2.1
  • with Ruby 3.1.4

Test runs

• homebrew-pact-ruby-standalone
  • x86_64
  • arm64
• pact-python
  • x86_64 https://github.com/YOU54F/pact-python/actions/runs/4941346866
  • arm64 https://cirrus-ci.com/build/6108629787475968
• pact-node
  • x86_64 https://github.com/YOU54F/pact-js-core/actions/runs/4941248126
  • arm64 https://cirrus-ci.com/build/5418915182936064
• pact-js-core
  • x86_64 https://github.com/YOU54F/pact-js-core/actions/runs/4941170981
  • arm64 https://cirrus-ci.com/build/5969803895111680
• pact-php
  • x86_64 https://github.com/YOU54F/pact-php/actions/runs/4941467873
  • arm64 https://cirrus-ci.com/build/5862300863692800
• pact-go-v1
  • x86_64 https://github.com/YOU54F/pact-go/actions/runs/4941862361
  • arm64 https://cirrus-ci.com/build/6622000215490560
• pact-net
  • x86_64
  • arm64
• pact-consumer-swift
  • x86_64
  • arm64
• example-consumer-golang
  • https://github.com/pactflow/example-consumer-golang/actions/runs/4941971784

This would make it easier for people to get set up.

https://pact.canny.io/admin/board/feature-requests/p/support-smart-mode-toggle-where-the-verification-task-automatically-switches-bet

Knowing who created an event in an event-driven system introduces a coupling that event driven systems aims to remove in the first place.
It would be ideal for consumers of an event to simply specify during a release, that there must be one or more providers that publish a particular event type.
The can-i-deploy check would then ask a question like this:
"Is there a provider in that produces compatible with schema ?"

https://pact.canny.io/admin/board/feature-requests/p/support-messages-without-knowing-who-the-provider-is

A placeholder for discussions around pact & pactflow example repos

https://pact.canny.io/admin/board/feature-requests/p/add-interactions-count-to-metrics

For PRs, it makes sense to report the status of the pact with the master branch of the provider.
${pactbroker.mainBranchGithubVerificationStatus}

https://pact.canny.io/admin/board/feature-requests/p/add-webhook-template-parameter-for-the-verification-status-between-the-consumer

Entries for https://github.com/realestate-com-au/pact should be moved to https://github.com/pact-foundation/pact-ruby, there are a few entries and it saves users multiple hops

pact-foundation/pact-mock_service#137 (comment)

What video conferencing tools are users comfortable with, for open-source related projects.

Would users prefer to use OSS/FOSS tools, and have a strong preference to lean towards either one.

Which tools would you suggest?

Also what are peoples preferences for video communication

• webinar style
• group style

For personal meetings, I've always just grabbed a google meet, but I can imagine there will be restrictions for larger groups, and there may be concerns on AI, collecting data.

There are other options available to maintainers, through their employers, Zoom for example.

Both google meet/zoom are not OSS, and therefore may not be suitable for some members who simply won't use those platforms.

Just want to gauge interest. Do people care? I've often had to sign up to new platforms to watch a single event and then never used it again.

M1 Runners now available in GitHub Actions

https://github.blog/changelog/2024-01-30-github-actions-introducing-the-new-m1-macos-runner-available-to-open-source/

• Pact-PHP
• Pact-JS-Core
• Pact-Net
• Pact-Go

... add other repos

If a consumer has published a new contract and there are several tags connected to them, it should be possible to trigger a webhook per tag.
We currently do the tag matching via the branch names of consumer / provider and the publication triggers a jenkins build. When there are several tags associated with the consumer, the URL to the jenkins job will currently not match becaus of the comma separated list ${pactbroker.consumerVersionTags}.

It would be great if it was possible to execute the webhook per tag.

https://pact.canny.io/admin/board/feature-requests/p/webhook-trigger-job-per-tag

Pactober Workshop 2 - Pact workshop (Message Pact)

Event Details

Background

Aims

Introduce users to the evolution of Microservices, and event based systems, and how this is handled by Pact.

Provide a workshop which builds on the previous CI/CD example but shows a messaging consumer and provider, to highlight the differences

Agenda

• Introduce users to the concepts of Message Pact introduced in Pact Spec v3
• Discuss some of the limitations of the current approach
  • V3 named diff providers
  • V4 spec introduces async/sync messages
  • V4 spec allows http / message interactions to exist in the same pact
  • Only checks message contents, not transports.
• Run a CI/CD workshop, showing users how to reach Pact Nirvana with Message Pact

Currently the last verified column on the home page of the broker shows when the last verification was run.
It would be great if on the home page you could see the latest verification result for a number of tags of interest, for example master and prod.

https://pact.canny.io/admin/board/feature-requests/p/add-configurable-number-of-last-verified-per-tag-on-the-home-page

Would be good to update existing webhooks in json format instead of via the form as sometimes its easier to copy paste settings via json.

As an aside, the form has a basic auth setting with autocomplete="new-password" parameters set on the input, which will automatically enter my username/password in the form when editing even though i dont have or want one for the webhook. It means every time i need to update the webhook i have to clear the username and password too.

https://pact.canny.io/admin/board/feature-requests/p/importexportedit-webhook-in-json

Pacticipant is a nice pun (and I do love puns), but it's hard to type, easy to misread as participant, and occasionally results in PRs to change it to participant. Also, I think "participant" carries the appropriate meaning.

https://pact.canny.io/admin/board/feature-requests/p/rename-pacticipant-to-participant

4 Voters

Pactober Workshop 1 - Pact workshop (HTTP Pact)

Event Details

Background

Aims

Warmup for the start of Pactober, introducing users to the core concept of contract testing, and Pact.

Provide a workshop where we take users through the recommended Pact setup.

Agenda

• Introduce users to contract testing and pact
• Run the workshop, showing users how to implement contract testing with HTTP Pact using NodeJS as a guide

When Provider verifies a specific commit of pact which automatically applies for similar content of pact , it also notifies for older commits , limit slack notifications for a specific commit using a flag

https://pact.canny.io/admin/board/feature-requests/p/slack-notification-for-a-specific-commit

The following link is dead,

https://github.com/pact-foundation/README/blame/master/README.md#L9

the package is still listed in pypi, last publish July 2017

https://pypi.org/project/pact-broker-client/#history

Re-using existing provider states can allow a new interaction to be successfully verified without having to make a change to the provider code. It is currently not easy to get a list of all the provider states for a particular provider. A new endpoint/CLI command would make it easy to discover and reuse provider states.
pact-foundation/pact_broker#438

https://pact.canny.io/admin/board/feature-requests/p/list-provider-states-for-a-provider

I want to schedule the particular jenkins job on application deployment. Technically it's when the application is tagged with production tag, for now I just add hook on deployment process which is very hard, since I need to modify each deployment. For me, the most convenient approach would be just provide a webhook, when app has been tagged with production tag.

https://pact.canny.io/admin/board/feature-requests/p/webhook-on-pacticipant-tag

Summary

Introduce a process to request for comments (RFC) for changes which will impact Pact as a whole.

Motivation

The Pact Foundation has always wanted to be transparent in the way new features are added to Pact, and while most of the information can be discovered (whether it be from some issue thread, Slack discussion or otherwise), the information may not always be as discoverable as desired.

By formalising a RFC process and storing the discussion in a centralised location, we hope to make the process much more discoverable.

Suggestion

In my experience, the Rust RFC process is excellent, albeit perhaps too rigorous for Pact's needs. I would suggest adopting a similar approach for Pact, with some adjustments made to be more lightweight.

Scopes

The Pact ecosystem is split across a number of languages, and therefore part of the initial discussion will be deciding what should go within the scope of the RFCs.

In order to avoid users who may be affected by rate limiting pulling images from DockerHub, it would be prudent to provide images published to GHCR

Dockerhub profile :- https://hub.docker.com/u/pactfoundation

Images / Repos and Build locations

• https://hub.docker.com/r/pactfoundation/pact-ref-verifier
  • https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_verifier_cli/release-docker.sh
• https://hub.docker.com/r/pactfoundation/pact-ref-mock-server
  • https://github.com/pact-foundation/pact-reference/blob/master/rust/pact_mock_server_cli/release-docker.sh
• https://hub.docker.com/r/pactfoundation/rust-musl-build
  • https://github.com/pact-foundation/pact-reference/blob/master/rust/Dockerfile.musl-build
• https://hub.docker.com/r/pactfoundation/pact-stub-server
  • https://github.com/pact-foundation/pact-stub-server
• https://hub.docker.com/r/pactfoundation/pact-js-musl
  • ?
• https://hub.docker.com/r/pactfoundation/pact-mock-service
  • ?
• https://hub.docker.com/r/pactfoundation/pact-broker
  • https://github.com/pact-foundation/pact-broker-docker/blob/master/script/release-workflow/docker-push.sh
• https://hub.docker.com/r/pactfoundation/pact-cli
  • https://github.com/pact-foundation/pact-ruby-cli/blob/master/script/release-workflow/docker-push.sh

Delta of required changes

https://github.com/pact-foundation/pact-ruby-cli/pull/127/files

Progress

• Pact-Ruby-CLI
• Pact-Broker-Docker
• Pact-Stub-Server

https://pact.canny.io/admin/board/feature-requests/p/allow-can-i-deploy-to-return-true-when-there-is-a-missing-verification-between-a

What types of Pact tooling do we have?

What should they be called?

• Language implementations
• Wrapper implementations https://docs.pact.io/wrapper_implementations
• Other languages https://docs.pact.io/implementation_guides/other_languages
• Test Framework helpers
• BYO Adapters
• Other things?

Pactober Workshop 3 - CI/CD workshop (Plugin Pact)

Event Details

Aims

Introduce the concepts of multi-protocol systems, and how the pact-plugin framework was developed to enable users to extend Pact to cover use cases that may not be applicable to all end users.

Provide a workshop which builds on the previous CI/CD example but shows a gRPC consumer and provider, to highlight the differences

Agenda

• Introduce users to the concepts of the Pact Plugin framework introduced in Pact Spec v4
• Discuss some of the benefits/limitations of the pact-plugin approach
• Run a CI/CD workshop, showing users how to reach Pact Nirvana with Plugin Pacts (probably gRPC area calculator)

It would be cool if pact verification warned if the verifier DSL is given states that are never used by any of the consumer contracts.

https://pact.canny.io/admin/board/feature-requests/p/support-dead-state-detection-in-verifier-dsl

If a pact has "a request for an order" given "an order exists" and, "a request for an order", given "an order does not exist", the first successful response will always be returned, meaning that you can't use the stub server to test error flows. The stub server could provide an endpoint to allow the response to the next request to be pre-selected by the provider state name.

https://pact.canny.io/admin/board/feature-requests/p/allow-the-interaction-for-a-particular-provider-state-to-be-selected-where-multi

Most of the pact developers don't not have or use windows, so their ability to troubleshoot is hampered. If we had an end to end pact net example that could run on a Windows cloud CI, that would help us diagnose issues more easily.

For reference: https://github.com/pact-foundation/pact-ruby-standalone-e2e-example

We would want it to generate a pact, publish it to test.pact.dius.com.au, and run the verification step, publishing results back to the broker.

https://pact.canny.io/admin/board/feature-requests/p/create-pact-net-e2e-example-that-runs-on-appveyor-or-similar-to-help-diagnose-is

Currently, each project must specify both the Pact Broker (or Pactflow) host and any credentials to publish or retrieve pacts.
It would be nice to have a utility (similar to aws configure or travis init) that creates a global config file (e.g. ~/.pact/config) where this data can be stored once and is understood by all of our CLI tools and test frameworks.
This isn't as much of a problem for CI/automation, but it is particularly acute for setting up developers in large scale teams.

https://pact.canny.io/admin/board/feature-requests/p/support-a-global-configuration-file

I know there is a csv support gem in ruby, but I couldn't find any documents in JVM. It would be really appreciated if there is a JVM support for matching csv format.

https://pact.canny.io/admin/board/feature-requests/p/support-textcsv-matching

Let's make pact-stub-server smarter by allow it to refer request data to be a part of response data like attached picture below. Furthermore, it would be really nice if it can refer to value in API path as well. xD

https://pact.canny.io/admin/board/feature-requests/p/allow-pact-stub-server-to-respond-data-that-depends-on-request

If a consumer and provider use matching feature branches to add new features, the webhook could be configured to trigger the matching branch of the provider build, if there was a matching branch known about in the broker. This would mean there wouldn't have to be an intermediate build in the CI to trigger the build with the right branch.

"request": {
    "body": {
      "branch": "${pactbroker.matchingFeatureBranchOrMainDevelopmentBranch}",
      "commit": "HEAD",
      "message": "Build all the things! :rocket:",
      "env": {
        "PACT_URL": "${pactbroker.pactUrl}"
      }
    },
    "method": "POST",
    "url": "https://api.buildkite.com/v2/organizations/<ORG>/pipelines/<PIPELINE>/builds"
  }

https://pact.canny.io/admin/board/feature-requests/p/support-feature-branch-matching-for-webhook-triggered-builds

pact-foundation/pact-mock_service#137 (comment)

Hey team!

The community Slack linked to from the docs only allows user registrations for emails under the domains dius.com.au, smartbear.com and ae.com:

Is this a mistake or have you restricted it for a reason? Is there another way to connect with the community?

https://pact.canny.io/admin/board/feature-requests/p/support-full-text-search-of-contracts-in-the-pact-broker

I'd like to be able to access test results information, especially in the Provider tests during a Junit4 test run.
Currently it seems as though there's no way to see the results of the tests in a Provider test outside of via the result reporter files.
I see that there is a context associated with the provider test, but it doesn't seem to be used. And there's also a callback collection that contains the results during the test execution. However, it appears to be private to the base class and there are no public/protected methods to access this information. Would it be possible to open up this information in a future release of the JVM libraries?

https://pact.canny.io/admin/board/feature-requests/p/access-to-internal-test-context-information-within-a-provider-or-consumer-test

Update https://docs.pact.io/5-minute-getting-started-guide

• Update repl's as they use old code
• create usable code repository for users for fork/use/see in single language (js)
• create ci for code repo
• trigger code repo ci on pact-js library update
• extract code snippets from getting-started-js for https://docs.pact.io/5-minute-getting-started-guide
• create equivalent tests for each language
• add code tabs to https://docs.pact.io/5-minute-getting-started-guide

This would return all consumer pacts with tags that matches the provided regex.
Adding this would allow consumers and providers to coordinate development with known branch patterns
ex:
tagPattern: .*-new-feature
Would return any pact that has a tag suffix of -new-feature

https://pact.canny.io/admin/board/feature-requests/p/allow-version-selectors-to-specify-tags-with-regex

https://pact.canny.io/admin/board/feature-requests/p/support-merging-2-existing-pacticipants-rather-than-rejecting-pact-publication-f

Quote from Slack: "So, we have a recurring problem with people inventing provider names because they don’t understand how Pact works."

At present, there is no way to generate a boilerplate for either the consumer or provider tests. It would be easy to onboard multiple teams across org if there is a feature like say swagger code generator that generates tests based on the API definitions (OpenAPI) yaml file. Is this a feature you could consider developing?

https://pact.canny.io/admin/board/feature-requests/p/autogenerate-code-stubs-for-contract-tests

Currently in order to skip SSL verification for a webhook one must turn it off globally using the PACT_BROKER_DISABLE_SSL_VERIFICATION environment variable.
This is to request an option added in the webhook config to turn off SSL verification just for the webhook.
A use case for this is when there is a URL mismatch in certificate validation. (eg using a VPC endpoint to connect to the destination and the URLs are not matching)

https://pact.canny.io/admin/board/feature-requests/p/skip-ssl-verification-per-webook

• Document all language implementations to cover, and add to list
• Vulnerability scans
• Dependency updates
• ensure tests exist
• ensure tests are isolated and do not depend on external setup
• ensure CI build process
• ensure CI test process
• ensure CI release process
• enable CI canary release process
• enable scheduled build triggers
• build external getting-started repo
• trigger example repositories on CI releases

Placeholder for workshop content.

Happy to incorporate feedback, or for suggesting of content topics etc.

Pactober Workshop 1 - CI/CD workshop (HTTP Pact)

Aims

Warmup for the start of Pactober, introducing users to the core concept of contract testing, and Pact.

Provide a workshop where we take users through the recommended Pact setup.

Agenda

• Introduce users to contract testing and pact
• Run a CI/CD workshop, showing users how to reach Pact Nirvana with HTTP Pact

Pactober Workshop 2 - CI/CD workshop (Message Pact)

Aims

Introduce users to the evolution of Microservices, and event based systems, and how this is handled by Pact.

Provide a workshop which builds on the previous CI/CD example but shows a messaging consumer and provider, to highlight the differences

Agenda

• Introduce users to the concepts of Message Pact introduced in Pact Spec v3
• Discuss some of the limitations of the current approach
  • V3 named diff providers
  • V4 spec introduces async/sync messages
  • V4 spec allows http / message interactions to exist in the same pact
  • Only checks message contents, not transports.
• Run a CI/CD workshop, showing users how to reach Pact Nirvana with Message Pact

Pactober Workshop 3 - CI/CD workshop (Plugin Pact)

Aims

Introduce the concepts of multi-protocol systems, and how the pact-plugin framework was developed to enable users to extend Pact to cover use cases that may not be applicable to all end users.

Provide a workshop which builds on the previous CI/CD example but shows a gRPC consumer and provider, to highlight the differences

Agenda

• Introduce users to the concepts of the Pact Plugin framework introduced in Pact Spec v4
• Discuss some of the benefits/limitations of the pact-plugin approach
• Run a CI/CD workshop, showing users how to reach Pact Nirvana with Plugin Pacts (probably gRPC area calculator)

Pactober Workshop 4 - Maintainer/contributor workshop How Pact is built

Aims

Introduce interested users into how Pact is built, distributed and used by client languages, by using our previous workshop examples as use cases.

This would be more aimed at maintainer/contributors, or those interested in the internals of Pact. This could be useful for users in languages who are unfamiliar with Rust (which our Pact reference core is written in)

Agenda

• Introduce users to the Pact reference core and the FFI approach
• Discuss some of the benefits/limitations of the new approach compared to the Pact ruby implementation.
• Run a workshop showing how to the FFI is leveraged in our 3 tests used in the CI/CD workshop
  • HTTP Pact
  • Message Pact
  • Plugin Pact

https://pact.canny.io/admin/board/feature-requests/p/support-a-communication-method-for-announcing-deprecations

For the webhooks to be able to trigger builds for the right commit of a project, it needs the commit. Not every project uses the pure commit field as the version number when publishing a pact or verification. Supporting two separate fields will allow users to use their own version number format, while allowing builds to be triggered without having to reverse engineer the commit from the version number.

https://pact.canny.io/admin/board/feature-requests/p/support-separate-commit-field-when-publishing-pacts-and-verification-results

Status

Rust Libraries

Note:- With exception to the pact_ffi library, the other libraries are provided as executables, statically linked to musl libc, which means they should work on all Linux distributions, both musl based (Alpine, Void, Chimera etc) & glibc based (Debian, RHEL etc)

Client Libraries

Background

Many teams choose to run builds on Alpine Linux due to its tiny footprint, and smaller security surface area.

Guidance for Alpine users, has been stored on our docs site here

For Pact implementations that use the Ruby shared core

Support is available by installing glibc compatibility layers due the underlying runtime being built on centos7

https://github.com/pact-foundation/pact-ruby-standalone/wiki/Using-the-pact-ruby-standalone-with-Alpine-Linux-Docker

For Pact implementations that use the Rust shared core

Alpine or other musl based distros have not be supported due to

1. Lack of musl based artifacts from pact-rust based projects
2. Potential issues requiring the project to possibly be rebuilt against specific versions of Alpine / musl.

Point 1 is now addressed, partially for the FFI library.

Pact-Reference is now publishing musl based versions of the Pact-FFI as of 0.4.15

We would like to investigate creating musl variants of all the pact-reference (rust) based artifacts, and incorporating them into client libraries

Support Level

Any of the musl based artifacts should be considered somewhat experimental and you may encounter issues, as they have not been used for a long time. I would strongly advise these are not used in production workflows, unless you are handy and don't mind investigating issues yourself

We would gratefully ask that if issues are raised, that two things are provided

1. A minimal reproducible example of a Docker image/file based on Alpine that recreates the issue
2. A minimal reproducible example of a Docker image/file based on Debian that recreates the issue

Note - The debian image, may not show the same behaviour, this will be useful to determine where there are bugs/issues or gaps in the musl implementation which can be communicated to others.

How to participate?

Drop a comment in this thread, or reach out via slack in #libpact_ffi-users

FFI

Investigate the possibility of incorporating into client libraries

Pact-Js-Core

• Pact-Js-Core
  • build musl pact.node bindings - Delta
  • release prebuilds
  • CI Test runs
    • arm64 musl
    • amd64 musl

Snags

1. pact ruby standalone arm64 fail under qemu in GHA which fails test suite
2. some inconsistent behaviour in node 16 (set /tmp cache) / 18 ( max sockets 1)
3. prebuilds take a good while, but these could be limited to only running when the ffi, or native bindings are updated, or failing that just run on pull requests. regular test runs could just grab the latest pre build

Pact-JS

• Pact-JS

Pact-PHP

• Pact-PHP
  • Support for musl - delta
  • CI Test runs
    • arm64 musl - gha
    • amd64 musl - gha

Snags

1. PHP can only load .so files, so requires converted .a musl library
2. AMD64 musl images require shared-mime-info installing for consistent content type matching, ARM64 doesn't. If installed, they flip behaviour.
3. Needs musl detection method in downloader/

Pact-Go

• Pact-Go
  • Support for musl - delta
  • CI Test runs
    • arm64 musl - partially working, some seg faults
    • amd64 musl - partially working, some seg faults

Snags

1. Some seg fauls, also occur on vanilla x86_64 build although not consistently reproducible.

Pact-Net

• Pact-Net
  • Support for musl - delta
  • CI Test runs
    • arm64 musl - gha - failing
    • amd64 musl - gha
    • arm64 musl - cirrus
    • amd64 musl - cirrus

Snags

1. .NET can only load .so files, so requires converted .a musl library
2. ARM64 musl on GHA fails to build project, but passes on Cirrus
3. Needs musl detection method in csproj file

add others

Mock Server CLI

• Create musl variants
  • Fork release
  • PR
  • Publish

Provider Verifier CLI

• Create musl variants
  • fork release
  • PR
  • Publish

Stub Server CLI

• Create musl variants
  • fork release
  • PR
  • Publish

Plugins

pact plugin cli

• fork release
• issue building existing x86_64 linux executable in CI (build with cross to retain known glibc version)
• pact plugin driver rust
• pact plugin driver jvm
• support downloading non musl variants if not avail, via pact-plugin-cli (rust and jvm driver)

Pact-Protobuf-Plugin

• Create musl variants
  • fork release
  • PR

Pact-csv-Plugin

• Create musl variants
• fork release
• PR

Pact-matt plugin

Build with goreleaser and linked with musl, so existing binaries work with alpine.

• support downloading non musl variants if not avail, via pact-plugin-cli (rust and jvm driver)

Client language FFI bindings that only support dynamic *.so libaries

For some languages, it is not possible to load a *.a static library.

• PHP
• Ruby
• Others?

It is possible however to convert a .a file to a .so file.

ar -x libpact_ffi.a
gcc -shared *.o -o libpact_ffi.so
rm -f *.o

This shrinks our .a file from 115mb to a circa 41mb .so file, which looks inline with the size of the musl node prebuild for pact-js

• Create .so musl variants of pact ffi
  • Fork release
  • Delta
  • PR
  • Publish

See examples here https://docs.pact.io/consumer/using_pact_to_support_ui_testing

https://pact.canny.io/admin/board/feature-requests/p/create-code-examples-for-how-to-use-pact-to-support-ui-testing

It would be awesome if either:

1. Pacticipant names were case insensitve
   or
2. The broker warned when publishing or retrieving a pact if the pacticipant name differs only in case from another
   This was indirectly suggested by Subrahmanyam Rentala on slack:
   At the consumer side I provided the provider name as : ABc and at the provider side it was ABC, and again error was not user friendly to investigate

https://pact.canny.io/admin/board/feature-requests/p/should-pacticipant-names-be-case-insensitve

Need to update cal invite to the following

Talked about ‘the other meeting’ currently scheduled for 07:00 AEDT/22:00 UK.
The times are not great for either time zone and currently the community members attend this UK timezone meeting. We agreed to try running bi-weekly in the UK timezone for now. Next community meeting will be on 01 May at the new time of 11:00 UK/20:00 AEDT

• Single event, every two weeks
• BST 11AM
• AEDT 8PM

https://github.com/pact-foundation/devrel?tab=readme-ov-file#-maintainer-sessions

• Update README
• Update Cal invite

Pactober Workshop 4 - Maintainer/contributor workshop How Pact is built

Event Details

Aims

Introduce interested users into how Pact is built, distributed and used by client languages, by using our previous workshop examples as use cases.

This would be more aimed at maintainer/contributors, or those interested in the internals of Pact. This could be useful for users in languages who are unfamiliar with Rust (which our Pact reference core is written in)

Agenda

• Introduce users to the Pact reference core and the FFI approach
• Discuss some of the benefits/limitations of the new approach compared to the Pact ruby implementation.
• Run a workshop showing how to the FFI is leveraged in our 3 tests used in the CI/CD workshop
  • HTTP Pact
  • Message Pact
  • Plugin Pact

See issues (pact-foundation/pact-jvm#506, pact-foundation/pact-support#51, pact-foundation/pact-net#217). Also array elements still need to work with existing value matchers (regex, type, etc.).

https://pact.canny.io/admin/board/feature-requests/p/support-ignoring-order-of-array-elements-in-json-and-xml