-
-
Notifications
You must be signed in to change notification settings - Fork 173
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
Master issue for new 'pending pacts' feature #320
Comments
mefellows
added a commit
to pact-foundation/pact-js-core
that referenced
this issue
Mar 25, 2020
- add support for Pending Pacts flag - add support for consumer version selectors See pact-foundation/pact_broker#320 for background
mefellows
added a commit
to pact-foundation/pact-js-core
that referenced
this issue
Mar 25, 2020
- add support for Pending Pacts flag - add support for consumer version selectors See pact-foundation/pact_broker#320 for background
This was referenced Jun 23, 2020
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Audience
This issue is for Pact library maintainers, to document and discuss the adoption of the new 'pacts for verification' endpoint.
Background
This piece of work requires that the new 'pacts for verification' API is being used.
For background on the feature, see http://blog.pact.io/p/d7c9601f-e2ca-4208-b1c0-f02eaf96c3c2/
Summary
When verifying a pact where pending is true, a verification failure should not make the overall build fail. I understand that this might be difficult, but it's going to make a lot of Pact users very happy!
What changes need to be made to the code that uses this new API?
For implementations that wrap the ruby standalone
1. Allow user to enable/disable feature
First, upgrade to the latest version of the pact-ruby-standalone.
The user will need to be able to configure whether or not this feature is enabled. For consistency, can we present this option as
enablePending
orenable_pending
, depending on the language naming conventions (open to suggestions on this). For backwards compatibility, this should default to false. When the value of enablePending is true, then the flag--enable-pending
should be used when calling the pact-provider-verifier.That's all folks. You can have a play around with an example CLI here https://github.com/pact-foundation/pact-provider-verifier/blob/master/script/dev/broker.sh
For native implementations
1. Allow user to enable/disable feature
The user will need to be able to configure whether or not this feature is enabled. For consistency, can we present this option as
enablePending
orenable_pending
, depending on the language naming conventions (open to suggestions on this). For backwards compatibility, this should default to false. The value of this setting will be sent to the "pacts for verification" endpoint as theincludePendingStatus
field, discussed below.2. Add new parameters to the "pacts for verification" call
They are:
See API documentation below.
The provider version tags need to be sent because the calculation for whether a pact is pending or not depends on the provider version tags (if tags are being used). Eg. a pact might be pending on
master
but not pending onfeat-x
branch. If the user does not actually use provider tags, then the pending status is calculated based on the entire verification history. It is slightly less useful in this case, but still an improvement on the previous "BREAK EVERYTHING" situation.Note that this query does not actually apply the tags to the provider version - you're just specifying which tags will be applied. If your library does not yet implement provider version tagging, then please do this as well!
3. Allow verifications to fail without causing the overall test suite to fail
The main change is, of course, that if a pact is in pending status, its verification should run without causing the overall test suite to fail. I appreciate this might be difficult. Please discuss below if you run into difficulties.
4. Print before and after verification notices
A set of notices will be included in the response that will explain to the user how the pending feature works, and what the pending state is of each pact, before and after the test run. The "before_verification" notices should be displayed before the tests run. In regards to the "after_verification" notices, the verification endpoint cannot know before the tests have run whether or not the results will pass or fail, or be published or not, so a full set of notices is generated, and the pact client framework needs to select which one to display. I've made it so that you can generate the key using the booleans
published
andsuccess
to generate the keyafter_verification:success_${success}_published_${published}
.API documentation
URL
As specified in #307
Parameters
includePendingStatus
: true|false (default false). When true, a pending boolean will be added to the verificationProperties in the response, and an extra message will appear in the notices array to indicate why this pact is/is not in pending state. This will allow your code to handle the response based on only what is present in the response, and not have to doifs
based on the user's options together with the response. As requested in the "pacts for verification" issue, please print out these messages in the tests if possible. If not possible, perhaps create a separate task which will list the pact URLs and messages for debugging purposes.providerVersionTags
: array of tag name(s) for the provider application version that will be published with the verification results. This is used by the Broker to determine whether or not a particular pact is in pending state or not.Example: This data structure represents the way a user might specify "I want to verify the latest master pacts; when I publish the verification results, I'm going to tag the provider version with 'master'"; and I don't want my build to fail if the contract has changed.
Response body
Testing
This feature is only released in the Pactflow code, until we have tested and finalised the API. You can use this instance to test with.
If you're writing a native implementation, please write me a pact and I'll add it to the verifications! Here's an example: https://github.com/pact-foundation/pact-ruby/blob/master/spec/service_providers/pact_ruby_fetch_pacts_for_verification_test.rb
The text was updated successfully, but these errors were encountered: