+ opened
+ #70 feat(cli): support PACT_PLUGIN_CLI_SKIP_LOAD
+
+
opened by YOU54F in pact-foundation/pact-plugins
+
5 files changed ++36 --15
+
-
samlarsen1
- starred
- pact-foundation/pact-jvm
+
YOU54F
+ opened
+ #69 fix(plugin-driver): use std:process over tokio for plugin loads on al…
+
+
opened by YOU54F in pact-foundation/pact-plugins
+
5 files changed ++33 --215
+
-
adamrodger
- commented on
- #96 rfc: RFC process
+
JP-Ellis
+ deleted
+ branch
+ chore/update-gh-templates
+ in
+ pact-foundation/pact-python
-
-
opened by JP-Ellis in pact-foundation/roadmap
-
Firstly, I think this is a step in the right direction so thanks for that 👍 Whilst a lot of the development happens in the open, I feel like a lot of the decision making happens in private, so anything we can do to make that more public is a good move.
-With that in mind, my first question is - will everyone be taking part in this RFC process? As in will Pact Foundation and SmartBesr employees also be making changes solely via this mechanism, or is this an avenue only for those external?
-My second question surrounds the areas covered vs not. It makes total sense to me that the spec is covered by this process, but other parts are less clear. For example, why is the pact CLI covered by this but something like pact-jvm isn't? To an outsider, that's an unclear distinction.
-Third point - what happens when an RFC is accepted? For example, a spec change RFC is accepted - is the spec now changed? Do we publish a new version bump? Or is this just accepting the idea of making that change at some future point?
-Similar with the CLI and other elements mentioned in the text - if someone says "the CLI should start doing X" and that gets accepted, what then? Obviously someone needs to actually make a code change, and if nobody does then what does accepting the RFC actually mean?
-In PactNet the RFC is like the initial design discussion, and is expected to be accompanied with a PR once the design has been agreed, and only then closed. So it's an atomic single ticket that results in a code change, whereas this didn't read like it was. This felt like it was accepting a plan to make a code change somewhere else later.
-
-
adamrodger
- commented on
- #508 [GH-505]: Include VerificationExecutionResult when verification fails
+
JP-Ellis
+ pushed 1 commit in
+ pact-foundation/pact-python
-
opened by flakey-bit in pact-foundation/pact-net
-
So I think for now we should just throw the more specific exception rather than try to deserialise all the verification results. They'll also be printed to the console, and it's a big UX change to alter that.
-This would also need to target 5.x because it's a breaking API change now that we're throwing a different exception type (albeit a sub type).
@@ -391,20 +397,17 @@ This would also need to target 5.x because it's a breaking API change now that w
-
Dreamescaper
- commented on
- #385 Requesting enhancement to update query param and body param in post call in provider state before pact verification
+
JP-Ellis
+ merged
+ #730 chore: update GitHub templates
-
opened by tl-madhulika-mitra in pact-foundation/pact-net
-
@adamrodger
-The example that I've shared does not work - because the IDs are auto-generated it is not possible to hardcode them.
-Maybe I'm bad at explaining things, especially considering that I'm new to Pact. But the issue I'm having is exactly the one that is described in OP's blog post:
-https://pactflow.io/blog/injecting-values-from-provider-states/