-
Notifications
You must be signed in to change notification settings - Fork 137
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs/async blog #744
Docs/async blog #744
Conversation
While footnotes are numbered when rendered, it is best to avoid using numbers in the Markdown file itself as the numbers are less descriptive, and make it difficult to refactor (or even repeat the use of a footer). Signed-off-by: JP-Ellis <josh@jpellis.me>
) | ||
``` | ||
|
||
1. The provider URL is required but only used if generating both HTTP and message interactions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe reword if the pacts to be verified contain both HTTP and message interactions. (they may be multiple pacts in the pact dir, that are for diff transport types - http/message. V4 spec allows for both interaction types in a single pact file. )
generating interactions to me would be the consumer side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reworded. I was thinking of generation in terms of Pact generating interactions (as in, mocking the other end), but that is clearly confusing.
``` | ||
|
||
1. The provider URL is required but only used if generating both HTTP and message interactions. | ||
2. The provider URL is required, though would only be used if the provider generates both HTTP and message interactions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this say provider state url?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed
2. The provider URL is required, though would only be used if the provider generates both HTTP and message interactions. | ||
3. This path is used by Pact to ensure that the provider is in the correct state before sending the message. | ||
|
||
Those familiar with HTTP interactions will notice that the process is very similar, with the key difference of the additional `add_transport` method. This configure a HTTP endpoint on the provider that Pact will call to trigger the provider to send the message. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
configures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- The provider URL is required but only used if generating both HTTP and message interactions.
- The provider URL is required, though would only be used if the provider generates both HTTP and message interactions.
are the provider.url and provider.state_url only used for http, will they be ignored for message interactions?
mentioned in points 1/2 above.
for 3, path="/_pact/message"
This configure a HTTP endpoint on the provider
If we are validating a message interaction only, no http interactions. I assume we need 1. the provider url to prefix this path
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For your first part: I've disambiguated the state_url portion to make it clear it is for both.
For your second part: You have to define a messages
transport at home point, though it technically could be done at the first. I'll rework the example to highlight this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, on revisiting this, I think that the Verifier always creates an endpoint for HTTP interactions, irrespective of whether the Pact contains HTTP interactions. So I'll just try and reword it to be clear.
provider = Provider() | ||
|
||
( | ||
Verifier() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it worth mentioning that this is a departure from the existing interfaces MessageProvider
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I personally want the blog post to just focus on what's coming, as opposed to how things were.
I would like to create a more thorough upgrade guide once we are much closer to v3
though.
Few minor comments, but looks and reads great. nice example. Great work @valkolovos! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Feel free to cherry pick any amendments from my comments, otherwise all good with me
docs/blog/posts/2024/05-02 integrating rust ffi with pact python.md
Outdated
Show resolved
Hide resolved
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. The only comment I have is to ensure the endpoint to verify messages is clear (i.e. making it clear what the API contract is for that endpoint to work). That need not be here
e221605
to
02fd5f5
Compare
I've fixed a few issues raised by @YOU54F, and if I understand your comment @mefellows, I'll also add example payloads for the intermediate HTTP relay as I think that will make things clear. |
Signed-off-by: JP-Ellis <josh@jpellis.me>
Signed-off-by: JP-Ellis <josh@jpellis.me>
The frequency of updating the docs was previously reduced to avoid noise in the Pact Python Slack channel; however, it means that blog posts, or minor corrections to any docstring do not get updated. I am reverting the previous change and will investigate the possibility of publishing updates to Slack, instead of Slack subscribing to all deployments. Signed-off-by: JP-Ellis <josh@jpellis.me>
02fd5f5
to
ee1da4b
Compare
📝 Summary
Adding a new blog post to highlight the contributions from @valkolovos that made it in v2.2.1 of Pact Python 🚀