has joined #pact-broker

/github subscribe pact-foundation/pact_broker issues

/github unsubscribe pact-foundation/pact_broker pulls

/github unsubscribe pact-foundation/pact_broker commits

/github unsubscribe pact-foundation/pact_broker statuses

/github unsubscribe pact-foundation/pact_broker public

added an integration to this channel: https://pact-foundation.slack.com/services/B9YEJCV19

removed an integration from this channel: https://pact-foundation.slack.com/services/B9YEJCV19

has joined #pact-broker

/github subscribe dius/pact_broker-docker

/github subscribe pact-foundation/pact_broker-client

added an integration to this channel: https://pact-foundation.slack.com/services/B9YEJPQQK

/github subscribe pact-foundation/pact_broker releases

/github unsubscribe pact-foundation/pact_broker deployments

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

/github unsubscribe DiUS/pact_broker-docker commits

/github unsubscribe DiUS/pact_broker-docker public

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

/github subscribe pact-foundation/pact_broker releases

@bethskurrie would you be able to point me out how to add authentication to my broker? Probably being blind, but can't see anything in the docs

There's no built in auth @mr.matt.r.long, but you can wrap basic auth around it. I'd recommend using the docker image. Proper auth is the first item on our DiUS hosted broker roadmap, but we haven't had time to pick it up (it's a bit of a background project).

One simple strategy is to add another docker container (e.g. nginx) as a proxy to the broker, and add auth there. Then you only expose the broker port to the proxy container.

Righto, thanks for the help @bethskurrie & @matt.fellows I'll look into it. We're already using the Docker images, so shouldn't be too much effort

Do either of you @bethskurrie or @matt.fellows know the best approach to handling executions from dev machines vs CI. Mainly how to prevent dev builds from populating results on the broker. Was thinking that potentially the basic auth itself on the broker would be able to handle this, in that it the creds are not available on the local builds then the results publishing wouldn't be successful. My only concern here would be if the provider builds remains successful with the 400 responses from the broker. Do you guys have any experience resolving this, or an alternative approach?

Funny @mr.matt.r.long, I was just talking to @uglyog about this yesterday. How you handle this depends on which implementation you're using. Which language are you on?

I'm in process of introducing Pact to my new team. They're largely JVM based, but there's one Go client too

The high level theory is that the pact tests should run as part of your standard build, but the pact publication should be a separate task that only runs on your CI. The pact verification should run as part of your standard provider build, but the publication should be turned off by default, and only turned on in your CI environment, generally by checking for some environment variable.

Unfortunately, pact-jvm has a bug whereby it publishes verifications automatically. I've just raised an issue to have that changed.

You'll need to work out if there's a way you can configure it to be off by default, and only on when you set a certain property or environment variable.

(Sorry, I'm not a java person, so I'm not sure how the configs work)

Here's an example consumer https://github.com/pact-foundation/zoo-app/blob/master/.travis.yml

It only publishes contracts when the tests pass, and the publish is only called on the CI.

Here's an example provider configuration https://github.com/pact-foundation/animal-service/blob/master/spec/service_consumers/pact_helper.rb

(Sorry they're in Ruby, not java, but you'll get the general picture)

Also, if you haven't seen this already, have a read: https://docs.google.com/document/d/e/2PACX-1vRf1kSDccImNipOOm1G-bjcSs-ifbZjf1v54K-dIcq8BLKeFPAAm_bf_p71UKqkRMIx30QWWL-kN8TI/pub

I think I'll add a bit on only publishing from CI, thanks to your question.

Awesome thanks for the help. I'll look into what options that I have using the JVM plugins that we're currently trialling, on the consumer side there's a MVN cmd to publish the pact so we can make sure that's only run from CI although I'd like to look into a programatic way to ensure that a developer can't accidentally run it, I'm thinking the broker Auth should handle that. On the Spring Provider plugin it does automatically publish the verification results, there is a workaround in that it won't if the Provider version isn't supplied, so this is an option I can look. Thanks again :thumbsup:

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

peeps is there a quick way to delete a pact from the broker?

@richard.peckett https://github.com/pact-foundation/pact_broker/wiki/Deleting-resources

There's a open issue for someone to add a button to the UI.

Cheers Beth :thumbsup: :star: as always

has joined #pact-broker

I ran the pact-jvm consumer tests and published the pact file to a pact broker hosted locally in my system. Now, I am running the pact-jvm provider tests and Last verified column is empty but the provider test is successful. Can someone tell me what could be the reason ?

My provider code is like this : ``` import au.com.dius.pact.provider.junit.PactRunner; import au.com.dius.pact.provider.junit.Provider; import au.com.dius.pact.provider.junit.VerificationReports; import au.com.dius.pact.provider.junit.loader.PactBroker; import au.com.dius.pact.provider.junit.target.HttpTarget; import au.com.dius.pact.provider.junit.target.Target; import au.com.dius.pact.provider.junit.target.TestTarget; import lombok.extern.slf4j.Slf4j; import org.junit.runner.RunWith; @Slf4j @RunWith(PactRunner.class) @Provider("controllerProvider") @PactBroker(host = "localhost", port = "2001") @VerificationReports(value = {"console", "markdown"}, reportDir = "target/reports") public class JavaAgentControllerProvider { private static final String HOST = "localhost"; private static final int PORT = 8777; @TestTarget public final Target target = new HttpTarget("http", HOST, PORT); } ```

What version of Pact JVM are you using @abhilash.hanumanth?

You?ll need at least 3.5.4 as per https://github.com/DiUS/pact-jvm/issues/417#issuecomment-323260710

Could you also please post any relevant logs?

@matt.fellows: I am using this version of pact-jvm-provider-junit in provider tests : ```testCompile 'au.com.dius:pact-jvm-provider-junit_2.12:3.5.17'```

@matt.fellows: For some reason, my provider version is empty in the Matrix.

can someone tell me how to set provider version ? In docs, it says using `pact.provider.version` system property. How and where do I set this system property in provider junit test ?

has joined #pact-broker

@abhilash.hanumanth shared a file: https://pact-foundation.slack.com/files/UAT4VE1UK/FB8810ASD/image.png and commented: @matt.fellows: For some reason, my provider version is empty in the Matrix.

A file, which can't be shown because your team is past the free storage limit, was commented on.

The same is working till pact jvm 3.5.16

Last verified column is not populated in pact jvm 3.5.17 but gets populated in 3.5.16 pact jvm.

You could use `System.setProperty(...)` or, more appropriately during CI builds, use the standard `-D` flags to the java command running it

@abhilash.hanumanth there is a defect in 3.5.17, see https://github.com/DiUS/pact-jvm/issues/694

has joined #pact-broker

has joined #pact-broker

Thanks @matt.fellows

has joined #pact-broker

has joined #pact-broker

Where do I find the doc on how to add users with basic auth to the pact-broker-docker?

@rlamb in short, https://pact-foundation.slack.com/archives/C9VPNUJR2/p1528730318000969?thread_ts=1528730318.000969&cid=C9VPNUJR2

Thanks, @matt.fellows!

no probs!

Hi, while creating a webhook I am getting an error { "errors": { "request.http_method": [ "must be POST. See /doc/webhooks#whitelist for more information." ], "request.url": [ "scheme must be https. See /doc/webhooks#whitelist for more information." ] } } I have observed that there is a hint to add this in "whitelist" could you please help me how to add. As for Jenkins webhook it works only with "GET" method (This is what I have observed). Also to test the webhook locally I need scheme as "http"

@shekharsp27 Did you look at the URL that it told you to read for more information?

Have you tried looking at the documentation for the Pact Broker? https://github.com/pact-foundation/pact_broker/wiki

I'd recommend reading the Configuration page.

@bethskurrie Thanks, looks like I have missed that :disappointed:

Hi all. One of the main things people don't like about the current implementation of CDC that Pact provides is the ability of a consumer to break a provider's build by pushing new or incorrect expectations to the Pact Broker. I've been thinking of a fairly simple solution to "protect" the provider build, by allowing a configuration option that basically says "you can't tag a pact as `master` (configurable tag name) until it has been verified by the `master` (configurable tag name) version of the provider". The way this would work is that the consumer team would publish a new pact with a non-master tag name, and once the provider had implemented the new feature, and published a verification for that pact content from the `master` branch of the provider, then that feature pact would be allowed to be tagged with master. This all pivots around the fact that the verifications belong to the pact *content* rather than the consumer version.

The only problem I see with this solution is that at some stage, a verification will have to be published from the master provider branch for the new content, and this should come from the CI - we don't want to have to have a developer manually verifying the feature pact from the master branch from their developer machine. So I'm thinking of introducing the concept of "wip" pacts - verifications that can run that are expected to fail, and won't fail the build if they fail. We could use tags for this, and if it works, perhaps introduce it as a higher level concept. I imagine the provider build verifying the `master` and `prod` pacts (fetched dynamically from the broker) and failing if the pacts fail, and also, verifying any `wip` pacts that do not already have a successful verification from master (again, fetched dynamically from the broker) but NOT failing if the verification fails.

If you're using webhooks to send git commit statuses for your pacts, this means that the "pact verification status" for a commit on a branch will go green automatically once the provider has successfully verified the new pact.

I'd love some feedback on this design from our Pact Broker users, new and old. I'm pretty sure you'll have some thoughts @cfmack @kevin.meiresonne @matt.fellows @uglyog

has joined #pact-broker

This is a good idea, but the main concern would be the complexity in the process. Let's not re-use the tags for this purpose. A higher level concept would be better, maybe a status associated with the pacts and verifications defined a workflow that would allow it to be easy to understand why things are happening.

@uglyog you're right about not re-using tags. I'd like to use it to prove the concept with some of our users, before I invest in making it a higher level concept however. We could do it with almost no coding change.

has joined #pact-broker

if verifications are not verified at provider side, it should stop consumer from deploying the code to master.

we have similar situation in our project. We use git branches and want to make sure we can?t commit breaking changes to either consumer or provider side.

Our consumers are publishing pacts tagged by branch name. ex `wip` if that is my branch. When we push the code changes on consumer branch build, it publishes new pact with tag `wip` and verify it against provider `master`. If build passes, it means provider is still full-filling all the consumer expectations and good to deploy the consumer code.

else, it will fail the consumer build. We are not doing anything with provider build in this case.

to implement consumer?s new expectations, we create `wip` branch at provider side and add the code. When we push the provider code, it will search for pacts tagged with `wip` and verify them. If everything is good, we merge the provider branch to master. Now we have new changes in provider master branch.

