has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

has joined #maintainers

:wave:

set the channel topic: Discuss strategy, roadmap, ideas and decisions around the Pact open source ecosystem.

where am I?

it was all a dream

:blobwave: Hello and welcome to our new public home for our maintainer community. Really hope this helps bring others into the fold! We?ve discussed a few times about having regular catch-ups and I am acutely aware of the difficulties of timezones with cross continent members, and everyones own day to day endeavours. I?d like to have some time in my cal, to spend with the maintainer/community weekly, where it can be a chance to discuss and showcase. Not really sure of the form. agenda and other stuff, but probably best with finding a time :slightly_smiling_face: I am UK based, but semi nocturnal, but maybe worth considering those in the EU timezones for starters, as to what might work for you. Are any days out of the question, are any times complete blockers? Feel free to let me know in a :thread:

I?m ready when you are. I think 11am or 12pm London time most days of the week (except Friday :stuck_out_tongue: ) work for me!

For all those who are asking for autogenerated tests - this is likely to be a step on the way: https://microsoft.github.io/TypeChat/blog/introducing-typechat/

interesting concept, thanks for sharing! i had a play with chatgpt when it first came out to see how far i could get with a domain idea. it?s kinda useful at points, but then the LLM dataset quickly shows it age. I keep wanting to put some time aside to have a play with doing something with Pact and AI, like feed it all our github issues or code. i did AI at uni, but i also get turned off stuff when there is loads of hype, so I haven?t really dug in

i saw a .netter mention they were trying to understand their pact net test with chatgpt and i think as they were using a new release, chatgpt really had no idea

Yeah. It?s not really there yet I think. I reckon it would be possible to build something pretty effective, but I think it would have to be a custom solution that wrapped something like this library

I think we?re a long way from ?hey, write all my tests?

Yeah you have to almost write pseudocode to get anything useful from say copilot, but it is useful for then allowing you to actually discretely list out the steps of what you need to do, to solve your problem when otherwise I might go a bit off piste!

but it definitely saves a fair few stack overflows

:mega: *Strategy Update* :mega: _NOTE: this is a repost from the private channel. Now that we have a public one, I think it makes sense to share it here. As discussed, I?ll be finding public places to track most of the suggestions where appropriate._ Hi all! Following up on the previous strategy update we identified several pain points that aligned with the current stated kernel and appeared as consistent themes in our workshops which we can and should get cracking on ASAP. To that end, and with the spirit of being as transparent as possible, I?ve been working with the team at SmartBear to consider how we can best support some of these activities and create alignment between the commercial and community initiatives. I?d like to communicate intent around the initiative we are calling _?SmartBear supported?_. You may have seen https://docs.pact.io/help/smartbear already, including a primitive labelling system we?ve been using to pick up tickets (into the SmartBear team backlog) across some projects. We would like to expand on this concept further. Some of this stems from our own customers wanting to see more support from us around the open source elements of the service we provide and some of it from within, wanting to improve our commitment (see also why we created PactFlow: https://pactflow.io/blog/why-build-an-open-source-company/) :dart: _The goal of this initiative is to find alignment between SmartBear?s commercial objectives and the open source ecosystem. The initial rollout aim is to start small and focus on key areas that can be improved for both parties._ What we have done in preparation and research for this: 1. Identified the key challenges for SmartBear (PactFlow) as it relates to the OSS project (see the ?Voice of the customer? image, with customer data/commentary redacted) 2. Brainstormed some approaches to address these needs and affinity mapped them (purple cards with yellow cards surrounding them) 3. Identified a number of actions we can take to improve that situation 4. Mapped these against the key OSS challenges (orange cards are the actions and the yellow ones are the root causes from the OSS strategy) 5. Worked with internal stakeholders to create alignment around what we would like to achieve and what we are able to commit to What we have come up with so far are four key areas. We are aiming to implement the following in the coming weeks/months: 1. Agree and communicate the SmartBear supported initiative a. What it is and why we are doing it. TL;DR - we want to improve the Pact ecosystem and take additional responsibilities in ensuring its success 2. Agree and implement a contributor triage process a. The objective here is to be able to provide improved support and responsiveness for ?in scope? projects (given the volume across the ecosystem, we may extend to all assets but we will see) b. This includes any issues, features and pull requests - i.e. preventing stale contributions, and encouraging more 3. Review and improve OSS/Commercial communications a. This is all about improving the communication and experiences where PactFlow and Pact intersect in public 4. Maintainer Experience a. Make it easier for maintainers to get involved, do their job and stay up to date _(there is bit more detail in the attached images, but the detail is still being worked on)_ *What I need from you* Feedback on the concept or ideas that could improve upon them. Particularly given point (3) above. I appreciate some of the workshop/Miro snippets may be a bit lost without further context, so please do ask/reach out if you want to know more. The biggest potential source of conflict/issue I can see, is supporting assets that are not currently maintained by SmartBear employees (e.g. Pact .NET which is quite active already but behind on some major features or Pact Python which is in a bit of limbo). A related topic on the agenda (related to point 3) is how to get non-SmartBear maintained projects up to the latest features, so we may need to solve it anyway. *What next?* Once feedback has been sought, we?ll get to work on finalising implementation. Some of the above we can get cracking on right away e.g. we can start to draft the wording and details of (1) to share, (3) is mostly an audit and proposed update, (4) is all stuff we?ve agreed to do previously.

In the next couple of weeks, I plan on: 1. Implementing the initial triage process 2. Drafting a public documentation page around the initiative 3. Performing the audit around PactFlow -> Pact touch points.

Separate note: I have asked one of the tech writers at SmartBear to review the ?getting started? and ?guides? section on http://docs.pact.io, and to help draft a style guide that we can follow.

Would we be interested in having a documentation style guide contributed from the tech writing team at SmartBear?

Or at the least, we could use theirs as a starting point for a conversation?

Sounds good to me!

