Starting to learn about pending pacts and work-in-progress pacts. Pending pacts - don't break the build for new pacts that have not yet passed verification. Work in progress pacts - run verification for the latest pact for any branch which is still pending, and which was not explicitly specified by the provider verification configuration. I was looking at using WIP to manage feature flag variations. But if WIP only runs for pending pacts, how do I make sure that a feature flag pact that previously passed verification will get verified in the future, when the provider changes?

I missed this. Your summary of WIP/Pending is how I think about it

Great, thanks, looking forward to your thoughts @Beth (pactflow.io/Pact Broker/pact-ruby)

Hi David, I’ll raise it with the Pactflow team tomorrow for discussion

So you would treat each variation of a consumer as a different consumer? I guess it's a workaround but ideally I'd like the Pact model to reflect the domain, which is that the same consumer can have multiple variations. One form of variation is over time, which is represented as versions. The other is over space, represented as feature toggled/configured variations (it may not be just toggles, it could be experiments or customers choosing different features, which I see a lot in the enterprise space). It seems like actually both variations over time and variations over space are both versions. It means that you can actually have multiple versions deployed simultaneously as well as released simultaneously

Yes, that is true and a good point

You might argue that the distinction between release and deploy starts getting a little fuzzy or even non-existent. Sorry, that's a tough thing to say when you put so much work into it.

yes

We're still using tags because the JVM doesn't support deployments and releases. Based on my statement that feature toggles are different versions of the same consumer that can be deployed on the same environment at the same time, here's what I think could work. But I'm not sure if the current Pact libraries support this... • When version a pacticipant, the version identifier includes the feature toggle name as well as the git hash • When we verify a provider, we have to verify all versions of that provider with the same git hash (e.g. all active toggles) and publish each one as a separate verification • When we run consumer tests, we have to run for all versions of the provider with the same git hash and publish each one separately. Assuming the test passes, we publish the pact and tag with the branch name. • When we deploy a pacticipant to an environment, we tag all versions that have the same git hash, regardless of the feature toggle • When we run can-i-deploy for a pacticipant to a given environment, we need to check all versions tagged with that environment, not just the latest (not sure if we can do this. I don't see an

--all

option)

I often say you deploy code and you release features (when you turn the toggle on)

yeah. I guess the challenge here is that the terms/language needs to work across concepts that have subtle variations (branches, toggles, …). So it might be hard to put that genie back into the bottle.

Yea, you discover your domain as you implement it, and of course things also evolve, but now you're stuck with a model that doesn't correctly represent the domain. That can create a mismatch that is hard to work with. It's a bummer.

BTW we’ll be picking up the feature branch/environments etc. work in the Pactflow backlog soon to drive implementation across the ecosystem. We kicked off some planning late last week for that. Just thinking out loud, I wonder if this would be a better approach than WIP for you. As you describe above, you simply tag all variations of your feature variations (versions) with a tag. On the provider side, you can take advantage of the

latest

selector set to

false

. This would have the effect of always verifying all versions with that tag. You would need to remove the tag from the version afterwards once undeployed, which is the messy bit. I think releases is probably going to be the better tool once you can take advantage of it. From that page: • `latest`: true. Used in conjuction with the

tag

property. If a

tag

is specified, and

latest

is

true

, then the latest pact for each of the consumers with that tag will be returned. If a

tag

is specified and the latest flag is not set to

true

, all the pacts with the specified tag will be returned. (This might seem a bit weird, but it’s done this way to match the syntax used for the matrix query params. See https://docs.pact.io/selectors).

ok duck away, talk more

@David Van Couvering (DVC) - eBay sorry, I've only just seen this thread and it looks like Matt has answered a lot of you questions. What is still outstanding that I can help with?

The new webhook - do tell? I wasn't aware of a new webhook

it verifies against the main branch and all currently deployed/released versions.

Well, the challenge is not finding which pacts to verify against. The challenge is you have to actually build, start up and run different versions of the provider, one for each version that is deployed or released

yup

Ah...

with the git sha of each provider.

I have to run, my son is ready to watch TV with me, but I'll take a look thanks!

👍🏼