if consumer build will run now, it will pass and can be merged to master.

@kevin.meiresonne I think this is pretty much what you're doing.

I've released consumer only/provider only/global webhooks in the latest version of the Pact Broker 2.23.0 (and the docker version 2.23.0-1). I've also released an update to the pact broker client that allows you to take a curl command to trigger a build (eg `curl https://ci.foo.org/builds -X POST -d {"foo": "bar"}`) and add a few params to save it as a webhook (eg `pact-broker create-webhook https://ci.foo.org/builds -X POST -d {"foo": "bar"}' --provider Foo --contract-content-changed`)

The following template variables are available now: ``` ${pactbroker.consumerName} ${pactbroker.providerName} ${pactbroker.consumerVersionNumber} ${pactbroker.providerVersionNumber} ${pactbroker.consumerVersionTags} ${pactbroker.providerVersionTags} ${pactbroker.githubVerificationStatus} ${pactbroker.pactUrl} ${pactbroker.verificationResultUrl} ``` Just a reminder that you can send pact verification commit statuses to github now. You can find a template for the request here: https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library

@jonas.lergell the official release is out now

has joined #pact-broker

@richard.jones ^^ regarding consumer only/provider only/global webhooks

has joined #pact-broker

That's indeed very close to what we're doing as well

Are these new variables already available on the hosted broker?

Yes

Still processing this idea in my head, but it sounds interesting. In our case our "master" is not called "master" though, so we'd have to change that in order to benefit from this.

Just a bit concerned if it would break our own workflow, which is already in place and very close to what @ragarwal describes in the blog post.

Master == configurable tag name.

It was just my example.

Tbh, I don't mind having to implement this workflow ourselves, since I can imagine it differs from case to case

I see this as supporting the branch workflow quite well.

yeah, I think it does, just a bit concerned about the "not being allowed to tag a pact as "master""-bit

so if you'd decide to implement this logic, I'd keep it optional

It would enforce what you already do manually, which is to ensure the provider can successfully verify a pact on a branch before you tag a pact as master.

the learning curve of pact and the broker is already quite steep, and you don't want people to pull their hairs out trying to figure out why they can't tag a pact

well, actually we don't stop the provider nor consumer to be already tagged as master

Yes, it is. There would obviously have to be very clear feedback built in.

we use the badges as a verification tool

(and the matrix)

Most people are quite upset about consumers breaking provider builds. This would turn that around.

While giving the consumer a mechanism to make proposed changes.

true

https://pact-foundation.slack.com/archives/C9VPNUJR2/p1529655967000032?thread_ts=1529626078.000169&cid=C9VPNUJR2 yes, it would definitely be optional.

but it could cause issues when a CI is setup differently and it does allow consumers to push to master before provider

which might sound weird, but it could just be their way of working

I mean, its often the chicken or the egg

Every ci is different!

we have for instance a BFF pattern (backend-for-frontend). Now, if we need to make a breaking change for the consumer of the backend, it doesn't really matter which one is pushed first to master

if you push provider first, the latest master of the consumer won't work until it's pushed to master as well

and vice versa

This could work, but the WIP should then be implemented in the PACT clients (as in I need to tell pact-jvm on the publish step and on the verify step trough a parameter that its in a branch.) (now ill start reading the whoel thread :wink:

My recommended workflow is to always push new changes to a non master tag, wait til the provider has verified it successfully on master then merge the consumer branch in.

it's different for a provider functioning as a general purpose api for instance, that needs to guarantee backwards compat

Yeah, that's indeed what we are moving to as well Beth

makes more sense

what would you consider a "wip" pact? Is this any pact not tagged with "master" or "prod"?

Yes @thadir we'd need to add the ability to say "try verifying all the wip pacts that don't have a successful verification already, but don't fail the build if they fail" to the verification configuration code.

I think this could work prity wel. Am at the point that I wanna revisit the pact configuration and pact steps in our CI so that I can actealy start tagging pacts at versions. And Also wana remove pact versions thats are stale. I atm dont tacg the provider that verifies the consumer. Bc it will always break if it doesnt setifies them all. And with WIP I can actealy use the matrix to also see what is in porduction and not. (seeing when its build it will go to production). So im in for this one

@thadir what do you mean about not tagging, because will always break?

You should be able to see what is in production already.

Hmm, atm any contract change from the consumer will break the provider. And not vise versa witch can be somtimes a problem. Its on my 2 do list to have some sort fo flow working that when a consumer builds on master it should be aible to check if the provider can verify there contract. And yes I can see it but (im a bit behind using all the features i am aible to version tag consumers in my ci but the provider part is messed up).

@matt.fellows pinned a message to this channel.

Yeah, the provider tags need to be used to get the real value from the matrix.

You can use the can-i-deploy tool to check the verification status of a pact from the consumer build. That's exactly what it's for.

If the contract hasn't changed since the last successful verification, it will come back true.

If you haven't read the Pact Nirvana document, this should help clarify how to use set up the tags in conjunction with can-i-deploy https://docs.google.com/document/d/e/2PACX-1vRf1kSDccImNipOOm1G-bjcSs-ifbZjf1v54K-dIcq8BLKeFPAAm_bf_p71UKqkRMIx30QWWL-kN8TI/pub

The doc is pretty ugly because it's still a WIP, and I've just published it from my google doc.

@bethskurrie, if these changes would be implemented, if I understand correctly, then the following workflow would no longer break the provider build

ah shoot, I can't paste images here

Basically the image describing the Consumer Workflow https://www.dius.com.au/2018/05/04/pact-testing-git-workflow-and-continuous-integration/

I love the idea of wip pacts... A problem I've hit recently is feature branches that forgot to update the version number on their first commit breaking the previous pact version

Totally, tags are a very flexible workaround tool ;D

Latest best practise is to always use or include the git sha dynamically in the version number. That should help you avoid that situation.

Actually, the more I think about the wip feature, the more I think, we don't need any change on the consumer side - we just need to add a "pb:wip-pacts-for-provider" relation/resource to the broker, and add code into the verification clients to say "don't fail the task if these verifications fail".

A "wip pact" would be a "latest tagged" pact that didn't yet have a successful verification.

This means the consumer team can push *any* new pact with a non-master tag, and get a verification result without breaking the provider build. If the new pact happens to pass without any changes being made to the codebase, then they can merge/promote (whatever their workflow is) that pact to "master" (or equivalent name), without the provider team having to do any work. This means that when the pact does become a "master" pact, it will be pre-verified, and the consumer can go straight into prod.

@matt.fellows I think this might achieve that no-waiting pipeline you were thinking of.

@uglyog ^^

This would involve almost no action on either the consumer/provider team's behalf, which should address @kevin.meiresonne?s concern that we need to keep it simple.

ty!

What's the format of the consumerVersionTags/providerVersionTags variables?

It's in the HAL docs

Click on the doc icon for the pb:webhooks relation in the HAL browser

I'm open to adding other formats too.

that's fine for me. Just a question: I currently resolve the tags by calling describe-version from within our build pipeline. If I understand correctly, this is now redundant and I can just use this variable instead?

It will give you the tags, but it won't tell you if it is the latest of that tag. I should make another var that only has the names of the tags for which this pact is the latest.

so describe-version will give the latest?

I think it's got a flag on the tag to say whether or not it's the latest.

Look at the JSON view of the response

Hmm, don't see that flag

just get a name and href

OK, it must be the matrix JSON I'm thinking of

Hi, I have a rather urgent issue with the hosted broker. It looks like our webhooks no longer work. Pact broker returns a statuscode 500 now. I've tested and verified the http request using postman to be sure it's not related to our build server. Recreating the webhook in the broker also didn't help. Can somebody from DIUS have a look at it? @matt.fellows @bethskurrie

Hello

Looking at it now

@kevin.meiresonne click on the webhook status cell in the menu

if you are using webhooks with headers, please upgrade to 2.23.2 (docker tag 2.23.2-1) as there was a bug found in 2.23.1 where the configured headers weren't being used when executing the webhook.

Thanks to @kevin.meiresonne for identifying it!

Thanks to @bethskurrie for fixing it ! :slightly_smiling_face:

Anyone else having issues with the hosted pact broker being unavailable atm?

@kevin.meiresonne uploaded a file: https://pact-foundation.slack.com/files/UB93QSC6T/FBDEYMPL3/image.png

We're getting this on the matrix, and 504's on the broker home page

Hi @kevin.meiresonne I'll look into that.

It seems to be up again. I think it was temporarily down while the kubernetes pods were rebalanced

There is work in progress already to improve our deployment process.

There was definitely a scaling even that seems to be over about 2am AEST

The quickest way is to open the URL in the HAL API browser and sent it a DELETE request.

A delete request to where?

Sorry @kevin.meiresonne I replied on the wrong thread.

has joined #pact-broker

Please let us know if you?re experiencing issues with your broker

Hi all, I have a question regarding the best practise use of the can-I-deploy cli cmd. If the Pact's have not been verified yet (perhaps they've just been published during the build), should the can-i-deploy *fail* the deploy step within the CI process? I would prefer that the deploy waits until it is verified, then either pass/fail the build appropriately. Anyone else overcome this? I'm primarily thinking of deploys to an integration environment, rather than production (at the minute). Also worth pointing out Im using Teamcity.

This is a really good question. If you're expecting the verification to happen within a few minutes, you could try polling with a time out to wait until the result comes back.

You should only have to do this when the pact content has changed - most of the time it will be pre-verified.

Did we chat about this on github? If we didn't, there's a new feature in the latest broker that will allow you to determine if you're waiting for a result still, or if it has failed.

I'd recommend that you write a little script that would poll for a given amount of time while there was an unknown result, and then pass or fail, based on the verification result. If this works for you, I might add it into the command itself.

has joined #pact-broker

@mr.matt.r.long I've added retries to the can-i-deploy for unknown results. Can you please try it and tell me how it goes? https://github.com/pact-foundation/pact_broker-client#can-i-deploy

"The steps to reaching Pact Nirvana" can be found here: https://docs.google.com/document/d/e/2PACX-1vRf1kSDccImNipOOm1G-bjcSs-ifbZjf1v54K-dIcq8BLKeFPAAm_bf_p71UKqkRMIx30QWWL-kN8TI/pub

@bethskurrie pinned a message to this channel.

Sorry Ive been away for a while. Thanks for the help on that, I'll let you know when I've had a chance to look into it.

Ta!

has joined #pact-broker

