Comments (5)
I suppose a --allow-pending
or something like that could be something for additional consideration. I'll move this to our feature request board, because it's separate to the specification itself.
from pact-specification.
It's a tricky situation. can-i-deploy
is very much about telling you how reality works, whereas during development we have a bit more leeway. I suppose in this case, it is safe for the provider to deploy, because the provider already in the target environment (probably) doesn't work.
But, your consumer has broken the rules by ignoring this check. We could add more configuration/options, but it feels like it just makes the shooting of your feet more likely. This implies the tools have been circumvented, so you could collectively circumvent them again to resolve the situation.
This would be somewhat analogous to allowing you to regular git push
after somebody else has git push --force
a change to a repo. The --force
was bad, and has now put the repo in a broken state, but allowing you to think things are normal by allowing regular options to keep working as is, is probably a bad idea.
from pact-specification.
Yeah I agree. We have some additional tests after the deployment we need and it is expected that every pacticipant can use one environment (test) and deploy and test ... let's say wildly ;). We include this environment in our can-i-deploy checks for faster feedback. I think this is our main issue at the moment. We do:
... deploy -> additional tests -> record-deployment -> can-i-deploy (everywhere)
We do it like that, because as said we need the deploy step on the test environment for the additional tests. This is why we did not put a can-i-deploy (test) infront of the deployment. Then it felt wrong not to include the record-deployment step afterwards. We were not sure where to include the can-i-deploy then. So we said ok at the end so that the teams still have the feedback from their tests etc. but also fast feedback from pact.
Maybe we can exclude test in can-i-deploy at the end, because as said we need to able to deploy there at any time and then maybe the can-i-deploy check makes no sense for this environment.
Or we can check if the usage of pending interactions can help us as well.
Nevertheless, I still want to ask regarding providing the information if a pact is pending or not also during the can-i-deploy step. Isn't that also a valid information, without changing anything regarding the can-i-deploy checks, but it provides us the info, ok somebody did something illegal or provides more flexibility for the different kinds of pipeline definitions?
Thx for the fast feedback btw.
from pact-specification.
We actually ran into something similar where because we have pending pacts and WIP turned on, junit essentially ignores the failures. The problem is that unless the dev is intimately familiar with pact, they assume that everything is ok and could potentially merge a PR that is actually not going to let them deploy.
Since the failure is essentially βhiddenβ by junit, a PR pipeline could still pass and be merged. Especially true if something like auto merge is turned on
from pact-specification.
Related Issues (20)
- Events driven architecture like aws event bridge contract testing HOT 1
- Feature Request - eachLike(itemDescriptionWithMatchers, exampleArray?) HOT 4
- Definitive word on PACT and HATEOAS HOT 1
- V4 Pact Specification Metadata format changed HOT 3
- Guidance and documentation needed to differentiate between event messages and command messages? HOT 1
- Option to check for no undeclared fields HOT 3
- Generated pact file body include json_class, contents information and doesn't have matchingRules section HOT 2
- V4: Tracking issue for support of synchronous messages HOT 6
- V4: add a boolean matcher
- Matchers don't work with SSE response format HOT 1
- Question: providerStates allowed in any contract? HOT 1
- Type of regular expressions used in pact HOT 2
- How to match xml elements with namespace ? HOT 3
- Serialisation of ProviderStateGenerator HOT 2
- Add number range matcher
- json schema for version 3 pact files HOT 2
- The V4 Specification Retrospectively Alters the V3 Specification for Matchers and Generators HOT 6
- Either matcher in Pact HOT 2
- Convert PACT file to OAS 3.0 file HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from pact-specification.