Friday I made time to go through @tien.xuan.vo?s Pact-PHP working on moving to the rust core, and it is spectacular. ? The migration guide ? The fact consumer tests don?t need to change at all (and in fact can have things taken out of the users setup) ? due to not needing a pact test listener to write to file ? the integration of the plugins and test demonstrations (csv and protobuf repos) and the pact plugin installer It has been tough to review because it?s so huge (nature of the beast), but has been GREAT fun to play around with the end result. Really looking forward to getting some of the snag list cleaned up today, getting it into the ``ffi` branch and getting the announcement out in our Pact OSS post on Thursday - Draft https://github.com/pact-foundation/docs.pact.io/pull/269

Can?t wait to see it in action!!

I assume soon we?ll need to be releasing an alpha or something to Composer (or whatever it is PHP uses these days?)

you can load branches via composer, which will go in the docs, so you will require `dev-<branch>` https://github.com/pact-foundation/pact-php/issues/262 > Anyone can start testing `pact-php` with `pact_ffi` code by updating their `composer.json` > `"pact-foundation/pact-php": "dev-ffi as 9.0.0"` Technically it is actually `dev-ffi-next` as I pushed up that to test it out on Friday but will be from that branch. I think we will want to publish @tien.xuan.vo?s additional packages to composer so they don?t have to be loaded from a git repo (which requires tokens to avoid rate limits) https://github.com/tienvx/pact-php-protobuf https://github.com/tienvx/pact-php-csv https://github.com/tienvx/pact-php-plugin https://github.com/tienvx/pact-plugin-install If these get transferred to the pact-foundation, we will want to add Tien to the maintainers group in composer I believe, or have a pact-foundation user, so we can generate a token for any other php repos in the pact-foundation org > I assume soon we?ll need to be releasing an alpha or something to Composer (or whatever it is PHP uses these days?) Yes, easy as creating a tag though, semantic versioning guidelines for composer are here https://getcomposer.org/doc/04-schema.md#version

tags are better all round tho, reading up on the docs, to get a deterministic package for the end user

1. It?s merged! Thank you @tien.xuan.vo :taco: :rocket: 2. Raised issue to track release https://github.com/pact-foundation/pact-php/issues/324 a. cc @cfmack / @tien.xuan.vo 3. Updated tracking issue for latest updates on how to use/ test / provide feedback and contribute a. https://github.com/pact-foundation/pact-php/issues/262 4. Updated README to point users looking for v3 spec + to the tracking i a. https://github.com/pact-foundation/pact-php#specifications Charles - hope you don?t feel I am stepping on your toes here with the push to get Tien?s changes out. They are pretty through and haven given them a spin on and off for the last couple of months,

When i first met the tech writing team, i asked if they had one because I knew it would be valuable and didn?t have the prior knowledge of what excellent looks like from experience. would definitely love to see what?s in store. super excited to get some tech writers eyes across the docs for a bit of a review/audit of the estate to date, and provide some suggestions. I can imagine some should be relatively low hanging fruit and great for contributors new and old to get involved.

Wow, a lot of thing happen when I'm away for a while :v:

Top searches in past 3 months on Pact Docs

search with no result. I?m tempted to create a page on the docs website that says: > Kadena Pact is a stupid blockchain thing, made from people who decided not to google the term ?Pact? and ?contract testing? before they named their product. They therefore should not be trusted and you should find another tool.

:blobwave: Snyk is telling me a test is failing but I can?t see the detail. I want a green build for them sweet sweet endorphins xD https://github.com/pact-foundation/pact-python/pull/357#issuecomment-1652581976 In other news, possibly janky, but does the job, Python FFI backed verifier side is available, and tested with plugins too :)

this is the vulnerability: https://app.snyk.io/org/pact-foundation-808/project/e9c5ba76-8566-4fb1-9045-d26403754ca6/pr-check/09e67f0e-c607-427f-898f-7e78bbb03aab

_(I think you should be able to login via Github to see it?)_

It?s this, anyway

in `requirements_dev.txt`

niente, however thats useful I can sort that :slightly_smiling_face:

Sent you an invite link in DM

:blobwave: Hey team, As part of our pledge to improve the Maintainer Experience, we would love to announce weekly collaborative agenda driven maintainer/community sessions. *Pact Community Meeting* Each Wednesday at 12:00 UK/21:00 AEST time we will hold a community meeting via a huddle in the #maintainers channel. Please see https://docs.google.com/document/d/1v_QWyYEl7rxR5hV0EQAcTFjBbiq5_uzn7_WMMYILRac/edit?usp=sharing for an openly editable agenda where anyone can table ideas for discussion. We are aware the timezones will be particularly challenging as we are globally distributed and have a-lot of other commitments. Open to ideas, suggestions, alternate times etc. We are taking some of the lessons and techniques learnt from @jo.laing?s time working with the Cucumber community. You can see Cucumbers open agenda here https://docs.google.com/document/d/1NbJDkGs4IgDUHDSA8W6WollVL0rnHDCMUxGPrzPPyiI/edit?usp=sharing

:date: If anyone would like a calendar invitation please let me know your email address or DM me if you'd prefer, thanks.

Thanks - looking forward to this! I?ll add some thoughts for an agenda later today

I doubt I?ll be able to make each week at that time, but will use the calendar to signal my intent. I wonder if we should use some slack automation/reminder here as well to get a :+1: / :-1: a day in advance so people can see who?s coming?

Happy to move times, and run additional sessions at alternate times to try and make it available to everyone as possible Slack automation/reminder sounds like a smart idea.

has joined #maintainers

:blobwave: Hey team! Adding @chrisjburnscg into the fold. He has built, transferred and is maintaining pact-broker-chart Repo :- https://github.com/pact-foundation/pact-broker-chart Doccos:- https://docs.pact.io/pact_broker/kubernetes

The DevOps playground did an online learning session around Pact last year, it was a good session, I went along for the ride. We?ve just had a lovely ask to consider https://pact-foundation.slack.com/archives/C5F4KFKR8/p1690539743735549?thread_ts=1688662926.571029&cid=C5F4KFKR8

@tien.xuan.vo we?ve got a green light for an alpha release of pact-php with ffi https://github.com/pact-foundation/pact-php/issues/324#issuecomment-1655589411 Thanks @cfmack

I can't wait for it. I will report one more bug on pact-reference and go back creating more PRs for pact-php after alpha1 release

Thank you so much for your time, dedication and effort. It really is very much appreciated as its very impressive work

yes!

Looks great. I think swag would be great, what are our options? SmartBear brand team or try and get some organised/printed ourselves?

This is a good idea, but I think something async might work better. I?m travelling for a month, so I won?t be around much at the moment I also can?t make Wednesday evening for any dates this year

Pretty much all Pact collaboration so far has been async, if it wasn?t in person (or the conference we ran)

> This is a good idea, but I think something async might work better. I would hope that this isn?t to replace async communication, but rather to allow contributors/maintainers a time to gather if they want. the agenda is openly editable and we can discuss anytime :) > I?m travelling for a month, so I won?t be around much at the moment > I also can?t make Wednesday evening for any dates this year ooh where are you travelling to? Thanks for letting us know, I?ve added an agenda note around maintainer avail and time zone preference. > Pretty much all Pact collaboration so far has been async, if it wasn?t in person (or the conference we ran) I don?t think that will ever change due to the nature of the beast. Pretty much 95% of my work has been async apart from a few video calls with maintainers

Thanks for the input dude :slightly_smiling_face:

This is why we?re having them in person Tim - to try something different! You might recall this was an action from the strategy sessions. I think it?s worth trying them out for a few months to see what works/doesn?t work. I certainly appreciate TZ issues (I?m finding I lack energy at night where previously I was in the zone) so we?ll have to iterate and explore this area. I don?t think we should make this a decision making point, at least not in lieu of a ?quorum? or other discussions as necessary, but if we can record and share the agenda and outcomes, it should still function well for async collaboration with an additional benefit of socialisation amongst not just maintainers, but the contributors and general community.

What is the thoughts on required pact-plugins being auto-installed by the Pact client libraries. Should 1. This be the preferable approach a. Should we allow configurability as to where the `PACT_PLUGIN_DIR` should be. 2. We allow the user to disable auto installation a. We allow the user to specify their own path to `PACT_PLUGIN_DIR` Thoughts come from https://github.com/pact-foundation/pact-php/pull/330 I believe the following libraries with self load plugins ? pact-rust ? pact-jvm ? pact-php v10 alpha Happy to be corrected on the above

The main concern was running in very strict corporate environments, where you couldn't download the plugins and you may not have write access to the home directory. So they could pre-setup a plugins directory somewhere else.

I still think the package managers could / should be used for this. Pact makes a "publish plugin" tool. It makes packages for all of the main pact ecosystems, which just wrap up the plugin into the package (possibly with some wrapper code if the Pact client lib needs it). As a plugin maintainer, you'd publish the packages made by this tool. Each Pact client lib would know (by convention) how to unwrap the plugin from that package. So you'd require the specific plugin's package for your language, then in code do something like: ```pact.loadPlugin("somePluginPackage")``` and the Pact client lib (eg pact-js) would read that package, unbox the plugin, and load it.

Why am I mentioning this? 1) Plugin downloading / management issues all go away (or become the same as any other package management in that ecosystem) 2) It solves the problem of how to do required pact-plugins - the pact client lib just depends on the required plugins, and can load them itself

It seems we cannot record Slack huddles :disappointed:

hey hey so just a nice little chat today in the first session, i recorded a few bits down in the agenda. just some brain dump on times as it?s really inconvenient for Aus and I?d love to be able to have a window where we could have Beth and Ron. i?m not really an early bird but I wonder if an early morning UK time might be a good time to catch our side before work and Aus side just around work hours. i could probably go 7am earliest ( any earlier and i would probably just stay up as an all nighter :sweat_smile: ) I?m also just open to being quite available ad hoc in whatever format works for each individual, i know we are all different and trying to get full agreement is nigh on unachievable

^ I can comfortably make that time from September onwards. If they're weekly would probably come every one to six weeks

That?s a fairly decent cadence, if people are open to that. Once every 6 weeks we flip the timing around?

I know @pact544 mentioned that work hours events are hard for him to manage, and other times can be difficult with kids/family commitments. But perhaps an 8am call would work?

FYI I came across this today during some research: https://www.linuxfoundation.org/research/open-source-maintainers?hsLang=en Well worth a read. We can obviously be doing better in some areas, but it?s pleasing to see that we have independently identified some of these items and are working on them now

> Pact makes a ?publish plugin? tool. It makes packages for all of the main pact ecosystems, which just wrap up the plugin into the package (possibly with some wrapper code if the Pact client lib needs it). you could raise this request it at http://pact.canny.io Tim :wink: It?s a good idea, possibly, but not an easy one to achieve.

I think given the plugin ecosystem is so nascent, it?s reasonable to start small and see how it evolves. I don?t think a CLI is an unreasonably painful thing to use, especially given that you need a CLI for other parts of the Pact ecosystem now already.

At least, that was the thinking

Re (3): I?ve created a *https://github.com/pact-foundation/community/discussions/1* in the *community* repository to track this work. I thought of a few alternatives, but I liked the idea that this is GitHub native. The community repo right now isn?t that visible / useful, but after the maintainer catch up this week, I can see us building on that a bit more. I?d be keen to get thoughts on other places for the audit to take place.

@yousafn I thought the (empty) community repository was something you created, but it was actually me. 5 years ago :laughing: Maybe I should move the discussion to https://github.com/pact-foundation/devrel and kill off the community repo?

UPDATE: I have deleted the community repo and transferred the issue. We don?t need more things/places to track stuff

Yes that was on my list to kill with fire, due to it being empty and taking up cognitive load. Nice work on the discussion pieces

Thanks, as you may have noticed they are all WIP but nobody is looking yet so I'll clean up Monday

a wip something is better than a whole bunch of nothing and yer weekend is calling

aww sad news about cirrus ci and free runner use https://cirrus-ci.org/blog/2023/07/17/limiting-free-usage-of-cirrus-ci/

This was Pact foundations usage (most of it is probably due to lack of limits on the tasks)

This is my own, I?ve got a paid for plan as well for private/persona repos at 10 dollars a month.

Maybe we should use our $$ to pay for the service? We get value from it.

I think my proposal is starting smaller- as in, you?d have to do very little. The existing strategy means implementing package management and reasoning about plugin dependencies

Can you perhaps explain? Taking an example, we have a community member who has created an Avro plugin. They wrote it in Java (actually, Scala) but it runs on the JVM. This plugin can be distributed to any language. If we wanted it in NPM, would we need to create an NPM package to wrap it?

Yes, that?s right. There?s an explanation above, unless you?re saying that it?s not clear from that?

> Pact makes a ?publish plugin? tool. It makes packages for all of the main pact ecosystems, which just wrap up the plugin into the package (possibly with some wrapper code if the Pact client lib needs it). This? If so, I agree that?s a nice experience, I?m just making the point that that?s a non-trivial amount of work, and definitely more than what the CLI has to do. I think your point though is that we may end up going a registry path, which would introduce a different line of complexity?

I think the CLI is needed where a package managed version doesn?t exist anyway - e.g. for a new language or language that doesn?t have the auto-package process, or even just the CLI verifier

I think it?s strictly less work than the current approach. Although maybe that?s already built, so it doesn?t matter

true. I think it?s a good idea though and will put a feature request for it. I?m currently thinking about how we do ?roadmaps? at the moment, but I don?t have any views so it?s just going to go in canny and perhaps with a tracking issue on pact-plugins repo

I like the general test that plugins should make Pact simpler

Then the core could be composed of plugins too

yeah i think so. you can get it hooked up with github actions and use a self hosted runner. i wonder if it?s just cheaper to buy a couple of mac minis and use them as private self hosted runners. but for now might just be worth paying something just for ease, (you can use cirrus-cli in gh actions so we can still retain the .cirrus.yml files we have today, and it still means people can use the tool locally to recreate the ci runs)

How much is it? We have lots in the kitty, and I?d be happy to commit some $$ to paying for them until GH actions supports ARM/Mac etc. properly (if it?s not drastically expensive)

They are already providing a lot of value

I shall get a tracking issue, can look at last months use, and then ascertain indicative cost and alternatives

Time is our most precious resource, so I?d rather us spend our time on the things the community most needs (e.g. Python, .NET upgraded to V4/Plugins, bugs squashed, documentation made betterer).

agreed 110%

hmmm so that would be $117 for Mac credits + $15 for Linux = $132 /mth :eyes:

My Immediate thoughts about the directory stuff ? What if we can?t write to the default `$HOME` location (`$HOME/.pact/plugins`) ? Pact-plugins support reading a non default location by setting `PACT_PLUGIN_DIR` ? What about libraries which store required things within its own folder ? PHP uses a bin folder On the plugin side, currently I've been interacting with the pact ffi lib through client library wrappers and download the required plugins with a cross platform `pact-plugin-cli` tool I was kinda thinking it would be nice if the pact_ffi could just go and make a request to get the required plugin, so the user doesn't have to know about it, and as a library author, I don't need to package seperate packages, I just the ffi and it takes care of it. That comes back to the problem of ? plugins being downloaded after the pact library is installed ? plugins being downloaded during a test (how do you know which plugins you need up front) Maybe that is okay for most users, they would download once and be stored. If you needed to download them prior you could use the pact ffi which functions into the pact-plugin-cli to allow a user to easily allow downloading of required plugins prior to a test, and can store them somewhere accessible to their code. I had a fleeting thought at the weekend about could the pact rust could be made extensible, so a user could easily build a new matcher or some kinda functionality, and bolt that into the pact core, rather than communicating via the plugin framework over grpc. Not sure of the _best_ experience here, and its tricky as some places are locked down, most people don't want the element of surprise, some people just want to write a test run it and everything be automagic

?If I understand https://cirrus-ci.org/pricing/#compute-credits properly:

> I like the general test that plugins should make Pact simpler I like that test for anything in the Pact world,

> build a new matcher Yes, this is the design I preferred

I think at the most part it doesn't make the concept simpler at the moment, but affords the capabilities to users. It's on us to really sharpen that user experience (and conversely the maintainer experience) through the docs and the critical journeys to what the hell is what, whats it's capabilities and why the hell would I need plugins. I'm just on a mission to get pact-python and pact-ruby to some element of ffi support and then its a big lens on the doccos. I am really love async apis work so have some lessons to take from them

Hah I am trying to make sense of that. I think that is correct. 1 compute is 1 dollar, macos is 5 times more expensive

> I had a fleeting thought at the weekend about could the pact rust could be made extensible, so a user could easily build a new matcher or some kinda functionality, and bolt that into the pact core, rather than communicating via the plugin framework over grpc. they could do that now, to be fair. The thinking - and really, evidence - is that getting contributions into the core (both Ruby and Rust) has been too much of an ask for people in the past. I have no doubt that if we spent some time thinking about it and making it as easy as possible, that we could increase the number of contributions. Matchers are a good example I think, because they are much narrower in scope. gRPC for example and Avro involve a lot more complexity, and asking someone to write it in rust instead of their preferred language, is a tall order. It also bloats the core a lot - plugins mitigate both of those problems.

Morning/Afternoon/Evening :slightly_smiling_face: Hanging out in the huddle for the maintainerati sesh.

trivys bug request raising goes through into discussion for triage https://github.com/aquasecurity/trivy it asked me a load of questions and gave commands to get the version of the libraries as well which is useful https://github.com/aquasecurity/trivy/discussions/4972

Huh, that?s interesting. I wonder why discussions an not issues?

I like that it?s clear

How do! I?ve put together a GH issue with some ideas for some workshops for Pactober https://github.com/pact-foundation/devrel/issues/20 Would love some feedback, and see if my thoughts aligns with any of yours. Additionally, I?d love to take some time to talk to open source maintainers both internally in our Pact world, but also externally to present some of the successes and challenges, and any useful advice. It?s a small world and we are all probably connected to many others in the open source scene through 6 degrees of seperation. Cheers all!

I won't make tonight sorry folks!

No worries dude! take it easy

Yeah, feel better soon @matt.fellows

Hey all, We got the Pactober site updated with the skeleton of a schedule and placeholders. I'll get some instructions up, so if anyone wants to host their own event, they can add one to the schedule, within the month. (just a PR and some html copy-pasta) https://pact.io/pactober You can just drop an asset in for a headshot, or pull from a remote source, if you've prefer not to store it in source. The source code is here for the page https://github.com/pact-foundation/pact.io/blob/master/pages/pactober.html#L262 images are stored here https://github.com/pact-foundation/pact.io/tree/master/pages/assets/img

So was interviewing someone today and he started to tell me what contract testing is :joy:

go on?

which version of contract testing did he tell you about?

Which version? He was all about pact. So that was good! And consumer driven so extra points for him

You just sitting there like hmmm, nod, sounds interesting, I need to check it out

Hope they are a hire :slightly_smiling_face:

Should have said what about e2e tests

I was being facetious - we often come against people that say ?I test against my OAS? and call it contract testing.

Can you imagine if he quoted your blog post :smile:

did you ask them ?what?s the cost complexity of contract tests vs e2e tests?

?and show me the calculations

Prove it!!

Ahahahah!! I love this so much

Nice! Thanks for getting this together. How should we get it out in the wild for feedback - link in #general and ask for people to engage with the content?

I won?t be able to make this week?s maintainers meet (I?ll be packing for heading away for some small annual leave). But the following week (30th August) I?ve suggested @stan.amsellem join us to discuss: https://pact-foundation.slack.com/archives/C9VBGLUM9/p1688393229363659. Have added the item to the agenda

Yeah I might split them into separate issues for each week/event. You mentioned about making a headline schedule page for the event, so we can have some little cards that link off for the workshop and a main schedule page for the birthday bash, and a template so that speakers can have a bio page, with details about their talk etc. I?ll share out links in the Pact post, asking in general is good too.

has joined #maintainers

:blobwave: Hanging out in the huddle for this weeks meeting, feel free to pop in you are about.

Hey folks! Who is looking to attend this week?s maintainer catch up? (I will be) You can propose an agenda item here: https://docs.google.com/document/d/1v_QWyYEl7rxR5hV0EQAcTFjBbiq5_uzn7_WMMYILRac/edit Also looking to get some ideas for future meets, ideas below (please thumbs up if you?d like to see it)

*BDD suite overview* One of the actions on the back of our strategy workshop. Would anybody be interested in getting a run through and providing feedback for the BDD compatibility suite @uglyog has completed here: https://github.com/pact-foundation/pact-compatibility-suite

*Strategy Update* Some items we are working on (currently in various https://github.com/pact-foundation/devrel/discussions): ? SmartBear supported ? Issue triaging ? Roadmaps

Hey hey, So Slack have gone a bit silly with a new way of recording active users and therefore billing, so it means it is prohibitively expensive now. My big rationale was to provide a searchable history, in a easy to use manner, than http://docs.pact.io/slack. For searching, I use Linen https://www.linen.dev/s/pact-foundation which is hooked up to our Slack, and propogates all the messages in a nice Slack clone. it is now open source and self hostable https://github.com/Linen-dev/linen.dev You can get a desktop client, super cool built with Tauri and Rust note to self, update docs help page to tell people to search on linen Did anyone else have any other big rationale bar searchable history? Or would Linen suffice? I think GitHub will be the poster child for main discussions/longer tail stuff, but Slack is nice just for being where most people are (alot of works still use Slack) and its been our spiritual community home for ages (beyond the evolution of the google group)

Thanks for raising Yousaf. As per our discussion, I think you made some really good points about clarifying our needs: 1. Slack is great, because it?s a convenient instant messaging tool for many developers. The community I think really benefits from that engagement. The lack of history is the main downside a. we?ve never really taken advantage of other slack features (e.g. video calls, integrations) so paying the ~$50k USD /year fee for IM with history is just not comparable to the value received 2. Being able to have a searchable history (even if off platform) would help offset that, however we do need a way of making it really accessible and visible (otherwise the benefits are eroded) 3. We still have not got a great agreed place to make decisions a. Spec repo: https://github.com/pact-foundation/pact-specification/ b. Discussions: https://github.com/pact-foundation/devrel/discussions c. Canny: https://pact.canny.io/ d. Issues on various repositories e. and of course this channel I?ll transfer some of these to your discussion board and put some thoughts, because they do overlap in different ways

Hello. I?m not really here. I?ve been avoiding Slack due to stress for a few months now. But I have finally created a 1Password team account! https://pactfoundation.1password.com/

Please share your pact email address with me (preferably personal email, not work, because jobs change, but pact is forever :laughing:) so I can add you.

Please put anything in here that someone else might need if you got hit by a bus! Or, won a billion dollars and retired to an off-grid paradise, if you find thoughts of buses a bit gloomy.

We do only get 10 people on the plan, but hopefully that?s enough.

I have to put in a credit card, and it?s $20USD/month so I?ll be claiming the money back from our OSS money pot.

Can you pay yearly so you don?t have the upkeep overhead?

Looks like we?ll need to find another tool for maintainer catch up?.hold up!

:point_right: https://smartbear.zoom.us/j/93783752739

:point_right: this is the guitar piece I had to learn: https://www.youtube.com/watch?v=IiKokl48SjM :guitar:

I love it, powerful one :raised_hands:

Great to see you both today @tien.xuan.vo & @stan.amsellem - thank you for finding the time :star-struck:

Yeah, it is!

It was really fun to play, stress of performing aside :grimacing:

Gosh, that is beautiful to listen to!

It was great to be here, thanks again folks :pray: Looking forward to be moving forward together :rocket:

I must also add this guy makes it look easy :laughing:

Recording of today?s session: ? Recording: https://smartbear.zoom.us/rec/share/UW-gGvqgciRiugTDD0pFHfW3xQFsoZ8GSAIl4tTGVfiyRwURU-IkUPcNFc6gqn5X.CaR4ZZATDyh-cT7R ? Passcode: `uaeAh9*0`

oh yeah, I guess it?s easier if you write the composition - but he still muffles a bunch of the notes high up the fret board, there?s some tricky transitions and a lot of little detail that I didn?t notice (or perform) on the first go. The bridge is also very fidgety

but it?s a lovely piece, obviously, that?s why my sister in-laws chose it :laughing:

I've added some notes to the https://docs.google.com/document/d/1v_QWyYEl7rxR5hV0EQAcTFjBbiq5_uzn7_WMMYILRac/edit. Feel free to edit/change/add!

Sorry I missed you homies, was in the land of nod. Thanks for recording @matt.fellows. Sounds like a good time was had. Welcome @stan.amsellem and yay @tien.xuan.vo!

Thanks Beth for sorting this :happy-hearts:

That's probably fair enough when your usual bed time is when people are just getting out of bed

watching now

Yes, good idea @matt.fellows

Ok, selected annual. Once it?s charged, I?ll work out how to claim it back! What?s the name of the oss fund thing called?! I?ve forgotten it.

Open collective

has joined #maintainers

Hi @joshua.ellis this is the public channel for maintainers

has joined #maintainers

set up a reminder to ?REMINDER: maintainer catch up happening in 5 minutes :clock1:! ? in this channel at 8:55PM every Wednesday, Australian Eastern Standard Time.

FYI I won?t be able to make the maintainers catch up tonight folks

You just have no commitment to this project!

I'll accept my 50 lashings

I suggested Josh join next week btw

No worries, thanks for the update Matt :+1::skin-tone-2:

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

Join Zoom Meeting https://smartbear.zoom.us/j/5795695925 Meeting ID:

Here is the slides for my recent presentation about pact. https://slides.tienvx.in/pact/ (self-hosted on my homelab, so will not be 100% uptime) Here is the source code for the slide if you want to view it on local https://github.com/tienvx/slides

Busts out epic set set of slides :clap: Love these, really in depth and well considered

also @aliciajforeman might recognise the pyramid xD

super cool that it is being hosted on your homelab too.

Thank for sharing these slides @tien.xuan.vo :star2:

@matt.fellows i?ve made you an owner and administrator, so if I run away to Majorca, the bills can still be paid. @yousafn I?ve made you an administrator so you can add any other OSS maintainers who need to use it.

Fabulous, thanks Beth and enjoy the margaritas in the :sunny: I?ll get some doccos up about it on the site, in our maintainers section, somewhere. There?s lot of useful information and a mindmap for maintainers of where to go, and who to prod would be good. Leave it with me

For this week?s maintainer meeting, I?d like to propose the following https://docs.google.com/document/d/1v_QWyYEl7rxR5hV0EQAcTFjBbiq5_uzn7_WMMYILRac/edit: ? Meet and greet with @joshua.ellis ? Discuss issue triaging process: https://github.com/pact-foundation/devrel/discussions/15

ahh just when I was thinking I could join one, that's for tomorrow not today isn't it :smile:

yes. Maybe we should find a different day to suit others?

definitely open to options

Happy to find an option. Given the broad range of timezones, it might be worth rotating through different times?

Tue generally better for me, but I wouldn't suggest changing plans on my account :upside_down_face:

That would be fine by me also

And me

https://smartbear.zoom.us/j/92311657471 for the maintainer catch up

Thanks for the agenda Matt, see you all shortly

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

Recording: https://smartbear.zoom.us/rec/share/3DbN31-FcjETaNNeloZKYHFu3TLwwT8y4E-vQcxT7hkon-QLf31SD7rQDYwomBBk.0r95LUgQNE3AsLK_ Passcode: `AYxs!8+9`

(Will be published to YouTube also :point_right: https://youtu.be/GvyNd6Swi6w)

So this is a bit bizarre! https://github.com/pact-foundation/devrel/issues/26 I don?t even know a) why we would have this restriction b) why of all things, http://ae.com would be on there c) why this is suddenly enabled? (maybe those entries were in the list from yesteryear, and for some reason the switch has been toggled, either by a admin or by Slack behind the scenes)

Wtf! No, this is not something I've seen before. I could imagine why DiUS is there but http://ae.com makes no sense. Can we revert it so anybody can join and we can share an unexpirable link?

So we?ve got 6 members from http://ae.com in our Slack, one has asked a question in pact-jvm so I don?t think its any nefarious. So if you select 1. allow invitations a. it seems to lock anyone from joining 2. allow invitations with domain a. requires at least one domain b. will also allow apple/google signups maybe we can wildcard the email domain to anything?

So if you check out https://pact-foundation.slack.com/admin/invites there are two users who have invite links that never expire. Just tried one that worked for me (2nd from bottom in the list)

Here we go, this is a never expires link (which we can deactivate from the admin page) https://join.slack.com/t/pact-foundation/shared_invite/zt-23bi0zdz7-2sIA1omqUhz69MuD5yeZjw

would we just need to setup a redirect from http://slack.pact.io to that link :point_up_2:

Awesome, thanks for this Saf - I?ve just fixed it now

For reference, fixing this is an update to the `index.html` file that exists in the `http://slack.pact.io` bucket. It uses a simple client side redirect