Hi all. I've added a Set up checklist for setting up a new integration to be tested using the Pact Broker. You can find it on the Pact Broker wiki (along with a heap of other useful info on the Pact Broker): https://github.com/pact-foundation/pact_broker/wiki/Set-up-checklist

This is great Beth!

Ta. Just adding a link to it in http://docs.pact.io

The only comment I have is that I thought you were about to demo how to integrate other things to it. E.g. web hooks

It's really the pipeline getting started, or best practices guide

Oh, right. Yeah, I meant consumer/provider.

The time limit for allowing a post to be edited is really short!

@mouser @andrewcfitzgerald I?m going to close down the other slack workspace now in favour of this - goodbye and hello :smile:

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

~Does the docker version of pact-broker require UID or GID root(0) access? I am trying to run it on my company's servers, and they disallow such access. Is there anyway to get around that?~

I am trying to write a dockerfile from the pact-broker image. How might I go about that? Also what are the permissions needed by the broker?

Have you looked at https://github.com/DiUS/pact_broker-docker?

I did just after I posted that question. It seems that the broker needs greater permission than 7447 (as mandated by security).

Permission on what? If you like, it's just a regular Ruby app so you can just create your own image and start it however you like. Or you could look at using http://pact.dius.com.au

@ssn899 can you explain that more? What permissions does it need?

I run it in my local machine without any special permissions, so I'm not sure what you're talking about. If there is something that needs changing, I'm happy to do it.

We run a modified version of the broker image on a kube stack without any special permissions too.

When I asked, I did not totally know what I needed. Sorry about that! So let me start again. What I am trying to accomplish is to host the Pact broker internally. (Security is here is pretty strict so http://pact.dius.com.au/ would not work. ) So to host in our own data center, root can not be used within the container. So I am creating a dockerfile based on dius/pact-broker to meet these security requirements. It seems that when starting the container, the broker runs `/sbin/my_init`, which I believe requires root. So I get the following error ``` Traceback (most recent call last): File "/sbin/my_init", line 414, in <module> main(args) File "/sbin/my_init", line 331, in main export_envvars() File "/sbin/my_init", line 114, in export_envvars with open("/etc/container_environment.sh", "w") as f: PermissionError: [Errno 13] Permission denied: '/etc/container_environment.sh' ``` (Ignore the whole 7447 thing, I was confused lol)

Wait ignore above, I think I fixed it. Sorry about that! :slightly_smiling_face:

:+1:

I just had a talk with an ex workmate who refused to use pact because of the ability of the consumer team to break the provider builds. I'm even more convinced of the usefulness of the wip pacts and the "build protection" features now.

I've been musing on whether I'd done the right design, but I think I just need to ship it and find out.

build protection, yeah, I can see that

but I think the main thing is changing the vision/mentality. It's not consumer driven anymore, it's collaborative

I think there needs to be a healthy tension between the two, and both should be in agreement to be in compliance

I?ll catch up on the rest of notifications over the course of the next couple of days.

But one thing I will say from talking to clients today - that is a challenge. How do we orchestrate the sequence of adding new features in the contract without breaking the builds in a seamless way

we?ve raised the same concerns internally too, although not to the point of refusing to use it. instead we thought we can come up with a process that solves it.

I think it's mostly a UX issue. I believe we need to adhere to a more "github style" approach: create a branch for a new contract for both consumer and provider, once they both work, both are merged into "master" and deployed

unless I'm not understanding the problem

That the way I always recommend.

@mboudreau thing is that with that suggestion you are coupling the github branching methodology with how pact works

And that's a bad thing?

in my opinion yes.

real world scenario in our webapps group (~30 devs) - there are a couple of teams working on a legacy system which is basically a monolith on the frontend and on the backend and they can?t move fast for different reasons like code quality, tests coverage etc. so they release once a sprint. on the other hand, there are also a couple of other teams which built their microservices systems as greenfield projects and can enjoy from trunk based development and CI/CD. So completely different git workflows employed by teams working on the same platform that eventually integrate with one another.

I'm with Liran on this. After all we're a set of tools, which need to be able to work in different contexts

Some contexts just won't be suited to CDC at all, but contract tests against legacy systems I see as a huge opportunity to solve

Every customer seems to be migrating away from their previous arch/approach and struggle to meet in the middle

Interesting. I still don't exactly see how branching/versioning via contract would break that approach, let it be greenfield or monolith

If we're allowing people to define their own workflows, then yes. I think we're just saying we shouldn't be too prescriptive

hello :wave: support issues here :slightly_smiling_face: - the pact icon links (when viewing the front page with tags) all take me to latest on our hosted broker, - also seems to be running pretty slow (but that might just be the internet in this building)

has joined #pact-broker

Seeing a fair few 503/4s from broker right now

Anyone else experiencing issues?

Nothing from our monitoring folks

Everything looked pretty normal that time for us across the system, will take a look at your individual cluster this morning @fergusstrange764

i saw a failed publish from a provider ci job around that time as well. seemed to clear up after a few minutes though

Thanks, will dig into that a bit more.

@abubics the first one is a genuine bug. Can you raise it in the pact_broker OSS repo please?

Will do :)

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

Hi folks, I might be missing something but I can?t seem to find a JSON to poke at in the broker to retrieve the latest verification results for a provider (I can do so for a consumer which is super awesome!). I can get a list of pacts from /pacts/provider/[name] pb:pacts but then the individual pact fetch doesn?t include the verification result (it?d be super nice if that first JSON listing the name had the verification result in the pb:pacts entries :smile: )

I *could* fetch all consumer results for each consumer and match the name back to the provider but that?d be potentially much more expensive :slightly_smiling_face:

Hey @richard.jones I just haven't added it yet because I didn't have a use case driving it. You can get to it through the UI though.

I can easily add it to the API.

Can you tell me what you're trying to achieve?

I?d prefer not to scrape the HTML :slightly_smiling_face:

HA. No.

If you use the can-i-deploy tool and turn it to JSON, you'll find the link to the relevant verification result.

`--format json` I think. Or `--output json`

I?ve got a monitoring dashboard (grafana) that displays a bunch of information about our systems, including pact verification results. Now that we have verification results in the broker I can stop asking Bamboo whether a pact verification job failed, and instead ask the broker :slightly_smiling_face:

Hmm, I?ve not used can-i-deploy - I?ll look into it, thanks

There are also the build badges

That would be an easy way to display the information.

This data goes into a database which we can then query by team and use in a number of ways

Let me know if that doesn't get you what you want.

I don?t have ruby stuffs installed on the VM I?m running this on so I?ll have to figure that stuff out :slightly_smiling_face:

You don't need ruby

it's a standalone cli

ooh, nice, thanks!

If you're using the broker without can-i-deploy, you're not really getting the full benefit of contracts. I highly recommend learning about it.

Step 7.

We?re still working on fixing a lot of the fundamentals which we didn?t get right in our implementation a long while back, and practises are embedded now, so we there?s a lot of momentum to shift. There?s a lot of interest from folks here in the dashboard work I?m doing in terms of visibility of pact information.

(for example, we?re not using tagging, we?ve still got two separate pact broker installs for ?dev? and ?master?)

:cry:

yah

Did the course with Ron help?

Definitely! It?s cleared a whole lot of confusion up here ? slowly :wink:

Things are much better post-Ron :slightly_smiling_face:

Ha. I'll have to quote that to him.

I'm itching to come out and be allowed to sort out the workflow!

We could probably use another visit (to have some weight of authority added to our plannig), but I think we?ve got a pretty good idea what we need to fix

It all takes time and $$!

Poking at can-i-deploy it still seems to be the consumer-oriented results whereas I?m after the provider view (all consumers of a provider)

I have a solution for now, can proceed.

Richard, you should be able to give either a consumer or provider name - it makes no difference.

Yep, but it only gives me the consumer results (the service in question is both consumer and provider)

ie. ```$ ~/Downloads/pact/bin/pact-broker can-i-deploy --pacticipant PriceServicePython --latest --broker-base-url ... Computer says no ¯\_(?)_/¯ CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? -------------------|---------------|-----------------------|---------------|--------- PriceServicePython | 2.3.0-1f6e135 | ProductService | 0.1 | true PriceServicePython | 2.3.0-1f6e135 | BranchService | 0.0.0 | true PriceServicePython | 2.3.0-1f6e135 | CustomerPythonService | ??? | ??? PriceServicePython | 2.3.0-1f6e135 | GSTService | ??? | ??? PriceServicePython | 2.3.0-1f6e135 | PriceLikesService | 2.1.0-cd077c7 | true PriceServicePython | 2.3.0-1f6e135 | StateService | ??? | ??? ```

(you can get a small glimpse there into the progress we?re making cleaning up a whole lot of things to make this work well :slightly_smiling_face: - only one participant has meaningful versioning and only 1/2 of them even register verification results)

well, two participants have versions

(as for the varying naming of participants, file that under ?please, don?t ask? :smile: )

if it only gives you the consumer results @richard.jones there is a bug

Ah, ok

If it is a provider and consumer, you should get both rows

I'm sure I have test cases for that, but I often find that real world data has corner cases that I haven't thought of.

Did you find the json switch for it?

Also, can you raise an issue in the pact_broker repository and I'll look at it as soon as I can.

@richard.jones is the version number that's used for the verifications exactly the same as the version number that's used when the pacts are published? ie. is its consumer version number the same as its provider number? If they're different, whichever one was published most recently will be considered the latest, and the other one won't be included in that query.

@bethskurrie Indeed, the versions do not match

