https://pact.io logo
Join Slack
Powered by
Is it correct that the broker deploy check operate...
# pact-broker
t
Is it correct that the broker deploy check operates on a {contract, provider version} pair?
(I'm trying to work out if I could implement deploy checks that work differently in cases like missing providers without changes to the broker)
m
Mind elaborating on this? I think it could mean a few things. for example, are you asking if you can check if a consumer is safe to deploy even if the Broker hasn’t seen a provider yet?
t
No, I’m asking exactly what the broker uses to determine deployability
👍 1
Currently, I believe the broker assumes a provider is required for a consumer to deploy - but that’s not always true. Long term, I think broker changes will be needed to support that, but I’m looking into what is possible with virtual providers etc
👍 1
m
yes, in the case of messaging systems for example
👍 1
🔮 I see you trawling through Ruby in the near future
😂 1
t
Right, I’m trying to avoid that 😅
😆 1
Well, not avoid, in as much as, I’m curious what the broker already supports with no changes
👍 1
like, I’m not trying to avoid looking at ruby, I’m trying to avoid making unnecessary software changes
👍 1
I think there are some possibilities based on the existing model of broker pacticipants - for example, in ContractCase, the the definer of the contract will be the consumer in the Pact broker (because you define what you consume), but that’s not the same as the consumer in Pact (which is kind of a synonym for client sometimes). This still works, even though it’s not what the broker was expecting. I’m asking if it’s the case that the broker decides compatibility only on {contract ,provider_version}, to look in to alternate uses and coercions of the model
m
I think it is more complicated than that, but in general it is very much aware of the different roles and the roles have the assumptions you listed above (i.e. a consumer / provider is not as general as your model)
t
I think it is 
{contract, provider_version} -> deployability status (true | false)
, and that consumer version is a pointer to contract. Is that right?
m
yes
I think so
👍 1
In PactFlow (and I don’t know if any parts / remnants of this exist in the OSS version) there is a concept of a provider contract, and that may also be bastardised for your use case. But I think you want to optimise for what’s in OSS for now
t
When you document it, I’ll support it 😉
😆 1
(Pactflow auth is supported)
💪 1
So, I have: • Contract definer, which defines what it consumes (could be an http response, like pact - but you can also consume http requests) • Contract verifier, which verifies that the expectations of a contract are produced (could be an http response, like pact,- but you can also verify that you produce http requests). ContractCase doesn’t need to support a separate concept for “provider driven”, because you can write a contract at either end. You could even do contracts at both ends at the same time, which I haven’t thought about to know if it’s a good idea, except to realise that it definitely should be called Case Closed.
😆 1
m
YES!
I can see the elegance in the model
😎 1
🙌 1
t
(you can even mix http clients and http server contracts in the same contract file. It’s pretty cool)
🙌 1
Open in Slack
PreviousNext
Powered by