(Just tested it with a new user - it works!)

FYI this is the new slack user experience - looks like the ?welcome? page that slack used to have is gone, and only the greet bot exists.

a fresh more focused slack, care for us to distract you for a bit, whilst you forget about why you came here in the first place

if you?ve just joined, you don?t know its new

so why do they tell you ffs

that makes me think, what was wrong with it before. Like new CIF with 100% more cleaning power. *empties entire cleaning cupboard into the bin crying because its all inferior*

_Oh, why did I buy it by the bucketload!_

Hey team, I?ll pass on the maintainers chat tonight. _Maybe_ :stuck_out_tongue:_. If I?m about I might pop my head in_

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

no worries homie

https://smartbear.zoom.us/j/96124075972 :point_up_2:

:blobwave: Would any of you like to give a short update on your libraries, whats new and what people can help with? I?m happy to present, and we can just have recorded snippets if you can?t attend on the day (10th Oct) https://pact.io/birthday Or just some bullet points of what it going on, and I?ll pull something together. I?d love to take the opportunity whilst we have a captive audience to help bring in willing hands to help you all out, so I would implore that you consider taking the opportunity at any time throughout the month, to share with the community. Much love, Saf

Yousaf, I saw this in the recent post. > I?ve been thinking about how we could potentially create an extendable mechanism, whereby users could provide their own provider schemes, for alternate sources, other than OpenAPI, such as AsyncAPI. Me too. For example, supporting Contract Case files and (as you would have seen) this sort of thing: https://datacontract.com/

Need to wrap my head around it a bit more, but one wonders if the Pact Broker (and the CLI tooling such as `can-i-deploy` could support these contracts with little to no change). We might need a data pipeline specific command to handle a longer lineage of data e.g. in the case of event sourced systems reprocessing old events, or data pipelines that need to handle multiple years of data evolutions (perhaps the `released` vs `deployed` semantics cover that scenario already)

I have been musing how pact and data could work together for ages. I think I need to prototype it. But essentially what is here touted as a data contract I think is a schema with examples. As data meshes and data products become a thing I think this will be a massive area

Data lineage and traceability is a huge emerging space, and with recent advances in AI, companies are recognising that they need to organise the data they have to make it parseable. One of the big recent announcements in this space was Microsoft's [Fabric](https://www.microsoft.com/en-us/microsoft-fabric), which (from what I can tell) is trying to provide an end-to-end offering covering the capabilities of data ingestion/processing (data factory), data warehousing (synapse) and data reporting (Power BI). There's a bit of a crowded OSS (and enterprise) collection of tools that help here, and it could be cool if Pact can help verify the glue between these tools.

I've not had a project to go deep enough into to apply any learnings, would love your input on how we could bring that adjacent use case to Pact ecosystem. It feels natural in many ways but that is obviously a nascent and naive perspective

Hey lovelies, just a reminder that the maintainers meeting is tomorrow instead of Wednesday, usual time.

I'll be there! Thanks for the reminder

set up a reminder to ?REMINDER: maintainer catch up happening in 5 minutes :clock1:! ? in this channel at 8:55PM every Tuesday, Australian Eastern Standard Time.

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

Do we have a Zoom link? Or are we using a huddle?

@joshua.ellis It's up in the pinned items ^

Whoops sorry I missed y'all

Morning soldier :wink:

:blobwave: Is it possible to get access to the Pact-Foundation Dockerhub? I?d like to pull out additional analytics https://docs.docker.com/trusted-content/insights-analytics/

Done!

danke danke

FYI - we are trying to pull together all the various sources of where packages are published, and possibly download values, across the Pact (and also Swagger/Cucumber) estates and provide that information to others

M1 Runners now available on GH Actions but pricey https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/ They are decent spec however

Hey everyone :blobwave: Do we have the maintainer catch up tonight? And could I confirm the time? We just switched to daylight saving, so I just want to double check.

Good question - I have it in my calendar for tomorrow and at 10pm local :stuck_out_tongue:

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

OK so it _is_ tomorrow

I?ve just spoken to Jo and Saf (another call), it looks like tomorrow at 10:30am BST / 8:30pm AEDT could work (to fit around some Pactober events)

man I hate it when the timezones change :cry-pig:

Ok, so tomorrow 8:30 pm Melbourne time :slightly_smiling_face: I'll see you all tomorrow (and I'll head to bed then)

> man I hate it when the timezones change Yes. But I _do_ like daylight savings :stuck_out_tongue:

I won?t make tonight folks, need to rest I think

No worries Matt, get good rest!

Hey hey I don?t have a zoom link in my cal, just checking online (my mac cal often doesn?t sync)

I miss this one. Can you invite me so I can see an event on my calendar?