I am not sure if I will get an answer, but I hope to start a discussion. A couple days ago I (very incoherently) posted about permissions within the `dius/pact-broker` image. Upon close examination, I see that the image is `FROM phusion/passenger-ruby24:0.9.26`. Phusion puts stuff in /sbin/my_init as root, and there is no way to change that (https://github.com/phusion/baseimage-docker/issues/264). From my understanding, it is not a good idea to run root in docker images. See http://blog.dscpl.com.au/2015/12/don-run-as-root-inside-of-docker.html and https://github.com/docker/docker-bench-security. My company mandates that docker containers run without write or execute permission. Is there any other way to get a docker version of the broker such that it runs without need of root (or one that builds `FROM` a different image)? I know that Matt said that it is possible to create my own image, but how can I do that while satisfying the permission restrictions? (I am also pretty new to docker)

It's a ruby app, you don't need phusion passenger to run it at all. It can be run in a pure Ruby image with `rackup` to start it

If you can run it locally first without docker your hand way there

But to deploy on our infrastructure, it needs to be a docker image.

So run it in a Ruby docker image, not a phusion passenger one

Wait, so I could just replace `FROM phusion/passenger-ruby24:0.9.26` with `FROM ruby`?

Pretty much. And then you start the Ruby process like you would on your desktop. Nothing special about it!

No tricks :laughing:

So you'll need to change `CMD`

What would I need to change `CMD` to?

Does it have to be anything specific?

Well atm phusion manages the process its own way. If you just look at the broker code base itself you just need to replicate the steps to running on your desktop in Ruby. So example https://github.com/pact-foundation/pact_broker/blob/master/example/README.md

Something like `bundle exec rackup -p 1234`

I get the following error when I run `bundle exec rackup`: ``` bundler: failed to load command: rackup (/home/app/pact_broker/vendor/bundle/ruby/2.5.0/bin/rackup) ```

So when I run with docker-compose, I get the following logs: ``` broker_app_1 | [2018-07-27 21:33:26] INFO WEBrick 1.4.2 broker_app_1 | [2018-07-27 21:33:26] INFO ruby 2.5.1 (2018-03-29) [x86_64-linux] broker_app_1 | [2018-07-27 21:33:26] INFO WEBrick::HTTPServer#start: pid=7 port=9292 ``` when I navigate to `localhost:9292`, I get localhost refused to connect.

@ssn899 make sure port 9292 is exported. Passenger runs on port 80, so the passenger based image will expose port 80

Thanks! When I navigate to localhost, I get `localhost didn?t send any data.`

@ssn899 you'll need to pass in `-p 80` when you start the process (if your permissions allow that) because you will have problems if you try to bind 80 on the host to 9292 in the Ruby process (the issues comes because the URLs don't get rewritten correctly, and Rack rejects requests that are not sent to the port that it's bound on.)

You'll hit problems if you try to run the current ruby app without any sort of web server in front of it. For starters, the default ruby app server (webrick) is single threaded, so at the very least, you'll need to add the `puma` gem.

Actually, having read that thread about the sudo permissions, you're not going to be able to run it on port 80 (or 443 if you're using ssl), so you'll need to pick a higher port to run and bind it to.

That's one approach, you could also scale the number of containers you run and have them all single threaded anyway. Also running as a root user in container is not necessary a security issue, it depends on how the underlying docker daemon is setup and maps users to the host

I agree. But that decision is out of our hands!

fwiw, this is fixed as I check it this minute :slightly_smiling_face: I never got around to raising the issue, though :thinking_face:

Yeah, I fixed it.

I was going to @ you in the commit, but I couldn't remember your github username.

has joined #pact-broker

Where can I see an example of what `${pactbroker.githubVerificationStatus}` looks like?

Google "github commit api"

I meant, does it contain any verification metadata?

No it's the string

Have a look at the webhook template library in the pact broker wiki

error, failure, pending, or success

Ok, gotcha. Through `${pactbroker.verificationResultUrl}` you can then get to the details of the verification result.

I think we only use success, failure and pending

Yes.

In the presence of a webhook for `contract_content_changed`, if a consumer publishes multiple pacts, and more than one pact changes, would the webhook be invoked multiple times?

If you created a webhook with a specific consumer and provider, then it would only be invoked once if that pact had changed. If you created a webhook for a particular provider (recommended) then that webhook would only be invoked once if that pact had changed, as each pact belongs to a different provider. If you created a webhook for a particular consumer, then the webhook would fire once for each pact that had changed.

Thanks again :slightly_smiling_face: Can you create multiple webhooks for the same provider? For example if you want to trigger verification on two different branches for the provider.

Yes

Fantastic! Thank you!

np

has joined #pact-broker

I?m trying to set up the pact-broker for local development

but I?m encountering issues when running `bundle install`

I?m on Mac

What version of `mysql` should I have installed?

Postgres :-P

Just comment out the gem.

You won't need it.

When you say, local development, do you mean you want to run it, or work on it?

If you just want to run it, follow the instructions on the readme for setting up the example. You shouldn't need mysql.

I was following this: https://github.com/pact-foundation/pact_broker/blob/master/DEVELOPER_SETUP.md

I am no ruby developer, but I wanted to look into how easy it would be to contribute

In that case, comment out mysql

You only need it on Travis.

The entire test suite runs against mysql, postgres and sqlite, but when you run it locally, they'll just use mysql by default.

Is there anything else I have to do before I can run `bundle exec pact_broker:dev:setup` besides - `gem install bundler` - clone - `bundle install` ?

I don't think so, but I've probably not run it for ages.

What problem are you facing ml

?

``` bundler: command not found: pact_broker:dev:setup Install missing gem executables with `bundle install` ```

Ha. You probably need rake.

It was a silly idea of mine to make a rake task to install things.

I should have made a shell script.

Just look at what it does and run it manually

It's just copying the example dir from memory

`rake pact_broker:dev:setup` worked fine

And I have a pact broker running locally

Oh! Yes. I didn't realise the command was missing the "rake'.

First PR?

Maybe! I will see if I can get my head around it.

:slightly_smiling_face:

If I get a moment, I'll try to add a bit more description to the developer docs.

mysql or postgres?

Gah! I meant sqlite.

:slightly_smiling_face:

@antonello I pushed a bit more documentation that might help you find your way around

thanks @bethskurrie!

@bethskurrie and everyone else here, I have a question, which may also be partly related to new WIP feature. It?s a bit long and perhaps a convoluted, but stick with me. Let?s say that - aside from feature branches - *Provider* has 3 branches at any single time: `master`, `release_candidate` and `production`. *Consumer* follows the same branching structure, so at any given time - apart from feature branches - it will have `master`, `release_candidate` and `production`. You have 3 webhooks for Provider, one for each of the 3 provider branches. All 3 provider branches, when built, verify pacts tagged with consumer tags `master`, `release_candidate` and `production`. This is because you want to know if a change made to Consumer and pushed to either `master`, `release_candidate` or `production` is compatible with all 3 provider branches. If you DID NOT do the above, the following could happen: - a field is added to Provider?s API response - the change is pushed into the `master` branch of Provider - Consumer starts consuming the new field and modifies the pact interaction - the change above is pushed to the `master` branch of Consumer - the webhook is fired and this will build Provider?s `master` branch - the verification succeeds (the pact won?t be a WIP pact anymore) - the Consumer team promotes the change to Consumer?s `release_candidate` branch - no webhook is fired because the pact has not changed - the Consumer releases the release candidate - Consumer is broken in production because in production the new field is not present in Provider?s response Conversely, by having the 3 webhooks I mentioned above, you will know whether the Consumer change you are promoting is compatible not only with Provider?s `master` but also with its release candidate and production versions. However you would end up with Provider?s `release_candidate` and `production` pipelines being red. On the one hand, I think that this may be a desirable side effect, because you want something that would stop you from promoting Consumer when it is incompatible with the Provider version that is in production or that may be about to go to production. On the other hand, how do you deal with Provider being red if you want to release it? Would the Provider team (which obviously may be the same team) say: ?Consumer, before you can push that change to master, we need to have released our change first. So revert you change please and let?s make a plan together?. Any thoughts on this? Is there something I am getting terribly wrong or that I?m missing?

has joined #pact-broker

can-i-deploy will stop the consumer deploying or promoting when it shouldn't.

The consumer won't be able to deploy the release candidate because there is no corresponding verification by the provider with the release candidate tag.

Yes, this workflow forces the provider to deploy to production before the consumer can be released to production, but you shouldn't need to have red builds on the provider. Let me get my head around it.

I think the key is "the consumer promotes the pact to the release candidate branch". At this stage, the broker will compare the pact content to the previous latest pact content (regardless of tags). Perhaps I need to make it tag aware. Let me ponder.

One of the features that I don't think you've included in the above plan is the "build protection" (which I haven't yet implemented). It's the ability to say, "consumer can't tag a version with a tag that could break our build until it's already been verified as a wip pact by the corresponding branch". Eg. If master branch of the provider verifies the master branch of the consumer, then a particular pact content must have been verified as a wip pact by the master provider before it can be published or tagged as a master pact by the consumer.

It's a bit convoluted, sorry!

Basically the pact has to have gone through the wip verification before it can be allowed to go through the real verification.

Thanks @bethskurrie. I think I get it. I?ll re-read it tomorrow morning. I?m half asleep now. :sweat_smile: I think I?ve overlooked can-I-deploy, so that?s some reading for tomorrow and I will have to get my head around how to use it in a way that encourages ?shifting left?.

can-i-deploy is an absolute requirement for a workflow as sophisticated as yours. The consumer has to check the verification results, otherwise there's no feedback loop to let them know when they've got an invalid contract.

I was thinking that the feedback loop could be provided by the webhook for the publication of the verification results.

I'd rely on can I deploy more than the webhook results.

Callbacks can be missed, or requests fail, or interleave.

Fetching the latest results is the most reliable method.

It's the pattern of "allow things to subscribe to change notifications, and then let them fetch and decide what to do with the data" pattern. I can't remember the short name!

Yes, it makes complete sense. So, another thing related to this conversation. In the example I?ve given, you?d have the `release_candidate` branch for Provider verify only Consumer contracts tagged as `release_candidate`, and the `production` branch for Provider verify only Consumer contracts tagged as `production`.

Actually, no - I don?t think that would work.

?the broker will compare the pact content to the previous latest pact content (regardless of tags)? -> this means that if a new pact published by Consumer `master` (and then verified by Provider `master` following a webhook), when Consumer is then promoted to `release_candidate`, the webhook won?t be fired, because the pact content won?t have changed from the previous one.

Clearly can-i-deploy could stop you from deploying `release_candidate` Consumer, because there is no corresponding verification by the provider with the release candidate tag. But then you?d have to manually trigger a Provider `release_candidate` pipeline. And how do you get around the fact that not only do you want to verify pact changes against `master` and `release_candidate` but also against the `production` version of Provider?

I would have each branch of the provider verify each branch of the consumer.

And I think I'll have to modify the logic for webhook firing.

It will need to check the tags as well.

?I would have each branch of the provider verify each branch of the consumer? -> This would do, but it comes with two problems, I think. 1) Your feedback loop suffers from a potentially painful delay. In order to know if your Consumer release candidate is compatible with the Provider release candidate, you have to wait until you?ve cut release candidate branches. 2) You won?t be able to verify the Consumer release candidate with the Provider production version.

Not unless you check out the prod provider codebase and run the verifications against it.

How long do your verification tests take?

Do you use swagger by any chance in this codebase?

I can?t say yet as we currently only a few tests that have been written as PoCs. The client is unwilling to move forward unless it?s clear how it?ll all fit in in terms of CI.

