Pact PHP - Support for V3 / V4 + Plugins Via FFI

[Lewiscowles1986]

Pact PHP - Support for V3 / V4 + Plugins Via FFI

What is the current status

Pact-PHP does not currently support v3+ features of the rust core, in the mainline branch.

V3+ features are now available for beta testing in ffi branch, in a view to stabilise and release into the mainline.

We would <3 your support

How can I test this today

Anyone can start testing pact-php with pact_ffi code by updating their composer.json

"pact-foundation/pact-php": "dev-ffi as 10.0.0"

Migration Guide:- https://github.com/pact-foundation/pact-php/blob/ffi/UPGRADE-10.0.md

PR's which made up this release

• Consumer Use Rust FFI #3: Consumer #280
• Message Consumer Use Rust FFI #4: Message Consumer #281
• Provider Use Rust FFI #5: Provider #282
• Stub Server Use Rust FFI #6: Stub Server #283
• Test stub server health check #294
• Use Rust FFI #6.1: Remove stub server health check #295
• Use Rust FFI #6.1: Remove stub server health check #295
• Use Rust FFI #6.2: Move endpoint config #296
• Use Rust FFI #7.1: Stub server random port #297
• Use Rust FFI #10: Remove pact broker #302
• Use Rust FFI #11: Allow set content type #303
• Use Rust FFI #3.6: Add generators and matchers #310

How can I submit feedback

All feedback is gratefully received, positive feedback is great, as it allows us to ascertain how well the package is doing for users. Constructive criticism is okay too, but see the next section

• Reply in this issue
• Raise a new issue, clearly stating you are using the ffi branch

How can I contribute

If you want to help improve Pact-PHP, read the DEVELOPING.md documentation, fork the repo and have a play!

Edited by @YOU54F to help showcase current status

[YOU54F]

Hey @Lewiscowles1986,

@tienvx and @mmoll have being doing some great work, and I'm along for the ride to help support you guys know.

I've created a pact-php project and given Tien the rights to help create tickets on it, however we are both pretty green to structuring projects in GitHub.

If you have any advice, we would love to chat.

We definitely want to pick up this thread of moving over to the FFI, but also wonder how we bring more maintainers into the fold.

I would also want to consider addressing some of the concerns you raised about the testability of the current project. Maybe addressing some of those now, might help ease the path of migration to the FFI (decoupling from Pactflow Broker, known state and tear down for the e2e tests)

[Lewiscowles1986]

Hey @YOU54F mostly it's trying to eliminate effects (filesystem, network, database, sub-process / os syscalls) or separate them into a suite that is run in an environment where the likelihood of failure is much lower. Basically anything inferring something that touches anything the code is not in total control of.

You can use interfaces and mocks to work around this at unit level, at the cost of needing a separate integration suite. This allows a dev to get into a fast-feedback loop.

The problems so far have been that network resources (almost super-global level of spread of information), was used, and the credentials were baked into the repository.

One way to solve for network state mutability with a smaller change, would be to use GitHub actions secrets, passed as environment variables to the test(s), with new credentials, for a resource the PACT team owns and sets up. This then means joe-public cannot find the credentials to access the mutable network resource (which I think of as a type of database as it persists state); and the maintainers of this repo can use to ensure that they have a collection in the correct state, that only this repo uses.

More broadly, FFI should exchange some flakiness around sub-process calls for needing to take control of ensuring FFI builds and is compatible. It should be easier to solve for and offer a more consistent contributor experience. I'd noticed inconsistent results which could be timing related, but were fairly annoying, and as you may have noticed, occasionally find me in a bitter mood (sorry about that).

Last things I'd suggest are documenting decisions and architecture. GitHub actions are one way to do that, as everything is written in a fairly readable YAML format. You can setup scheduled builds once-per-week and that will let you know if something breaks. We all know it shouldn't, but I've seen it 2-3 times since last year in this repo alone.

[mefellows]