Sorry @tien.xuan.vo we missed seeing you :disappointed: I have added you to the calendar invitation. Next week (Wednesday 11th) the meeting is from 10:15 BST for 45 minute duration. (I've updated the duration from 30 minutes to 45 minutes for now as we over run most weeks and there is a lot to talk about it seems!)

I saw the invitation. Thanks @jo.laing

You're welcome. Thank you so much for making the effort to join the Pactober celebrations this week. @yousafn and I have loved seeing you there :pray::skin-tone-2:

Sorry dude! Glad you have one now. Agreed, its been lovely to have you watching the events so far, really appreciate it when we are amongst friends

fyi I found the zoom link, its in the pinned items at the top of the channel

Awesome, somebody asked for this!

I found this just today, and I think its def worth while uploading

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

Lies! :stuck_out_tongue:

We discussed creating a page for all of this - we?ll do in the wash after this crazy week :stuck_out_tongue:

Just checking, is the maintainer meetup in an hour or so?

Yes, it's

I'm going to skip tonight folks, as I have a presentation I need to prep for at a conference tomorrow. One action would be to fix/update the maintainer meet reminder in the channel :joy:

I think it is at 10:15 for me (in 11 mins)

I will add the dates/times to the google calendar tomorrow and share the link here and in YouTube. Might have a go at setting the Slack Bot now. After looking at the times with Josh ad Tien in the meeting today we wanted to suggest alternating between 0900 UTC and 2100 UTC.

I forgot to press record on this weeks meeting Zoom :disappointed:

I was thinking, instead of a Google Calendar link, can we just export the event's `.ics`?

Hey @tien.xuan.vo - Got a load of the reviewed PR?s merged for you in Pact-PHP, and reviewed others and merged. Would you like to consider an alpha3 release soon? If so, I can help with that, or we can get you promoted so you can start merging your reviewed PR?s

After https://github.com/pact-foundation/pact-php/pull/335#issuecomment-1760766234, we can close that PR and I'm looking forward to alpha3

Docker has sent a threatening letter, which is odd because we?re on an OSS account. I?ll chase it up.

I was about to ask, thanks Beth. Just a small $300 USD bill :laughing:

I released version alpha3

Awesome nice stuff dude!

Hmm I saw those this weekend, quite roood pal

So they gave us a nice coupon so it was free last year, but it hasn?t been applied this year, assume it will be the same deal. Happy to chase up if you need to Beth

Reminder: REMINDER: maintainer catch up happening in 5 minutes :clock1:!

^^ lies!

deleted

They replied saying that we have to re-apply for our OSS status every year. So I?ll fill in their paperwork again, and remember to keep the answers for next year.

Was the meeting still on today? Or did I miss it with timezones/daylight saving changing?

Argh, I totally forgot also sorry (was out last night)

Argh!!! Found the rogue pact-support email address! Killed it with fire now.

REMINDER: maintainer catch up happening in 5 minutes :clock1:!

(ok 4 mins)

Nice to see you all - the progress is :amaze:

Hey team, I won't be able to make tonight's catch up sorry. Hope it goes well!

@jo.laing Joining the catch up as well?

:blobwave:

PHP downloads by version - you can grab it via an API https://packagist.org/packages/pact-foundation/pact-php/downloads.json ```10.0.0-alpha1 / 17 10.0.0-alpha2 / 607 10.0.0-alpha3 / 4``` You can also get all time ```{"total":698368,"monthly":25440,"daily":986}``` cc: @tien.xuan.vo

RE: Python ? docs:- https://pypistats.org/api/ ? stats:- https://pypistats.org/packages/pact-python

Hey team, We?ve created a calendar invite with dual time zone sessions, details below in screenshot. Created with https://ical.marudot.com/# Time zone sessions alternate weekly between ? 9am-9:45am UTC ? 9pm-9:45pm UTC Hope this helps!

should it be a repeated event? I imported it to Google Calendar and I can see it is a single time event.

Yes it should be - we'll get it sorted

thanks for letting us know

:clap: nice! Once we?re all happy it works, shall we put it up on https://github.com/pact-foundation/devrel/ and/or on the docs site somewhere?

https://github.com/pact-foundation/devrel/commit/77ec43518ce9d78041026ba6a02a946531dfec9a tick on the dev rel site, which uses the same/similar content to this section on the docs site https://docs.pact.io/contributing#pact---how-you-can-help so yes good to add there :)

ah, that?s better actually - thanks!

https://pact-foundation.slack.com/archives/C9UN99H24/p1699260669272269?thread_ts=1699260669.272269&cid=C9UN99H24 Interesting feedback for our triage Yousaf! Also, thanks for holding the fort in my absence. You?re an answering machine my friend :pray:

Got an updated invite that now includes a recurring rule `RRULE:FREQ=WEEKLY;INTERVAL=2;BYDAY=WE` The only issue is, Outlook calendars don?t support the repeat aspect. When I imported it into my google cal, it works perfectly

Reminder that our community meeting will be on an Aussie friendly time zone today. If you are GMT based, it will be at 9pm. That should be 9am for our AEDT folks. Hopefully see some of you there! And don?t worry about pinging me if I?m not, I might be doing zoomies on the sim rig

Updated the cal invite https://github.com/pact-foundation/devrel/commit/43ce8b66fb07ae7b037c6386cb057e6311776df7

I miss you, google

Bazel + Pact :chefkiss: https://github.com/pact-foundation/docs.pact.io/pull/297#issue-1984236438

Be there in a few minutes folks...

it looks to have worked for me? The zoom link doesn?t show in outlook, but the location shows up as a link to slack, which should then have the right pointers to zoom etc.

:mega: Reminder that our community meeting will be on an European/EDT friendly time zone tomorrow, Wednesday 15th. If you are *GMT* based, it will be at *9am*. That should be *8pm* for our *AEDT* friends.

The labels on the Pact-JVM issues keep getting removed. I assume this is some automation you have added?

Can you exclude Pact-JVM and Rust repos from that?

Do they keep getting removed, or were they just removed on July 12? The automation was modified recently to be opt-in

I can?t link to the thread where I stuffed this up because history, but, sorry about that!

I've added some back (most of the old issues are now un-labeled), but I'm assuming they will stay back then

yep they should

I'll try to attend tonight but will definitely be late if I make it (putting kids to bed)

FYI created a new devrel discussion for how we look at telemetry going forward: https://github.com/pact-foundation/devrel/discussions/28

Has anybody come across https://reproducible-builds.org/ before?

Negative, but this came on my radar re: HomeBrew v recently which is tangentially related https://blog.trailofbits.com/2023/11/06/adding-build-provenance-to-homebrew/

Oh, interesting -> https://slsa.dev/

:mega: Reminder that our community meeting will be on an Aussie friendly time zone today. If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks.

I might be a little late as I'm hopping on a train around that time

:mega: Reminder that our community meeting will be on an UK friendly time zone tomorrow (Wednesday 29) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks.

Trying to join. My home internet decided to drop out though :grimacing:

Hullo all! Just been trying to add Polly to Slack, but we?ve hit out limit on integrations, I?ve cleaned out some ones added by the community that we don?t use, and there is one straggler called Lucid for LucidChart and LucidSpark. It?s not possibly to remove it directly via Slack, so I?ve emailed Slack support to see if they can :+1:

:mega: Reminder that our community meeting will be on an Aussie friendly time zone today. If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks.

So it transpires we do have 10 integrations. 9 apps, and 1 custom webhook integration, which means 10 in total. Lucid seems to have disappeared from the list now, but wasn?t actually added before (as it would have taken us over the limit, so must have been a UI issue)

:blobwave: Hello fellow Maintainerati! Just to let you know I will be on holiday at the end of today, returning back on the 5th January, I?ll be trying to stay away from the computer but will check in periodically so still here if you need me. Have a fantastic holidays when you do get the chance to finish up for the season. Thanks for everything you?ve worked on this year, we are grateful to have you all as part of the team.

:heart: https://github.com/pact-foundation/pact-php/issues/377

:mega: Reminder that our community meeting will be on an UK friendly time zone today (Wednesday 13) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks.

I have a clash tomorrow morning, so won?t be able to make it for the Australia-friendly timezone (8am AEDT). Merry Xmas to all of you amazing contributors, thank you for all of your help and support in 2023 and can?t wait to see what 2024 brings! :heart:

:wave: Hi all, Merry New Year! :fireworks: Hope you all got a chance to celebrate and relax with loved ones. I?m taking a pass through any unread slack messages/github notifications, but if I?ve missed anything important please DM or `@` me in the right place and I?ll follow up

thanks Matt, happy Christmas and new year all. glad to be back in the fold

Looks like our monthly compute limit was exceeded. Will need to find a solution, as its blocking a Pact JS Core release :thread:

If I understand correctly, there are two paths we can take for (at least Mac M1and Linux ARM support): 1. Use their runners and add credits (minimum $20 USD per credit purchase) 2. BYO infrastructure (e.g. AWS) I?m confident I could get SmartBear to pay for either, probably, but definitely the AWS account. It would need to be made a child account of another SmartBear, but just for billing purposes. We?ll retain admin permissions

I recall Yousaf did some numbers a while back, but that will be lost to slack history (probably, as I think it was before we made a public maintainers channel)

I?d like to support them (Cirrus) if I can, and buying credits isn?t that expensive. I think we could double our usage for about $20 USD a month. It?s hard to know if we?d go much over that, because usage has been capped since they introduced limits:

Hey chap, Oh noes. I found the thread https://www.linen.dev/s/pact-foundation/t/13592341/aww-sad-news-about-cirrus-ci-and-free-runner-use-https-cirru hmmm so that would be $117 for Mac credits + $15 for Linux = $132 /mth Cirrus pricing https://cirrus-ci.org/pricing/#compute-credits 1000m = 15 credits = $15 66.66667m = 1 credit = $1 1m = 0.015 credits = $0.015 GitHub pricing https://github.blog/2023-10-02-introducing-the-new-apple-silicon-powered-m1-macos-larger-runner-for-github-actions/ MacOS M1 is $0.12 a minute for large, $0.16 for XL on GH These are 3/4 vcpus, whereas Cirrus costs are per vcpu GH looks to be, by my naive calculations cheaper, plus is higher aligned with our other workflows, only thing we would miss out on would be arm64 linux but we would probably be able to get away with arm linux under our free tier on cirrus

fyi, I?ve built the prebuilds for arm64 versions on my laptop and added them to the draft release, and kicked off the failing release check, so that will get us out of a bind for the mo

Thanks for doing that dude, that?s great.

What about running our own hosted runners for Github on e.g. Amazon Mac and linux ARM agents?

Is another option reducing what gets built on those runners to purely master builds/release only?

(that might already be the case, btw)

> Is another option reducing what gets built on those runners to purely master builds/release only? limiting builds is prudent, I was a bit fast and loose whilst there was no limits. > What about running our own hosted runners for Github on e.g. Amazon Mac and linux ARM agents? Yeah that isn?t a bad shout, the gh images are available (they use Packer) so we can make sure they have near enough the same stuff on them. We can limit their use as well to keep costs down

Is the pricing with GitHub per user though? I seem to recall that was the reason we couldn?t do that in the past

Pretty sure GitHub is per minute of use of each worker. Also regarding the `aarch64` Linux builds, I get around that for Pact Python by using `qemu` virtualisation and a `aarch64` Docker image. It is _slow_, but at least it works. This would ensure that everything basically runs the same.

See https://github.com/pact-foundation/pact-python/blob/53518e6f8442bbd9f467799a5e903887657f0ae8/.github/workflows/build.yml#L90-L130

:mega: Reminder that our community meeting will be on an UK friendly time zone today (Wednesday 24 JAN 2024) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks.

Couple of workshop updates for Java https://github.com/pact-foundation/pact-workshop-jvm-spring/pull/24 https://github.com/pact-foundation/pact-workshop-Maven-Springboot-JUnit5/pull/4 Along with https://github.com/pact-foundation/pact-workshop-go/pull/9 need to roll out all the changes to the README?s and steps

Thanks Jo! Unfortunately I have a meeting clash tonight, I?ll jump in if it finishes early.

No worries!

Started on a Python workshop https://github.com/YOU54F/pact-workshop-python Couple of snags that stop it being as aligned with the other workshops 1. no request filters in python, can use custom provider header, but I can?t see a way of validating that the header is present before adding the customer provider header, so it can be used say per request (for an authenticated state) and not for unauthed states a. workaround - use custom provider header b. caveat - header injected, may not exist in client pact 2. no ability to verify pact by URL, can retrieve from broker by consumer version selectors, or directly from URL a. workaround - use docker based verifier Both are feature reqs against the project, already open.

:mega: Reminder that our community meeting will be on an Aussie friendly time zone today. If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks.

see you there!

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

> Today, GitHub is excited to announce the launch of a new M1 macOS runner! This runner is available for all plans, free in public repositories, and eligible to consume included free plan minutes in private repositories. The new runner executes Actions workflows with a 3 vCPU, 7 GB RAM, and 14 GB of storage VM, which provides the latest Mac hardware Actions has to offer. The new runner operates exclusively on macOS 14 and to use it, simply update the `runs-on` key in your YAML workflow file to `macos-14`.

I got this email on the 20th RE: Docker sponsored open source subscription. I know @bethskurrie was chasing it up before. Does anyone have updates, or would you like me to pick up the mantle and chase them up? On a Docker related note, is there any reservation about publishing images to GitHub?s container registry ( as well as DockerHub)? We got an ask about getting AWS ECR verified, but it appears that GHCR should solve most peoples ails with dockerhub rate limits https://github.com/pact-foundation/pact-stub-server/issues/61

Perks of being an open source maintainer - Free co-pilot. https://github.com/github-copilot/free_signup

Great idea! I think Beth was following it up, but hasn?t been in slack for a bit. I?ll schedule a message for her morning

ty dude, no rush on this, I?m _not_ sure of the impact but I don?t think it?s major, probably lose the insights tab

Might be throttled too?

https://docs.docker.com/trusted-content/dsos-program/ not sure if by developers if means users of the image, or creators of the image

We only really leverage the _removal of rate limiting for developers_ I would say. Publishing to ghcr should be fairly trivial, so a nice alternative motion we can do whilst we wait for Docker

:mega: Reminder that our community meeting will be on a UK friendly time zone tomorrow (Wednesday 07 Feb 2024) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

I won?t be able to make that sorry folks, I have a suit fitting for an upcoming wedding :baby_penguin:

Sorry, I won't be able to attend either.

no worries gents. Matt good luck with the fitting, I?m sure you will look properly dappa

will be joining in 5 minutes ty

Got Alpine and Pact-JS playing ball last night, after the new release of pact 0.4.15 with musl based variants. What is really bizarre though, is I initially linked it to the `.a` file, and we get a `musl` prebuild. I assumed it was linked to the `.a` file, but actually it is quite happy with the `.so` file which is non-musl, as long as it has a `musl` based prebuilt node file. :head-splode:

Interesting. I'm wondering if the archive is embedded in the node file

that is plausible ```du -sh js/prebuilds/linux-arm64/node.napi.musl.node 46M js/prebuilds/linux-arm64/node.napi.musl.node```

prebuilds are here that contain the musl flavoured node prebuild https://github.com/YOU54F/pact-js-core/releases/tag/v15.0.0 you can unpack the archive into the root of a js project, or anywhere and set the `PACT_PREBUILD_LOCATION` to use it with a released version of pact-js

Yeah, `.a` files don?t get linked at runtime, they are compiled into (statically linked) the artifact itself

You can test it working by removing the .so file in your musl tests. If there is no dynamic library on the system and it works, you know the `.node` file has everything it needs

Yep it is embedded and it?s all you need :raised_hands:, managed to build the mock and stub server, verifier, plugin cli, and protobuf plugin linked against musl, and get a pact js grpc test working in Alpine For the vanilla tests in pact-js-core tested against alpine 3.13 -> 3.19, and from node 14 -> 20 (despite our node engines locking at 16 - 14 throws a warning) plugin driver and cli need updating to detect musl and try and install those variants. interesting wee meander

Awesome work sir!

Managed to get it rocking in pact-go, pact-php and ruby, woop woop

fyi tracking progress here https://github.com/pact-foundation/devrel/issues/30

:mega: Reminder that our community meeting will be on an Aussie friendly time zone today. If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks.

I am unlikely to make it tomorrow as my wife has been called in to work (she?s back teaching as a relief teacher) and I have to do kids morning/school drop off routine etc. Josh is also moving homes, so might be a quiet one

no worries homies, that is totaly fine. cheers for the heads up. have a good day with the kids and Josh best of luck with house move!

Yeah, got the reminder... And I won't be able to make it :sweat_smile: Currently have a half empty apartment and a half full truck

so last night i decided to see how much effort it would to create a musl based traveling-ruby implementation, as I?d gained some decent knowledge of the build system after updating it to OpenSSL 3.2.0 it?s aliiiiiive https://github.com/YOU54F/traveling-ruby/releases/tag/rel-20240215 actions run with pact ruby standalone https://github.com/YOU54F/pact-ruby-standalone/actions/runs/7915718214

You?ve managed to resurrect Ruby from it?s demise. The question is, will this just be putting it on life support or should we put it out of its misery :stuck_out_tongue:

Next you?ll be working out how to compile it into a binary so it doesn?t need the Ruby runtime!

well.. ahem https://github.com/natalie-lang/natalie it has crossed my mind :sweat_smile: in all honesty, I?m just liking the consistency, of being able to support musl based distros with both the ffi and ruby considering we still use it for the cli it means getting rid of our alpine guidance page might be a full on reality

:mega: Reminder that our community meeting will be on a UK friendly time zone tomorrow (Wednesday 21 Feb 2024) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

@joshua.ellis this was the req for python 3.12 support release https://github.com/pact-foundation/pact-python/pull/422#issuecomment-1935874000

thank you lovelies

always great to you all!

Hey all, I noticed this evening when reviewing the https://github.com/pact-foundation/pact-net/issues/492 that we don?t actually have a feature in our compatibility suite for Pact Plugins (see https://github.com/pact-foundation/pact-compatibility-suite/issues/7). @tien.xuan.vo I know you?re working through the Pact PHP work here, so just wanted to give you the heads up. We should add those tests. At this stage, we can take that work on toward the end of the Python compatibility suite work that @joshua.ellis is currently working on, but if you get to it before and want to pick it up just let us know

Didn't seem much value in adding it. It would be 2 scenarios. `When using a plugin` and `when the plugin is not there`

I thought it may have been something like that. I think it could be valuable for FFI implementations, because it will test the additional methods that need to be implemented and that would translate to a support table in the future (one of the side effects of doing this is to get an accurate and up-to-date feature matrix across clients). Would appreciate Josh?s/Tien?s view on it though.

I haven't gotten to implementing plugins yet through the FFI in Pact Python, so I can't say I'm fully across what's part of the FFI at this stage. For now, I've noticed that there's a `interaction_content` which "sets the interaction part using a plugin", but I have not yet really used that. It might be better if we had a chat so I can understand the context better. In any case, regarding having plugins being tested as part of the compatibility suite, I think this is a must. The compatibility suite should, ideally, test the whole range of uses for Pact.

Sure, we can discuss when you get to that bit if you like?

I implemented csv and protobuf/grpc in pact-php. I'm okay with adding those scenarios to compatibility suites. I assume we need to re-use csv plugin in the scenario `When using a plugin` , or we can create a new `dummy` plugin that do something different so we can compare with the result of the scenario `when the plugin is not there` ?

Just in case it?s not clear - it?s not envisaged that every project needs to have examples of every plugin in use (or tests for them). Simply, we want to make sure that plugins can be used in all of the places they should (HTTP, async, sync interactions [consumer/provider side] + that we support plugins in content types and transports)

> I implemented csv and protobuf/grpc in pact-php. I?m okay with adding those scenarios to compatibility suites. I assume we need to re-use csv plugin in the scenario `When using a plugin` , or we can create a new `dummy` plugin that do something different so we can compare with the result of the scenario `when the plugin is not there` ? using gRPC via the protobuf plugin is probably a good choice for the test, because it is both a transport _and_ content-matcher, and it?s something we created and can rely upon

Awesome work with all of those RFCs and PRs over the weekend @yousafn, looks like we have a few things to review next week!

Hey @matt.fellows and @yousafn the latest FFI build failed on MacOS.

There are these two lines in the build script: ```export SDKROOT=$(xcrun -sdk macosx11.1 --show-sdk-path) export MACOSX_DEPLOYMENT_TARGET=$(xcrun -sdk macosx11.1 --show-sdk-platform-version)```

We need to understand why there is a need to target the SDK like this (what is this doing to the generated dynlib) and also why it is failing

was that me? I?d need to go back to check why we did that. Hopefully there is an issue. I assume it?s _not_ related to the install_name shenanigans. Perhaps it was an attempt to build on an older version so that it would be forward compatible?

Looking at the history, might have been an M1 thing: https://github.com/pact-foundation/pact-reference/blame/28eb5c2e0c4b905490a92487fdc925f14e6eb145/rust/pact_ffi/release-osx.sh

im not sure why we need the sdkroot env var but you can fix it with this action https://github.com/maxim-lobanov/setup-xcode and set to xcode 12.4 https://github.com/pact-foundation/pact-reference/commit/2e02838e9f1196f03e6e6ed38e40d45bfa6ddc6d macos gha github runners should have that xcode version installed but its not linking. i think the only thing that matters there is setting the maosx deployment target to the oldest version you can support

tested to resolve on my fork. btw

> need to understand why there is a need to target the SDK like this (what is this doing to the generated dynlib) and also why it is failing it allows newer versions of xcode to generate binaries which can be used by older versions of macos.

woop woop green build :green_heart:

Thanks!

pact-cli is now published to GitHub container registry https://github.com/pact-foundation/pact-ruby-cli/pkgs/container/pact-cli the org name is `pact-foundation` ( as per gh) where our docker org is `pactfoundation` They are multi-manifest images and you can pull them like `docker pull http://ghcr.io/pact-foundation/pact-cli:latest` pact-broker-docker's next release run will publish multi manifest images without the `-multi` suffix, and also publish to http://ghcr.io HOWEVER... There was an error in the latest release run due to an audit issue with Rack, however the update gem workflow failed integration tests https://github.com/pact-foundation/pact-broker-docker/actions/runs/8043208816/job/21964933527#step:10:605 I can reproduce it locally, but isn't showing up in the other test runs, which run the same integration tests :head-splode: cookie trail in this PR to update rack https://github.com/pact-foundation/pact-broker-docker/pull/173 TL;DR - we should probably revert https://github.com/pact-foundation/pact-broker-docker/pull/170 until we iron out that bug

Could it be worth finding the oldest SDK version dynamically on the runner by inspecting the contents of the `/Library/Developer/CommandLineTools/SDKs/` directory? E.g., something like: ```find /Library/Developer/CommandLineTools/SDKs/ -type d -maxdepth 1 | sort -V | tail -n+2 | head -n1``` or perhaps ```find /Library/Developer/CommandLineTools/SDKs/ -type d -maxdepth 1 -path '*.sdk' | sort -V | head -n1```

:mega: Reminder that our community meeting will be on an Aussie friendly time zone today. If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks :pactflow-platypus-slack:

Yousaf is on his way to London to present at the Women Who Go London event this evening :raised_hands::skin-tone-2: The event starts at 18:00 and Saf is due to present at 20:00 so I very much doubt he will be joining the community call this week.

I've prepped an agenda for you :wink:

:mega: Reminder that our community meeting will be on a UK friendly time zone today (Wednesday 06 March 2024) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

I cant join today

:mega: Reminder that our community meeting will be on an Aussie friendly time zone tomorrow (Wednesday 13 March 2024) If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks :pactflow-platypus-slack:

I've created the agenda for you.

:mega: Reminder that our community meeting will be on a UK friendly time zone tomorrow (Wednesday 20 March 2024) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

I'll join this but might be a bit late (putting kids to bed)

:mega: Reminder that our community meeting will be on an Aussie friendly time zone tomorrow (Wednesday 27 March 2024) If you are GMT based, it will be at 21:00. That should be 08:00 for our AEDT folks :pactflow-platypus-slack:

@matt.fellows @yousafn I'm thinking of pulling the mock server crates out of the current repo into it's own repo. The reason is I want to start a redesign/rewrite for a V2 version, and it is easier to support multiple versions with branches if it is not in a mono-repo. We currently have `pact-mock_service` repo which is the old Ruby version, so creating a `pact-mock-server` repo will be confusing (but not to me). So need to start with a repo name.

Can probably do the same with the verifier crates at some point.

I guess the main question for me is how often we make simultaneous releases, because simultaneous releases from a monorepo is a lot more straightforward. Having not worked on these crates, I don't really have an opinion either way.

The mock server crates have hardly changed in the last few years, and are released independently from the other crates

I don't have an opinion on the splitting. I wonder how we expedite the decommissioning of the Ruby libraries so we don't need to support both (to your point about confusion of naming) @yousafn has been playing with that, but perhaps we should raise it to the level of an official project to be completed

I?m on board. would be want to split out the verifier as well? naming wise okay keeping it as is as we can use guidance to support what the user should be user and clearly mark in the readmes, spec support and status. so for each ruby lib point to its rust replacement does it make sense to make pact-reference - pact-core or split into seperate repos per crate. not sure how much value the examples ( python, js ) add anymore, with those languages being fleshed out now. on the expedition of the decomissioning of the ruby libs, ive looked at a few options and pathways 1. create a top level pact tools doc page rather than landing on the cli tools overview https://docs.pact.io/implementation_guides/cli 2. on the docs page show tools ( cli / available lang impls) 3. for each cli, show links to current ( rust ) and legacy (ruby) 4. for each legacy cli provide a migration path to rust cli 5. implement pact broker client functionality in rust, I?ve been making a start on this whilst learning rust after hitting a point of diminishing returns in the land of ruby packaging. https://github.com/YOU54F/hello_cli - warning code may make rustaceans cry 1-4 should help users navigate the current landscape and provide more context to the available tooling, which we don?t have currently 5 should mean that to all intents and purposes we can stop talking about ruby as anything other than heritage with exception to the pact broker, and support ruby language end users in implementing a ruby client dsl over the ffi. I?ve got some samples in place in https://github.com/YOU54F/pact-ruby-ffi as a bit of an aside, but maybe a good opportunity. It appears that cargo fmt and my editor want to fight against the current code, and I feel like this might be an impediment to contributions. How would you feel about taking the commit history hit and adding in a linting step. oh and with regards to the cli, i took an opinionated move to roll all the existing cli crates into one project, so it just built one executable. This saves on disk space and makes it easier just to have all of Pact in one place, which for me, makes the story of Pact just easier to tell in general. The entry point could be the cli rather than reams of documentation up front. thoughts on a postcard? its nothing that can?t be undone and its been a good learning exercise on personal time. I?d love a cli where users could easily extend themselves, the gh cli is a create example of where users can register subcommands and the really nice thing about their impl, is users don?t have to code in golang, it could be a shell script, or a binary from any lang. If we wanted to increase user exposure to rust, cli?s seem like a nice way to dip your toe in. I?d love to explore how users could extend the rust cli, by either integrating into their own cli tool written in rust ( maybe clap builder is exported from each crate and can be integrated into a users cli, or they can easily add in their own crate for a subcommand ) sorry brain dumping again haha

can we normalise hyphens and underscores between the rust projects, we have pact-stub-server and pact_mock_server_cli can we do one or the other across the rust projects.

can we also give some thought to guidance for contributors on how to setup a workspace for building the whole meta project if they need to make a change in pact_models, and they want to pull it through into one of the other crates. One would imagine most of the external contribs are going to come from users leveraging pact through the ffi and would want to test it e2e in the respective client lang it might be clone x repos, setup x workspace, link to crates via path etc. I would have liked something like that to have bootstrapped the ruby projects as they are split into i think 6 gems

> I wonder how we expedite the decommissioning of the Ruby libraries so we don't need to support both (to your point about confusion of naming) better guidance in the repo and docs site would go far > @yousafn has been playing with that, but perhaps we should raise it to the level of an official project to be completed with the pact broker client being the only critical func left in ruby, fully stable and currently on the latest stable ruby version, I?m a little less concerned about needing to deprecate this asap. what i would like to investigate, is porting the func over to rust, with also consideration to the availability of it through client language wrappers, so the ffi basically, to allow users who?ve lost that native lang wrapper over the pact broker client, as we moved to rust ffi unless we also package ruby alongside which many projects seeked to drop completely. do we want to do that, or is just using the cli a better way forward? if its via the ffi as well, then existing rust ffi users can leverage from the same shared lib. was the maint effort of these wrappers such a burden that this is a futile endeavour. I think that could be somewhat overcome by a couple of approaches ? ffi interface generators, I?ve played with a few, and create a fair few from knowledge of what an implemented interface looks like and working backwards to template it ? having args as json object with ffi func taking a single param. the json message could be tested with pact to give cli/ffi authors feedback on who is using what and the impact of removing/adding a new field. okay so maybe after writing that we probably do want to have a separate topic/project listed somewhere about the decommissioning of the pact broker client looks like. :sweat_smile:

Unfortunately Matt and I can't make it this morning due to a clash

If anyway wants to jump on to the call, just give me a nudge and I'll jump on. I think a few of our Aus friends have another engagement so can't make it

No worries dude!

:mega: Reminder that our community meeting will be on a UK friendly time zone tomorrow (Wednesday 03 April 2024) If you are GMT based, it will be at 09:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

Sorry folks, starting in 20 mins at 10:00 UK time.

@yousafn Would you be able to add some notes to the minutes from meeting today re the discussions around PHP with Tien please?

tien linked to a post where i?ve already pretty much said what I said today, will pull out the link and pop it in

Thanks buddy!

Can I ask why spec v1 & v1.1 are rarely mentioned in many document, e.g. https://docs.pact.io/getting_started/specification#client-language-support ?

I remember I read somewhere that they are only available before Pact is open source (DiUS). But I can't find that information again.

I?d say it?s because they are the first two versions of the spec, and for all intents and purposes are irrelevant (i.e. they haven?t been actively used by anyone for probably a decade). Version 2 is really the minimum we?d expect anyone to be using today

But that?s not a good reason to have them documented

Here is related the conversation in the Pact-PHP's pull request https://github.com/pact-foundation/pact-php/pull/547#discussion_r1549990995

:alarm_clock: *Please note the times for this meeting have changed due to clocks changing in UK and Australia. Melbourne are +9 hours ahead of UK* :alarm_clock: :mega: Reminder that our community meeting will be on an Aussie friendly time zone tomorrow (Wednesday 10 April 2024) If you are *GMT* based, it will be at *22:00*. That should be *07:00* for our *AEDT* folks :pactflow-platypus-slack:

Sorry folks I won't make tomorrow's meeting. Just got home now from a concert

FYI I?m unlikely to be able to make tonight?s community meeting also, 7pm is smack bang in the middle of kids dinner/bed routine. If others are OK, we could push it back and hour the next one?

Happy to push it back, I'm pretty flexible though. Are we wanting to push back the meeting tonight too? @jo.laing @tien.xuan.vo @yousafn would that work for you?

thanks Josh. It might be a bit too late notice to ask others, but I?ll pop back here at 8pm to check-in just in case

today meeting is 1 hour later than usual? I am ok with it

Shit, I?m actually doing the kids bed routine tonight. I might even be a few minutes late for tonight (I have a recurring Tuesday meeting with Jo/Yousaf, so that night I get my wife to do it :laughing: ). I?ll hopefully get them down early!

OK - so see you in just over 1 hour?

:mega: Our community meeting is on a UK friendly time zone today (Wednesday 17 April 2024) If you are GMT based, we're meeting at 11:00 today. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

@joshua.ellis to add GA to your blog, you can add the following snippet: ```<!-- Google tag (gtag.js) --> <script async src="https://www.googletagmanager.com/gtag/js?id=G-68LZ66H7R0"></script> <script> window.dataLayer = window.dataLayer || []; function gtag(){dataLayer.push(arguments);} gtag('js', new Date()); gtag('config', 'G-68LZ66H7R0'); </script>``` I?ll set you up with access to the property shortly also. If anybody else would like access, please let me know

FYI: That funding model where it automatically allocates funds to dependencies and their dependencies is https://www.stackaid.us/

At least, I think that's what it was. I'll need to double check the podcast I heard it from

huh, interesting. In theory it?s a great idea, in practice? do we really need to be giving Microsoft and Facebook more money :thinking_face:

Yeah, I thought there was a way of tweaking which dependencies you want to give funds to

There is probably a way to exclude certain dependencies/orgs

yeah, that makes sense

maybe it was https://thanks.dev/home ?

Thinking it through, if this model wins, I wonder how it would change behaviour of open source tool writers - would you be inclined to depend on less dependencies so you get more of the share? :thinking_face:

Interesting to think about (I?m sure many of these companies have). Great to see so many of these cropping up - I?d heard of neither of these previously

I was directly approached by one of the founders of this previously: https://www.paydevs.com/

sorry i missed you lovelies hope you had nice catch up. holla if you need anything. i did get a pact php workshop beginnings sorted but got stuck on state handlers and modifying my instantiated product repo. i?ll push the code up later today. i?ve got one a partial one for python v2 https://github.com/YOU54F/pact-workshop-python

No worries mate - hope all is well!

FYI I briefly mentioned strategy/roadmap on the maintainer call last night. I see that AsyncAPI have updated their https://www.asyncapi.com/roadmap. I like how open they are about these things, and would love to get feedback from this group on something like that for our community

i like that alot!

The slack inviter looks to have stopped again

(I?ve fixed it)

I tried using the various inviter solutions, but they all rely on legacy API tokens which we no longer have. Admin APIs are only available to enterprise customers. So we?re stuck with this for now

Can we configure a quarterly cron job over on GitHub to renew this automatically?

So, https://slack.pact.io/ is actually an HTML page in our OSS amazon account

It?s a nice shortcut and is littered everywhere, so ideally we can keep that. It currently simply redirects to an invite URL.

But in general, automating it makes sense. Unfortunately, the invite API is an API _only_ available to enterprise users. You need to manually create an invite link like this:

?which creates a link like this: https://join.slack.com/t/pact-foundation/shared_invite/zt-2h7ovnj5x-VD82RSfK68jseNXTQ_KTdA If you curl http://slack.pact.io, it?s the same URL. Once it expires, it creates a new one.

There?s probably a way to reverse engineer that URL and detect once it changes, which is when you could apply the update

Any thoughts?

If Slack implemented that share functionality nicely, there might be a nice overlap period, so we may never need to detect when it changes, and instead just have a weekly (or so) cron job that updates that redirect page

assuming there can be two concurrent share links that are valid

yes, but not from the same user it _seems_ (so we could alternate). I managed to get the network (via enabling developer settings and usinsg the chrome dev tools): ```curl 'https://pact-foundation.slack.com/api/users.sharedInvites.list?_x_id=5c288879-1713761600.107&_x_csid=GsiLVTc50vo&slack_route=T5F60FXSQ&_x_version_ts=1713740845&_x_frontend_build_type=current&_x_desktop_ia=4&_x_gantry=true&fp=0c' \ -H 'authority: pact-foundation.slack.com' \ -H 'accept: */*' \ -H 'accept-language: en-GB' \ -H 'content-type: multipart/form-data; boundary=----WebKitFormBoundarycJNsxcGAVeyxgwjH' \ -H 'cookie: b=.f545c729a8a9b2e3b0faf295182ddd53; ssb_instance_id=3798c14f-b087-434e-b267-14574690f95a; tz=600; web_cache_last_updated343081cc5653590830c3818f6821f2c2=1713396725114; web_cache_last_updated2c46ce20eb394510ce2a5c7beb691b8b=1713402759113; web_cache_last_updatedac29e4dd4cb4a029722e4ffc39224b31=1713751646611; web_cache_last_updated08de5c8e01d4e938aa21c2b2ad354a22=1713755599586; d=xoxd-dlXpa2t6nps%2FouorucQSLH8WhMVCEuFnCCiFjuph7To%2BqWk9vZbkkDouvjgE%2BjcLG%2F%2B%2BMp6lUccmEJPBYq1DDn0J7V0W3uS90W1RN7KXMXu9X5fk6FsqPIR9SQr2d57nilCVen097Pumdb1Xrz5Oam1oSWH6Df5R6PVYQ7oedLWCyS%2FweMA1HC7fBjTBLLpAgV89k3lztA%3D%3D; d-s=1713761501; x=f545c729a8a9b2e3b0faf295182ddd53.1713761502' \ -H 'origin: https://app.slack.com' \ -H 'sec-ch-ua: "Not(A:Brand";v="24", "Chromium";v="122"' \ -H 'sec-ch-ua-mobile: ?0' \ -H 'sec-ch-ua-platform: "macOS"' \ -H 'sec-fetch-dest: empty' \ -H 'sec-fetch-mode: cors' \ -H 'sec-fetch-site: same-site' \ -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 14_4_1) AppleWebKit/537.36 (KHTML, like Gecko) Slack/4.37.94 Chrome/122.0.6261.129 Electron/29.1.4 Safari/537.36 AppleSilicon Sonic Slack_SSB/4.37.94' \ --data-raw $'------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="token"\r\n\r\nREDACTED\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="mode"\r\n\r\nlast_active_for_user\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="team_id"\r\n\r\nT5F60FXSQ\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="_x_reason"\r\n\r\nlist_shared_invites\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="_x_mode"\r\n\r\nonline\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="_x_sonic"\r\n\r\ntrue\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH\r\nContent-Disposition: form-data; name="_x_app_name"\r\n\r\nclient\r\n------WebKitFormBoundarycJNsxcGAVeyxgwjH--\r\n'``` The output is: ```{ "ok": true, "invites": [ { "inviter_id": "U9UUY3CU9", "date_create": 1713564109, "date_delete": 0, "date_expire": 33249761012, "code": "zt-2h7ovnj5x-VD82RSfK68jseNXTQ_KTdA", "url": "https://join.slack.com/t/pact-foundation/shared_invite/zt-2h7ovnj5x-VD82RSfK68jseNXTQ_KTdA", "max_signups": 400, "num_signups": 0, "notifications_enabled": false } ] }``` So what?s nice about that, is you get the `num_signups` and `max_signups`. So I _think_ that could be taken advantage of to get a new URL.

I can?t find `users.sharedInvites.list` as an API on the slack docs, so I wonder if it?s an internal-only API

Looks like the JVM docs sync is broken: https://github.com/pact-foundation/pact-jvm/issues/1786

Nothing has changed there in 4 years, but it looks like the `{"event_type": "pact-jvm-docs-updated"}` is not doing anything

I've manually run the sync in the docs repo

Has the credential expired?

i bet it will be the creds, the sync job is green when it has invalid creds :facepalm:

yep https://github.com/pact-foundation/pact-jvm/actions/runs/8732358703/job/23959227530#step:2:1 we should update to use an org level set token to avoid having to update at each repo level

updated now, We do have an org level one set `GHTOKENFORTRIGGERINGPACTDOCSUPDATE` Just needed updating to allow pact-jvm repo to access it

so in true yak shaving style turns out pact-go docs weren?t syncing either, so that has been restored. Then images from pact-js and pact-jvm were not displaying on the site, so fixed that up too. pact-js release is sorted and pact-go ci pipeline is green again :green_heart: have an awesome day people

Thank you!

:mega: There will be no community meeting this week. See you next Wednesday instead (01 May) on the UK friendly time of 11:00, which is 20:00 for our AEDT folks :pactflow-platypus-slack:

I deffo raced there at 10:20 like where is everyboddddy and then saw this message :sweat_smile:

What specification do you think should be default when user didn't specify?

Probably v3 now given the major languages can stop still pretty verifying them now

V2 safe option

V2? Isn't it quite old now? How about V4?

V2 has the widest support, all implementations I'm aware of support it. You're right though in that the 5 major top languages would be able to verify V4 so it's safe enough

Ah, I didn't think about this before: The lower specification version client generated for consumer, the more compatibility it has with different providers, according to this table https://docs.pact.io/getting_started/specification#language-compatibility

So I will leave the default specification version of Pact-PHP to 3.0 for now

V2 definitely provides the widest compat because they support anything that uses a verifier based on the ruby implementation, That being said, if the user is aware they are verifying a v3 pact against a ruby verifier, that they could switch to the command line version, if their language doesn?t currently have the rust verifier exposed. V2 just makes it easier to talk about at a simpler level but loses lots of features (message pact in v3), (multi diff interaction types in one pact in v4, plugin support) Ideally by the end of the year, most of the key languages will support v4, and I?d love to be at a point where the default is v4 and you only drop back to v3/v2 if required for compat

I think JVM is now defaulting to 3, or you have to specify (it may be a bug) Whichever we choose, it should be nice and clear in our spec table

ty for merging some pr?s Tien! Just writing last bit of the pact post and its the PHP section, so thought I would get the doc sync import working so we could show off the new readme and docs to the world

Perhaps we default to V4 because users can always specify a lower level. This will encourage more big reports and requests out of the woodwork and ultimately level us up?

Wouldn?t be a bad shout, we won?t move forward unless we really make people, and if we can provide some decent guidance about how to drop a spec level, and what they lose out on, it might make them want to get on the v4 features across the board in their org, and spend time working on that, rather than trying to fudge the old spec. Might mean we see more people trying plugins for things like gql etc

I think default to V4 also help new users, since they can use all of features without worrying about learning what is specification, how to change it, what spec need to change to.

https://deploy-preview-319--docs-pact-io.netlify.app/blog/2024/04/26/pact-open-source-update-april-2024 https://github.com/pact-foundation/docs.pact.io/pull/319 https://deploy-preview-319--docs-pact-io.netlify.app/implementation_guides/php/readme

Nice write up, as always heaps happening.

Thanks for the Golang callout too - that?s a good idea

just put an issue on the board to update our invites https://github.com/pact-foundation/devrel/issues/31

:thinking_face: *Curious about what happens at our Community meetings? We'd love more of our wonderful contributors to join us!* :pig-hello-door: There's one tomorrow (*Wednesday 01 May* 2024) at *11:00 UK* time which is *20:00* for our *AEDT* folks. You can join the meeting using the Zoom link bookmarked at the top of this channel.

I can't join it today. I am still on holiday. I am interested in adding 1 more feature before beta release: combined matching rules. After beta release, I would like to focusing on improving myself.

Thanks for letting us know @tien.xuan.vo and we appreciate the update too! I hope you are enjoying holiday time!

@matt.fellows @yousafn Temp check on meeting today? Josh and I are available, Tien is unable to make it.

Sorry just finished with kids. You folks in there?

I need to update the calendar entry I have but I knew it was on

sorry homies :( , was asleep after yesterdays very late night hospital stint.

No worries mate, hope things are tracking better today

ICYMI: https://github.com/wiremock/wiremock-pact

Nice work @tomas.bjerre85!

has joined #maintainers

Thanks :)

GH Tracking Issue: https://github.com/pact-foundation/pact-reference/issues/414

newest post re Linux ARM runners from GitHub actions https://github.blog/2024-04-26-github-actions-arm64-and-the-future-of-automotive-software-development/ > look for the public beta for Arm-hosted runners coming later this year.

Good morning @uglyog and team :blobwave:! I've got a couple of PR's in pact-protobuf-plugin, and there are a couple of people waiting for an FFI release. Ready for a little brain dump of some of the things I think need playing out to get a release out with some of the outstanding changes. (so you might want a coffee before you read this :point_down: :sweat_smile: :coffee2: ) The pact-protobuf-plugin musl PR's will close the loop on all the alpine stuff, so we will need to do a little release train ? plugin releases ? pact-protobuf-plugin ? pact-csv-plugin ? update indexes to reference new plugins ? pact-plugin-cli ? pact-plugin-driver (is this needed or do they pickup the new index straight from the repo) ? pact ffi ? ideally this will contain references to the new plugins, so they can pick up musl supported plugins with the auto-download functionality (via pact-plugin-driver) ? pact-stub-server (can go independently) ? this _should_ in theory ? publish new musl variants ? publish multi arch images to dockerhub and ghcr If you are happy with someone else getting involved in the mix, I can kick off the release train during the day, otherwise feel free to let me know if there is anything I've missed out and if you would rather do it yourself. I noticed that your groovy release scripts are used to kick off the release workflows by genning the changelog, sorting release numbers and pushing tags. There is an option to publish to Cargo as well, and I obviously don't have creds for those locally. Would you want to look at automating the release kick off (so it can be done via a workflow dispatch), and automate the publishing of the crates? :rockon:

No need to release pact-plugin-driver.

For pact ffi release, as there was a breaking change to pact_models, we have to release all the other libs first as ffi depends on everything. I've done most of then, just pact_consumer and pact_verifier need a release.

The reason for the Groovy scripts, is that they prompt each step, and are re-runnable by design. If a middle step fails, you can then fix it and re-run the release from there. With a a workflow dispatch, you have to fix failures by undoing was done up to the failure, fix the issue, and then run everything from the start again. With lots of waiting on CI builds. CI's are the worst things to use for releases.

I think it is good for someone else to do the release. We have had a few people over the years who can do it, but they have all gone on to better things. The only creds you need are push rights to GitHub and deploy permissions to http://crates.io.

Unfortunately, you do need the deploy permissions set for every crate, which is a bit of a pain.

I?m pretty sure I still have the access to do a release, should you decide to cross the street one fateful day

You sure do

Awesomesauce! I've currently got lost in the BSD matrix. I've been enjoying trying new aarch64 distros with my m1 mac, then got frustrated that cross couldn't build for some of the targets that Rust could support. I went on a mission to expand the gcc compiler collection on MacOS to cover more esoteric linux architectures, for both gnu and musl flavours. the gnu flavours are only relevant really for me now for Ruby, and also OCD completeness. Modified a tool called Macpine which is basically like lima, (linux machines on mac) to run more qemu images so i have the full suites of BSD's and a windows VM because Wine is slow although pretty useful. https://github.com/YOU54F/macpine/tree/bsd I really liked Orbstacks feature of basically wrapping up `docker run -v $PWD:/app <image> /bin/sh -c 'cd /app && <whatever>` so you can semi-transparently run linux binaries on a mac machine (similar to Rosetta or binfmt for linux peeps) It does it with nfs shares, but its not open source and that smokes pole. It also doesn't support BSD's and not being open source is no bueno. So I basically rebuilt that functionality in MacPine with Qemu. Ultimate goal for me is to be able to build/test all targets on my local machine, pretty transparently from my macos command line. Coupling it with a fork of https://github.com/nektos/act which allows you to run act as a self hosted runner https://github.com/ChristopherHX/github-act-runner means I can effectively run GH actions on my VM's and get coverage on all the machines without having to rely on CI systems that are underpowered, or don't cover the hardware I want to test. (might as well put the machines I have at home to some use) More than happy to adventure into the land of the rust releases, have built out a fair bit of it on my forks, to consume in downstream projects, so I can be fairly confident before it comes into the foundation. But computers do what computers do :head-splode:

I?ve got a http://crates.io account under the username YOU54F now. shall i add one for our pact-dev github user and we can use that for automating the crate releases. will need Matt or Ron to add users as maintainers of crates.

https://www.phoronix.com/news/GCC-aarch64-w64-mingw32 good news for woa

Oh man, been neglecting this unpaid job for a long time now... But, I've been nerd sniped and spent some time figuring out how to continue with PactSwift. What have I missed in the last year or so?

How dare you! What?s happened? Probably the biggest thing we?re still focussed on is getting all languages onto FFI, V4 (with the new synchronous interaction type) and plugins. The https://github.com/pact-foundation/pact-compatibility-suite/ was created to help teams understand when they are ?done?. PHP and Python are currently undergoing the necessary rewrites to do the above, including implementation of the BDD suite.

Cool, I've got a branch moving most of the business logic responsibility into `libpact_ffi.x` so `v4` should be easy to support. No idea about how to deal plugins yet tho. So don't hold your breath.

:mega: Our community meeting is on a UK friendly time zone tomorrow (Wednesday 15 May 2024) If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

Just finished a wee bit of yak shaving to help work out why Tien was having some issues with implementing alpine support, and naturally came across a few more issues. None has still topped my bamboozlement of yesterdays ruby require randomness. (how did you ever work :awesome: ) Hopefully see some of you in the morning!

I?ll likely be late to this, my daughter has been a PITA to get to bed recently. I?ll do my best though :stuck_out_tongue:

1 min away

So sorry team, I fell asleep with my daughter when putting her to sleep :laughing:

awwww :aww: No problemo! I'd rather your were snuggling with your daughter anyway

:mega: Community meeting tomorrow - Wednesday 29th May :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

Sorry folks, unfortunately I can?t make tonight as I have a family thing on

You are forgiven :wink: Enjoy!

wooot linux and windows arm64 runners! https://github.blog/2024-06-03-arm64-on-github-actions-powering-faster-more-efficient-build-systems/

>> These runners are available to our customers on our GitHub Team and Enterprise Cloud plans. We expect to begin offering Arm runners for open source projects by the end of the year doh, bit longer

Do we have a community meeting tomorrow morning (Australian time)? Or did we switch to having them once a fortnight and only in the European morning?

I think the latter. I?ve removed tomorrow morning?s from my calendar. Next meeting should be next Wednesday

Yep, the latter. Oh, and welcome back @joshua.ellis! I hope you had a great break!

Should we make reference to https://stackoverflow.com/questions/78575417/running-pact-tests-getting-classgraph-worker-11-retried-waiting-for-gclockersomewhere in our docs?

This is cool: https://github.com/asyncapi/community/pull/897/files#BOUNTY_PROGRAM.md

is there a general jvm trouble shooting page? Can?t see a resolution for the user apart from switching to using the Quarkus extension. Are you making ref to pointing to Quarkus Pact stuff or for that particular issue. As it?s not resolved, we could just raise it as a gh issue, so it has search ability for others in future

very interesting! I thought it was about sec ops first, with my bounty brain

I like the point made here about the fact that some might come just for the bounty, but if it helps get complex work done then that is a brilliant means to an end

heads up, windows runners have had a recent update that is causing some issues i?ve got previously passing runs now failing when picking up the updated images, so this might avoid you a bit of yak shaving! https://github.com/actions/runner-images/issues/10004

I?d like to propose to add to our discussion tonight/tomorrow: 1. The decommission of canny, and replacement of a ?roadmap? repo via github 2. RFC process to propose new major features across the project - where/how/format? _(I?ve added to the proposed agenda)_

Also, did we end up updating the regular meeting to 8pm AEST / 11 GMT+1? I can?t make 7pm unfortunately.

11am BST on my phone cal

Thanks!

some thoughts on a repo for central discussion. rfcs or roadmap? https://github.com/rust-lang/rfcs https://github.com/pactflow/roadmap https://www.asyncapi.com/roadmap

we could rename devrel to roadmap https://github.com/pact-foundation/devrel

I like roadmap, because it also helps to specify intent (?here?s where we?re going!?) and use the projects feature to visually show that.

Following the discussion about the main page for the GitHub Pact Foundation org, I've opened this ticket: https://github.com/pact-foundation/.github/issues/18

I can't seem to assign the ticket to myself though... or request feedback from anyone in particular

ty dude! appreciate that. odd how its not letting you assign =/

And following the discussion about RFCs, here's the issue to introduce RFCs: https://github.com/pact-foundation/devrel/issues/32

I'll look at adapting things from the Rust RFC process and create a PR at some point :slightly_smiling_face:

and finally, the ticket for the messages FFI confusion: https://github.com/pact-foundation/pact-reference/issues/440

I?m wondering if we should open an issue on each maintainer?s repo to ask them to contribute to the RFC in case they aren?t active on slack. What do you think? Possibly, once we?re happy with the RFC on RFCs and have a roadmap process, we should issue a PR to each README to link to the roadmap to increase visibility/transparency.

Github is running very slowly for the Rust crates

Most of the builds just get queued for a long time (starting to approach an hour). I wonder if this may affect it

If that is so, then for those who don't know what Irony is, this is an example.

That's some hefty caches... I know that for Pact Python, part of the bloat are old caches which are in the 30 days queue until expiration.

The largest Python caches are ~200MB each And then x5 for each Python version supported (3.8, 3.9, 3.10, 3.11, 3.12) and then x3 for each operating system

Completely agree with creating PRs in each of the (main) repos to increase visibility :smile: I'll do that once the PR for the initial RFC process is opened

rust debug builds are horrendous. i get +25gb on my machine building for all targets

hmmm, I wonder if there's a compromise that might work? E.g., use a `debug` build because it is fast, but without all of the intermediate artefacts?

to be honest we only save about 6 mins per run with the cache on the linux builds. save a fair bit more on macos

>> https://pact-foundation.slack.com/archives/C05HCLA3C93/p1718354665565509?thread_ts=1718328808.032669&channel=C05HCLA3C93&message_ts=1718354665.565509 >> yeah this sounds good

:mega: Community meeting today - Wednesday 26 June :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

I see somebody has found the canny -> github integration? :laughing:

Yo, So creating GH issues from Canny into the following repo https://github.com/pact-foundation/roadmap/issues will need to copy comments over and close off canny issues. some are 110% for specific repos rather than wider reqs, so will transfer them as appropriate. some already resolved :slightly_smiling_face:

lovely, thank you so much!

Right so I have created linked issues for about 98% of the issues. There are 20 outstanding requests which just need the comments copying over to the linked issue, and then the canny feature request closing. I was closing them with ?tracking with linked github issue? however the linked github issue doesn?t show up on public view :facepalm: so I will comment back on each ticket with the linked issue ticket. Some have been moved to their respective repos.

This looks really interesting@david.j.smith https://github.com/davesmith00000/close-enough/tree/getting-it-close-enough

Cool, I'll update the Pact Python issue-creation workflow and remove the link to Canny :slightly_smiling_face:

Amazing, thanks for doing that Yousaf!

Right 9 are left ? need comments copying over to github linked issue ? closing with "tracking with linked github issue <link>

Reviewing the contract testing book manuscript and saw this test output - the `INFO` log level from the core is getting in the way of this story! 1. Is this configurable by us? Seeing INFO level logs from Hyper is unlikely to be useful to the user 2. I?m going to ask the authors to set log level to ERROR for the purposes of this :stuck_out_tongue:

Looks like part of 1 is resolved in https://github.com/search?q=repo%3Apact-foundation%2Fpact-core-mock-server+received+request&type=code

it?s here https://github.com/pact-foundation/pact-core-mock-server/blob/febf7974b648aeeefb6af3d69dd988051886243e/pact_mock_server/src/hyper_server.rs#L275 here https://github.com/pact-foundation/pact-core-mock-server/blob/febf7974b648aeeefb6af3d69dd988051886243e/pact_mock_server/src/hyper_server.rs#L185 The debug values captured for the incoming and outgoing requests are useful and could be captured for sending in case of failure. and here https://github.com/pact-foundation/pact-reference/blob/efc54d263e7ea53c9511cf389870e790c0158bc3/rust/pact_matching/src/lib.rs#L1665 There are other instances of `info!` statements https://github.com/search?q=repo%3Apact-foundation%2Fpact-reference+info%21&type=code I think lib authors can suppress log output by piping to a buffer (or file) and reading from there if necessary (fetch_log_buffer_as_json)

:mega: Community meeting tomorrow - Wednesday 10 July :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

At this stage, I won?t be be able to make tonight sorry

I?ll aim to review the RFC work though as that was the key action (thanks Josh!)

No worries Matt. Thanks for the update.

Following the community meetup, here's the PR to streamline/simplify the Pact Foundation profile page: https://github.com/pact-foundation/.github/pull/19 You can preview the updated README at https://github.com/pact-foundation/.github/blob/feat/update-org-profile/PROFILE/README.md, though noting that the metrics image won't have a valid URL until the PR is merged (as it has a hard-coded link to the `master` branch). Instead, you can preview the much more minimal stats image with the PR's "Files Changed" tab :slightly_smiling_face:

:mega: Community meeting tomorrow - Wednesday 24 July :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

Unfortunately I can't make tonights session folks. Personal commitments I'm afraid

Thanks for the update Matt

For the next community meeting, I?d like to add discussion around the 5 minute guide to the agenda (see https://docs.pact.io/5-minute-getting-started-guide). The http://repl.it used to be executable from within the docs page, but now that it isn?t I?m wondering about how useful it is for others and if we should be looking at something like killercoda (or just a straightforward tutorial).

:mega: Community meeting tomorrow - Wednesday 07 August :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

I?ll join tonight. I have the sniffles from a cold, but would like to say hi to everyone!

Yay! We will be happy to see you, sniffles n'all

Will be on shortly, just saying goodnight to kids

:blobwave: I?ve archived https://github.com/pact-foundation/sucker_punch We were using our fork as we waited for https://github.com/brandonhilkert/sucker_punch/pull/253 to be merged. In an ideal world I would prefer to delete the fork, however we have released gems that contain this reference, to our fork, so I would imagine they would then break. We have updated versions of the gems published that use the now updated, release, origin package. https://github.com/pact-foundation/pact_broker/commit/b1bac7118ab782672d51b1c0f36240771d7e3156

How old are the gems? Should we set ourselves a remind for when it's been 'long enough' that we can delete the fork?

between march 23 and feb 24, pact broker gems were released with a dependency on our forked suckerpunch gem. any using older versions, will be fine as long as they are running ruby 2.7 or earlier. my worry is the gems released in that 13 month period will effectively be unresolvable and I?m not sure if bundler would be okay with that. might be a non issue but I haven?t found much in the way ont internet to ascertain what may happen or best practise here

Fair, and given how relatively recent that is, I would also err on keeping the repo archived for now. Perhaps once 24 months have elapsed, then it might be safe to delete the repo :slightly_smiling_face:

:mega: Community meeting tomorrow - Wednesday 21st August :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

Sorry folks I won't make it tonight (off for a few days holidays and am busy cleaning the decks). But...Great work on closing the RFC Josh! :clap:

Enjoy your break!

Is anyone else joining? @jo.laing @yousafn

Sorry dude, my cal invite was out of sync. I?ve updated the cal invite again, and set it up for repeating. looks to be okay on my cal now https://github.com/pact-foundation/roadmap/blob/master/Pact%20Community%20Meeting.ics

ICYMI Josh dropped this nice Pact RFC last week, with a proposal to support global configuration across the ecosystem: https://github.com/pact-foundation/roadmap/pull/98

Do we have a meeting tonight/now?

DOH!

Sorry dudes

I just added invite to work laptop and its not repeating again :crazy: set it to repeat manually once added to cal, for every 2 weeks

All good, we had a nice chat and updated the agenda with the topics we discussed.

hey team, will be on the train heading down to London for APIDays. it?s due to arrive at 11:30. will see if i can join, maybe via audio

I think I?ll be missing tonight anyway as I have a customer call, sorry team!

:mega: Community meeting today - Wednesday 18 September :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

Community meeting tomorrow - Wednesday 02 October :mega: If you are GMT based, we're meeting at 11:00. That should be 20:00 for our AEDT folks :pactflow-platypus-slack:

wheee, I think the clocks are going to start changing on either side. wonder if this is still right

Aus change on the 6th - go forward 1 hour UK on the 27th - go back 1 hour

Am I right that the next meeting on the 16th will be 10:00 UK and 20:00 Aus, then after 27th Oct it will be 09:00 UK and 20:00 Aus? :confusion:

The ICS file on GitHub has a timezone included, so I'll just trust the computer to tell me the right time :laughing: So for Melbourne, it is 20:00 tonight, and 21:00 next fortnight

That's what's in mine too Josh

Sorry I won't be able to make tonight also. Last minute family gathering (my Dad is home alone at the moment as my Mum is overseas with her friends on a trip, and he's recovering from a surgery)

aww recover quickly Daddy Fellows. have a nice evening bud

OK, I will put my faith in the ICS file - thanks @joshua.ellis !

Looks like SCC dropped support for Pact?s in the 4.x.x line. I can?t see it in the docs there, but is in the 3.x.x line: https://docs.spring.io/spring-cloud-contract/docs/3.0.4/reference/html/howto.html#how-to-use-pact-broker Probably Marcin got sick of asking us to take over support (I don?t blame him!)

Correcto. I also believe @marcin.grzejszczak is still here. :blobwave: https://github.com/spring-cloud/spring-cloud-contract/issues/1845 https://github.com/spring-cloud/spring-cloud-contract/commit/dc581e89341356f7fe504645f5b1c78b2e366f8e Extracted https://github.com/marcingrzejszczak/spring-cloud-contract-pact project Slack history ? https://www.linen.dev/s/pact-foundation/t/9001773/hey-3-4-months-ago-we-started-the-discussion-around-migratin ? https://www.linen.dev/s/pact-foundation/t/5153612/hey-i-tried-pinging-u9uuy3cu9-about-this-but-didn-t-get-any- I don?t believe we ever agreed on whether it would be taken under the pact-foundation org, as it didn?t have an owner.

Hi team, if you get a moment, please take a moment to review https://docs.pact.io/help/enabling-debug-logging. It?s helpful when people have questions to be able to point them to a simple way to get debugging logs for us to investigate. @joshua.ellis @tien.xuan.vo it looks like both Python and PHP are missing. I?m looking into how we might improve logging/debugging across the ecosystem so that we can streamline and communicate more clearly to all users how we ask for help. I think an RFC might be the way to go for it though.

(raised https://github.com/pact-foundation/pact-net/issues/524 for Pact .NET)

I do think an RFC should be in place, whether we want to support a common logging flag or what. It's difficult because each language has its own conventions, and logging across the FFI boundary is also difficult. But these difficulties merely justify why we should go through an RFC to get a solution that works for most people mostly well

Yep!

Created PR for it https://github.com/pact-foundation/docs.pact.io/pull/355

@matt.fellows I have another one https://github.com/pact-foundation/docs.pact.io/pull/356

Hey folks, I'm running a little late for our catch up tonight (assuming it's happening?)

No worries! Thanks for letting us know. I'm assuming the meeting is in 1 hour....(timezone changes playing on my mind)

:mega: Community meeting today - Wednesday 16 October :mega: If you are GMT based, we're meeting at 11:00. That should be 21:00 for our AEDT folks :pactflow-platypus-slack:

think its set as 45 min in cal

replit needs logging in with pact account otherwise it will get deleted. I think the repl might be worth dumping as you say and replacing with a killercoda. No-one has mentioned the repl for months, still get people forking the getting started guide

I feel like we should shift the community meeting by an hour. Tomorrow's meeting is scheduled for 22:00 Melbourne time which is a little late :confused:

PR to switch to UTC and shift the meeting to be 1 hour earlier. https://github.com/pact-foundation/roadmap/pull/103

I've also created a few other PRs to adjust more minor aspects of the ICS

Thank you Josh. Definitely way too late for a meeting at 22:00. Also appreciating the other minor aspects you've adjusted. ICS files make me ICK :wink: :thankyou:

is 9pm still a bit late for you guys? would you all prefer 8pm?

have merged those changes thank you. i?ll leave it open to discussion but I?m okay with waking up earlier over winter to help make times more amiable across the pond

9pm is still fine I think. It's our summer and we have plenty of daylight typically

jealous :stuck_out_tongue:

Thanks for being so accommodating Josh. I don't even know my own name by 9pm - there is no way I could function usefully in a meeting!

:mega: Community meeting today - Wednesday 30 October :mega: :alarm_clock: TIME CHANGE :alarm_clock: If you are GMT based, we're meeting at 10:00. That should be 21:00 for our AEDT folks :pactflow-platypus-slack:

Sorry folks I have a customer call tonight so will likely miss our catch up. If it finishes early I'll join in

:mega: Community meeting today - Wednesday 13 November :mega: If you are GMT based, we're meeting at 10:00. That should be 21:00 for our AEDT folks :pactflow-platypus-slack:

This is cool: https://github.com/VerifyTests/Verify/tree/main/docs/wiz

it's cool... and it seems like a lot to maintain :laughing:

yep!

Do you have additional review for this RFC https://github.com/pact-foundation/roadmap/pull/99 ?

:mega: Community meeting tomorrow - Wednesday 27 November :mega: If you are GMT based, we're meeting at 10:00. That should be 21:00 for our AEDT folk :pactflow-platypus-slack: :pact:

I _may_ not be able to make tonight?s call, but I?ll do my best to (it?s my daughter?s birthday, so it just depends on how long it takes us to wrangle them to bed :stuck_out_tongue: )

Hope your daughter has had a happy birthday! No worries re meeting - take time with your fam. We can record the meeting if you'd like? I've been meaning to get into the habit of that anyway!

Always great catching up - never a dull moment and lots happening :heart:

This is so sad! Compared to the other ones. We can do better!

maybe it needs `pact-reference` -> `some-intermediary` -> `pact_jvm` ?

Lets just make the Java cohert move from Java 8 to 21 and FFI :allthethings: https://docs.oracle.com/en/java/javase/21/core/foreign-function-and-memory-api.html

Java has had FFI support since 1997

They keep rebranding it

JNI, JNA, there was Panama recently

or different arms, same jumper, idk

or is this now panama that is in j21?

ahh they actually have arm64 binaries now for jextract https://jdk.java.net/jextract/ annoyingly it was x64 at the time when I last looked

JDK 21 change is more about safe functions and shared memory.

ahh h'oki, that makes sense, I remember seeing the memory session used in panama but I didn't really tickle it much, just tried to do the bare minimum in the different java ffi interop modes https://github.com/YOU54F/hello_ffi/blob/main/java/panama/Panama.java

Renovate has started adding onboarding PRs to a few repos (not exactly sure what triggered it, and not sure why some but not all repos are being onboarded). In my experience, Renovate does a much better job keeping dependencies up to date compared to Dependabot, and can be extensively configured to adjust how noisy it is.

Seems like a good idea. I definitely enjoy the Pact JS and Golang updates (although Yousaf usually beats me to the merge), and if renovate does a better job then I?m all ears

I think we still hav snyk about - any thoughts on that? (should we just remove?)

Great! I'll monitor the onboarding PRs and adjust the config slightly

I'll also disable Dependabot updates, since there's no need to keep both

We are going to start looking at the Pact plugins again. I have started writing some proposals for some of the ideas I have, and I'm going to try using GitHub discussions as the mechanism for discussions on them. We will see how it goes. WARNING: there will be lots of spelling and grammar errors! https://github.com/pact-foundation/pact-plugins/tree/main/docs/proposals

Hey folks, I think a community meeting was scheduled for tonight however Josh is out sick, Yousaf is on leave and I think Jo is also. So I'm going to assume we cancel (let me know otherwise)

Got it, Matt!

Hello everyone! I think it goes without saying that, being Christmas, we won't have the community meeting tonight. Wishing everyone a fantastic Christmas and festive season! :christmasparrot: :pactflow-platypus-slack:

:mega: Community meeting today, Wednesday 08 Jan 2025? Anyone around to meet? :mega: :pact: That's 10:00am for GMT which is 21:00 for our AEDT folk :pactflow-platypus-slack:

I?ve created the retro board for our next session here: https://miro.com/app/board/uXjVMV_3Tjc=/?moveToWidget=3458764612478566842&cot=14

Miro board link: https://miro.com/app/board/uXjVMV_3Tjc=/ Password: `pact-foundation`

A colleague shared this today: https://diataxis.fr/. It looks like an excellent framework for thinking about documentation

Hey all :blobwave: , Just letting you know that we ~are deprecating~ have deprecated the basic auth on http://test.pactflow.io (see why below). If you are using the test broker, you just need to switch from user/password to token based auth. You can use these credentials: ```export PACT_BROKER_BASE_URL=https://test.pactflow.io export PACT_BROKER_TOKEN=129cCdfCWhMzcC9pFwb4bw``` Users won?t be able to login with basic auth either, but you can use this pre-signed URL for them to login as a guest user and poke around: https://test.pactflow.io/login?code=98f7810e-c7dc-493b-9c3d-7849952f1d9a&utm_medium=web&utm_source=pact-js _(update the UTM at the end to your project or remove them altogether)_ _*Want your own broker?*_ If you?re a maintainer and would prefer to have your own PactFlow instance separate from above, please just create a free account https://pactflow.io/try-for-free/ and let me know the PactFlow details once done to prevent it from downgrading at the end of a trial. _*Why / Background*_ Basic auth is terrible. We thought it was broken and yesterday I updated the configuration of that tenant to make it a ?normal? account. It wasn?t until a bit later that we realised basic auth was actually still working and something else was going on, but by then I?d already made all of the requisite updates across the foundation.

has joined #maintainers

woop woop arm64 linux runners now avail for free on public repos https://github.blog/changelog/2025-01-16-linux-arm64-hosted-runners-now-available-for-free-in-public-repositories-public-preview/

You mentioned a blog - don't forget to add useful content and articles to this page :point_right: https://docs.pact.io/blogs_videos_and_articles

bad bot :stuck_out_tongue:

I?ve removed this auto responder - it?s a little to trigger happy!

So we have our weekly community catch up tomorrow - was the plan to do the retro in the session, or add our retro items beforehand and use the session to vote / discuss? I see Josh has gone in there, I might add a few today.

I wanted to ask you exactly this!

Saf and I just had a quick look to see what was on the board and/or if more time was needed for individuals to add their tings

:mega: Community meeting tomorrow, Wednesday 22 Jan 2025? Anyone around to meet? :mega: :pact: That's 10:00am for GMT which is 21:00 for our AEDT folk :pact:

are we zooming? I?ve lost link

Oh, I guess I missed it.

It?s hard trying to log into zoom without arms

We talked over the miro board & 2025 goals. https://pact-foundation.slack.com/archives/C05HCLA3C93/p1736336202729579 we are going to async go over the miro doc, set a bit of a plan of things we want to tackle for the year and raise them in a pinned ticket in pact-foundation/roadmap repo. Jo & I are going to create a maintainers notification list in GH, so we can tag everyone for visibility in the created ticket. Oh and probably transposing our agenda items into issues or something in the roadmap repo, so we have gh tracking/searchability of the actions. Helps our engineers who aren?t in Miro/Slack

Since I was looking into ways of allowing to propagate PACT_BROKER_BASE_URL/TOKEN secrets in PRs from forks (see https://github.com/pact-foundation/pact-js/pull/1343#issuecomment-2608192974), I was looking into some of the other secrets we store in the GitHub org and whether any are no longer used. I found just two which don't seem to be used by any repository: ? PACTFLOW_PACT_OSS_TOKEN ? SNYK_TOKEN

Hi folks :wave: Following on from last week?s maintainer meet up, we https://pact-foundation.slack.com/archives/C05HCLA3C93/p1737545331549529 that we would conduct an *asynchronous* retrospective on 2024. Access details for the board are https://pact-foundation.slack.com/archives/C05HCLA3C93/p1736336260715839?thread_ts=1736336202.729579&cid=C05HCLA3C93 (also pinned so we don?t lose it to history). *Instructions / timeline* ? Retro board is open to feedback from today, closing Monday 17th Feb ? I will affinity map and attempt to summarise feedback and ideas ? In the 19th February maintainer meetup, we can discuss some of this feedback and ideas, and discuss next steps (likely more workshops and planning) I will reach out to maintainers that aren?t on slack to ensure they have some input into the process (if they would like).

@matt.fellows @yousafn been chatting to ludorival wrt to his pact-jvm-mock library (https://github.com/ludorival/pact-jvm-mock). They have been asking how to integrate it with Pact-JVM (see https://github.com/pact-foundation/pact-jvm/issues/1847). As they are already publishing it to Maven Central, I thought the best thing would to have a section in the pact docs for it.

Makes sense. I?ll add some notes to the ticket

Hey folks :wave: Just a reminder / check-in on the above ^^. Any questions let me know! I also can?t make this Wednesday owing to a personal obligation, sorry.

:mega: Community meeting tomorrow, Wednesday 05 Feb. Anyone around to meet? :mega: :pact: That's 10:00am for GMT which is 21:00 for our AEDT folk :pact:

I'm out at a conference about conferences tomorrow so won't be able to make the meeting.

Hey folks, I'll be summarising the retro board tomorrow in preparation for the next community meeting on Wednesday. Please have your items in by Monday EOD 17th

There wasn?t that many tickets, so no real need to affinity map. We can discuss the items one by one and see what comes of it in our session tonight

yeah that makes sense. It would probably be good on the cover pages for each repo in the docs, to have links to ancillary projects relating to each client lib for example the test framework wrappers for pact-js (jest-pact/mocha-pact/nestjs-pact) I am not sure if they will be able to make submissions to pull in their code into docs, as the repo is outside the pact-foundation. maybe they want to transfer it in and retain ownership

I?m pretty sure he has done a pact msw adapter too

Hey folks - just a quick one. I won?t be able to make the maintainer meetup next week (March 5) as it?s my wife?s birthday and I have a dinner on :slightly_smiling_face:

We got some feedback/updates on the canny board overnight (see https://pact-foundation.slack.com/archives/CSUFRDVKN/p1740587267520819). Given Yousaf put the notice up in July last year, I?ve taken the step to make the board private. Let?s give it a few weeks, and if nothing bad happens and we haven?t got anything in there we need, i?ll delete the board altogether. (_I?ll migrate the comments added to the relevant GH issue)_

:mega: *Community meeting today! Wednesday 05 March.* Anyone around to meet? :mega: :pact: That's 10:00am for GMT which is 21:00 for our AEDT folk :pact:

Sorry I haven?t read https://github.com/pact-foundation/roadmap/pull/113/files yet @tien.xuan.vo. On my todo for tomorrow! (Although I see some good conversation already happening, thanks everyone who has looked at it already!)

I cant join community meeting on Wednesday anymore because I am busy at that time.

no worries, what times might be more convenient for you now? hope this means you got the job :fingerscrossed:

Yes, that's right. If it's 2 hours later than usual, I might be able to join

:mega: *Community meeting tomorrow! Wednesday 18 March.* Anyone around to meet? :mega: :pact: That's 10:00am for GMT which is 21:00 for our AEDT folk :pact:

I actually can?t make tonight either I?m afraid, sorry folks. I?m a bit behind on the retro board updates as well, sorry!

So... I just lost power at my place. I just have candles going :sweat_smile:

Still no power :grimacing: so unlikely I'll make it to the meeting

OK, no worries Josh - thanks for letting us know. I hope power is restored soon for you!

Congratulations @tien.xuan.vo!

Congrats indeed dude! We will have to re-think times or approach at some point then. Thanks for having attended for so long, it?s been really great to having regular catch-ups with a few.

:blobwave: I don?t think Josh is feeling well today. :get-well-soon: I?ll be around for the 45, if anyone wants to pop in but no worries otherwise.

ahh time zone fail (uk clocks gone forward). back in 45 ;D

I'll be there, see you soon

Sorry folks - I thought we agreed on the last call we were going to have these on a less regular cadence/as need basis. But I might be COMPLETELY making stuff up! _ I removed it from my calendar regardless, and had another work call. Hope it went well - miss your faces :wave:

We did, but me and Jo are free at that time, so we don?t mind being available and hanging out. Gives us some dedicated Pact time. I am also going to make my calendly available, so that anyone can book an ad hoc meeting that may suit those that can?t make our dedicated slot

On the way back from a function, might be a touch late for the Meetup

I'll dial in from the car for the first bit

Hey folks, apologies again but I?m going to miss the maintainers catch up this week (family gathering) A couple of updates: 1. I?m working on the retro items from the past 2. I?ve been looking at socialising feedback around an update to our documentation (a restructure into a diataxis format, with some assistance from Tech Writers at SmartBear)

I also wont be avail, as ill be in NY talking about all things contract testing

Hey folks, not sure if the maintainer catch up is on tonight but I?m smoked - I also need to wrap up a few things at work before I clock off. i?ll give tonight a miss, that is

All good buddy, me and Jo wrapping up some bits and bobs

oh shoot - was it 50 mins ago?! :facepalm:

Yeah, me and Jo got confused and thought it was an hour earlier than that as well :sweat_smile:

But we also discussed canning it, and getting some comms out with the community about how they want to interact with us. Maybe some calendly time. We?re working on finalising some comms pieces today. ? Pact Foundation org members ? Thank you?s and do you still want to be part of the org ? Aim: Review members and set up appropriate groups / permissions, and ensure we have bots rather than users for automations ? Pact Community at large ? How can we meet you where we are, maybe survey ? Aim: Find better aligned ways to communicate with our user base, ? Pact Repo Usage Survey ? For each repo, have a issue/discussion around current usage / feedback / maintainer and/or contributor participation. ? Aim: Try and archive repos that are not used, or do not serve the community well, to reduce cognitive load and sunken costs, when reviewing viability of our tooling. ? Secondary Aim: Try and find a maintainer, or group of maintainers/contributors who actively want to maintain/shepherd each repo

https://github.com/pact-foundation/roadmap/issues/121 https://github.com/pact-foundation/roadmap/issues/120 https://github.com/pact-foundation/roadmap/issues/119

@rholshausen I was speaking with Yousaf and Jo the other day and I mentioned how you were rebuilding the JVM release pipelines as the current stack is being shutdown. Is this a good opportunity to re-think automating the release process from GitHub? Also, a reminder for any secrets/credentials to pop them into the Pact Foundation?s 1Password in case you win the lottery and disappear to Mallorca

> Is this a good opportunity to re-think automating the release process from GitHub? Probably, but I couldn't be bothered doing it

I don't gamble, so you don't have to worry about me winning any lotteries

Do you travel on public transport?

Just clarifying - what time is our maintainer meet tonight? I think 8pm AEST / 12pm CET / 6am ET?

In 1 hour from now?

haha thanks all :wave:

What's on the agenda for tonight? I'm still behind on my actions and need to get some other urgent stuff done if nothing pressing

I don't have anything in particular

nowt pressing, feel free to skip if you have urgent stuff to attend to buddy

FYI I think Yousaf and Jo are at a conference. I could use the time tonight to work on my commitments (retro follow up and progressing the JS PR)vif we don't have much to discuss? I'm also likely to be slightly late (kids)

i?ll be about. we don?t head off till later this eve. all good if you want to get your head down buddy

Ah cool. I'll aim to be there. Initiating bed time routine in 3-2-1...

I would like a new version for pact-protobuf-plugin and pact-ffi, can you release them for me @rholshausen?

Yeah, sure

Thank you very much!

Hey all, Welcome @kevin.rohanvaz who recently joined the PactFlow team and will be helping triage and work on some issues in the Pact-Python space. alongside @joshua.ellis who has been doing awesome work. I?ve created a https://github.com/orgs/pact-foundation/teams/pact-python-triagers team and added https://github.com/orgs/pact-foundation/people/kevinrvaz into it, rather than full maintainer/admin rights. Josh feel free to amend to suit.

has joined #maintainers

I notice pact_matching dependency of pact_ffi is locked at 1.2.x in this commit https://github.com/pact-foundation/pact-reference/commit/9afae5a5cbe64dbcb55957f9e8c0fe7fa5bbb0bc I was expecting my code (in https://github.com/pact-foundation/pact-reference/releases/tag/libpact_matching-v2.0.0-beta.2) to be in new version of pact_ffi, but isn't. I wonder when pact_ffi will switch to version 2.0 of pact_matching.

pact_ffi still uses the old 1.0 version of pact mock server crate. That will need to be upgraded to the 2.0 version first.

Sorry folks, I need to skip on tonight?s meeting. I need to get something done tonight (insert MS Powerpoint emoji!)

:blobwave: On Friday, some CLI tooling changes were merged to to help the migration/adoption of our rust based tooling, over our ruby tooling. All rust cli tooling is now available in a consolidated docker image and standalone package, these are additions to the existing ruby consolidated cli packages. To support this 1. pact-ruby-cli has been renamed to pact-docker-cli 2. pact-ruby-standalone has been renamed to pact-standalone Ruby packages have been marked as legacy in cli docs, with exception of the pact_broker-client. ? https://github.com/pact-foundation/pact-docker-cli/pull/135 ? https://github.com/pact-foundation/pact-standalone/pull/146 Updated docs / repo links ? https://docs.pact.io/implementation_guides/overview

This is FANTASTIC - thanks Yousaf!

It really was overdue for a cleanup :broom:

I need to add a couple of tickets, to kick off updates to the projects when any of the clis are released/updated

Hey folks, I?ll be there tonight (albeit will need to drop a little earlier to get to another call). Looking forward to seeing you :wave:

h?awesome, see you in an hour :muscle:

I?ve dropped these crate owners (pact) a message to see if we can claim it as they have renamed to codas and have a notice in place about transferring https://crates.io/crates/pact

this is also unfortunate :sweat_smile: i might drop them a message whilst I am at it https://crates.io/crates/pact-cli

it was originally written in rust, but then rewritten in rust so I don?t imagine they would be to precious about it as it was just a tool mainly built for the users own niche needs

Sorry folks, I realised the maintainer invite dropped out of my calendar. I wouldn?t have made last week anyway as I was on leave. I should be right for next Wednesday

someone trying to add pact_broker-client as pact-cli to homebrew-core https://github.com/pact-foundation/pact_broker-client/pull/195 kind of nice to have it in homebrew-core, but without having a live url to update, it makes it more awkward to use to update (an extra hope out of our control), plus those type of package managers don?t usually like have meta cli packages that bundle up many clis ( I got grief from scoop about it when looking to create listed packages for there)

I asked some questions to see if we be viable to be the core,, but to also address some concerns about the meta cli

came across this at the weekend https://github.com/kmdreko/venator you can stream rust tracing logs to it, which is quite nice. (and view otel traces/spans) although it needs some UI love on macos as navigation isn't quite right Also finally got round to having a play with https://rybbit.local/ at tracking calls from the rewritten pact-broker-cli. Went on a bit of a diversion and added it into a local copy of pact-reference and was able to get a nice view of the calls. I reused and extended the existing metrics to allow configuration to GA, or a locall rybbit instance but could be extended for other providers Then took a bit of wander into otel, adding it into the pact_broker, ruby pact_broker-client and rust pact-broker-cli. Have the traces nicely connected into a span between ruby -> ruby but not rust -> ruby yet Once I've got that connected, I'd love to get otel hooked up with verifier and/or mock server to see what it could look like

Curl as debug, I tried this out and modified the code a bit. https://gitlab.com/mcarton/dbg_as_curl Francis showed something similar she did over in JVM https://github.com/pact-foundation/pact-jvm/issues/1507 I think this would be gamechanger for me for http debugging (if you discount the fact that your provider wont have a state server setup if you run it locally to send the curl request against. )

renovate will be renamed to mend, so if you have any filters which exclude bots, you will need to rename to add mend (I believe) from reading this https://github.com/renovatebot/renovate/discussions/37842 shouldn?t make much difference to day to day ( i have a saved click house query for pact-foundation and a few other orgs but exclude bots for my sanity)

There's some work done within PactFlow for oTel support... Should probably have a chat to avoid duplicating work :sweat_smile: As for following spans across devices, it requires configuring appropriate headers that can act as request IDs. In AWS, it likes to use the `X-Request-ID` or equivalent header.

Pretty sure they've gone full circle then :laughing:

yep hahahaa :infinity:

> There?s some work done within PactFlow for oTel support... Should probably have a chat to avoid duplicating work :sweat_smile: Oh nice! I was just experimenting in personal time, with tidying off some bits of the pact-broker-cli (rust) and pact-ruby v2 with rust core. proprietary code and open source play time don?t tend to mix :slightly_smiling_face: Will have a chat and see if we can leverage, if we integrate something like this for reals into Pact. > As for following spans across devices, it requires configuring appropriate headers that can act as request IDs. In AWS, it likes to use the `X-Request-ID` or equivalent header. If you use official otel sdk integrations you get that for free, (you can configure different otel providers). my only prior experience commercial with tracing, has been with xray :) I was looking for something I can self-host, as I was to use otel across a few things in my homelab. Also reqwest didn?t look like it had a listed integration on the otel integration guide for rust, which is why it probably needs some additional tickling to populate with required metadata.

hmm it seems this page skipped me by https://docs.pactflow.io/docs/on-premises/observability

Will have to get my self hosted instance back up and running. Tore most things down when I sold my hades canyon

Caer, a super cool dev rel sent me a lovely message over the weekend. > Hi Yousaf, > > So glad to hear it; I was hoping a member of the Pact team specifically would reach out, since the naming conflict with your product was one (of a few) reasons for us transitioning to the Codas (https://crates.io/crates/codas) name. > > Let me know if you need anything else--it was nice to meet a fellow DX/developer advocate! > > Caer will be transferring over `pact` and `pact-derive` crates today :) there was a `pact-crypto` but I mentioned that would probably be good for the kadena crew :sweat_smile:

codas actually looks quite interesting, but a yak shave for another day

> codas actually looks quite interesting, but a yak shave for another day (edited) yeah? interesting

https://crates.io/crates/pact I don?t think we will really need this but still https://crates.io/crates/pact-derive

rename is no more haha, that was short lived

I wonder why...

I mean, the name 'Renovate' is excellent for what the bot does

and I have no issue with them putting links that "Renovate is provided by http://mend.io" or something to that effect

bye. bye macos x86_64 https://github.blog/changelog/2025-09-19-github-actions-macos-13-runner-image-is-closing-down/ we will probably need to switch to using rosetta, for x64 compilation, as `macos-15-intel` I believe is a chargable runner, and x64 will be dropped by macos anyway, but supporting older x86_64 clients should still be on our radar, as it generally is just setting an xcode env var. If/when rosetta gets removed, it?ll be a different story, but as it is used for x64 emulation of linux, which has been gaining in popularity on macos, especially with apple releasing `container` (their docker alternative), I imagine it will be here for a while

@tien.xuan.vo has confimed the runner is on the free paid plan :pray:

pact broker client rewrite is transferred over to the pact-foundation now https://github.com/pact-foundation/pact-broker-cli released to crates/dockerhub/ghcr and available as a github action and has install scripts for windows and unix systems :rockon: :rust:

Ideally, we erase/cleanup all references to the old CLI as soon as we can and get everyone onto this amazingness. Before we do that, I guess we need to get it into the wild for a bit more testing? I?m going to raise some tasks in PactFlow also to update to this CLI, which wouldn?t be a bad idea. A few questions (which absolutely should _not_ detract from this glorious work!). Should we also consider updating the following other places that use the old one: 1. Should we package this into the main Docker image (i.e. replace https://hub.docker.com/r/pactfoundation/pact-cli)? a. Or update the pointers to say ?this is now deprecated, use the new one here..?? 2. https://github.com/pact-foundation/pact-js-cli 3. Homebrew formula? 4. Should we update the _*PactFlow*_ GH Actions with the new one also (or wait until these are ? I reckon we could do some updates to our docs, specifically on recommended usage of our CLIs, e.g. ? https://docs.pact.io/implementation_guides/cli ? https://docs.pact.io/implementation_guides/overview

great questions, some of which worth tabling in a migration issue i reckon Ideally, we erase/cleanup all references to the old CLI as soon as we can and get everyone onto this amazingness > Before we do that, I guess we need to get it into the wild for a bit more testing? yep, would love to get more testing in. 1. Should we package this into the main Docker image (i.e. replace https://hub.docker.com/r/pactfoundation/pact-cli)? a. Or update the pointers to say ?this is now deprecated, use the new one here..?? include pact-broker-cli exe into pact-cli docker image. ultimately replace with consolidated rust cli with all bins embedded in single bin 1. https://github.com/pact-foundation/pact-js-cli should be added to pact-standalone as interim, which would let this be distributed via the js cli, homebrew. 1. Homebrew formula? 2. Should we update the _*PactFlow*_ GH Actions with the new one also (or wait until these are ? i wonder if we toggle the old/new pact broker client by an env var. opting in makes the pact-broker command use the rust instead of ruby impl > I reckon we could do some updates to our docs, specifically on recommended usage of our CLIs, e.g. yep on my list to pull in docs, and update guidance, ty

@surpher is asking if we should move https://github.com/surpher/PactSwift into the pact foundation org. I think it makes sense, given it?s replaced the previous defacto project

Any objections?

There's lots of moving parts though. I've tried to document them and set up scripts to automate most of things: ? `surpher/PactSwift` is the main interface that's aiming to remove pact business logic but only act as a Swift interface ? `surpher/PactSwiftMockServer` is the wrapper around `lib_pactffi` (and should delegate most/all the business logic to lib.a`. This is the working repo that does the implementation ? `surpher/PactSwiftServer` is vending XCFramework binary avoiding https://github.com/surpher/PactSwift/discussions/122. This is the "shareable" repo that vends the compiled results of `PactSwiftMockServer` ? `surpher/PactMockServer` delivers module.modulemap to bridge Rust -> Swift

Do it

None from me. Great work @surpher :rocket:

Some of these names are, at least to me, not entirely obvious. For example from `PactSwiftMockServer`, I would not have guessed that it is a wrapper about Pact FFI :sweat_smile:

I'm not necessarily suggesting that the downstream packages get renamed (e.g., whatever the equivalent is of a `pip install` or `npm install`)

well, you can rename it when it's in your hands :slightly_smiling_face: It was an evolution of requirements and everchanging Swift/Apple ecosystem

`swift package update`

In your opinion, would there be much of a benefit from having a bit of a monorepo structure? I did this for example with https://github.com/pact-foundation/pact-python. The repo has `pact-python`, `pact-python-ffi` and `pact-python-cli`

it was a monorepo, but it quickly blew up to Gigs and Gigs of repo to download on each CI pull

that's why it got split up

ah, yeah ok... I'm not familiar with what gets pulled in within the Swift ecosystem

the actual interface was maybe a couple of files, but the binaries that need to include rust runtime so it can run on an iOS device or on a system that doesn't install rust so dylibs could be used, each binary version was more than 150MB, now split that to platforms, that ended up adding another ~600MB of history to the repo on each release :tada:

and you really don't want to force iOS devs installing Rust, trust me

You're saying that the binaries were being incorporated into the Git history?

yup, at the time SPM didn't do the plugins yet, where it could download a hosted binary

oh wow... that's a glaring feature gap from SPM :laughing:

and only when XCFrameworks were introduced, that was able to shed a lot of binary crap

anyway, the split to multiple repos that pull in what they need for the platform they need for now is... okay

but whoever wants to take over can do whaterver they want with it.

You don't want to maintain it after it moves into the Pact Foundation?

I haven't touched it in a year, but I'm not against continuing to be the main maintainer of it

one thing we'll need to figure out is the transition. there were 10k clones in last 14 days

so lots of CIs might go `'hol up a minute`

I _believe_ if you use GitHub's 'transfer owner' feature, GitHub will automatically redirect? At least, I know it does that if you rename your default branch (I did that going from `master` to `main` in Pact Python)

not sure, just pointing it out

if it's not a problem, then ignore me

But you're right, if there's no redirect, then you'll need to have repos on your side informing people of the redirect.

But back to the maintainer side of things: it would be good to have you still 'own' the package, even after it transfers into the Pact Foundation. It would want to avoid have it become abandonware

not a problem, can even push in a logger warning telling them to make the switch

lots of ways we can do it

yeah, I just haven't had the need for it. I've moved from consulting to a product role and we're using GraphQL and there's little support for adding contract testing in.

fair enough. It's also possible to put a notice up that, while there's someone who can review PRs, we're looking for someone to take ownership

there was very little contribution from outside so I'm not worried if you'd want me to remain the PR reviewer and worry about architecture. Just can't put as much time as I used to to jump on new features. I've set up scripts to release new wrappers when Ron pushes out new libpact_ffis but then updating/introducing new features is a bit of an ask right now.

someone else who needs it can do that and I'm happy to mentor

ok, seems like you're keen to take it under your wing. I'll have a think how we can approach this so you don't inherit all the crap I had to add into the history. I'll pull out a crystal bowl or ouija board to help me remember where I left it off and what would need to be done for `pact-foundation/PactSwift` and co carry on from point where it supports Swift Concurrency (eg. PactSwift `v2`).

Scratched out a few thoughts here on how we _may_ go about supporting optionals. Feedback welcome :wink: https://github.com/pact-foundation/roadmap/discussions/128

Perhaps we should get up an issue on the project to see if anybody is interested in becoming the maintainer?

@joshua.ellis I currently have a 9pm conflict with a call with EMEA SE?s, Yousaf is on leave. @jo.laing were you planning on joining? The session might move 30 mins before/after so if it does, i?ll join if anybody else is planning on it.