There is some swagger documentation for some of the services, but not all.

If your verification tests take more than a few minutes, something is not right.

When you say ?checkout the prod provider?, do you mean as a manual step?

It could be an automated step.

Have you read the pact nirvana doc?

It's the last step in there.

I don't generally think it should be necessary if you deploy the provider often though.

I hadn?t read it, will read it today.

I think it will answer some questions

You've already worked most of it out.

I don't understand what you mean by "cut release candidate branch"

If it's all seeming too hard, one alternative is to use the swagger workflow

It's not fully supported by the broker yet though.

Basically, provider publishes a swagger doc with each build, and when it deploys, it marks that version as the prod/release candidate etc. It needs to use dredd to make sure it matches its own spec.

Currently everything gets released together, and pact is seen as one of the tools that is going to enable them to start breaking things up and move towards releasing services independently. The workflow is that feature branches are merged into master and when they want to release (usually twice a week), a release branch is created from master for all the services/applications.

The consumer uses the atlassian pact swagger validator to check its pact against the swagger doc.

That branch is used for regression testing and it?s then released to production. Once the release is successful, it?s merged down to the production mirror branch and to master.

Something that makes that workflow a bit trickier is that your shas will change every time you merge, right?

Yes.

So you can't reuse a verification result from the previous branch.

Tricky.

If you could get people to commit to swagger/dredd (or some other way to keep swagger in sync with your code) the swagger method might simplify your workflow.

has joined #pact-broker

?The steps to reaching Pact Nirvana? guide is really well written. It all makes sense and it is - after all - along the lines what was already in my head. I have some questions, though. ?To reach Pact Nirvana, the final step is to have a CI build that checks out the code for the production version of your provider, and have it verify the same pacts that the head version does?. This makes complete sense and it could be triggered by a webhook, but it obviously means that that CI build will go red if a verification fails. Also, when it says ?If you have followed the recommended strategy of tagging provider versions in the broker on deployment to production?, is it referring to using `pact-broker describe-version`?

Yes.

> it obviously means that that CI build will go red if a verification fails. I would imagine this would be a side build, outside of the master build pipeline. Wouldn't you want it to go red?

You have such a complex set up, I'm really quite wary of using the pact only flow. It's sounding really complicated. Did the swagger workflow I described make sense? Would it be an option for you?

I haven?t done any reading on it yet. I only remember a talk from Atlassian that I watched on YouTube some time ago.

I think we can find a way to make a pact only flow work, with some compromises.

Million dollar question... when do you think the WIP feature will be released?

The code is actually done, I was just trying to work out what to call it.

I think I've decided to call it "pending" instead of "wip". I can have it out as soon as I get the time to do a release. I'll try and do that in the next few days.

By the way, because for each service we have a branch that is always inline with prod, we can do without having to tag provider versions

I think I can find a way to make it work, the only thing that?s missing really is having the `contract_content_changed` logic tag based.

has joined #pact-broker

What languages are you doing your verifications in @antonello?

I'll see if I can do the tag thing.

@bethskurrie Verifications in Java. (Consumers are more varied)

I?ve started looking into the tag thing and I have an initial implementation. I?m not sure if it?s right though. I?ve added some tests for the repository, but haven?t finished the service tests.

I was in the process of pushing the changes to a fork but didn?t get a chance to finish.

I can see if I manage to do that before going to bed (it?s 11 pm here) so that you could review the changes?

I'm doing parenting work today, so I may or may not get a chance. I'll be doing Pact work tomorrow (actual job) so I can review them tomorrow.

I think that means you can go to bed...

has joined #pact-broker

Hey all, question on the docker pact broker. I know i found the answer to this before in the docs but I can't for the life of me find it again. To persist the data in the postgres th it needs to have a mounted volume, which postgres tables or store should that mount be against?

I would look in the docs for the postgres docker image

It will be something configurable like `PG_DATA`

You'll need to explicitly set it probably

has joined #pact-broker

After some conversations with @bethskurrie, I?ve just created a PR: https://github.com/pact-foundation/pact_broker/pull/226 Hopefully Beth will get a chance to review it later tomorrow (or today, depending on timezones!), but if anyone would like to have a look and provide feedback, they?ll be more than welcome. Also, if anyone could help me understand whey my PR would fall below the Codeclimate diff-coverage threshold, I would appreciate it. I?ve heavily tested my changes, so I?m struggling to get what?s happening there.

has joined #pact-broker

Hi, I'm getting a 504 trying to access my pact broker - is this the right place to report issues?

what is the URL for your broker?

DM'd you

Sorted - thanks!

has joined #pact-broker

if you are using the OSS docker pact broker, and you have been having problems with slowness or large database size, please upgrade to the latest version, as I have made some significant optimizations to the "index with tags" queries, and removed the massive pre-cached matrix table. This should make your broker run faster and cheaper!

has joined #pact-broker

has joined #pact-broker

Hello Guys, i have a basic question about the pact broker. in case of a failure in pact verification, how can i know from the pact broker, what was the cause of the error. Example, expected statusCode 200 and got 201. I see that from the maven console, when mvn:pactVerify is run, but is there a way to track it from the pact broker?

@amitojduggal it depends which language you're using. JVM does not have this yet, but the shared library that js, python, net and go use have this capability if they are on the latest version of what we call the "standalone".

Which language are you using?

@bethskurrie - a general question about the broker: which APIs could be considered reasonably settled for now - is something like /pacts/provider/ProviderName/latest very unlikely to change, or should I be wary of making that assumption?

Always use the HAL relations.

If there's something you can't get to, let me know.

Most of the API is stable, but I make no promises for the future!

I've been planning a v2 where I want to standardise the naming a bit better, but I have no timeline for that yet.

HAL is ? a pain to work with, but I will do so. So I should use pb:latest-provider-pacts from the root HAL, gotcha!

Why are you finding it a pain?

it?s just? meh

Do you have a client library?

It would suck doing it manually, but there should be a HAL client for all languages.

It?s very ?well, JSON is all nice, but it really needs more SOAP? :smile: But more seriously, I think it?s that the current HAL client library for Python isn?t very user-friendly, and involves a lot of guesswork to make things work.

I wrote my own for the pact ruby, because I don't like to add dependencies that might clash with the user's ones.

It was quite simple, and simplified my code greatly.

we did the same for Pact Node, sorta. Depending on what you do, you don?t really need a lib

For example, this code from pactman to publish results: ``` params = dict(success=self.result.success, providerApplicationVersion=version) overrides = dict(action='POST', encoding='application/json', fields=[coreapi.Field(name='success'), coreapi.Field(name='providerApplicationVersion')]) coreapi_client.action(self.hal, ['publish-verification-results'], params=params, overrides=overrides, validate=False) ``` vs the requests version: ``` http://requests.post(self.hal['publish-verification-results'].url, json=params) ```

and it took me ? far too long to figure out that arcane hal_client version :confused:

That does look verbose.

anyhoo, thanks for the tip, will not hard code that URL

My code does not look like that!

I?m looking around for a nicer client

I just did a bare minimum impl in 4 classes

Entity, link, http client, response

I?d prefer not to have to write my own HAL implementation, plenty of Pact-related code to write :slightly_smiling_face:

Fair enough

https://github.com/deontologician/restnavigator looks like a much nicer interface, I?ll experiment with it

`http://pact_entity.post(PUBLISH_RELATION, verification_result)` is the Ruby code.

For tagging `provider_entity._link(VERSION_TAG_RELATION).expand(version: provider_version, tag: tag).put`

yep, this library looks similar

just having a look at the readme. looks much better than that first example.

way, way simpler :smile:

Right, that?s all fixed :smile:

@bethskurrie Thanks, i am using JVM.

So this capability has to be build on the pact-jvm side, i can work on it; give me some pointers. :slightly_smiling_face:

:wave: I seem to be having issues DNS resolving `http://pact.dius.au`

Did you mean `http://pact.dius.com.au`?

....Ha yes

Thanks. My mistake.

:ok_hand:

Freaked me out!

can we download pact file from broker ? is there any API available for that ?

Yes of course.

Have you looked at the documentation?

