-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Pact PHP - Support for V3 / V4 + Plugins Via FFI #262
Comments
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) |
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. |
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.
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 |
You mentioned a cucumber approach. Were you thinking of focusing on network-familiarity matchers:
or RPC / task based matchers:
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? |
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? |
Thanks for pinning @mefellows have updated the list to provide a big of a spiderweb of work to date. |
Hey all! Just to let you know that we've merged @tienvx's changes into the @Lewiscowles1986 apologies for the multiple edits under you name - have added a note now to say its me :) |
No need to apologise, this is HUGE win (I observed lower latencies using this months ago). @YOU54F is this now closed? |
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 |
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 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!
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! |
Unpinning, please redirect feedback to #377 |
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
withpact_ffi
code by updating theircomposer.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
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
ffi
branchHow 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
The text was updated successfully, but these errors were encountered: