Closed mefellows closed 1 year ago
LGTM. I need to think on this a bit more, there must be a better way to support this requirement
Thanks. Rather than merge this in (and increase the API surface area), should I create an issue out of it so we can track?
The methods themselves aren't exactly problematic, so I guess it wouldn't be the worst thing to bring them in.
I'll take your advice though. No need to rush this.
Yeah, ok, let's do that.
I haven't tested the generator function yet, but the matching rule function works nicely.
This enables me to pull them out from the following plugin RPCs:
CompareContents
GenerateContent
And therefore would solve the problem for a content matcher plugin, but not a transport one.
i.e. it won't work for the methods that accept the
Pact
object (e.g.VerifyInteraction
orStartMockServer
). I had a look at the existing FFI methods, and I don't think there is a way to navigate to a place where you can extract aMatchingRule
(that might be possible, and perhaps is a better pathway).PrepareInteractionForVerification
andVerifyInteraction
both already have access to theConfig
struct, and so could use the other FFI methods (e.g.pactffi_parse_matcher_definition(const char *expression)
) for this purpose..So that would leave just
StartMockServer
lacking a way to get to the expressions.This can all be worked around by maintaining state of course, but you mentioned this is against the aim of the framework.
What do you think is the best way to make the expressions (in the form of
MatchingRule
s andGenerator
s) available to a Plugin at all stages?(I also expect the build to fail because the FFI package will need the new functions in the models package)