i am making use of pact stub server to bring up the mocked provider(https://github.com/uglyog/pact-stub-server), for this can i link the pact files that are in pact broker ?

wiki for pact broker says like, this is the endpoint for retrieving the pacts, http://your-pact-broker/pacts/provider/PROVIDER/consumer/CONSUMER/latest

I think so.

Have you tried it?

yeah, when i tried to pass that URL as the pact file location, stub server was not able to recognise it as a pact file

Are you using basic auth?

I'm pretty sure the URL feature is supported.

it says -U is for url resource, can we pass on that broker endpoint here ?

If the -u doesn't work, then please create an executable code example demonstrating the problem and raise an issue in the repo

Yes.

sure, thanks Beth :slightly_smiling_face:

If you're using basic auth, you'll need to include the credentials in URL form I would expect.

no, broker is open, its not having any auth

Does the broker do anything ?magic? if it receives a pact that is identical in content, for the same consumer version and with exactly the same tags as the previous one?

In other words, should it show up as a new version?

Yes

It ignores it

Yes, it is magic. No, it is not a new version.

I should?ve asked 2 hours ago.

It makes sense

Is the magic based on all those 3 criteria?

The tags are irrelevant

They belong to the version resource

It's just based on the content and the consumer version number

Ordering of interactions and keys is ignored.

Thanks @bethskurrie

Does the broker just return a 200 regardless?

Actually, I could check the code myself

I think it returns a 201 if a new resource was created, and a 200 otherwise

Why?

Just curious. I was using the maven plugin which used the jvm broker client and it spits out the status code after publishing. It just says published (obviously), I?ll check later if I was getting a 200 rather than a 201.

That versioning page in the docs is really good, I recommend reading it if you haven't.

Someone else wrote it better than I could have!

I read it last week when I was making the change to the broker, but I?d forgotten!

Hello ! with pact broker new deployment i am getting Publishing 'A-B.json' ... FAILED! 302 Moved Temporarily - <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> </body> </html>

any pointers around this?

Where is it redirecting you to? How are you publishing it?

Hi @bethskurrie from the endpoints will i be able to get the details like whether that pact file has been verified or not ?

Use the can-i-deploy tool

i saw that broker client/can-i-deploy tool, but there are some restrictions in our environment to use such tools. Thats the reason i am planning to get those details by querying the broker

Turn on verbose to see the queries it makes.

sure, thank you :slightly_smiling_face:

Hi! It would be nice to pick your brain on something. The current git flow that my client uses is like this: - development is done on feature branches of `master` - branches are merged into `master` after testing - a `release-1.x.x` branch is taken from `master` for regression testing/fixing - once a release is ready to go live, it gets merged into a branch called `maint` from which the production artifacts are built - if a hotfix (or unplanned release) is required, a `hotfix-1.x.x` branch is created from `maint` - once the hotifix goes live, the branch is merged into `maint` from which the production artifacts are built All these branches publish pacts with a matching tag (`a-feature-branch-name`, `master`, `release_candidate`, `hotfix`, `maint`). Once a release has gone live, the appropriate pacticipant(s) versions and tags are tagged as `prod`. We want to make sure (among other things) that the `master` and `release_candidate` branches of the providers verify the latest pacts (among other tags) published with a `release_candidate` branch. Now, the issue is that once a hotfix release has gone live, any pacts tagged as `release_candidate` may be ?out of date?, as a new release may have gone live. How could we address the problem?

Hey, thanks, we were able to figure it out, it was because of redirection of the apis to a single sign on page internally.

Ahh :+1:

Is this because the hot fix never went through the release candidate branch?

As long as you're verifying the production pacts as well, I don't think it's a problem.

If you have a specific release process for the hot fix release, you could tag the same version as release candidate when you deploy.

There may be a main release candidate and a hotfix branch going on at the same time.

I'll go back to, what is the problem if you're verifying the prod version as well?

Yes. Prod will be the definitive one. Once prod has gone live we wouldn?t want to verify Any previous versions tagged as release candidate or hotfix.

I just had a though though. All consumer are versioned with a release number (1.123.0, 1.123.1 and so on) + a sha. We could only verify pacts tagged with release and hotfix if the release number is > than that?s in prod.

I?m not sure if the provider verification we use (mvn plugin) would allow that or if it?s even sensible.

I'm going to go back to my theory that using the swagger workflow would be simpler for you.

This is just feeling crazy complicated.

There is a desire to make it simpler in the future

I wonder if you could just skip all the checks except for the prod and main line of development.

Maybe checking for each environment isn't necessary

If you imagine that prod has interactions 1 and 2, the latest dev has 1,2, 3, 4, and 5, and the intermediate branches have somewhere in between, maybe you only need to check each end of that spectrum.

That is exactly what I think we may end up doing

There is a risk of a bit of a delay in feedback but can_i_deploy will tell us

has joined #pact-broker

Hi, I recently noticed that env variable `PACT_BROKER_BASE_EQUALITY_ONLY_ON_CONTENT_THAT_AFFECTS_VERIFICATION_RESULTS` exists for the docker image. The doc states that the default is true but I can only find this place where it is set in the code: https://github.com/pact-foundation/pact_broker/blob/fa827c4122e742e13d5432da3dc24c3bec2423f1/lib/pact_broker/configuration.rb#L76 Am I missing something?

Is there a way to set the broker to use pactSpecification version 3.0? My provider states aren't showing up and I think it's because the broker is expecting V2, but I'm using V3. I didn't see anything about it here https://github.com/pact-foundation/pact_broker/wiki/Configuration

It supports them for publishing etc, it just doesn't render them yet

Thanks, do you know when rendering is coming?

Nope. It's not hard, just needs some time

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

ive been running a personal broker on a free heroku instance and just got a notification that i'm close to the row limit for the free tier. ? do i remember there being something that was improved about the efficiency of how data was persisted? was there a command suggested to reduce the size of old data related to that? ? is there a recommended way to remove old versions that arent providing as much value anymore, or is that discouraged?

@slack1 grab the latest version - the data storage will be much less as I'm not storing the cached "matrix" in it's entirety any more. It will remove the data in the "materialized matrix" table in the migrations.

You can totally remove old versions that aren't used any more - I wrote a script to do it, but it was hard to do it in a general way, because the pacts that can be safely removed depend on how you're using it.

Eg. if you don't use tags, you can basically remove any pacts that aren't the latest ones. If you do use tags, you can remove any pacts that aren't your "prod" ones, or one of your "dev" ones that may be promoted to prod soon etc..

How's your ruby @mmonson? :wink:

thank you very much for the info

has joined #pact-broker

I know that postgres is the recommended database for pact-broker. My question is that how strong recommendation is it? We have some limitations in introducing postgres at the moment as we already have mysql and mongo databases. We want to avoid adding a third database to the mix.

we're not so concerned about the support for json search at this moment. The major concern is around the support for mysql, I see some issues in the past around mysql migrations failing from time to time.

Each build is tested against MySQL so in theory it should work.

We run production broker systems on postgres so can speak to its stability, that's not to say you should have any issues with MySQL

MySQL is fully supported now, if grudgingly :wink: @culbluswan123

I believe that since we first made the decision (5 years ago?), MySQL now supports JSON searching. I should probably remove that comment.

Yes, MySQL 5.7 onwards there's support for JSON data type.

Thanks @matt.fellows and @bethskurrie

It would be helpful if the wiki and README are also updated to reflect the same. At least the fact that MySQL is fully supported

Beth just pushed a few changes to that repo - so should be up to date now :slightly_smiling_face:

Hey @antonello did you manage to work out a flow that you were happy with?

Hey @bethskurrie! Not yet. I?m trying to get the team to engage so that we can make some trade offs together, but they haven?t engaged much.

has joined #pact-broker

I see `Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.` with latest pact broker docker. Any suggestions? Thanks.

You can't do anything, unless you want to submit a PR. I just haven't gotten around to writing the code to display v3 pacts.

Not a ruby person yet. I could help with Java, react, python etc.. never used ruby. Will have to wait then :-)

Is it possible to change tag in pactbroker? *Scenario*: *1)* I run consumer tests in CI (mvn test), *2)* publish pact tagged as head: `mvn pact:publish -Dpactbroker.tags=head`.. *3)* deploy in QA environment, test software *4)* deploy in production *5)* Change latest `head` tag from `head` to `prod`. In step 5: Instead of running consumer tests again to generate pacts and then publish, I would like change latest `head` tag from `head` to `prod`. Can I achieve that? Thanks.

You can tag as many times as you like. Something can be latest head and latest prod.

Use the pact broker CLI

The recommend approach is to tag with the branch name and the stage name.

So a pact may be latest master, test and prod all at the same time.

Tag with the branch name when you run CI, then with the stage name every time you deploy.

This allows you to use can-i-deploy to make sure you can safely deploy a compatible version to a given environment.

thanks. sure. Then I can add a tag to an existing pact? Will have a look at pact broker cli.

Of course.

You actually tag a pacticipant version, not a pact.

But pacts can be identified by the tags on their version.

hmm okay thanks.. will check pact broker cli and do some thinking. :slightly_smiling_face:

Have a read of the "reaching pact nirvana" doc. There's a link to it in the pact broker wiki.

It explains how to get the most out of tagging.

Thanks quick q: suppose we tag a pacticipant version 1.0 as ?prod?, then we make some changes and then tag pacticipant version 2.0 as ?prod?. Now when we run provider test to validate against contracts tagged as prod (`mvn test -PproviderTests -Dpactbroker.tags=prod`), it will be run only against version 2.0 of pact, right? (although both 1.0 and 2.0 are tagged as prod)

Yes @gaurav it only validates the latest with the specified tag.

thanks. :slightly_smiling_face:

Potentially weird question: say we have a new provider and we?d like to start up our automated monitoring system to check for failing pacts against it. There?s no consumers registered yet though, but AFAICT there?s no way to register a provider with the broker outside of registering a pact - so the latest-provider-pacts list will 404 rather than return an empty list. Just wondering what folks thoughts might be on this. Also relevant, I guess: the HAL libraries I have access to all handle the 404 case poorly, and barf because there?s HTML being returned instead of JSON.

1. You should get a JSON 404. I need to fix it if you're getting html

2. You can create a pacticipant with no pacts. Just post to /pacticipants with a JSON document with a name.

1: ok, thanks! 2: ahah! I had forgotten that, thanks, that?ll solve the problem even betterer :smile:

Hey @richard.jones. We've fixed the content type for 404s, but just wondering if your tool cares whether you get an empty body, or if it expects a `{}`?

We've gone with empty body for now, but it can change.

Hm, I honestly am not sure what the HAL libraries will do in either case. Thanks for fixing the content-type tho!

np. we're just pushing out the new docker image

(sorry, my round tuits for testing such behaviour are in incredibly short supply at the moment)

np

it probably doesn't matter

currently getting a 503 response when trying to push pacts to our hosted instance. any known problems right now?

i can go to the instance in the browser and i do get prompted for credentials, but then get a page with just the text "Service Unavailable" (it also has the 503 status code)

appears to be back

Hi folks, We've looked into a couple of point issues and resolved them today. if anyone else is experiencing issues don't hesitate to hit us up directly.

Apologies, looks like there were some intermittent issues which resolved itself, and we made some adjustments. Sorry about the interruption!

Anyone else having issues publishing to pact broker after upgrading gradle to 4.10.1? I get this response `HTTP/1.1 200 OK`, but the file on the broker hasn't changed.

Gradle version shouldn't make a difference, unless they have changed some core library. Debug logs will help (running with `-d`). Also check that the pact files have actually changed :wink:

Morning guys, can someone tell me if the pact broker docker image is compatible with windows?

I have some feeling that there has been trouble binding to port 80. But otherwise, it should be. I'm not a docker expert, but shouldn't all docker images be windows compatible?

Hi Beth, I wasn't sure as the readme for the docker image suggests having to set environment vars for connection strings and the like, obvs thats easy enough to do in windows but the readme seems geared toward linux so just wanted to ask the question :slightly_smiling_face:

Should be OK. As long as you can bind to port 80 on the host.

We managed to get this working and deployed in Azure Container instances yesterday, worked nicely with minimum effort! If anyone wants any help or instructions PM me!

Would you be interested in adding notes to the readme @richard.peckett?

sure thing, will do this tomorrow when I've got some free time

Good to know. I couldn?t understand why it wouldn?t work, but theory != practice

has joined #pact-broker

Still going to do this, sorry completely forgot over the weekend!

:grinning:

has joined #pact-broker

has joined #pact-broker

Hi, The Matrix on Pact Broker shows the high-level verification results, is there any way in Pact Broker where a user can see detailed verification result. For Example:- A detailed result which shows what was the contract and what is an execution result as well (e.g. which user gets while executing verification goal using maven).