One way to solve for network state mutability with a smaller change, would be to use GitHub actions secrets, passed as environment variables to the test(s), with new credentials, for a resource the PACT team owns and sets up. This then means joe-public cannot find the credentials to access the mutable network resource (which I think of as a type of database as it persists state); and the maintainers of this repo can use to ensure that they have a collection in the correct state, that only this repo uses.

I think these are broker credentials, and generally agree with the point. There should be a core set of tests that are deterministic and reliable (and therefore not bound to external conditions), and then we should consider a regression suite that tests end-to-end scenarios (I'm looking at ways to document this using e.g. Gherkin syntax, allowing us to re-use across all key projects). The starting point might be a kitchen sink type suite, that we use across all projects that eventually evolves into the fine grained BDD suite.

I'd noticed inconsistent results which could be timing related, but were fairly annoying, and as you may have noticed, occasionally find me in a bitter mood (sorry about that).

We all do it, especially at 2am in the morning when you just want that f*cken build to pass but you found yourself yak shaving n levels deep...

[Lewiscowles1986]

You mentioned a cucumber approach. Were you thinking of focusing on network-familiarity matchers:

Given I have Headers {headersObject}
  And I have body {bodyObject}
When I call POST /action
Then matches agreed contract {identifier}

Examples:
| headersObject | bodyObject | identifier |
| ....

or RPC / task based matchers:

Given I have {arrangement}
When I {verb}
Then broker validation confirms my contract

This is the problem I see many projects fall into without huge teams. Moving the furniture while there is a fire. Multiple teams could surely address, but the core problems then multiply as there are multiple distinct problems. Being able to shop for a third-party matcher library that does what you need with implementations across languages sounds like "such fun" and perhaps a cause of more yaks being imported to the shaving area?

[Lewiscowles1986]

Would you say a unit-suite that avoids all the sub-process calls using mocks and stubs, and dependency injection + inversion might be a way to secure that fast inner, effect-free loop, or were you thinking of something else for the faster suite?

Also would you have the BDD for the end-to-end suite as well as a perhaps post-merge suite? How would you plan to resolve discrepancies between the unit level passing and the integration tests passing? (any time the full set of suites is not run is a chance for a bug to escape into the wild).

Would you say that perhaps it's fine as long as nobody releases with broken integration / e2e?

[YOU54F]

Thanks for pinning @mefellows have updated the list to provide a big of a spiderweb of work to date.

[YOU54F]

Hey all!

Just to let you know that we've merged @tienvx's changes into the ffi branch so you can start testing this today!

@Lewiscowles1986 apologies for the multiple edits under you name - have added a note now to say its me :)

[Lewiscowles1986]

No need to apologise, this is HUGE win (I observed lower latencies using this months ago).

@YOU54F is this now closed?

[YOU54F]

I think I would like to keep it as a conversation place for feedback on the alpha (release tracking here #324) that way people can hustle around it, for more general discussion or raise an issue if its something bigger

Happy to close it down and create a new issue if you would rather be tracked at the top level with notifications

[Lewiscowles1986]

Makes sense to me to do whatever you like. I was more curious as there are a number of issues listed at the top. Not all seemed closed off.

[YOU54F]

Makes sense to me to do whatever you like. I was more curious as there are a number of issues listed at the top. Not all seemed closed off.

Not 100% sure which you are referring to as there are a few interspersed concerns in this thread

if it is with regards to the PR's which are marked as closed, they have been consolidated into the ffi branch as a single PR (@tienvx had merged all the changes into a single branch named all which I picked from.)

If its with regards to the other great issues discussed in the thread, I'll be honest, I haven't had the time to properly digest enough to give you a cohesive structured reply to them, but they are brilliant points to raise for consideration.

We are kicking off a maintainers/community public session and you can find info in our new public #maintainers channel so that will be a good place to discuss some of those project wide approaches, along with advantages and disadvantages.

Not saying you need to get involved, just stating that we will pick up your comments, slowly but surely!

is this now closed?

In reflection, I think so. For any readers you can find a alpha release with this functionality available to test

https://github.com/pact-foundation/pact-php/releases/tag/10.0.0-alpha1

along with links to instructions for migrating, using and contributing in the release notes.

We look forward to hearing your feedback!