Simplifing WIP pacts #640
Replies: 3 comments 7 replies
-
|
cc: @mefellows @uglyog |
Beta Was this translation helpful? Give feedback.
-
A webhook endpoint that is aware of the various CI providers for this would be an excellent addition. |
Beta Was this translation helpful? Give feedback.
-
|
Wip pacts doesn't work for trunk based dev. Unless they're somehow manually using tags. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, I was thinking this advice: https://docs.pact.io/pact_broker/tags#using-tags-with-feature-toggles-instead-of-feature-branches |
Beta Was this translation helpful? Give feedback.
-
|
We really need to work out how to support feature toggles properly. Is it on our "roadmap" somewhere? |
Beta Was this translation helpful? Give feedback.
-
|
It's currently here 👉 https://pact.canny.io/feature-requests/p/add-better-support-for-workflows-that-are-managed-by-feature-toggles-rather-than (we have a PF tracking item also) |
Beta Was this translation helpful? Give feedback.
-
|
Sounds all ok to me |
Beta Was this translation helpful? Give feedback.
-
|
I have a potentially unrelated question: the phrase
sounds strange to me. Perhaps I got it all wrong, but a flow like: verify all contracts + check only relevant(*) verification results in can-i-deploy makes sense to me. So I'd like to ask: is the notion of verifying a subset of all published contracts ever an optimisation on the above flow? (*) relevant to the environment you're trying to deploy to |
Beta Was this translation helpful? Give feedback.
-
In what way does it not work like that now? |
Beta Was this translation helpful? Give feedback.
-
Background
The purpose of the WIP ("work in progress") pacts feature is allow pacts from the feature branches of the consumer to be verified automatically during a provider CI build without the provider having to change its configuration.
At the moment, this is achieved using some very complex logic to try and identify which pacts are currently being worked on by the consumer team. This complex logic is needed because the Pact Broker did not when a git branch was merged/deleted. Because pacts are not currently automatically removed from the Pact Broker when the git branch is merged or deleted, it is hard to tell which branches should be included for WIP pacts, and a date must be provided in the configuration to indicate how far back in the history the WIP pacts should start being detected.
Since the WIP pacts feature was implemented, we now have support for git branches (the original logic used tags).
Proposed change
{ branch: true, active: true}which will return the pacts for all active branches. The "pending" feature will continue to ensure that the newly changed pacts to not cause the provider build to fail.The reason for using a flag on the branch rather than just deleting the branch and associated pacts is that some teams will merge, but leave the branch there, and some will delete the branch. Using the phrase "you should verify the pacts from all active branches" makes sense when describing the real world, and then would translate directly into the Pact Broker domain model. The branches can then be cleared up using the clean function, or using a SCM hook, as a separate concern from determining which pacts to verify.
The reason I think using a flag called "active" is better than "merged" is because some branches may be merged into other branches that are not main, and may still be considered active. The customer would be able to choose at what point a branch is no longer considered active (eg. when it's deleted, when it's merged, when it's too old etc).
I would expect the lifecycle of the active flag to go:
If a pact was for some reason re-published from a branch with the same name as a branch previously marked as inactive, it would set it to active again.
Required work
Beta Was this translation helpful? Give feedback.
All reactions