Not in the JVM implementation. @uglyog is it reasonably straight forward to add an appender for the pact verification tests that would publish the results to the broker? In the ruby impl I just made another rspec formatter, it was quite easy. I'm not sure how the JVM outputs work though.

I could probably have a go at it myself now I'm back in the Java world, sigh.

:+1:

@bethskurrie Are there any API's which can be used to generate custom report for PACT tests

has joined #pact-broker

has joined #pact-broker

Hi :wave: guys. Attempting to set up a pact broker via a local docker implementation using Postgres. When running test.sh step 11 fails after posting a heartbeat status url followed by `Waiting for the Pact Broker to be ready...parse error: Invalid numeric literal at line 1, column 10` I?d appreciate any help I can get on this

according to the log in nginx it's having difficulty connecting to the postgres instance

fixed :smile:

What was the issue? anything worth sharing?

wow, great new issues :ok_hand:

@bethskurrie the Pending pacts feature, is that technically in the codebase now just not yet documented?

It needs an env var to be turned on in the verifier

I do need to document it.

has joined #pact-broker

Any strategy on how to output the whole error stack on state setup stage? At the moment I get `Failure/Error: set_up_provider_state interaction.provider_state, options[:consumer]` which is not very helpful.

Hey @antonios.klimis - which language? Might be best asking there

it looks unrelated to the pact broker

Ok @matt.fellows!

:thumbsup:

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

Hi all, I have a question about the pact broker. I?ve published a pact for consumer C1 and provider P1 to the pact broker. And it is posted successfully with the correct version and listed on the matrix view as well as the pact list view. But when we trying to retrieve it, the pact was for a different consumer C2 to the same provider P1. Anyone has any idea what?s going on?

I've never heard of that happening. Can you look at the logs and identify which url it's publishing to, and which one it's being retrieved from?

Yup, I?ve checked the log and confirmed that the url is the same

Cause I can see the specific version that I?m publishing in the matrix and pact list view

Can you write a script to reproduce it on another broker?

hmm.. let me try that

can you share what are the two consumer names?

I wonder if it?s some edge case with regards to lower/upper case letters or special chars being stripped off or something

@sylvia.yap how do you retrieve retrieve it?

@liran.tal The consumers are SalespersonService and UserServicePython. The provider is EmployeeService

@matt.fellows I?m retrieve the pact from the url {host}/pacts/provider/EmployeeService/consumer/SalespersonService/version/2.7.0-cd7b8710

@sylvia.yap I'm just getting you a test broker so you can try and replicate it against a database that I can then use to debug. Unless you can send me a copy of your database.

@sylvia.yap I'm going to PM you credentials to a test broker. Can you try and replicate it there, and I should be able to debug it.

I haven't been able to recreate it locally

@sylvia.yap ok another idea. maybe the problem is actually on publishing the contracts to the broker and that?s why the get mixed. Is it possible you can test how you are publishing it? maybe you are using the wrong consumer name?

@liran.tal Thanks for the suggestions and I think Beth found the issue, and it has been fixed now (#249 was raised for this bug)

Ahh cool, happy to hear!

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

Is the pact-broker down? My team reports that their managed pact-broker is not responding?

@bethskurrie ^

@hstene looks ok to me. What is the name of the broker instance your team use?

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

The hosted pact broker seems to be down... We're getting 503 responses.

Yeah same here.

has joined #pact-broker

@ugly is on it.

@uglyog!

Thanks @bethskurrie

We're planning to start moving customers to put our new environment tomorrow

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

Hello, Our back broker was previously set up but not being utilized. It is now giving us a 404 `https://aramark.pact.dius.com.au/` did it get shut down?

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

has joined #pact-broker

Hi @bethskurrie! Is it possible to customise the title or name of a webhook? Unless I?m missing something it does not seem to be possible.

has joined #pact-broker

Hi @bethskurrie trying to verify the published contract and its always getting timeout

``` Animal Profile Service listening on http://localhost:8081 Pact Verification [2018-12-03T14:54:07.105Z] INFO: pact-node@6.20.0/45416 on : Verifying Pacts. [2018-12-03T14:54:07.107Z] INFO: pact-node@6.20.0/45416 on : Verifying Pact Files [2018-12-03T14:54:10.336Z] INFO: pact-node@6.20.0/45416 on : Created './standalone/darwin-1.61.1/bin/pact-provider-verifier 'https://test.pact.dius.com.au/pacts/provider/Animal%20Profile%20Service/consumer/Matching%20Service/version/1.0.1543848742' --provider-base-url 'http://localhost:8081' --provider-states-setup-url 'http://localhost:8081/setup' --broker-username 'dXfltyFMgNOFZAxr8io9wJ37iUpY42M' --broker-password 'O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1' --publish-verification-results 'true' --provider-app-version '1.0.0' --custom-provider-header 'Authorization: basic e5e5e5e5e5e5e5'' process with PID: 45417 1) should validate the expectations of Matching Service 0 passing (30s) 1 failing 1) Pact Verification should validate the expectations of Matching Service: Error: Timeout of 30000ms exceeded. For async tests and hooks, ensure "done()" is called; if returning a Promise, ensure it resolves. (/Users/sai.krishna/Downloads/pact-js-master/examples/e2e/test/provider.spec.js) at Test.Runnable._timeoutError (/Users/sai.krishna/Downloads/pact-js-master/examples/e2e/node_modules/mocha/lib/runnable.js:440:10) at Timeout.<anonymous> (/Users/sai.krishna/Downloads/pact-js-master/examples/e2e/node_modules/mocha/lib/runnable.js:251:24) at ontimeout (timers.js:482:11) at tryOnTimeout (timers.js:317:5) at Timer.listOnTimeout (timers.js:277:5) ```

any help on this ?

has joined #pact-broker

Hi! Does the pact-broker support pacts using the version 3.0.0 spec? I have uploaded an async message pact to my broker, and I see this message when navigating to the pact in the UI: `Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.`

@andrew.nicholson yes it supports them, it just doesn?t render them yet. There is probably an issue in the broker for this, feel free to upvote (or better yet, a PR :slightly_smiling_face: )

All the usual operations work on them though (publish, retrieve, verify etc.)

You might need to provide some more help on this. Could be a transient network issue, could be a firewall etc.

can you navigate to the broker in the browser?

Noted, thank you!

:thumbsup:

We're doing a deployment of the hosted pact broker that will hopefully fix the 502s during deployment. Hopefully, you won't experience a 502!

has joined #pact-broker

has joined #pact-broker

Possible bug with how(when?) `provider-verification-published` event is handled in webhooks. Took reference from the template library https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library#github---publish-commit-status to create the webhook. ``` { "request": { "method": "POST", "url": "https://api.github.com/repos/ORG/${pactbroker.consumerName}/statuses/${pactbroker.consumerVersionNumber}", "headers": { "Content-Type": "application/json", "Authorization": "**********" }, "body": { "state": "${pactbroker.githubVerificationStatus}", "description": "Pact Verification Tests", "context": "${pactbroker.providerName} ${pactbroker.providerVersionTags}", "target_url": "${pactbroker.verificationResultUrl}" } }, "events": [ { "name": "contract_content_changed" }, { "name": "provider_verification_published" } ], "createdAt": "2018-12-04T06:17:26+00:00" } ``` But I guess that during creation `${pactbroker.providerVersionTags}` wasn't available, which is why two different statuses were created

Say i use tags for knowing which versions are deployed in which environment. So when i deploy my application i tag the deployed version `55555` with `prod`. This works fine and i can fetch the pact with `/pacts/provider/aaa/consumer/bbb/latest/prod`, but what if i deploy an old version say `44444` to prod now? The endpoint still returns the `55555` pact. Do i have to delete tags when i deploy a new version? How should i do that?

Yeah, that's tricky.

I'm afraid you would have to delete the tags from the later versions.

It's a bit of an unusual use case.

Can you explain it further?

We figured that putting tag in context doesn't help anyway, since it will keep making the status check different for each branch. Which means that we won't be able to make the status check required for the repo. Just the provider name as context works better.

We currently have a microservice architecture with a handful components. Before we deploy a component i want to check whether the component is compatible with the other components deployed to the environment.

So if one component has been deployed to `prod`, but then rollbacked to an older version. They both have the `prod` tag, but the latest endpoint returns the newest version.

morning peeps, does the broker support contracts for AMQP yet? (sorry if it's been asked a zillion times, I couldn't see anything about it in CHANGELOG.md on github)

So when i use `can-i-deploy` with `--to prod` it verifies against the wrong version (Which is no longer in the environment).

@bethskurrie ^

Hi, broker shows v3 specs just liker json file

has joined #pact-broker

Hey up all, I am working on a new greenfield application, integrating with some back end services. I am reasonably familiar with micro-service architecture and consumer driven contract testing. For around 5 years, I have advocated swagger use for documenting API's, especially in the initial start up phase, as it is always so hard to get people to agree to something concrete, especially in agile teams. I was recently introduced to PACT a few weeks ago, and instantly bought into the concept. I thought it would be a great asset to our team. I have built a POC which have received really great feedback. - It incorporates 4 providing API's and a single consumer. (although for demonstration, I incorporated a 2nd consumer, who hasn't followed the swagger design spec, to show PACT verification failures) - A pact broker is hosted on an ec2 instance with an rds postgres db - Consumers are publishing to the pact broker with a version number and git short commit sha `1.0.0-a43d33` and tagging with a branch name - Consumers are using `@pact-foundation/pact` written in typescript, executed with jest - Consumers are using `pactfoundation/pact-stub-server` docker with generated pact files, for component integration testing - Publishers are verifying against the hosted pacts. currently using `1.x.x` style versioning - Showed the use of can-i-deploy from the console with the pact ruby standalone app, but have mentioned that there are web hooks that can be used to trigger provider verification, when a consumer publishes a new pact. Things I am having trouble with in PACT (but haven?t investigated yet in the broker code) - Provider version numbers such as `1.0.0-a43d33` are rejected, I was only able to use <1.0.0> - branch names such as `feature/ABC-10` are not tagged Some questions that have been pitched by the client - Can we get reports that we can send round in an email? The console output from provider verification is well formatted, but only the JSON from the pact-broker looks to be visible. I need to look into report formatters. Devs were pleased to see that we could run the provider verification without publishing results to the broker (so they could get a decent report after a verification has failed) - it looks like a lot of hard work. - I am sitting on the consumer side, and we have already built it into our pipeline so we are publishing pacts to a broker. It looks to me that on the provider side, their touch points with PACT is light. They don?t need to own or provide their consumer a mock, to allow them to work in insolation. The verification is simply ensuring they have implemented their contract correctly and the clients expectations have been met. There is a point on provider states, but that isn?t PACT specific - we would always want our provider to provide test data & states to stimulate different test cases as in any other api testing framework. Things I need to investigate - provider versioning (want to include git short sha) - branch tagging (want feature/ABC-10 format branches to show up in the broker) - reporting of verifcation failures in a pretty format - provider states

PS. Thanks for the awesome work Dius crew :fist:

I don't have time to address all your issues right now, but I will get back to you. I've quick question, which version of the broker are you using? The date ordering should be turned on in the latest version, so the version number can be anything. Also, I've fixed the tags with slashes issue.

It sounds like you have an old version.

> - it looks like a lot of hard work

It's not insignificant, but compare it to the work you would do if you were trying to do everything via traditional integration tests. As the number of interactions increases, traditional integration tests scale exponentially, where as contract tests scale linearly.

As always, you as the developer need to make informed decisions based on the tradeoffs in your particular situation. Generally, at least some level of contract testing gets a better ROI than 1. nothing or 2. only doing traditional integration tests.

We're having some issues with the hosted environment at the moment, and will be pushing out a fix soon.

*How to Add Provider Side Tag to Pact Broker* ? i am able to run the provider verification successfully and publish the result to pact broker but not sure how to attach tag to pact broker from provider side ? using the pactNet:

I'm not sure if the .net impl has it yet. You can raise an issue in the pact-net repo, and in the meantime, use the pact broker client CLI

> "traditional integration tests scale exponentially, where as contract tests scale linearly" sounds like a cool concept that could strengthen my team's interest in contract testing. Would love it if you could elaborate a bit

@bethskurrie Could you explain to me what is unusual about my use case (or how I should do it differently) as we spoke about previously in the thread? (https://pact-foundation.slack.com/archives/C9VPNUJR2/p1543916586017400) I tried to elaborate in the thread, but i would think rollbacking is something that might be needed occasionally for everyone (?)

I have worked with a 20 microservice eco system, where we covered everything with traditional integration tests, but also ran CDC tests within the same framework, and used mocks generated with Wiremock. This has been simpler to implement as your framework is very well documented and reasonably mature. The pact-broker is a great tool to allowing a central repository for expectations, and the swagger mock validator, helping to tie the pacts (and therefore our development) up to our swagger specs will be invaluable. Our first pass of the swagger-mock-validator threw up 68 errors, where the swagger has evolved but these changes were not communicated to the consumer dev team. It will be interesting to see it play out. There are still decisions to be made on our provider side, latest news is that we are going to have an api gateway acting as a pass through to some internal services, so we may have to look at non-http based contract testing options available within PACT. @madhukar.mishra - Contract testing is an invaluable tool in API development. If your team is interested in some reading https://martinfowler.com/articles/consumerDrivenContracts.html or get some pizzas in for lunch and get them to watch this https://www.youtube.com/watch?v=-6x6XBDf9sQ

Thanks for getting back to me, there is no rush. I am currently using `x-pact-broker-version: 2.27.3` and have noted its a few versions behind so will get it updated!

@bethskurrie -Thank you, i will raise an issue

I guess I've mostly worked in "roll forward only" environments. If there's a bug, it gets fixed and a new version goes out.

These are environments where ci/cd is strong, and releases are quick and frequent.

So it's just simpler to go forward.

I understand that different places have different methods of working though.

@yousafn great, let me know if you're still having any of those problems

the broker supports all json documents.

whether or not it displays them nicely is another question!

:thumbsup::skin-tone-3:

@madhukar.mishra > "traditional integration tests scale exponentially, where as contract tests scale linearly" When you test from a "high" level, (eg traditional integration tests) you have to execute paths you have already tested before, just to get to get to the place where you can test the thing you're interested in. Eg. you have to execute login for every test, and if you have 100 tests, you have to execute login 100 times. With a contract test, you would test login once.

This is why it scales so much better. If there is a new endpoint, you implement and execute one (or maybe a few, if there are variations) new test. If you're using integration tests, you may have to make multiple API calls just to get to the place where you can test the new call. And then, perhaps, you want to test variations on it, so you're adding n*y new calls to the suite. It's easy to see why integration tests get out of hand so quickly.

I see, think i will try to write a script for deleting the tags then. Thanks for the replies! :slightly_smiling_face:

I have an issue similar to described here: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1543915335013800 with webhooks and `provider_verification_published` event.

my webhook looks like this: ```{ "consumer": { "name": "NAME" }, "events": [ { "name": "provider_verification_published" } ], "request": { "method": "POST", "url": "https://api.github.com/repos/ORG/project/statuses/${pactbroker.consumerVersionNumber}", "headers": { "Content-Type": "application/json" }, "body": { "state": "${pactbroker.githubVerificationStatus}", "description": "Pact Verification '${pactbroker.providerVersionTags}' ${pactbroker.consumerVersionTags}", "context": "PACT-${pactbroker.providerName}-${pactbroker.providerVersionNumber}", "target_url": "${pactbroker.verificationResultUrl}" }, "username": "...", "password": "...." } }``` and issue I experience is that `${pactbroker.providerVersionTags}` doesn?t show anything. Although the `${pactbroker.providerName}` and `${pactbroker.providerVersionNumber}` are present. Any idea why? I use pact-broker `v2.27.5`

It?s crucial to us because we run two verifications every time contract changes once on `develop` and other on `master` to know where is it now ready and whether or not was it released. And we store the branch name in the provider tags.

even when I try to test the webhook run through `pb:execute` I do not get the `tags` :confused:

I discover that for lookup via `tag` with `pact_uri` like: `https://pactbroker.project.com/pacts/provider/Elli/consumer/Demeter/latest/develop` in `_links` section for `"pb:publish-verification-results"` returns not the same version of contract that was in return but returns latest pushed contract variant. Any thoughs why it happend? Also same other version I see in `"pb:diff"` section. It bites me much on `rake pact:verify` run because then the verification is submit to a different version of contract and it ends with a mess. @bethskurrie

looks like `pact_version_sha` is different from `consumer_version_number` on same `represented` pact record

@bethskurrie can you help me somehow?

has joined #pact-broker

Hiya! We're getting 401s from the broker - implying our credentials have been rotated

What's the best place to keep track of this?

Hi Richard, can youoo please DM me with more detaials?

cross posting this from #general: for some reason from my ubuntu machine I can `dig http://foo.pact.dius.com.au` just fine but when I do `curl http://foo.pact.dius.com.au` I get `Could not resolve host: http://foo.pact.dius.com.au` any DNS changes happened recently?

is `foo` important to you or are you obscuring the real domain?

``` > dig http://foo.pact.dius.com.au +short *.http://pact-prod.dius.com.au. 13.211.26.183 13.236.214.174 ```

obscuring the real domain. foo -> grofers in my case

has joined #pact-broker

@matt.fellows http://portbase.pact.dius.com.au could not be resolved either.

I'm experiencing the same problem as @ashish.dubey91 Coleagues on Windows can reach the site, but on Ubuntu I can't. Our Jenkins build server on linux experiences UnknownHostException. Anyone?

Hiya we're having the same DNS resolution issues

It seems http://foo.pact.dius.com.au is being redirected to *.http://pact-prod.dius.com.au which is breaking the DNS lookup

You can getaround it by using http://foo.pact-prod.dius.com.au (but the SSL cert is wrong)

Hi guys. We've done some DNS magic to migrate to the new infrastructure without downtime (or that was the plan!) This had had some unexpected effects. We'll address them asap.

Sorry about the inconvenience. The new environment will be much more stable than the old one once we've sorted out the teething issues.

Ok @d.van.dijk @richard.hulm @ashish.dubey91 can you try again now?

I'm guessing you're all probably asleep. The joys of working in a global distributed industry!

it works now! :slightly_smiling_face:

I'm curious to find out though how DNS resolution behavior was weird with the changes you guys did

Mac -> dig and curl are both able to resolve. On Ubuntu however, dig is able to find A records but not curl

It seemed only to be the case on Ubuntu but could more likely be related to specific versions of tooling/network stack

But yes, strange

My guess is that some implementations do some extra smarts when there are wildcards involved.

It should also be noted that it did work on other Linux variations (in our case Amazon Linux)

Yes, it works

thanks

:thumbsup:

All good - thanks for your help @bethskurrie and @matt.fellows (Quite right - we're in the office ~9-17 GMT! Woo worldwide economy :stuck_out_tongue: )

@bethskurrie any chance getting some help on this?

has joined #pact-broker

Few days ago I posted an issue yet got no answer. But I believe it?s a real flaw in pactbroker. Any chance someone can help me? https://pact-foundation.slack.com/archives/C9VPNUJR2/p1544194044044700

If that?s true, I think the best starting point would be to create a bug on the pact-broker repository, with something we can use to reproduce the issue.

It would surprise me if nobody had noticed this, as it is critical functionality. I won't rule it out thought. Can you please create a script to recreate it @ravbaker? Note that the verifications belong to the content, not the consumer version, so if the latest has the same content as the latest develop, the verification result will apply to both.

I upgraded my local pact docker from 2.24.0 to 2.27.6 and I'm having issues with viewing some pacts

I get the following error:

`this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.`

but other v3 contracts are rendering OK

does the pact broker not support v3 pacts in all cases?

the old version rendered it just fine

> does the pact broker not support v3 pacts in all cases? The broker doesn?t support _visualising_ v3 pacts at all. It supports them for all the usual operations, you just can?t render them

Render them nicely

are you sure other v3 pacts are rendering OK? (perhaps they are v3 part aren?t using any of the v3 features)

They render the JSON

has joined #pact-broker

Any plans to add some of the v3 features to the pact broker UI? Specifically for the markdown pact document. 1. multiple provider states 2. provider state variables

lol as always i should check if matt posted a response to my question right before i posted it

If you?re feeling generous, it shouldn?t be a big PR :slightly_smiling_face:

Ha maybe this weekend

Is the web ui code in the pact broker repo?

Can you point out where the pact rendering code is?

yep, at the moment

ummm? maybe

somewhere in here -> https://github.com/pact-foundation/pact_broker/tree/master/lib/pact_broker/ui

Haha i am there

actually, maybe not

I see the network view

But not the actual pact

It?s going to be a new Resource I think

Something like this https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/api/resources/latest_pact.rb

and https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/api/renderers/html_pact_renderer.rb

The latter being the `text/html` ?renderer? for the new resource

Oh god

Ruby

Ha ok i will explore this when i have some time

indeed