bethskurrie
2018-03-29 22:13
added an integration to this channel: https://pact-foundation.slack.com/services/B9YEJCV19
bethskurrie
2018-03-29 22:14
removed an integration from this channel: https://pact-foundation.slack.com/services/B9YEJCV19
bethskurrie
2018-04-05 04:28
added an integration to this channel: https://pact-foundation.slack.com/services/B9YEJPQQK
mr.matt.r.long
2018-06-11 15:18
@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
bethskurrie
2018-06-11 21:33
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).
matt.fellows
2018-06-11 21:54
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.
mr.matt.r.long
2018-06-12 07:55
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
mr.matt.r.long
2018-06-12 09:11
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?
bethskurrie
2018-06-12 10:04
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?
mr.matt.r.long
2018-06-12 10:05
I'm in process of introducing Pact to my new team. They're largely JVM based, but there's one Go client too
bethskurrie
2018-06-12 10:05
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.
bethskurrie
2018-06-12 10:06
Unfortunately, pact-jvm has a bug whereby it publishes verifications automatically. I've just raised an issue to have that changed.
bethskurrie
2018-06-12 10:07
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.
bethskurrie
2018-06-12 10:08
Here's an example consumer https://github.com/pact-foundation/zoo-app/blob/master/.travis.yml
bethskurrie
2018-06-12 10:09
It only publishes contracts when the tests pass, and the publish is only called on the CI.
bethskurrie
2018-06-12 10:09
Here's an example provider configuration https://github.com/pact-foundation/animal-service/blob/master/spec/service_consumers/pact_helper.rb
bethskurrie
2018-06-12 10:13
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
bethskurrie
2018-06-12 10:14
I think I'll add a bit on only publishing from CI, thanks to your question.
mr.matt.r.long
2018-06-12 10:26
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:
bethskurrie
2018-06-13 21:07
abhilash.hanumanth
2018-06-16 10:08
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 ?
abhilash.hanumanth
2018-06-16 10:20
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);
}
```
matt.fellows
2018-06-16 10:35
You?ll need at least 3.5.4 as per https://github.com/DiUS/pact-jvm/issues/417#issuecomment-323260710
abhilash.hanumanth
2018-06-16 10:49
@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'```
abhilash.hanumanth
2018-06-16 12:52
@matt.fellows: For some reason, my provider version is empty in the Matrix.
abhilash.hanumanth
2018-06-16 13:30
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 ?
abhilash.hanumanth
2018-06-16 15:19
@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.
2018-06-16 15:19
A file, which can't be shown because your team is past the free storage limit, was commented on.
abhilash.hanumanth
2018-06-16 15:30
Last verified column is not populated in pact jvm 3.5.17 but gets populated in 3.5.16 pact jvm.
matt.fellows
2018-06-16 21:35
You could use `System.setProperty(...)` or, more appropriately during CI builds, use the standard `-D` flags to the java command running it
uglyog
2018-06-17 00:19
@abhilash.hanumanth there is a defect in 3.5.17, see https://github.com/DiUS/pact-jvm/issues/694
rlamb
2018-06-19 21:10
Where do I find the doc on how to add users with basic auth to the pact-broker-docker?
shekharsp27
2018-06-20 13:46
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"
bethskurrie
2018-06-21 03:13
@shekharsp27 Did you look at the URL that it told you to read for more information?
bethskurrie
2018-06-21 03:24
Have you tried looking at the documentation for the Pact Broker? https://github.com/pact-foundation/pact_broker/wiki
bethskurrie
2018-06-21 23:47
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.
bethskurrie
2018-06-22 00:04
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.
bethskurrie
2018-06-22 00:06
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.
bethskurrie
2018-06-22 00:07
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
uglyog
2018-06-22 00:23
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.
bethskurrie
2018-06-22 01:05
@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.
ragarwal
2018-06-22 01:34
if verifications are not verified at provider side, it should stop consumer from deploying the code to master.
ragarwal
2018-06-22 01:35
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.
ragarwal
2018-06-22 01:39
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.
ragarwal
2018-06-22 01:39
else, it will fail the consumer build. We are not doing anything with provider build in this case.
ragarwal
2018-06-22 01:41
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.
bethskurrie
2018-06-22 06:17
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`)
bethskurrie
2018-06-22 06:19
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
kevin.meiresonne
2018-06-22 08:20
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.
kevin.meiresonne
2018-06-22 08:22
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.
kevin.meiresonne
2018-06-22 08:24
Tbh, I don't mind having to implement this workflow ourselves, since I can imagine it differs from case to case
kevin.meiresonne
2018-06-22 08:25
yeah, I think it does, just a bit concerned about the "not being allowed to tag a pact as "master""-bit
bethskurrie
2018-06-22 08:26
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.
kevin.meiresonne
2018-06-22 08:27
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
kevin.meiresonne
2018-06-22 08:27
well, actually we don't stop the provider nor consumer to be already tagged as master
bethskurrie
2018-06-22 08:28
Yes, it is. There would obviously have to be very clear feedback built in.
bethskurrie
2018-06-22 08:28
Most people are quite upset about consumers breaking provider builds. This would turn that around.
bethskurrie
2018-06-22 08:31
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1529655967000032?thread_ts=1529626078.000169&cid=C9VPNUJR2 yes, it would definitely be optional.
kevin.meiresonne
2018-06-22 08:31
but it could cause issues when a CI is setup differently and it does allow consumers to push to master before provider
kevin.meiresonne
2018-06-22 08:34
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
kevin.meiresonne
2018-06-22 08:34
if you push provider first, the latest master of the consumer won't work until it's pushed to master as well
thadir
2018-06-22 08:35
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:
bethskurrie
2018-06-22 08:35
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.
kevin.meiresonne
2018-06-22 08:35
it's different for a provider functioning as a general purpose api for instance, that needs to guarantee backwards compat
kevin.meiresonne
2018-06-22 08:38
what would you consider a "wip" pact? Is this any pact not tagged with "master" or "prod"?
bethskurrie
2018-06-22 08:39
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.
thadir
2018-06-22 08:42
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
2018-06-22 08:51
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).
bethskurrie
2018-06-22 09:16
Yeah, the provider tags need to be used to get the real value from the matrix.
bethskurrie
2018-06-22 09:17
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.
bethskurrie
2018-06-22 09:18
If the contract hasn't changed since the last successful verification, it will come back true.
bethskurrie
2018-06-22 09:20
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
bethskurrie
2018-06-22 09:20
The doc is pretty ugly because it's still a WIP, and I've just published it from my google doc.
kevin.meiresonne
2018-06-22 09:31
@bethskurrie, if these changes would be implemented, if I understand correctly, then the following workflow would no longer break the provider build
kevin.meiresonne
2018-06-22 09:32
Basically the image describing the Consumer Workflow
https://www.dius.com.au/2018/05/04/pact-testing-git-workflow-and-continuous-integration/
abubics
2018-06-22 10:15
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
bethskurrie
2018-06-22 10:33
Latest best practise is to always use or include the git sha dynamically in the version number. That should help you avoid that situation.
bethskurrie
2018-06-23 11:02
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".
bethskurrie
2018-06-23 11:04
A "wip pact" would be a "latest tagged" pact that didn't yet have a successful verification.
bethskurrie
2018-06-23 11:05
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.
bethskurrie
2018-06-23 11:07
@matt.fellows I think this might achieve that no-waiting pipeline you were thinking of.
bethskurrie
2018-06-23 11:09
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.
kevin.meiresonne
2018-06-25 07:21
What's the format of the consumerVersionTags/providerVersionTags variables?
kevin.meiresonne
2018-06-25 07:39
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?
bethskurrie
2018-06-25 07:54
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.
bethskurrie
2018-06-25 07:59
I think it's got a flag on the tag to say whether or not it's the latest.
kevin.meiresonne
2018-06-25 11:28
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
bethskurrie
2018-06-25 12:41
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.
kevin.meiresonne
2018-06-25 15:52
Anyone else having issues with the hosted pact broker being unavailable atm?
kevin.meiresonne
2018-06-25 15:52
@kevin.meiresonne uploaded a file: https://pact-foundation.slack.com/files/UB93QSC6T/FBDEYMPL3/image.png
bethskurrie
2018-06-25 22:04
It seems to be up again. I think it was temporarily down while the kubernetes pods were rebalanced
matt.fellows
2018-06-25 22:04
There was definitely a scaling even that seems to be over about 2am AEST
bethskurrie
2018-06-25 22:08
The quickest way is to open the URL in the HAL API browser and sent it a DELETE request.
mr.matt.r.long
2018-07-05 13:38
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.
bethskurrie
2018-07-05 21:36
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.
bethskurrie
2018-07-05 21:38
You should only have to do this when the pact content has changed - most of the time it will be pre-verified.
bethskurrie
2018-07-05 21:40
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.
bethskurrie
2018-07-05 21:44
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.
bethskurrie
2018-07-09 11:20
@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
bethskurrie
2018-07-09 11:28
"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
mr.matt.r.long
2018-07-09 11:37
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.
bethskurrie
2018-07-11 22:49
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
matt.fellows
2018-07-11 22:54
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
matt.fellows
2018-07-12 23:12
@mouser @andrewcfitzgerald I?m going to close down the other slack workspace now in favour of this - goodbye and hello :smile:
ssn899
2018-07-17 17:13
~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?~
ssn899
2018-07-17 18:07
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?
ssn899
2018-07-17 21:35
I did just after I posted that question. It seems that the broker needs greater permission than 7447 (as mandated by security).
matt.fellows
2018-07-17 21:44
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
bethskurrie
2018-07-18 00:58
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.
bethskurrie
2018-07-18 00:58
We run a modified version of the broker image on a kube stack without any special permissions too.
ssn899
2018-07-18 19:21
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)
ssn899
2018-07-18 20:27
Wait ignore above, I think I fixed it. Sorry about that! :slightly_smiling_face:
bethskurrie
2018-07-20 04:43
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.
bethskurrie
2018-07-20 04:44
I've been musing on whether I'd done the right design, but I think I just need to ship it and find out.
mboudreau
2018-07-20 04:47
but I think the main thing is changing the vision/mentality. It's not consumer driven anymore, it's collaborative
mboudreau
2018-07-20 04:47
I think there needs to be a healthy tension between the two, and both should be in agreement to be in compliance
matt.fellows
2018-07-20 07:03
I?ll catch up on the rest of notifications over the course of the next couple of days.
matt.fellows
2018-07-20 07:03
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
liran.tal
2018-07-21 00:14
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.
mboudreau
2018-07-21 02:07
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
liran.tal
2018-07-21 07:48
@mboudreau thing is that with that suggestion you are coupling the github branching methodology with how pact works
liran.tal
2018-07-21 08:15
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.
matt.fellows
2018-07-21 08:22
I'm with Liran on this. After all we're a set of tools, which need to be able to work in different contexts
matt.fellows
2018-07-21 08:23
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
matt.fellows
2018-07-21 08:23
Every customer seems to be migrating away from their previous arch/approach and struggle to meet in the middle
mboudreau
2018-07-21 13:07
Interesting. I still don't exactly see how branching/versioning via contract would break that approach, let it be greenfield or monolith
matt.fellows
2018-07-21 13:40
If we're allowing people to define their own workflows, then yes. I think we're just saying we shouldn't be too prescriptive
abubics
2018-07-23 08:11
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)
matt.fellows
2018-07-23 20:55
Everything looked pretty normal that time for us across the system, will take a look at your individual cluster this morning @fergusstrange764
slack1
2018-07-23 20:56
i saw a failed publish from a provider ci job around that time as well. seemed to clear up after a few minutes though
bethskurrie
2018-07-23 22:47
@abubics the first one is a genuine bug. Can you raise it in the pact_broker OSS repo please?
richard.jones
2018-07-25 22:44
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: )
richard.jones
2018-07-25 22:47
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:
bethskurrie
2018-07-25 22:47
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.
bethskurrie
2018-07-25 22:48
If you use the can-i-deploy tool and turn it to JSON, you'll find the link to the relevant verification result.
richard.jones
2018-07-25 22:49
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:
richard.jones
2018-07-25 22:50
This data goes into a database which we can then query by team and use in a number of ways
richard.jones
2018-07-25 22:51
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:
bethskurrie
2018-07-25 22:53
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.
richard.jones
2018-07-25 22:54
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.
richard.jones
2018-07-25 22:55
(for example, we?re not using tagging, we?ve still got two separate pact broker installs for ?dev? and ?master?)
richard.jones
2018-07-25 22:56
Definitely! It?s cleared a whole lot of confusion up here ? slowly :wink:
richard.jones
2018-07-25 22:58
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
richard.jones
2018-07-25 23:04
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)
bethskurrie
2018-07-26 00:50
Richard, you should be able to give either a consumer or provider name - it makes no difference.
richard.jones
2018-07-26 01:56
Yep, but it only gives me the consumer results (the service in question is both consumer and provider)
richard.jones
2018-07-26 01:56
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 | ??? | ???
```
richard.jones
2018-07-26 01:58
(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)
richard.jones
2018-07-26 01:59
(as for the varying naming of participants, file that under ?please, don?t ask? :smile: )
bethskurrie
2018-07-26 04:42
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.
bethskurrie
2018-07-26 04:43
Also, can you raise an issue in the pact_broker repository and I'll look at it as soon as I can.
bethskurrie
2018-07-26 12:47
@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.
ssn899
2018-07-27 16:02
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)
matt.fellows
2018-07-27 19:18
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
ssn899
2018-07-27 19:38
Wait, so I could just replace `FROM phusion/passenger-ruby24:0.9.26` with `FROM ruby`?
matt.fellows
2018-07-27 19:39
Pretty much. And then you start the Ruby process like you would on your desktop. Nothing special about it!
matt.fellows
2018-07-27 19:49
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
ssn899
2018-07-27 20:43
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)
```
ssn899
2018-07-27 21:35
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.
uglyog
2018-07-27 22:27
@ssn899 make sure port 9292 is exported. Passenger runs on port 80, so the passenger based image will expose port 80
bethskurrie
2018-07-29 21:36
@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.)
bethskurrie
2018-07-29 21:37
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.
bethskurrie
2018-07-29 21:40
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.
matt.fellows
2018-07-29 21:48
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
abubics
2018-07-30 06:33
fwiw, this is fixed as I check it this minute :slightly_smiling_face: I never got around to raising the issue, though :thinking_face:
bethskurrie
2018-07-30 06:38
I was going to @ you in the commit, but I couldn't remember your github username.
antonello
2018-07-31 07:33
Where can I see an example of what `${pactbroker.githubVerificationStatus}` looks like?
antonello
2018-07-31 07:42
Ok, gotcha. Through `${pactbroker.verificationResultUrl}` you can then get to the details of the verification result.
antonello
2018-07-31 08:44
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?
bethskurrie
2018-07-31 09:36
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.
antonello
2018-07-31 10:16
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.
bethskurrie
2018-08-01 08:13
When you say, local development, do you mean you want to run it, or work on it?
bethskurrie
2018-08-01 08:13
If you just want to run it, follow the instructions on the readme for setting up the example. You shouldn't need mysql.
antonello
2018-08-01 08:14
I was following this: https://github.com/pact-foundation/pact_broker/blob/master/DEVELOPER_SETUP.md
antonello
2018-08-01 08:15
I am no ruby developer, but I wanted to look into how easy it would be to contribute
bethskurrie
2018-08-01 08:17
The entire test suite runs against mysql, postgres and sqlite, but when you run it locally, they'll just use mysql by default.
antonello
2018-08-01 08:20
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`
?
antonello
2018-08-01 08:20
```
bundler: command not found: pact_broker:dev:setup
Install missing gem executables with `bundle install`
```
bethskurrie
2018-08-01 08:28
If I get a moment, I'll try to add a bit more description to the developer docs.
bethskurrie
2018-08-01 09:55
@antonello I pushed a bit more documentation that might help you find your way around
antonello
2018-08-03 16:21
@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?
bethskurrie
2018-08-05 21:53
can-i-deploy will stop the consumer deploying or promoting when it shouldn't.
bethskurrie
2018-08-05 21:55
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.
bethskurrie
2018-08-05 21:58
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.
bethskurrie
2018-08-05 22:04
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.
bethskurrie
2018-08-05 22:08
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.
bethskurrie
2018-08-05 22:10
Basically the pact has to have gone through the wip verification before it can be allowed to go through the real verification.
antonello
2018-08-05 22:36
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?.
bethskurrie
2018-08-05 23:13
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.
antonello
2018-08-06 06:57
I was thinking that the feedback loop could be provided by the webhook for the publication of the verification results.
bethskurrie
2018-08-06 07:24
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!
antonello
2018-08-06 08:40
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`.
antonello
2018-08-06 09:10
?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.
antonello
2018-08-06 09:15
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?
bethskurrie
2018-08-06 09:33
I would have each branch of the provider verify each branch of the consumer.
antonello
2018-08-06 09:42
?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.
bethskurrie
2018-08-06 09:43
Not unless you check out the prod provider codebase and run the verifications against it.
antonello
2018-08-06 09:45
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.
bethskurrie
2018-08-06 09:45
If your verification tests take more than a few minutes, something is not right.
bethskurrie
2018-08-06 09:47
I don't generally think it should be necessary if you deploy the provider often though.
bethskurrie
2018-08-06 09:50
If it's all seeming too hard, one alternative is to use the swagger workflow
bethskurrie
2018-08-06 09:52
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.
antonello
2018-08-06 09:52
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.
bethskurrie
2018-08-06 09:52
The consumer uses the atlassian pact swagger validator to check its pact against the swagger doc.
antonello
2018-08-06 09:53
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.
bethskurrie
2018-08-06 09:53
Something that makes that workflow a bit trickier is that your shas will change every time you merge, right?
bethskurrie
2018-08-06 09:55
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.
antonello
2018-08-06 14:18
?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`?
bethskurrie
2018-08-07 00:48
> 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?
bethskurrie
2018-08-07 00:49
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?
antonello
2018-08-07 06:37
I haven?t done any reading on it yet. I only remember a talk from Atlassian that I watched on YouTube some time ago.
antonello
2018-08-07 06:38
I think we can find a way to make a pact only flow work, with some compromises.
antonello
2018-08-07 06:48
Million dollar question... when do you think the WIP feature will be released?
bethskurrie
2018-08-07 08:32
The code is actually done, I was just trying to work out what to call it.
bethskurrie
2018-08-07 08:33
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.
antonello
2018-08-07 08:40
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
antonello
2018-08-07 11:53
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.
antonello
2018-08-07 21:59
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.
antonello
2018-08-07 22:01
I was in the process of pushing the changes to a fork but didn?t get a chance to finish.
antonello
2018-08-07 22:05
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?
bethskurrie
2018-08-07 22:06
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.
conallbennett
2018-08-07 22:46
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?
antonello
2018-08-08 16:16
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.
richard.hulm
2018-08-09 09:13
Hi, I'm getting a 504 trying to access my pact broker - is this the right place to report issues?
bethskurrie
2018-08-10 02:22
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!
amitojduggal
2018-08-13 14:50
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?
bethskurrie
2018-08-13 22:01
@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".
richard.jones
2018-08-13 22:49
@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?
bethskurrie
2018-08-13 22:51
I've been planning a v2 where I want to standardise the naming a bit better, but I have no timeline for that yet.
richard.jones
2018-08-13 22:51
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!
bethskurrie
2018-08-13 22:52
It would suck doing it manually, but there should be a HAL client for all languages.
richard.jones
2018-08-13 22:52
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.
bethskurrie
2018-08-13 22:53
I wrote my own for the pact ruby, because I don't like to add dependencies that might clash with the user's ones.
matt.fellows
2018-08-13 22:53
we did the same for Pact Node, sorta. Depending on what you do, you don?t really need a lib
richard.jones
2018-08-13 22:53
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)
```
richard.jones
2018-08-13 22:54
and it took me ? far too long to figure out that arcane hal_client version :confused:
richard.jones
2018-08-13 22:58
I?d prefer not to have to write my own HAL implementation, plenty of Pact-related code to write :slightly_smiling_face:
richard.jones
2018-08-13 23:00
https://github.com/deontologician/restnavigator looks like a much nicer interface, I?ll experiment with it
bethskurrie
2018-08-13 23:24
`http://pact_entity.post(PUBLISH_RELATION, verification_result)` is the Ruby code.
bethskurrie
2018-08-13 23:24
For tagging `provider_entity._link(VERSION_TAG_RELATION).expand(version: provider_version, tag: tag).put`
bethskurrie
2018-08-13 23:29
just having a look at the readme. looks much better than that first example.
amitojduggal
2018-08-14 05:10
So this capability has to be build on the pact-jvm side, i can work on it; give me some pointers. :slightly_smiling_face:
vinod.baradwaj
2018-08-14 10:48
can we download pact file from broker ? is there any API available for that ?
vinod.baradwaj
2018-08-14 10:53
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 ?
vinod.baradwaj
2018-08-14 10:53
wiki for pact broker says like, this is the endpoint for retrieving the pacts,
http://your-pact-broker/pacts/provider/PROVIDER/consumer/CONSUMER/latest
vinod.baradwaj
2018-08-14 10:55
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
vinod.baradwaj
2018-08-14 11:01
it says -U is for url resource, can we pass on that broker endpoint here ?
bethskurrie
2018-08-14 11:01
If the -u doesn't work, then please create an executable code example demonstrating the problem and raise an issue in the repo
bethskurrie
2018-08-14 11:02
If you're using basic auth, you'll need to include the credentials in URL form I would expect.
antonello
2018-08-14 11:21
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?
bethskurrie
2018-08-14 11:27
I think it returns a 201 if a new resource was created, and a 200 otherwise
antonello
2018-08-14 11:32
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.
bethskurrie
2018-08-14 11:34
That versioning page in the docs is really good, I recommend reading it if you haven't.
antonello
2018-08-14 11:53
I read it last week when I was making the change to the broker, but I?d forgotten!
amitojduggal
2018-08-15 14:51
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>
vinod.baradwaj
2018-08-16 06:08
Hi @bethskurrie from the endpoints will i be able to get the details like whether that pact file has been verified or not ?
vinod.baradwaj
2018-08-16 06:10
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
antonello
2018-08-16 09:21
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?
amitojduggal
2018-08-16 12:02
Hey, thanks, we were able to figure it out, it was because of redirection of the apis to a single sign on page internally.
bethskurrie
2018-08-16 21:44
Is this because the hot fix never went through the release candidate branch?
bethskurrie
2018-08-16 21:44
As long as you're verifying the production pacts as well, I don't think it's a problem.
bethskurrie
2018-08-16 21:45
If you have a specific release process for the hot fix release, you could tag the same version as release candidate when you deploy.
antonello
2018-08-17 05:28
There may be a main release candidate and a hotfix branch going on at the same time.
bethskurrie
2018-08-17 05:45
I'll go back to, what is the problem if you're verifying the prod version as well?
antonello
2018-08-17 05:52
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.
antonello
2018-08-17 05:54
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.
antonello
2018-08-17 05:55
I?m not sure if the provider verification we use (mvn plugin) would allow that or if it?s even sensible.
bethskurrie
2018-08-17 06:04
I'm going to go back to my theory that using the swagger workflow would be simpler for you.
bethskurrie
2018-08-17 06:28
I wonder if you could just skip all the checks except for the prod and main line of development.
bethskurrie
2018-08-17 06:30
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.
antonello
2018-08-17 07:37
There is a risk of a bit of a delay in feedback but can_i_deploy will tell us
kristine.jetzke
2018-08-20 18:47
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?
mmonson
2018-08-20 21:11
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
slack1
2018-09-04 21:15
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?
bethskurrie
2018-09-06 06:12
@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.
bethskurrie
2018-09-06 06:13
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.
bethskurrie
2018-09-06 06:14
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..
culbluswan123
2018-09-06 15:11
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.
culbluswan123
2018-09-06 15:40
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.
matt.fellows
2018-09-06 21:37
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
bethskurrie
2018-09-07 04:21
I believe that since we first made the decision (5 years ago?), MySQL now supports JSON searching. I should probably remove that comment.
culbluswan123
2018-09-07 04:24
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
matt.fellows
2018-09-07 05:30
Beth just pushed a few changes to that repo - so should be up to date now :slightly_smiling_face:
bethskurrie
2018-09-09 21:39
Hey @antonello did you manage to work out a flow that you were happy with?
antonello
2018-09-10 06:17
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.
gaurav
2018-09-13 10:57
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.
bethskurrie
2018-09-13 11:00
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.
gaurav
2018-09-13 11:05
Not a ruby person yet. I could help with Java, react, python etc.. never used ruby. Will have to wait then :-)
gaurav
2018-09-13 11:44
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.
bethskurrie
2018-09-13 11:48
You can tag as many times as you like. Something can be latest head and latest prod.
bethskurrie
2018-09-13 11:48
The recommend approach is to tag with the branch name and the stage name.
bethskurrie
2018-09-13 11:49
Tag with the branch name when you run CI, then with the stage name every time you deploy.
bethskurrie
2018-09-13 11:50
This allows you to use can-i-deploy to make sure you can safely deploy a compatible version to a given environment.
gaurav
2018-09-13 11:51
thanks. sure. Then I can add a tag to an existing pact? Will have a look at pact broker cli.
gaurav
2018-09-13 11:53
hmm okay thanks.. will check pact broker cli and do some thinking. :slightly_smiling_face:
bethskurrie
2018-09-13 11:58
Have a read of the "reaching pact nirvana" doc. There's a link to it in the pact broker wiki.
gaurav
2018-09-13 12:18
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)
richard.jones
2018-09-18 23:08
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.
bethskurrie
2018-09-18 23:54
2. You can create a pacticipant with no pacts. Just post to /pacticipants with a JSON document with a name.
richard.jones
2018-09-19 05:45
1: ok, thanks! 2: ahah! I had forgotten that, thanks, that?ll solve the problem even betterer :smile:
bethskurrie
2018-09-20 02:11
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 `{}`?
richard.jones
2018-09-20 02:14
Hm, I honestly am not sure what the HAL libraries will do in either case. Thanks for fixing the content-type tho!
richard.jones
2018-09-20 02:15
(sorry, my round tuits for testing such behaviour are in incredibly short supply at the moment)
slack1
2018-09-20 20:25
currently getting a 503 response when trying to push pacts to our hosted instance. any known problems right now?
slack1
2018-09-20 20:27
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)
matt.fellows
2018-09-21 13:22
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.
matt.fellows
2018-09-21 13:23
Apologies, looks like there were some intermittent issues which resolved itself, and we made some adjustments. Sorry about the interruption!
mmonson
2018-09-21 20:36
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.
uglyog
2018-09-23 22:29
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:
richard.peckett
2018-09-27 09:28
Morning guys, can someone tell me if the pact broker docker image is compatible with windows?
bethskurrie
2018-09-27 09:34
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?
richard.peckett
2018-09-27 09:56
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:
richard.peckett
2018-09-28 08:49
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!
matt.fellows
2018-09-28 11:39
Good to know. I couldn?t understand why it wouldn?t work, but theory != practice
shekharsp27
2018-10-09 10:13
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).
bethskurrie
2018-10-09 10:20
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.
bethskurrie
2018-10-09 10:21
I could probably have a go at it myself now I'm back in the Java world, sigh.
shekharsp27
2018-10-09 11:07
@bethskurrie Are there any API's which can be used to generate custom report for PACT tests
inbox
2018-10-10 15:45
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
inbox
2018-10-10 15:53
according to the log in nginx it's having difficulty connecting to the postgres instance
matt.fellows
2018-10-14 21:54
@bethskurrie the Pending pacts feature, is that technically in the codebase now just not yet documented?
antonios.klimis
2018-10-22 11:03
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.
sylvia.yap
2018-10-31 05:27
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?
bethskurrie
2018-10-31 05:33
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?
sylvia.yap
2018-10-31 05:43
Cause I can see the specific version that I?m publishing in the matrix and pact list view
liran.tal
2018-10-31 06:13
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
2018-10-31 21:39
@liran.tal The consumers are SalespersonService and UserServicePython. The provider is EmployeeService
sylvia.yap
2018-10-31 21:41
@matt.fellows I?m retrieve the pact from the url {host}/pacts/provider/EmployeeService/consumer/SalespersonService/version/2.7.0-cd7b8710
bethskurrie
2018-10-31 21:58
@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.
bethskurrie
2018-11-01 02:11
@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.
liran.tal
2018-11-01 04:43
@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?
sylvia.yap
2018-11-01 04:44
@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)
hstene
2018-11-08 11:00
Is the pact-broker down? My team reports that their managed pact-broker is not responding?
uglyog
2018-11-08 12:18
@hstene looks ok to me. What is the name of the broker instance your team use?
kevin.meiresonne
2018-11-20 14:28
The hosted pact broker seems to be down... We're getting 503 responses.
bethskurrie
2018-11-20 22:20
We're planning to start moving customers to put our new environment tomorrow
inbox
2018-11-26 16:23
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?
bethskurrie
2018-11-28 21:49
set the channel description: Discussion about the Pact Broker. For support regarding the DiUS hosted broker, email .
antonello
2018-12-03 12:04
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.
sai.krishna
2018-12-03 14:55
Hi @bethskurrie trying to verify the published contract and its always getting timeout
sai.krishna
2018-12-03 14:56
```
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)
```
andrew.nicholson
2018-12-03 16:34
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.`
matt.fellows
2018-12-03 21:14
@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: )
matt.fellows
2018-12-03 21:14
All the usual operations work on them though (publish, retrieve, verify etc.)
matt.fellows
2018-12-03 21:15
You might need to provide some more help on this. Could be a transient network issue, could be a firewall etc.
bethskurrie
2018-12-03 22:46
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!
madhukar.mishra
2018-12-04 09:22
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
jonas.natten
2018-12-04 09:43
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?
madhukar.mishra
2018-12-04 10:14
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.
jonas.natten
2018-12-04 11:00
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.
jonas.natten
2018-12-04 11:08
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.
richard.peckett
2018-12-04 11:35
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)
jonas.natten
2018-12-04 11:37
So when i use `can-i-deploy` with `--to prod` it verifies against the wrong version (Which is no longer in the environment).
yousafn
2018-12-04 22:06
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
bethskurrie
2018-12-04 22:59
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.
bethskurrie
2018-12-04 23:06
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.
bethskurrie
2018-12-04 23:07
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.
bethskurrie
2018-12-05 00:18
We're having some issues with the hosted environment at the moment, and will be pushing out a fix soon.
thirumal.net
2018-12-05 00:32
*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:
bethskurrie
2018-12-05 03:13
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
madhukar.mishra
2018-12-05 08:35
> "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
jonas.natten
2018-12-05 11:48
@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 (?)
yousafn
2018-12-05 19:21
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
yousafn
2018-12-05 19:23
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
2018-12-05 21:45
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.
bethskurrie
2018-12-05 21:46
These are environments where ci/cd is strong, and releases are quick and frequent.
bethskurrie
2018-12-05 21:47
I understand that different places have different methods of working though.
bethskurrie
2018-12-06 09:05
@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.
bethskurrie
2018-12-06 09:08
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.
jonas.natten
2018-12-07 06:13
I see, think i will try to write a script for deleting the tags then. Thanks for the replies! :slightly_smiling_face:
ravbaker
2018-12-07 11:31
I have an issue similar to described here: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1543915335013800 with webhooks and `provider_verification_published` event.
ravbaker
2018-12-07 11:34
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`
ravbaker
2018-12-07 11:39
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.
ravbaker
2018-12-07 12:40
even when I try to test the webhook run through `pb:execute` I do not get the `tags` :confused:
ravbaker
2018-12-07 14:47
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
ravbaker
2018-12-07 15:02
looks like `pact_version_sha` is different from `consumer_version_number` on same `represented` pact record
richard.hulm
2018-12-10 11:35
Hiya! We're getting 401s from the broker - implying our credentials have been rotated
ashish.dubey91
2018-12-10 12:25
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?
matt.fellows
2018-12-10 12:41
```
> dig http://foo.pact.dius.com.au +short
*.http://pact-prod.dius.com.au.
13.211.26.183
13.236.214.174
```
d.van.dijk
2018-12-10 14:04
@matt.fellows http://portbase.pact.dius.com.au could not be resolved either.
d.van.dijk
2018-12-10 14:35
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?
richard.hulm
2018-12-10 16:18
It seems http://foo.pact.dius.com.au is being redirected to *.http://pact-prod.dius.com.au which is breaking the DNS lookup
richard.hulm
2018-12-10 16:18
You can getaround it by using http://foo.pact-prod.dius.com.au (but the SSL cert is wrong)
bethskurrie
2018-12-10 19:15
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.
bethskurrie
2018-12-10 19:17
Sorry about the inconvenience. The new environment will be much more stable than the old one once we've sorted out the teething issues.
bethskurrie
2018-12-10 20:10
I'm guessing you're all probably asleep. The joys of working in a global distributed industry!
ashish.dubey91
2018-12-10 20:41
I'm curious to find out though how DNS resolution behavior was weird with the changes you guys did
ashish.dubey91
2018-12-10 20:43
Mac -> dig and curl are both able to resolve. On Ubuntu however, dig is able to find A records but not curl
matt.fellows
2018-12-10 21:15
It seemed only to be the case on Ubuntu but could more likely be related to specific versions of tooling/network stack
bethskurrie
2018-12-10 21:17
My guess is that some implementations do some extra smarts when there are wildcards involved.
matt.fellows
2018-12-10 21:18
It should also be noted that it did work on other Linux variations (in our case Amazon Linux)
richard.hulm
2018-12-11 09:54
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: )
ravbaker
2018-12-13 07:23
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
matt.fellows
2018-12-13 07:28
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.
bethskurrie
2018-12-13 07:35
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.
brentbarker9
2018-12-13 23:05
I upgraded my local pact docker from 2.24.0 to 2.27.6 and I'm having issues with viewing some pacts
brentbarker9
2018-12-13 23:05
`this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.`
matt.fellows
2018-12-13 23:12
> 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
matt.fellows
2018-12-13 23:12
are you sure other v3 pacts are rendering OK? (perhaps they are v3 part aren?t using any of the v3 features)
zach.the.hammer
2018-12-18 16:13
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
zach.the.hammer
2018-12-18 16:15
lol as always i should check if matt posted a response to my question right before i posted it
matt.fellows
2018-12-18 23:00
If you?re feeling generous, it shouldn?t be a big PR :slightly_smiling_face:
matt.fellows
2018-12-18 23:42
somewhere in here -> https://github.com/pact-foundation/pact_broker/tree/master/lib/pact_broker/ui
matt.fellows
2018-12-18 23:45
matt.fellows
2018-12-18 23:48
I think it?s more wrapping your head around WebMachine which is basically HTTP projected unto overly precise OO concepts. It?s pretty great though, from what little I?ve seen of it
matt.fellows
2018-12-18 23:52
Know that any progress you make here will make lots of people happy (and probably avoid another repeat of that question tomorrow :laughing: )
zach.the.hammer
2018-12-19 00:02
haha whatever i can do to get beth to answer more of my random questions
mehdizonjy
2019-01-10 09:03
hello everyone
Thanks for all the work you've put into the broker and the whole pact echosystem. I'm currently spiking on creating a POC and integrating Pacts Broker into our pipeline.
I'm stuck on configuring the `contract_content_changed` webhook. I can execute the webhook manually and it's able to access and call my provider's CI. However whenever my consumer updates their version and publishes a new contract, the webhook shows `not run` status and it's not attempting to call my endpoint.
There doesn't seem to be any log messages when i try to access the `logs endpoint`.
anytips on how to further debug this ?
matt.fellows
2019-01-11 03:09
@mehdizonjy are you actually publishing a _new_ contract? as in, are there new fields / interactions in it? If it?s just a new version, this won?t trigger (as the contract itself hasn?t changed, and therefore there is no reason to bug the provider about it)
mehdizonjy
2019-01-11 03:12
thanks for the reply.
i changed both the contract (by requiring an extra field) and pumping up the consumer version.
it's worth noting that i'm using the hosted pacts broker solution , but when running pacts broker locally on my machine via docker it's working like a charm.
bethskurrie
2019-01-11 03:26
There should be some debug logs that say what's going on with regards to webhooks when a pact is published
bethskurrie
2019-01-11 03:28
If you're just messing around (ie. it's a test pact) then try deleting the pact entirely and starting again.
mehdizonjy
2019-01-11 03:51
i just removed all the published pacts, and then published a new version. however it's still stuck at `notRun`. I then proceeded to removing the both participants and give it another try, sadly no luck :cry:
> we'll need to bump the log level
is there away for me to do that in the hosted broker solution and access the logs ?
the logs on the webhook itself are still empty
bethskurrie
2019-01-11 03:58
@mehdizonjy I'm just deploying a change to prod which will allow me to modify the log level dynamically and check out why it thinks it's not changed.
bethskurrie
2019-01-11 04:03
```
def update_pact params, existing_pact
http://logger.info "Updating existing pact publication with params #{params.reject{ |k, v| k == :json_content}}"
logger.debug "Content #{params[:json_content]}"
updated_pact = pact_repository.update existing_pact.id, params
if existing_pact.json_content != updated_pact.json_content
webhook_service.trigger_webhooks updated_pact, nil, PactBroker::Webhooks::WebhookEvent::CONTRACT_CONTENT_CHANGED
else
logger.debug "Pact has not changed since previous revision, not triggering webhooks"
end
updated_pact
end
```
mehdizonjy
2019-01-11 04:07
how come following the same steps on my local pact broker produces different results ?
galvinshane
2019-01-18 11:46
Im wondering is it possible to change the default port (from 80) and context path of pact broker? so i am using docker to deploy to kubernetes and would like to be able configure ingress with a path of /pact and also change the default port. Wondering if there are environmental variable to can set to achieve this currently?
galvinshane
2019-01-18 16:58
Hi Gopinath, have you been able to do this? would you happen to remember how to did?
hossam.saraya.ext
2019-02-01 09:29
Oh sounds good! I didn't see any paid plans. Only saw the free option
hossam.saraya.ext
2019-02-01 09:32
Okay so at my company we have a distributed microservices arch. services live on a private network and outside world can't access services directly. We also don't have an API gateway layer, we have frontend servers that speaks with the services in the private networks
hossam.saraya.ext
2019-02-01 09:32
So, I am setting up pact between the smallest provider/consumer we have to get started
hossam.saraya.ext
2019-02-01 09:33
One question is, if I use the hosted pact broker. *Can I assume that the broker machine ip is static* so that I can whitelist it
hossam.saraya.ext
2019-02-01 09:34
Otherwise, I will not be able to setup webhooks because the http requests fired from the broker will never reach our network
hossam.saraya.ext
2019-02-01 09:38
I also wanted to ask you what are the possible use cases for webhooks? So what I have in mind for our CI pipeline is:
*Consumer*
- Defines and publishes contracts to broker at the end of the build
*Provider*
- Query the broker for contracts and test its ownself against the matching contracts
- Publish verification results back to the broker
- Pass if the verification succeeds, fail otherwise
hossam.saraya.ext
2019-02-01 09:39
Does this sound like the right way to use pact for you? @bethskurrie
bethskurrie
2019-02-01 09:39
Have you read this? https://github.com/pact-foundation/pact_broker/wiki/Webhooks
hossam.saraya.ext
2019-02-01 09:39
Yea it says that a use case would be to trigger builds on provider when contracts change
bethskurrie
2019-02-01 09:40
if you're running your provider ci regularly anyway, it's not such a big deal.
hossam.saraya.ext
2019-02-01 09:41
mmm so what if the provider build fails...we will have the system in a contract-violating state after we deploy the consumer. yes?
hossam.saraya.ext
2019-02-01 09:42
because for us. QA, Staging environments auto deploy if the build passes. So for a consumer that violates the contract, the build will still pass and it will be deployed
hossam.saraya.ext
2019-02-01 09:50
Okay so to use the `can-i-deploy` tool. I have to `verify` the provider against the updated/new contracts first?
matt.fellows
2019-02-01 10:00
yes, but if the contract hasn?t changed between consumer builds the broker knows and it will already be green (it also won?t fire the webhook for changed pacts, because it hasn?t changed)
hossam.saraya.ext
2019-02-01 10:02
makes sense. But for changed contracts, how can I asynchronously verify the provider from the consumer build? I am worried about deadlocks here. If I add pact verification as a build step in both consumer and provider..I might end up in a deadlock where both provider and consumer will fail
matt.fellows
2019-02-01 10:06
Well, the webhook is async and the consumer build shouldn?t know about the provider build going on (i.e. it shouldn?t wait for it or anythnig).
matt.fellows
2019-02-01 10:07
If a new expectation is added to the contract that has yet to be validated by its provider, it _will_ currently fail the contract test
matt.fellows
2019-02-01 10:07
so the branch wouldn?t be in a mergeable state just yet, but once the provider has gotten to it and verified, a rebuild on that branch should succeed
matt.fellows
2019-02-01 10:08
It?s a bit clumsy, to be fair, and we?re not far away from releasing a way to resolve that deadlock (currently called WIP pacts). Stay tuned
hossam.saraya.ext
2019-02-01 10:09
Okay but that means that for every contract change, the consumer has to fail once?
matt.fellows
2019-02-01 10:10
there are ways to automate that part (e.g. create a dependency on the contract testing step of the provider?s build), but given WIP pacts are coming my advice would be to not attempt it
bethskurrie
2019-02-01 10:11
publish that to the broker, get the provider to verify it, then once it's green, merge in your feature branch into the consumer.
bethskurrie
2019-02-01 10:11
Because the pact will have been "pre-verified" when it was on a branch, it won't fail on master.
matt.fellows
2019-02-01 10:14
yes, sorry if that part wasn?t clear earlier. For some reason I thought branches had been discussed
hossam.saraya.ext
2019-02-01 10:14
mmm that makes sense I think. Only downside here is that it needs human interaction. I was looking for a way to have that check inside the consumer build (a way to ask the provider to verify without going into a deadlock). But you saying its WIP anyways right?
hossam.saraya.ext
2019-02-01 10:15
and since webhooks are async, we cant wait for it in consumer build
matt.fellows
2019-02-01 10:17
you can link builds together as noted, but that just creates a dependency tree that can get complicated very quickly for anything other than fairly simple architectures. Best to let builds fail and have humans review
hossam.saraya.ext
2019-02-01 10:17
cant I get away with:
```
- consumer publish contract
- webhook triggers provider verifications
- consumer sleeps ?
- consumer polls `can-i-deploy`
- consumer fails or succeed when `can-i-deploy` has new results
```
bethskurrie
2019-02-01 10:18
You can poll can-i-deploy if you'd really like to - it's got built in retries for this.
matt.fellows
2019-02-01 10:18
of course, but that is still creating a dependency on another non-deterministic build. It can work, you can weigh up if the additional complexity is worth it in your environment
matt.fellows
2019-02-01 10:19
And I should note I?ve seen this done in a number of places to great success
matt.fellows
2019-02-01 10:19
in some environments, this just gets a bit messy. Keep an eye on it and change if it does
hossam.saraya.ext
2019-02-01 10:20
Okay I think you are right about creating a dep on a non deterministic build..I suspect that to get nasty at some point of future time
matt.fellows
2019-02-01 10:20
it tends to work nicely with new apps that have quick builds and a small amount of collaborators
hossam.saraya.ext
2019-02-01 10:20
I will ask our PR reviewers to check the broker UI first before merging a PR.
matt.fellows
2019-02-01 10:21
as this scales, you now could have multiple builds waiting for multiple other builds
hossam.saraya.ext
2019-02-01 10:23
Okay but from the provider side, we should have the pact verification as a build step and that would make the build fail if the verification fails. So thats still automated on the provider which is good
hossam.saraya.ext
2019-02-01 10:26
so, do you think I should only spin up one broker for all the environments? In that case I would prefix service names like `staging-user-service` and `production-billing-service`..etc
hossam.saraya.ext
2019-02-01 10:27
ah and is there a filter in the UI where can I filter pacts by tag?
hossam.saraya.ext
2019-02-01 10:28
at some point I would like to contribute..maybe create a UI for you :muscle:
bethskurrie
2019-02-01 10:28
you tag a version with metadata that tells you about the branch it's on or the stage it's in (eg. "master" or "prod")
bethskurrie
2019-02-01 10:29
Then you can say "I want to verify the latest "master" pact" or "the latest production pact"
bethskurrie
2019-02-01 10:29
Any help with the UI would be appreciated. I initially didn't have the skillz, and now I just don't have the time, to make it look good.
hossam.saraya.ext
2019-02-01 10:31
https://dribbble.com/daedlock not so active on dribble but I share some stuff there.
bethskurrie
2019-02-01 10:32
Man, I am such a back end dev these days, I love it when front end devs want to do UIs for me!
bethskurrie
2019-02-01 10:32
I think I lost touch with CSS about 5 years ago and never caught up again.
hossam.saraya.ext
2019-02-01 10:33
yea frontend part of the world is changing faster than my brain can handle
hossam.saraya.ext
2019-02-01 10:34
Awesome!! I just need to know if I can assume that brokers ip is static or not. Otherwise I can't use the webhooks and I will have to run and maintain a local copy :disappointed:
matt.fellows
2019-02-01 10:35
```
13.210.164.235
13.210.66.183
13.211.59.138
13.54.130.12
54.252.242.229
54.66.180.72
13.236.113.160
54.252.233.246
```
matt.fellows
2019-02-01 10:37
Just so we?re clear, the broker itself is not on a static address, but webhooks will come out via one of them
hossam.saraya.ext
2019-02-01 10:41
great. are you using any frameworks on frontend? or is it just SSR with bootstrap
bethskurrie
2019-02-01 10:52
Something that a lot of people can contribute to for maintenance - the problem with the Ruby back end is that not many people use Ruby these days.
hossam.saraya.ext
2019-02-01 10:55
I can imagine. Can't we generate api documentations from the contracts? Is it something you would consider?
hossam.saraya.ext
2019-02-01 10:59
idk I am thinking like a documentation with each service and its endpoints..etc
hossam.saraya.ext
2019-02-01 10:59
but that might sound silly since this is not what pact is about anyways
bethskurrie
2019-02-01 11:00
We want to integrate swagger into the pact work flow better in thrle future.
bethskurrie
2019-02-01 11:02
I'd recommend starting with some wire frames and getting some feedback from the pact community on slack if you're interested in the UI. We actually need to start with a design exercise.
hossam.saraya.ext
2019-02-01 11:04
Will start on something this weekend. The pages we have are (pact list, pact view and network graph) I think I need to discuss this in a bit more details later to know what pages should be designed, what api endpoints we already have..etc
hossam.saraya.ext
2019-02-03 10:28
Okay I am back again to discuss the UI screens we have. I will start a designing a prototype for broker's UI but need more direction from you
hossam.saraya.ext
2019-02-03 10:36
Oh almost forgot that for me its an open source contribution and for you its a full time job :smile: so probably I won't be able to reach you guys on weekends -.-
matt.fellows
2019-02-03 11:02
> for you its a full time job :smile:
well? no, we also have full time jobs too. This is our, not-paid-but-still-basically-full-time job :slightly_smiling_face:
bethskurrie
2019-02-03 20:37
I'd start by doing some wire frames. Put them in front of some of the users from the slack channel, get some feedback, and iterate.
bethskurrie
2019-02-03 20:37
Sorry, the time zone difference means you're ready to work on this when I'm in bed, unfortunately!
hossam.saraya.ext
2019-02-04 14:05
Is it a good idea to use *git SHA* as consumer and provider versions?
yousafn
2019-02-04 14:13
I use short git sha plus a CI build version number, gives us the ability to reference a single commit, and know which build artefacts have been tested (as our deployable artefacts contain the CI build number)
james.carman
2019-02-07 22:59
I think the problem I ran into before with all of this automation was that if the provider does not declare any pacts, the broker won?t have data on it. There?s nothing to tag
james.carman
2019-02-07 23:02
I need to make sure the production version of the provider is verified against my consumer pact
james.carman
2019-02-07 23:03
This is when trying to deploy a new consumer version into an environment
bethskurrie
2019-02-07 23:08
Can you come up with a concise and complete description of your problem scenario, with an expected result, and the actual result
james.carman
2019-02-07 23:22
Part of our issue is we can?t use webhooks because we are using a hosted instance, which can?t reach our Jenkins box
abubics
2019-02-07 23:32
The provider doesn't need to declare any pacts (that's not really a concept) or tests . . . it just tells the broker which provider it is, so it knows which Pact scenarios to verify
james.carman
2019-02-07 23:42
I understand that the provider doesn?t declare pacts and they?re not supposed to
james.carman
2019-02-07 23:43
The issue is I need to know that the right version (the production version) of the provider is verified against my pact
abubics
2019-02-07 23:46
To clarify, you want to know what the provider version is for the latest `prod` tag on a pact version?
james.carman
2019-02-07 23:47
Before I deploy a consumer to production, I need to make sure its pacts have been verified against all of the production versions of the providers
james.carman
2019-02-07 23:51
But there doesn?t appear to be a way to declare that a specific provider version is the production version
abubics
2019-02-08 00:01
1. When a provider verifies a pact version, the provider's version is listed in the matrix.
2. When a verified pact version is promoted to a prod environment, it should push the `prod` tag to that pact version.
3. Now any consumer changes have an updated prod provider version to verify against.
abubics
2019-02-08 00:02
(You still need to add the `prod` tag when the provider is promoted to prod. Nothing in Pact can do that for you, of course)
james.carman
2019-02-08 00:35
The issue is that I have no way of knowing what is the production version of the provider
james.carman
2019-02-08 00:37
The pact, and the tags associated with it are meant to be associated with the consumer that uploaded the pact
hossam.saraya.ext
2019-02-08 01:09
I think the tag is associated with a ?pact? not a service. The provider would then verify itself against the latest ?prod? pacts. Someone correct me if I am wrong
hossam.saraya.ext
2019-02-08 01:15
If all is green, you deploy. If you do a CD and deployments doesnt happen manually. I think the flow would be
1. Consumer changes and publish new pact to brokee
2. Broker trigger a build on the provider via a webhook
3. You use can-i-deploy as a consumer build step. If it succeeds, deploy. Otherwise exit with non-0
hossam.saraya.ext
2019-02-08 01:17
Cant you whitelist the brokers ip on your jenki ns box? I think webhooks is needed for having the flow you need
abubics
2019-02-08 02:32
You're right, @hossam.saraya.ext, tags go on Pact versions.
Pacts are versioned by content, so if multiple versions of consumers have the same Pact content, no extra work needs to happen. Likewise, if a provider has verified one version of a Pact, all future verifications automatically happen until the content changes again.
abubics
2019-02-08 02:33
If you wanted to have `consumer-prod` and `provider-prod` as separate tags, I guess you could, but I'm not sure what that solves.
james.carman
2019-02-08 04:49
The trick is that the specific version of the provider needs to verify the pact
james.carman
2019-02-08 04:51
Yes, the pact is what?s tagged, but the pact comes from the consumer. So, the tag on the pact is really within the context of a version of the consumer.
james.carman
2019-02-08 04:53
I?m not trying to be difficult. I?m just trying to figure out if I can safely certify that a consumer works with the versions of the providers that it is about to be deployed with
abubics
2019-02-08 05:04
I'm sure you can, have you looked at the matrix? It shows every combination of consumer version that either
- hasn't been verified by any provider version, or
- has been verified, and which version it is
abubics
2019-02-08 05:04
If you need that info by an API or CLI tool, I'm not the best person to direct you, but maybe one of the actual maintainers :slightly_smiling_face:
james.carman
2019-02-08 05:25
Oh I?m sure the matrix can tell me the answer. But, I need to know which specific combination(s) to look for.
abubics
2019-02-08 05:33
I must still be missing something . . . if the matrix can tell you the answer, what outstanding issues do you have? Maybe describe the usage context?
james.carman
2019-02-08 05:38
I need to know what question to ask it, which cell to look for in the grid.
james.carman
2019-02-08 05:46
I mean programmatically, by the way. Of course we know (or can easily determine) what version of our stuff is running where.
james.carman
2019-02-08 20:43
That can certainly help with our automation. Let me ping our ops guys and see if they?re down with that
hossam.saraya.ext
2019-02-09 11:19
pact screen first concept. Feedback & suggestions are much appreciated
pkuang
2019-02-14 16:57
Hi! I was wondering if someone can comment on the prospect of this proposed feature: https://github.com/pact-foundation/pact_broker/issues/248
This would be useful for my CI/CD use case where I have a consumer change in a branch that requires verification from the provider version in prod. However this may fail if the corresponding change hasn't been deployed to prod yet. However, once the provider has deployed to prod and we know the consumer branch change is compatible, can-i-deploy will still fail since the provider verification build wasn't rerun against the consumer branch contracts. It would be useful if we were able to simply re-run the consumer branch build (which would republish the same contract) and have the webhook trigger the provider verification build via a 'contract_published' event that fires regardless of whether the contract has changed.
bethskurrie
2019-02-18 02:11
This would be quite easy to do. It's just a matter of having the free time to do it, which I don't have a lot of right now.
bethskurrie
2019-02-18 02:11
If you're keen enough to do a PR, I can show you where the code would need to change.
bethskurrie
2019-02-18 02:12
I remember I deliberately made the event "CONTRACT_CONTENT_CHANGED" instead of PUBLISHED so that we could add one for PUBLISHED later.
bethskurrie
2019-02-18 02:13
Here are the webhook event types: https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/webhooks/webhook_event.rb
bethskurrie
2019-02-18 02:15
Adding the event to this list should allow the API to accept the new value: https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/webhooks/webhook_event.rb#L14
hossam.saraya.ext
2019-02-18 08:30
That wont be a good idea. we should create some identity thats visible on all pages
bethskurrie
2019-02-18 08:32
One concern I'd have with putting the request and response side by side is that deeply nested JSON might end up being squished.
bethskurrie
2019-02-18 08:32
It looks great with a simple example, but might not scale for real world data.
hossam.saraya.ext
2019-02-18 08:33
So we have both text and tree view. But that doesnt totally fix the indentation hell
bethskurrie
2019-02-18 08:34
Have you worked with the v3 pact spec where there are multiple provider states, and provider state params?
hossam.saraya.ext
2019-02-18 08:35
Nope havent seen that. I might need you to walk me through the broker to point out the core ui interactions
bethskurrie
2019-02-18 08:36
Really, there are only 4 pages. The index, the network diagram, the matrix, and the pact itself.
hossam.saraya.ext
2019-02-18 08:39
Yea thats what I thought. I think the matrix is interesting. I will think of another way to present it beside the tabular format
hossam.saraya.ext
2019-02-18 08:43
Do you think we should have a brand primary color. Or you are already settled on ?black??
bethskurrie
2019-02-18 08:44
I do quite like the b/w, as it's striking, and doesn't look like anything else I've seen.
bethskurrie
2019-02-18 08:45
Given that the matrix by it's nature is very tabular, i'm curious as to how else it could be presented.
bethskurrie
2019-02-18 08:46
I think there's a lot that could be done with that, but the matrix... I can't quite imagine. I'll look forward to seeing what you come up with though.
bethskurrie
2019-02-18 08:47
Something to note with the index is that there is the simple view, and the tags view.
hossam.saraya.ext
2019-02-18 08:48
I think we should combine both views because they are ultimately the same. And maybe have a switch ?show with/without tags?
bethskurrie
2019-02-18 08:48
I'd actually like to have the tags on the default view, and not have the 'simple' view. But making the space for each pact allow you to have multiple tags for the consumer and provider versions was quite tricky for us (we have done some work on the UI at DiUS for the commercial broker, but we haven't gotten it in to prod yet)
bethskurrie
2019-02-18 08:49
The matrix and index are not the same - the matrix is every combination of two particular services.
hossam.saraya.ext
2019-02-18 08:52
Also I noticed that searching the matrix by tag & latest version doesnt work
hossam.saraya.ext
2019-02-18 08:54
Yep. Gotta jump in a quick meeting now but will post a screenie right after
hossam.saraya.ext
2019-02-18 13:34
Okay it works when I apply the filter to one participant only (the consumer)
hossam.saraya.ext
2019-02-18 13:35
I know that each participant can have versions..but what about the tags? Do we tag a participant or do we tag a pact?
pkuang
2019-02-26 16:33
Hi @bethskurrie, can you review https://github.com/pact-foundation/pact_broker/pull/258 when you get the chance please?
ragarwal
2019-02-27 06:03
Hello, I have a question: I want to use the pact broker interface and features but can?t use its own db. Is it possible to provide the data via some api?
ragarwal
2019-02-27 06:07
we are doing contract testing is a way where consumer side writes pacts but the provider side is using swagger files for verification. Company has its own contract-testing-cli which does all the validation work. The cli is a command line tool and prints everything on console which is not easy to consume. I really like the power pact_broker has and all the details it provides. Just trying to understand how can we use it in our setup?
bethskurrie
2019-02-27 06:07
You can publish any JSON contract to the broker. It doesn't have to be a pact.
bethskurrie
2019-02-27 06:08
We're actually adding support for swagger documents in the DiUS commercial broker. cc @matt.fellows
mouser
2019-03-04 04:55
hi, just wondering if there has been any change in behaviour around webhooks for the hosted pact broker? we seem to be having webhooks triggered even if the contract hasn?t changed??
matt.fellows
2019-03-04 05:02
Not that I?m aware of, but I know others have had that issue if they use matchers with defaults as the library generates new dates/integers etc. each time
bethskurrie
2019-03-04 05:04
you can see what has changed by going to the pact in the API browser, then clicking on the `pb:diff-previous-distinct` relation.
mouser
2019-03-04 05:04
yeah we?ve had that issue before and are generally fairly careful to provide fixed examples when writing our tests
mouser
2019-03-04 05:05
we?ve just noticed in the last few days that at times our build monitor lights up with what appears to be multiple webhooks being triggered?. we manually diff?ed one in particular and could see no difference other than the published date
mouser
2019-03-04 21:54
Not yet?. I found one of our javascript pact tests was using a dynamic timestamp that was causing one provider to be unnecessarily run?.
bethskurrie
2019-03-04 21:59
If you can't identify the reason, I can add some logging so we can see what the broker thinks the diff is.
mouser
2019-03-04 22:51
Ok? let me keep a bit more of an eye on things over the next day or so and I?ll try to get more details about when it?s happening. It doesn?t seem to be happening on all consumer builds so I suspect it might be an incorrectly configured service or webhook somewheere
rabih
2019-03-05 06:17
Hi, is it possible to force the name for consumer/provider instead of getting this message(other than creating manually):
The name ?ServicesProvider? is very similar to the following existing consumers/providers:
* providers_api
If you meant to specify one of the above names, please correct the pact configuration, and re-publish the pact.
bethskurrie
2019-03-05 06:27
Please read this: https://github.com/pact-foundation/pact_broker/wiki/Troubleshooting
rabih
2019-03-05 06:29
Hi Beth, yes this is the message that we got, also note that we are using the hosted pact broker so we could not chanbe the config
bethskurrie
2019-03-05 06:30
Can I actually suggest that in this case, your names are very vague, and perhaps changing them to be more descriptive of what the services does might kill two birds with one stone?
rabih
2019-03-05 06:31
so is there any way to add this check when initialising dsl.Pact or when publishing
bethskurrie
2019-03-05 06:31
Is this actually a provider that returns information about other providers?
rabih
2019-03-05 06:32
we are following a convention of `servicename_type` so for example a service named triggers that has api providers would be triggers_api
bethskurrie
2019-03-05 06:34
As an aside, a client I was at banned the use of "service" and "api" in the name, because they felt it was redundant.
bethskurrie
2019-03-05 06:36
I may be able to turn this off for your broker specifically if you continue to have problems.
bethskurrie
2019-03-05 06:39
I just need to know your broker. You'll need to send it from an email address that matches the original registration domain if it's for a company.
bethskurrie
2019-03-06 07:48
There's a really good doc on versioning in the broker on http://docs.pact.io
rabih
2019-03-06 12:09
Hello @bethskurrie , any updates regarding this issue, still getting the same message
vinod.baradwaj
2019-03-07 10:19
is it possible to `delete` webhooks that are already created or update it ? when i try to `delete` i get 405 error ?
vinod.baradwaj
2019-03-07 10:31
I am trying to setup webhooks to trigger provider build on jenkins, so trying out different combinations, still not able to trigger the provider build. is it possible to get status of webhooks ?
matt.fellows
2019-03-07 10:32
Navigate through the HAL API and you should be able to see the status and any logs associated with it
bethskurrie
2019-03-07 10:33
From the index page, you'll see a link to the Webhook status for that pact. Follow those links, and you'll find the execution logs for the Webhook.
vinod.baradwaj
2019-03-07 10:57
in status it says `success`.. yes @matt.fellows i triggered manually.. but not sure whats the actual issue in calling the jenkins build
oswald.quek
2019-03-12 14:35
:wave: is there an endpoint in the pact broker to delete pacts that are older than a certain date?
davidjgmendes
2019-03-13 14:43
@yousafn sry for digging up this old thread, but your use case interested me and brought up some questions.
You mentioned your use of WireMock alongside CDC testing. My question is on the scope of each of the tests. Are the tests using WireMock functionally testing the service that is consuming the mocked service ? And how do you make sure the WireMock mocks keep parity with the evolving contracts. Thanks in advance for any input on this.
yousafn
2019-03-13 16:46
Hi mate, no problem.
It was a big struggle to ensure our wiremock mocks, we kept in sync with our documentation, as we weren?t writing api documentation up front and using generated swagger from the services to document the functionality. If I?m honest it was a massive cluster-fuck, and we built wiremock provider mocks as the providing teams weren?t engaged or bothered about providing these.
this tool supports validating wiremock against swagger
https://bitbucket.org/atlassian/swagger-request-validator/src/master/
My use case for my current client is documented in the following blog with an example repository showing how we are keeping our pact and swagger contracts in sync
https://you54f.wordpress.com/2019/02/19/protecting-your-api-development-workflows-with-swagger-openapi-pact-io/
https://github.com/YOU54F/pact-consumer-example-typescript
yousafn
2019-03-13 16:48
the wiremock representations were similar to the pact approach, however our mocks would return a full response body and not just the bit we were interested in. Our test would check that our expectation was being met (as in the particular piece of data from the response was available)
Pact seems to address alot of the issues but it all hinges on collaboration, if you don?t have that, it is never going to mesh well
yousafn
2019-03-13 16:54
just to add, because we didn?t trust our providers and because there was no collaboration, and we didn?t have a view of their changes, we should run a set of tests against their service every hour. A failure meant the request or response structure had changed, and we then needed to assess the change, and the impact it had on us.
davidjgmendes
2019-03-13 16:59
Thanks for the insight, it's really helpful . Will analyse the links you have sent. Much appreciated :pray:
yousafn
2019-03-13 17:02
Any time mate, I have been meaning to write up about my experiences in my last company, I?ve got an example repo that I keep meaning to polish up and get it up on github to demonstrate how we were using it for CDC, but I don?t think it is of much use anymore because I would advocate the use of pact and its supporting toolset to anyone doing cdc testing, bearing in mind the considering of pacts limitations listed in the FAQ of what it is not good for (pass through apis/public api?s)
bethskurrie
2019-03-13 22:34
@hossam.saraya.ext someone has raised an issue asking for pagination on the index page of the broker. I thought I'd check where you're up to in your UI redesign before I spend any time updating the current page.
davidjgmendes
2019-03-14 11:08
In your blog-post you mention "So we are now using our PACT contracts, that we generated, to perform our component integration and e2e testing, with mocks". Are these pact defined interactions enough to functionally test the consumer service ? And if so, don't you end up with contracts that are too tight ? Guiding myself mostly through the PACT Docs here. For component testing is where I would resort to implementing wiremocks instead of resorting to the contracts, my issue is the ability to make sure wiremocks are in sync with the pacts / swagger. From what i have seen from the tool you have referenced it only works if we are defining wiremocks through java (not my case) and I'm looking for a more language agnostic solution. Still, imo it's a great workflow that you have managed there :thumbsup:
yousafn
2019-03-14 15:17
We are functionally testing our consumers with our pact mocks but we are using request matchers to ensure that we are loose with the data our mock provider accepts, (instead of expecting an exact string, it uses a matcher to take any string) so we are interested in checking the structure of the message and only return information defined in an integration test plan, so we can ensure that our data we have defined for our provider states is in sync with the real provider when it is developed.
We try and push as much of our testing, as far down the stack as possible, and we use cypress for our e2e and UI tests, but only run a few full stack journeys and stub out responses for the test to provide more granular control.
Wiremock is nice, it provides really fine control of your mocks, however I would advise that if you want to use it, that you get your providers to produce the mock, and therefore you as a consumer, you don?t have to worry about keeping a full mock stood up (where you may only care about a tiny portion of an entire response returned).
We had to also have a suite of tests, that tested that wiremock behaved as we expected it to, especially when we had developers/testers adding more scenarios, as sometimes they would conflict and not provide expected responses (as a new matcher may be at a higher priority level than your existing mocks)
yousafn
2019-03-14 15:25
Can we set the title of a webhook when registering it with the pact broker?
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown
The webhooks I have added to circleci and slack reporting both appear with a title of `title: "A webhook for all pacts",` when viewed via the `/webhooks` endpoint.
I have tried adding title inside the body element, and outside to no avail.
Danke
yousafn
2019-03-14 15:32
Actually, doing some more digging, I believe it is not currently implemented.
https://github.com/pact-foundation/pact_broker/issues/136
I have 4 webhooks currently, two for circleci and two for slack (one for publisher verification, and one for contract changed) and it isn?t easy to distinguish which one is which.
Will take a look at the issue and files that need changing and see what I can do. I am not familiar with Ruby, so if I do propose a PR, go easy on me :thumbsup: :stuck_out_tongue:
yousafn
2019-03-14 17:42
Another one, now that I have created my webhooks, the sensitive information in the URL?s (CircleCI token and Slack webhook URL) is exposed to readonly users.
They can navigate to `/webhooks` and then click on the href under pb:webhooks and it is exposed. Is there any way I can whitelist this for read-only users
yousafn
2019-03-14 17:46
edit:- found the bit in the docs re: webhook whitelists
https://github.com/pact-foundation/pact_broker/wiki/Configuration#webhook-whitelists
thirumal.net
2019-03-15 01:55
*how to connect to RDS Postgres Database from Dockerized pact broker which is deployed in aws EC2 Instance *?
i am able to run both pactbroker and postgres docker images successfully in EC2 instance. publishing and verfifcation is working fine
but i am facing issue if want to use external AWS RDS database like postgres . i am following below steps but unable to run frontend pact broker
1) Created RDS DB with credentials
2) running pact broker front end docker image in EC2 successfully
3) *how to make sure Pact broker front end application is talking properly with Postgres DB which is not dockeized*
i have inspected docker id of frontend pact broker and it has proper usernames/pwd which i executed from rancher "Env": [
"PACT_BROKER_DATABASE_USERNAME=postgres",
"PACT_BROKER_DATABASE_PASSWORD=pwd",
"PACT_BROKER_DATABASE_HOST=http://pactbroker.c16kmrwxzbxe.us-west-2.rds.amazonaws.com",
"PACT_BROKER_DATABASE_NAME=pactbroker",
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"DEBIAN_FRONTEND=teletype",
"LANG=en_US.UTF-8",
"LANGUAGE=en_US:en",
"LC_ALL=en_US.UTF-8",
"APP_HOME=/home/app/pact_broker/" reason i am not using dockerized pact broker is to get the benefit of RDS autobackup, high avilability, scalability ..etc *please help me what are my next steps to make sure pactbroker is talking with backend postgres database*
richard.jones
2019-03-15 03:18
Our pact broker is currently returning ```{
error: {
message: "undefined method `name' for nil:NilClass"
}
}``` for requests to `/dashboard` ? any ideas?
bethskurrie
2019-03-15 03:21
Have you considered signing up for a free hosted version at http://pact.dius.com.au @thirumal.net?
bethskurrie
2019-03-15 03:23
I really cannot comment on your AWS set up as there are many reasons why your set up may be failing (firewall, policies, VPN access). You need an AWS ops person to help you.
richard.jones
2019-03-15 05:41
@bethskurrie we?ve apparently seen this previously with bad pacts that were uploaded to the broker. We?ll be looking into it on Monday to figure the specific pact that is causing the issue this time.
bethskurrie
2019-03-15 05:42
That was my gut feel, because a consumer/provider is really the only thing with a name
thirumal.net
2019-03-15 17:14
@bethskurrie -Thank you beth, i have to add AWS host IP to inboud rule of RDS , then it started working fine.
thirumal.net
2019-03-15 17:24
@bethskurrie -Regarding http://pact.dius.com.au - i have recommended this pact broker but my management asked me whether this is hippa compliance or not . can you please direct me where can i see this hippa info
yousafn
2019-03-17 14:18
Hey @thirumal.net. I would change your credentials and security settings.
Your pact database looks like it is accessible publicly. (ie the postgres port is open)
I am happy to answer any questions about AWS Setup has I have a pact-broker hosted on AWS EC2 instance, with an RDS postgres DB.
You should ensure your database isn?t given a public IP and put it on a VPC accessible to your EC2 instance only.
Setup seperate security groups for your pact broker db and your pact broker ec2 instance.
Did you have an ELB? if so you can sign your certificates with amazons cert manager, otherwise you need to roll your own as you can?t use amazons cert manager with your own ec2 instance.
I am going to do a write up in a few days, as I have had just had to toughen our security up at work to get it compliant and want to share back my knowledge
richard.jones
2019-03-18 02:50
@bethskurrie if it helps, I can privately supply you with our database dump for the above ^^
bethskurrie
2019-03-18 02:54
```
Pacticipant.find(id: PactBroker::Pacts::AllPactPublications
.where(pact_version_id: pact_version_id)
.limit(1).select(:provider_id))
```
bethskurrie
2019-03-18 02:55
There should not be a way that can be nil, so there's obviously some data combination that I haven't thought of happening in your database.
richard.jones
2019-03-18 02:58
Yep. I?m poking around the database and I can?t see it either, though I?m not confident I?m reading the Ruby code correctly!
bethskurrie
2019-03-18 02:59
If I have the db, I'll just put a debug point at that line and it should explain what the problem is.
thirumal.net
2019-03-20 06:17
@yousafn -Thank you for your reply. i have tried for ELB in AWS but some reason it is not working.. i am doing pact broker infrastruture task where i am playing with RDS but as you mentioned i need to change security setting for db. please share your article once you are completed -Thanks
yousafn
2019-03-20 20:40
Hi mate,
I have written something up here
https://you54f.wordpress.com/2019/03/19/securing-the-pact-broker-with-nginx-letsencrypt/
But it doesn?t talk about securing your rds database
If you are just using an ec2 with docker instance of the pact broker and your rds Postgres instance
- ensure your database doesn?t have a publicly accessible endpoint ( you can do this via rds console),
- stick it on the same vpc as the ec2 instance
- set up 2 security groups, one for the ec2 instance to allow http or https traffic. One for your database.
- for your db security group ensure it can exposes only the Postgres post and limit access to the ec2 security group
- if you need ssh access to your ec2 instance, limit access to your IP ( ideally your work will have a fixed IP )
- if you need to open it up to access from anywhere, then add 2 factor auth to your ssh session and use fail2ban to parse your logs for ssh brute force attacks and exclude the ip addresses via iptables
Regarding running on an ELB, ideally use cloud formation templates. You want to clear a cluster with a network stack including vpcs, route 53 for dns and roles with ecs access to execute the containers, then service template?s to run fargate ecs and rds tasks. Deploy via AWS-cli to allow you to pass in environment variables at runtime into the docker container for the pact broker to pick up. Additionally you can store your env vars in amazons parameter store
This is a good place to start for the CF templates. You can deploy your db with CF templates too
https://github.com/nathanpeck/aws-cloudformation-fargate#private-subnet-public-load-balancer
Unfortunately I can?t share my work CF templates. Best of luck with playing with AWS but please do be mindful that you don?t want to leave your resources insecure for too long.
Feel free to drop me a pm if you want help with any specifics.
richard.jones
2019-03-21 23:14
We?re seeing a really confusing issue here, wondering if others have also seen it. If we fetch the HTML view of a pact and the JSON view, the contents of the pact differ. There have been many revisions of the pact uploaded.
richard.jones
2019-03-21 23:17
I don?t believe the pact exhibiting this issue is in the snapshot I provided previously, the pact is only a couple of days old. I?ll ask for a fresh snapshot :slightly_smiling_face:
bethskurrie
2019-03-22 08:26
Question for broker users. I'm improving the messages in the can I deploy results, that explain why an app can't be deployed.
bethskurrie
2019-03-22 08:28
These two options describe the same situation - which one makes more sense (esp for users who are not familiar with the underlying domain model)
1. Version xyz of SomeApp does not exist.
2. No pacts or verifications have been published for version xyz of SomeApp.
bethskurrie
2019-03-22 08:44
Mm. I was leaning towards that. 1 is technically correct, but I think 2 is probably more helpful.
vitaliy.grigoruk
2019-03-22 08:54
option 2 gives a hint about a possible reason, while option 1 just says that it doesn?t exist.
arunkumarpoonia
2019-03-22 10:27
how to publish result with this image - image: dius/pact-provider-verifier-docker?
arunkumarpoonia
2019-03-22 12:07
Unable to verify pact from cli - https://github.com/pact-foundation/pact-provider-verifier/issues/32
arunkumarpoonia
2019-03-22 13:34
@bethskurrie I am unable to use pact-provider-verifier to verify pacts from broker .
arunkumarpoonia
2019-03-22 13:36
I am running this command - ./pact-provider-verifier --PACT_URL=baseURL/pacts/provider/catalogApi/consumer/magento/latest -h, --provider-base-url=providerURLi
rjmcguinness
2019-03-22 16:27
The pact team is based in Australia, so I expect you?ll need to wait till this evening (if you?re in Europe)
matt.fellows
2019-03-22 20:45
I've just responded. Look more carefully at the CLI flags, you've just got them a bit wrong.
mwroblewski
2019-03-24 16:41
Hello, I have a question concerning plugging Pact into CI / CD: https://stackoverflow.com/questions/55324476/plugging-pact-into-ci-cd. Thanks for help in advance
bethskurrie
2019-03-25 02:57
I've updated the can-i-deploy logic so that can-i-deploy does not stop you deploying a provider to a given environment when the consumer is not yet deployed.
bethskurrie
2019-03-25 02:58
I know there have been a few people having problems with this. Please update your broker and try again.
matt.fellows
2019-03-25 05:52
Is this the WIP pacts or just not failing if there are no consumers yet?
hossam.saraya.ext
2019-03-25 10:03
I haven't added anything since then as I am quite super busy. I don't know when I am getting more free time :disappointed:
bethskurrie
2019-03-25 10:04
I feel your pain. It's why the UI still looks like it does after 5 years!
hossam.saraya.ext
2019-03-25 10:05
:smile: yea...it's always the UI that we compromise at the end..sadly
bethskurrie
2019-03-25 10:05
It's the part I enjoy the least, so there are always other things I find higher on the priority list!
richard.jones
2019-03-25 22:39
I?ve finally found some time to poke into it more, and learn a bit more how to read the ruby code, and think I?ve found an issue: the code at https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/domain/verification.rb#L83 joins `verifications` and `pact_publications` on `pact_version_id` from both tables, but in our database we have 228 rows where there is no corresponding entry in `pact_publications` for the `pact_version_id` in `verifications`. This would result in a `nil` provider, if I understand correctly. Many different `pact_version_id` are in those 228 rows.
richard.jones
2019-03-25 22:39
There hasn?t been a bogus row in `verifications` generated since December though
richard.jones
2019-03-25 22:40
`select * from verifications where pact_version_id not in (select pact_version_id from pact_publications);` is the SQL I used to find those rows
bethskurrie
2019-03-25 22:42
it's like the pact was verified, and then the publication was deleted through the API.
richard.jones
2019-03-25 22:43
OK, yep. We definitely need to do some weeding in our broker, as we know there?s a bunch of mis-registered pacts (mis-spelled or just out of date participants for a start). But we?ve not done any of that yet.
richard.jones
2019-03-25 23:24
I?ve confirmed with the broker maintainers here that we?ve only used the API calls to manipulate data in the broker, never manual SQL.
bethskurrie
2019-03-25 23:24
it deletes the publication, but leaves the content, and its connected verifications.
bethskurrie
2019-03-25 23:24
I'm not sure what the best thing is to do about it. Will have to give it some thought.
bethskurrie
2019-03-25 23:25
basiscally, it seems you have left over verifications for pact publications that have been deleted at some stage.
richard.jones
2019-03-26 00:18
(sorry for AFK) thanks for investigating! We can certainly delete the orphan rows, thanks.
mwroblewski
2019-03-26 09:51
Hello, is it possible to use pact broker without tags ? https://stackoverflow.com/questions/55346970/using-pact-broker-without-tags
matt.fellows
2019-03-26 09:53
I'll try to answer later, but the short answer is yes (you just get less flexibility)
mwroblewski
2019-03-26 10:01
Thanks in advance, let's just say it's due to the way feature branches are used in our project - we can't use their name as tags :wink:
bethskurrie
2019-03-26 10:12
That is a very vague question @arunkumarpoonia. Can you be more specific?
bethskurrie
2019-03-26 10:14
You say in your question that the build could still pass even if the pact verification failed. Which build?
bethskurrie
2019-03-26 10:15
Can you be clearer about the underlying problem that is stopping you using tags? Is it a technical issue or a human one?
bethskurrie
2019-03-26 10:22
This is what allows you to ensure backwards compatibility between your consumer and provider.
bethskurrie
2019-03-26 10:23
You tag with dev when you publish the pact, and tag with prod when you deploy that app version to prod.
matt.fellows
2019-03-26 10:39
FWIW I almost always start with just those two tags and in many situations that is good enough
matt.fellows
2019-03-26 10:40
Not all projects enable easy symmetry of feature branches, so that can be difficult.
arunkumarpoonia
2019-03-27 08:22
what is the best approach to create provider state when we verify contract . I am using https://github.com/pact-foundation/pact-provider-verifier this to verify pact.
matt.fellows
2019-03-27 08:24
Do you have to use that verifier? Is there not a language/framework you can use? (more optimal)
arunkumarpoonia
2019-03-27 09:37
what is the best approach to handle provider state ? it will be good to get some pointers so that we can head in right direction .
matt.fellows
2019-03-27 09:45
> what is the best approach to handle provider state ? it will be good to get some pointers so that we can head in right direction .
Normally I use a state to setup a data fixture (e.g. to seed a specific set of data into a database)
arunkumarpoonia
2019-03-27 10:18
Thanks @matt.fellows i looked at pact-php but cant find any example to handle provider state?
matt.fellows
2019-03-27 10:22
Basically, you need to add a route to your code (just during testing). It will be called prior to each test, to ask the API to setup a particular state. That is where you can change the database / setup internal state etc.
adamgreen
2019-03-27 16:39
investigation threw up this previous issue:
https://github.com/pact-foundation/pact-provider-verifier/issues/11
adamgreen
2019-03-27 16:40
however i am still getting Cross Origin errors when calling the APIs from an external web app
arunkumarpoonia
2019-03-28 11:50
if i want to test getCustomer/{customerId} customer id is random here
arunkumarpoonia
2019-03-28 11:51
I am able to test post action but not sure how to create state for {ustomerId} here
dagarwal
2019-03-28 12:10
you need to pass the exact id .i achieved this by updating db at provider level
mboudreau
2019-03-28 22:18
Exact id if that's important for you to test, or you can use a matcher so that it doesn't matter what it is
bethskurrie
2019-03-29 03:40
That can actually be quite tricky @arunkumarpoonia and the answer depends on which library (language) you're using. Can you ask the question in the relevant channel? eg #pact-jvm or #pact-js
bethskurrie
2019-03-29 03:41
@arunkumarpoonia are you talking about CORS issues with the mock service or the Pact Broker?
bethskurrie
2019-03-29 03:42
I feel like you may be getting them confused. The mock service runs on your local machine, and provides an HTTP mock provider. The Pact Broker allows you to exchange contracts and verification results between projects. I can't see why you'd have CORS issues making a request to the Pact Broker.
adamgreen
2019-03-29 08:34
@bethskurrie we're trying to access the pact-broker from a different web application through the apis but due to the different domains the the pact-broker doesn't allow cross domain requests
adamgreen
2019-03-29 08:39
ah ok, so we need the reverse proxy if we're going to do this then? That's fine, i'll have a look into setting that up. Thanks for the guidance :slightly_smiling_face:
adamgreen
2019-03-29 08:42
when setting up for the first time in an azure vm, passenger phusion was having trouble with the nginx set up, if i recall correctly. removing the nginx removed that issue, hence maybe i've ended up looking in the wrong place for a solution
adamgreen
2019-03-29 08:50
so if i pull the pact-broker repo, add that to the app.rb file, build my own broker image - we should be good to go. I'll give this a shot. Thanks again!
yousafn
2019-03-29 17:11
Ola, does the webhook event `contract_content_changed` fire if there is a different version number?
Our pact version numbers use circleci buld num + git commit sha such as `761-45dd0a4`. and we tag with `feature/foo-123`
If I trigger the CI build to run again, the version number will be upped due to the circleci build number increasing from `761-45dd0a4` to `762-45dd0a4`.
The content of the pact hasn?t changed, bar the version number, and this fires the ` "name": "contract_content_changed"` event.
bethskurrie
2019-04-01 02:32
To work out what this is, open the pact in the API (HAL) browser, then use either the `pb:diff` or `pb:diff-previous-distinct` relations to work out what has changed in the contract.
bethskurrie
2019-04-01 02:33
@yousafn using CI build numbers is not recommended. Have a read of this: https://github.com/pact-foundation/pact_broker/wiki/Pacticipant-version-numbers
franklin.huynh
2019-04-01 03:31
Hi, I'm not sure if it is the right place to ask.
I'm having an issue with triggering webhook to bamboo build. I receive this error.
```
"error": {
"message": "SSL_connect returned=1 errno=0 state=error: certificate verify failed",
```
I can make sure the request and webhook created correctly. Could anyone shed a light for me?
I could provide more stacktrace if needed
franklin.huynh
2019-04-01 03:34
thanks @bethskurrie for your quick response.
I tried implementing that and the fix by executing this script
https://github.com/pact-foundation/pact_broker/blob/master/script/insert-self-signed-certificate-from-url.rb
I don't have much knowledge on ruby
I'm having issue with the database credentials
bethskurrie
2019-04-01 03:36
DATABASE_CREDENTIALS = {logger: Logger.new($stdout), adapter: "postgres", host: "HOST", username: "USERNAME", password: "PASSWORD", :encoding => 'utf8'}
franklin.huynh
2019-04-01 04:02
Hi @bethskurrie
I tried and get this error
```
/System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require': LoadError: cannot load such file -- pg (Sequel::AdapterNotFound)
from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Library/Ruby/Gems/2.3.0/gems/sequel-5.18.0/lib/sequel/adapters/postgres.rb:6:in `<top (required)>'
from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /System/Library/Frameworks/Ruby.framework/Versions/2.3/usr/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:55:in `require'
from /Library/Ruby/Gems/2.3.0/gems/sequel-5.18.0/lib/sequel/database/connecting.rb:88:in `load_adapter'
from /Library/Ruby/Gems/2.3.0/gems/sequel-5.18.0/lib/sequel/database/connecting.rb:17:in `adapter_class'
from /Library/Ruby/Gems/2.3.0/gems/sequel-5.18.0/lib/sequel/database/connecting.rb:45:in `connect'
from /Library/Ruby/Gems/2.3.0/gems/sequel-5.18.0/lib/sequel/core.rb:121:in `connect'
from certificate2.rb:20:in `<main>'
```
franklin.huynh
2019-04-01 04:09
no I'm not
let me try with the bundle install and run the script again
bethskurrie
2019-04-01 04:11
```
require 'uri'
require 'securerandom'
require 'date'
require 'json'
uri_string = "https://google.com"
uri = URI(uri_string)
certificate_command = "openssl s_client -showcerts -servername #{uri.host} -connect #{uri.host}:#{uri.port} </dev/null 2>/dev/null | openssl x509 -outform PEM"
certificate_content = `#{certificate_command}`
puts "Downloaded certificate from #{uri.host}: #{certificate_content}"
puts({
uuid: SecureRandom.urlsafe_base64,
description: "Self signed certificate for #{uri.host}",
content: certificate_content,
created_at: DateTime.now,
updated_at: DateTime.now
}.to_json)
```
bethskurrie
2019-04-01 04:12
install pgAdmin and then just manually insert the record into the database.
franklin.huynh
2019-04-01 04:36
@bethskurrie Guess what, itis working like a charm after I inserted the certificate manually.
I just wanna say thank you so much for your support
franklin.huynh
2019-04-01 04:39
I have a question. do we have a pact broker cloud version with licensed?
bethskurrie
2019-04-01 04:40
If you are interested in a cloud version, go to http://pact.dius.com.au and sign up for a free trial.
franklin.huynh
2019-04-01 04:49
I registered it before. But chose to host by our company. (on aws) However, I found out that it may requires effort to maintain it sometime and also cost us a bit on aws service. so we may consider if we can go with licensed cloud version
matt.fellows
2019-04-01 05:50
If by licensed you mean paid/supported, please drop us an email at and we can chat further
yousafn
2019-04-01 12:46
Thanks for the reply Beth.
Looking at the `pb:diff` or `pb:diff-previous-distinct` relations really helped.
It looked to be verifying against old pacts, that actually had changes in, and was ignoring the tag.
This appeared to be due to the way we were publishing/tagging - we used 2 curl scripts, one to publish, one to tag.
We have now switched to the pact-js publishing step, and tag during the publish step, which has tightened up the checks against contracts using the same tag only, limiting the webhook noise we were getting
With regards to the CI number, we use the build number from our deploy step to tag our artefacts, which we promote from test, into staging and production, so the source is always known. Apparently we store this in a git tag, so I will use that, plus a git sha to make up the version number
adamgreen
2019-04-03 14:26
Hi Beth, sadly had no joy in just amending the config as part of the pact_broker-docker repo, suspect i'd have to amend the app.rb file in the base pact-broker repo and create my image from there?
vitaliy.grigoruk
2019-04-11 15:20
Hi there. I?m trying to add a webhook to pact broker, which will trigger provider verification on provider CI. But for this, I need somehow to tell provider exactly which consumer contract has changed (I don?t want to re-run provider verification for all tags / versions of all consumers). I?d like to run verification only a contract that has been just published. Is there any way to add variables to webhook definitions? e.g. I?d like to pass consumer `$contractTags` to provider CI.
franklin.huynh
2019-04-12 00:04
Hi @vitaliy.grigoruk , I have a question but not sure if it is the same with you or not. I'd like the webhook trigger only when the contract with "master" tag changed. Are we able to do it? I cannot find it is the docs.
bethskurrie
2019-04-12 01:22
Hi @vitaliy.grigoruk @franklin.huynh this feature is on the backlog. In the meantime, you can add the consumerVersionTags to the webhook body (as per https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution) and get it to trigger an intermediate build. That intermediate build can decide whether or not to trigger the downstream build, and what branch of the provider to use.
matt.fellows
2019-04-12 01:26
Hi , this morning we enabled a Web Application Firewall on our hosted Pact Broker service (https://pact.dius.com.au).
This follows a number of additions to our security, compliance and auditing work this year, including a recent third party penetration test.
We are monitoring the change closely, however if you do experience any issues today that are out of the ordinary, please let us know so that we can investigate ASAP.
Cheers,
Matt
james.carman
2019-04-12 01:27
We did see some 504s today. I was wondering if you guys were doing some maintenance
bethskurrie
2019-04-12 01:28
@james.carman we've put out a new version of the pact-jvm library with retries to handle any 504s that happen during broker interactions. If you're using one of the other languages, let me know so I can make sure it's got the latest code.
matt.fellows
2019-04-12 01:34
Confirmed that the 504s are unrelated to the change (I think the JVM issues as you mentioned)
james.carman
2019-04-12 01:42
Would you guys be interested in a nice ?test harness? for JAX-RS-based services?
james.carman
2019-04-12 01:43
I?m going to publish one in my ?Jaxxy? library and I?ll let you know when it?s out there:
https://github.com/jaxxy-rs/jaxxy
matt.fellows
2019-04-12 01:43
I?m keen to see it, @uglyog would probably have more opinions as the JVM mantainer
james.carman
2019-04-12 01:46
So, this 3.6.3 version of pact-jvm does the retries automatically? Or, do I need to turn on some setting?
vitaliy.grigoruk
2019-04-12 07:26
I guess it is not possible. But you can pass tags to your CI job and then based on tag value either perform a build or not. Alternatively, you can have a small proxy application running between pact broker and your CI, where you can do filtering of webhooks based on tag value
vitaliy.grigoruk
2019-04-12 09:40
Hey folks, what are the best practices around cleanup of consumer versions that are not needed anymore (e.g. the ones that are already released). For example, when `consumer feature branch is deleted` -> remove all consumer contract versions that were associated with that deleted branch.
bethskurrie
2019-04-12 09:42
Have a look at the Pact Broker github wiki, on the "deleting things" page.
kevin.meiresonne
2019-04-15 09:46
Hi all, we have this weird issue on our hosted pact broker. When publishing a new version of a certain contract, we keep getting a 403 FORBIDDEN since April 12th. However, publishing other contracts on the same broker using the same credentials works just fine...
Any idea what could be causing this?
bethskurrie
2019-04-15 09:48
i'll ping you when I've finished deploying, and we can see if it fixes it.
kevin.meiresonne
2019-04-15 09:49
We publish to something looking like this: https://<host>.http://pact.dius.com.au/pacts/provider/<provider>/consumer/<consumer>/version/aa53bfa0fed09e99c8fb2482d4474c5c0fb50f88
bethskurrie
2019-04-15 09:50
There is some routing logic that makes sure the request goes to the right place (UI or API) based on the headers, content types, etc. I realised this afternoon that there was a bug in it.
bethskurrie
2019-04-15 09:51
I love everything about our new build pipeline, except that it takes what I consider ages to deploy to prod because of ECS draining. Will ping you in half an hour or so...
kevin.meiresonne
2019-04-15 09:52
Weird though that we only have this issue on one particular contract... All others work just fine, just this one started giving 403's since friday
vinod.baradwaj
2019-04-15 10:57
webhooks in our broker is not triggering provider jobs in jenkins. When i try to directly call pb:execute endpoint, it is triggering the job in jenkins. But the same is not getting triggered when pact file is updated to broker. Is this something related to versioning of the pact files ?
bethskurrie
2019-04-15 11:16
Webhooks are only triggered when the content itself has changed, not just when a new publication is made.
bethskurrie
2019-04-15 11:17
There's no point - if the previous version is verified, and it's the same content, then it gets the same verification results.
bethskurrie
2019-04-15 11:20
If the content is the same as the previous version, then the only reason you'd need to run the verification again is if the provider had changed - but then if the provider had changed, it would run it's own build, and would pull in the latest pacts and verify them during that.
arunkumarpoonia
2019-04-15 12:22
@vinod.baradwaj @beth I am unable to trigger webhook, getting below error :
arunkumarpoonia
2019-04-15 12:22
{
"errors": {
"request.url": [
"scheme must be https. See /doc/webhooks#whitelist for more information."
]
}
}
arunkumarpoonia
2019-04-15 12:29
{
"errors": {
"request.url": [
"scheme must be https. See /doc/webhooks#whitelist for more information."
]
}
}
arunkumarpoonia
2019-04-18 15:12
I want to create webhook for gitlab, it will be if someone can provide me sample request.
yousafn
2019-04-18 15:20
Hi @arunkumarpoonia this may help
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown
ravbaker
2019-04-19 13:15
@bethskurrie hi! I?ve just made a PR that fixes merging of pacts when they have the v2/v3 way of naming `providerState` https://github.com/pact-foundation/pact_broker/pull/269 Please review and incorporate in next release if no objections. We have been using this as a fix in forked version of pact_broker for some time without any issues in my current project. I?m also open for discussion if something is unclear.
bheemreddy181
2019-04-22 01:38
Is it recommended to trigger the Travis CI or CIRCLE CI job of provider when we write webhooks from Consumer Side or Create a specific job on Jenkins which just does pact:verify , rather if we trigger Travis CI Job it might trigger the functional tests and unit tests etc as well @bethskurrie @matt.fellows ?
bheemreddy181
2019-04-22 01:39
The wait time from Travis CI job might be more compared to the time taken by the jenkins job which just does pact:verify ?
bethskurrie
2019-04-22 01:39
Personally, I'd just make a separate job that did the pact:verify, so as to get quicker feedback.
bethskurrie
2019-04-22 01:40
But of course, you'd want the pact:verify to also run during the normal build of the provider too.
bethskurrie
2019-04-22 01:40
Remember, if the pact hasn't changed, it's "pre-verified" in the broker, and no webhook gets triggered.
matt.fellows
2019-04-22 01:43
I don't really like triggering the provider builds from a consumer publish, and tend not to need it. Occasionally you push a change on the consider that requires waiting for a provider build and we just handle it by talking to the teams. This problem will be improved with the upcoming WIP pacts feature also
bheemreddy181
2019-04-22 01:48
@bethskurrie Does *last published pact* change each time I publish a new pact but it is the same as the previous pact - I don't see a change in there until unless I change the expectations - if the expectations are not changed then it shows way older value?
matt.fellows
2019-04-22 02:21
That sounds correct - there is no _new_ published pact, just the same one published again
matt.fellows
2019-04-22 02:22
so no, the *last published pact* doesn?t change if you keep pushing the same contract up
bheemreddy181
2019-04-22 02:40
but doesn't we have to update the latest date there so that we will know that the pact published but don't trigger the webhooks because the content didn?t change ?
bheemreddy181
2019-04-22 03:06
@bethskurrie It doesn?t actually i published two pacts within a time difference of 2 mins, I only see one which was published 2 mins ago
bheemreddy181
2019-04-22 04:07
I published 10 pacts in last one hour -- i only see one which is published one hour ago
bethskurrie
2019-04-22 04:47
What is the output from the publishing logs? You can turn on verbose output.
bethskurrie
2019-04-22 05:02
So, if you publish with the exact same consumer version number and the same content, no new resource gets created.
bethskurrie
2019-04-22 05:04
If you publish a pact with the same content, but a different consumer version number, you'll see a new line in the matrix, but no webhooks will be triggered. If you publish content that has changed, and a new consumer version number, you'll see a new line in be matrix, and the webhooks will be triggered.
bheemreddy181
2019-04-22 14:24
I agree that no new resource would get created but why not the *last published pact* value doesn't change ?
bethskurrie
2019-04-22 20:09
It was an arbitrary decision that could have gone either way. The underlying pact publication database row is designed to be immutable, and so only has a created date, not an updated date.
bethskurrie
2019-04-22 20:10
I could add an updated date column, and set it if an identical request came in.
bethskurrie
2019-04-22 20:11
Nobody has actually raised it before. I think it's probably only relevant when you're messing around. Usually, the consumer version number will change with each build and that means the last published date should change. I'll double check which column it's using @bheemreddy181
vitaliy.grigoruk
2019-04-24 12:21
Hi folks. I have couple of pact publishing failures today.
```
[2019-04-24T10:30:36.020Z] ERROR: pact-node@6.21.5/112 on 7758fa148fa7:
Could not publish pact:
Failed to publish consumer/provider pact due to error: PactBroker::Client::Error - <html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
</body>
</html>
```
Wondering if anybody else seeing the same.
vitaliy.grigoruk
2019-04-24 13:03
I?d also like to talk about future pricing of https://pact.dius.com.au/
Who would be the best contact person?
matt.fellows
2019-04-24 22:26
We did see a few issues last night that resolved fairly quickly, let us know if you do have any further issues
bheemreddy181
2019-04-24 22:51
Thanks for checking back , I haven?t got time to check the things what you mentioned last time I am yet to complete the POC ( working one ) for demo at our company
bheemreddy181
2019-04-24 22:55
The documentation you mentioned last time is not clear enough to understand for verifying pact from pact broker
bheemreddy181
2019-04-24 22:57
I have quick question here - how do I check the optional field types while contract testing
bethskurrie
2019-04-24 22:57
the point is not to stop the tests ever failing - the point is to have them fail up front.
bheemreddy181
2019-04-24 22:58
Yes true that I should write test for pieces what I send rather than writing for everything you mean ?
bheemreddy181
2019-04-24 23:00
One more thing if have my own verification task I set to the latest rather than version as you said
bethskurrie
2019-04-24 23:01
If you have integration tests that require you to deploy to a test environment, they should definitely be run before then. They should fail if something has changed, so that you don't even deploy a broken integration.
bethskurrie
2019-04-24 23:02
best practice is to manage your versions with tags - let me find you some links.
bethskurrie
2019-04-24 23:04
If you haven't come across tags by now, you're missing a critical part, and there's more reading to do.
bheemreddy181
2019-04-25 03:54
Out of the below 4 links apart from docker pact broker everything else is returning 404 just fyi
bheemreddy181
2019-04-25 04:12
Even this is broken : https://github.com/pact-foundation/pact/_broker-client#can-i-deploy
yousafn
2019-04-26 09:36
Hey all,
Been messing about with AWS Lambda recently, and have managed to get the pact-broker running in a lambda function. I have a repo here
https://github.com/YOU54F/pact_broker-serverless
The lambda based pact broker can be visited on https://you54f.co.uk/
I will be doing a blog write up in the next week, but for now, enjoy :ok_hand:
yousafn
2019-04-26 09:45
It?s pretty decent tbh, so much quicker than heroku that?s for sure. (mind you, my heroku instance is running passenger standalone)
I need to hook it up with a CI pipeline later on today on one of my pact example repos so I can push pacts, perform webhooks and verifications and make sure everything is working as intended
matt.fellows
2019-04-26 09:47
Background processes won't work, and some other things won't will need to change but that's great!
yousafn
2019-04-26 09:50
I imagine it is going to be a painful process, especially as it wasn?t designed to run in a lambda, but I?m not planning on running this in prod for work, it was more for my experimentation with AWS lambda, and being able to understand it?s limitations. Will keep you lot posted anyhoo
yousafn
2019-04-26 12:01
publishing, slack webhooks (contract_content_changed & provider_verification_published) and verification seem to working a-ok! :party_parrot:
thadir
2019-04-26 15:11
Is there any good documentation on creating custom webhooks. I want to when the broker sees that the consumer changed the contract that the broker triggers our build server.Any one experiance with this?
yousafn
2019-04-26 15:14
https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library
great examples here
bethskurrie
2019-04-28 02:35
we're doing some upgrades to the DiUS hosted broker folks. There will be some downtime on this one, but we should be back up and running within an hour. You can follow the status on http://status.pact.dius.com.au/
ashish.dubey91
2019-04-28 05:22
curious how?s the infrastructure fairing now overall? I remember there were issues few months ago which led us to setup our own broker
kevin.meiresonne
2019-04-29 12:35
Hi, we're getting slow responses and 502's on the hosted pact broker. Is there maintenance going on? Status page doesn't say so.
matt.fellows
2019-04-29 12:44
I?ll be around for a few hours prepping for the AWS Summit, so ping me if you have issues
kevin.meiresonne
2019-04-29 12:46
non technical question: does dius/pact have official logo's that can be used? I'm working on a slack webhook, and was wondering if I could use a proper pact logo for it
matt.fellows
2019-04-29 12:52
It looks like there might have been a garbage collection like event on RDS around that time. Average requests went up to 1.9s (around 10:30 local time, so 22 mins ago)
s1apped
2019-04-29 13:46
if I have a webhook with event = contract_content_changed, both consumer and provied version is commit sha and consumer is tagged with branch name
s1apped
2019-04-29 13:47
should this webhook trigger provider build even though the contract didn't change?
s1apped
2019-04-29 13:57
I created this issue https://github.com/pact-foundation/pact_broker/issues/270
vinod.baradwaj
2019-04-30 06:23
through pack-broker API's can we get list of providers for one particular consumer ?
bheemreddy181
2019-05-01 03:52
So @bethskurrie I did read through tags part now I am clear on that - but we are not yet in place of implementing a feature branch but we merge everything into master as a dark release
james.carman
2019-05-01 19:11
is there a ?global? badge for a provider that means ?all pacts verified??
james.carman
2019-05-01 19:11
Or, is the idea that you?d put a badge for each provider you consume from on your consumer README?
vitaliy.grigoruk
2019-05-01 19:45
Hey folks,
I have a question for people who?re using broker webhooks to trigger provider verifications when consumer contract is changed.
How do you make your provider verification CI job to verify only changed contract ? Right now, my provider verification job verifies contracts from all consumers that have same tag.
For example:
- there is 1 provider and 3 consumers.
- git branch name is used to tag contracts.
- consumer#1 contract changes for master build and it is published to a broker.
- broker webhook triggers provider verification CI job and passes `CONSUMER_VERSION_TAG=master` as build param
- `pact-provider-verifier` is invoked with `--consumer-version-tag master` arg.
As a result, provider verification CI job will fetch contracts from all 3 consumers instead of a contract that has been changed recently.
It feels like `pact-provider-verifier` is missing an optional arg `--consumer`, so it will be possible to filter contracts by consumer name (if provided)
bethskurrie
2019-05-01 23:12
The webhook payload can be templated. You can pass the url of the contract that has just been published to the ci job, and if you can parse the parameters, you can then pass that url to the verification job.
bethskurrie
2019-05-01 23:13
It will be a different command than the one you use as part of your default verification job, where you would just give the name of the provider and it would fetch all the pacts based on the name. You'll need to use the format where you pass in a specific URL.
bethskurrie
2019-05-02 05:35
pact-provider-verifier http://the-pact-that-changed --broker-username ... --broker-password ...
bethskurrie
2019-05-02 05:36
yes, when I answered your question I realised it wasn't written anywhere.
bethskurrie
2019-05-02 05:37
I mean, the CLI args are documened in the github auth, and if you use --help
vitaliy.grigoruk
2019-05-02 07:14
I?ve been using this doc: https://github.com/pact-foundation/pact_broker/wiki/Webhooks
bethskurrie
2019-05-02 07:15
The problem is, there are so many different pact languages that someone might verify in, it's hard to know what docs to put where.
bethskurrie
2019-05-02 07:15
@uglyog in the pact-jvm impl, is it possible to set up a pact verification task (separate from the default one) that just accepts one pact URL and broker creds?
bethskurrie
2019-05-02 07:19
cool. I'll add some docs saying that you can configure your job to just accept the changed pact, and say "see the docs for your verification task" because we don't want to have that repeated all over the place.
bethskurrie
2019-05-02 07:34
I've updated this @vitaliy.grigoruk. Does that explain it clearly enough? https://github.com/pact-foundation/pact_broker/wiki/Webhooks#provider-ci
bart.schotten
2019-05-02 10:54
Question: When you have a pacticipant A that is both a consumer of events of pacticipant B, *and* a consumer of an API of pacticipant B, it seems that you would have two contracts between the same consumer and provider (at least based on how it's now being implemented for pact-net. Is there a way for the Pact Broker to deal with this, or can it only deal with one contract per consumer-provider pair?
A possible workaround would be to give the consumer or provider a slightly different name or something, but that's a bit nasty.
ian.mcwilliams
2019-05-02 11:01
i'll be hitting this issue in the near future - so pactSetup.js lets you set the provider info and it seems you can only set one consumer and provider, right? what if you are consuming from more than one provider?
ian.mcwilliams
2019-05-02 11:01
```global.provider = new Pact({
consumer: 'my-system',
provider: 'some-provider',
port: global.port,
log: path.resolve(__dirname, '../', 'logs', 'mockserver-integration.log'),
dir: path.resolve(__dirname, '../', 'pacts'),
spec: 2,
cors: true,
pactfileWriteMode: 'update',
});```
bethskurrie
2019-05-02 11:03
It's not going to be something that will get picked up immediately, but you can raise an issue for a future feature request.
ian.mcwilliams
2019-05-02 11:13
i don't think anyone's _really_ a js person :wink: no i think it's just understanding how to separate the two, for example it could be that global.provider contains an array of Pact objects, or it could be that we have `global.provider_a` and `global.provider_b`, each containing a Pact object - i'm not sure how the pactfile job identifies relevant Pact objects so whatever we do needs to just be in line with how that job works
ian.mcwilliams
2019-05-02 11:15
ok great, thanks! hopefully @matt.fellows can help with the CI issue, if i can get that working for us then i'll quickly be onto multiple providers :+1::blush:
bethskurrie
2019-05-02 11:15
Then you just make sure that file is required before any of your pact tests
matt.fellows
2019-05-02 11:17
I?ll be looking shortly at that issue Ian - I?m at the AWS Summit and the lights at my desk stopped working. Moving things around so that I can comfortably work :slightly_smiling_face:
bethskurrie
2019-05-02 11:18
Clarification. The lights at the summit worked fine - it's the lights on his hotel that aren't working!
matt.fellows
2019-05-02 11:20
can?t brain now, so don?t expect amazing problem solving skills from me :slightly_smiling_face:
ian.mcwilliams
2019-05-02 11:21
yeah, i guess light can be considered a vital pre-requisite :laughing: cheers matt, i'll be in a meeting or two but otherwise around if there's anything i can try or info i can provide :+1:
vitaliy.grigoruk
2019-05-07 08:56
Hey folks. Does anybody use pack broker webhooks for posting status checks to consumer github commits?
I?m triggering 2 provider verifications jobs (using code from master and release branches, that correspond to staging and production environments) every time consumer contract is updated on a broker.
The question is:
- how can I pass a link to provider CI build when verification results are published to a broker and then pass it to github status (so when I click on the link in github status check -> I got redirected to provider CI build URL instead of pact broker verification results URL). I guess that support for this should be implemented in both pact broker as well as client libraries. Right now I don?t have a possibility to trace provider verification results in pact broker to a URL of provider CI build that generated those results
bethskurrie
2019-05-07 08:57
The underlying API supports it, but I don't think it's currently used in the clients.
bethskurrie
2019-05-07 08:59
Raise an issue in pact provider verifier to be able to provide the CI link via the CLI verify call.
vitaliy.grigoruk
2019-05-07 11:24
Hi @bethskurrie. I?ve implemented it according to your suggestion, but now provider verification results are not posted back to pact broker?
bethskurrie
2019-05-07 11:52
Are you passing the right things in? It needs the provider version number, and the flag to publish the results has to be turned on.
bethskurrie
2019-05-07 11:54
It's the same underlying code, no matter how it gets the link, so if it's not publishing the verification, it's because something is not being passed in the same way. It might be a bug in the js wrapper code.
bethskurrie
2019-05-08 07:08
Do you use feature toggles @bheemreddy181? You can use the feature toggles as tag names, and generate a different contract by turning the feature toggle on.
mtissot79
2019-05-10 14:42
Hi pact. I need the new docker image that can be run without root permissions, as the kubernetes instance on which I try to deploy does not allow root deployment.
But I can not find this image on docker registry.
Could you please tell me where can I find it?
Thx so much
yousafn
2019-05-10 14:47
There is a link on the repo
https://github.com/pact-foundation/pact-broker-docker
https://hub.docker.com/r/pactfoundation/pact-broker/
but note the image is currently tagged as `edge`
bethskurrie
2019-05-12 23:39
@mtissot79 we're expecting that this will be the new standard Pact Broker deployment image, but as this particular deployment configuration is quite new, we're just making sure people know this before they use it. So far, nobody has reported any issues, and it's been out for a few weeks.
james.hattersley-dyke
2019-05-13 10:48
Hi, I'm using the broker and can-i-deploy but there's no option on the cli for a token? Only username and password?
james.hattersley-dyke
2019-05-13 10:49
nothing documented in the `can-i-deploy --help` either :disappointed:
matt.fellows
2019-05-13 11:13
you could use https://github.com/pact-foundation/pact-ruby-standalone/releases in the meanwhile
matt.fellows
2019-05-13 11:25
OK yep just missing the flag - should be a new release out in 30 mins @james.hattersley-dyke
matt.fellows
2019-05-13 12:10
@james.hattersley-dyke https://github.com/pact-foundation/pact-node/blob/master/CHANGELOG.md#830-2019-05-13
matt.fellows
2019-05-15 05:38
we?ve been discussing the pros/cons of having a hosted mock service (stub in Pact parlance) as part of http://pactflow.io. One the one hand, it wouldn?t be a huge amount of work to have any contract become an instant ?mock server? on the other you can already do it via CLI tools like the pact-stub-server at https://github.com/pact-foundation/pact-ruby-standalone/releases .
Is this something people would find useful? If so, why?
franklin.huynh
2019-05-15 08:43
hello @matt.fellows
I'm proposing the team (5 users) plan for my company as you my know. I'm getting some questions
- Will it limit our developers to access to pact broker.
- What will happen if there are many people login to pact broker at the same time?
- What the meaning of "user" here? For example, the contract publish by user a. Will other user be able to see the contract?
- What will happen if the pact broker is unavailable? Will we have a timely support only with chat and email?
Could you help me with these questions?
matt.fellows
2019-05-15 09:20
Hi @franklin.huynh, i?ll try to answer your questions
A user is considered any person / system that requires independent access to the broker. For example, if you have a User that will be logging into the UI they will need their own user.
Each user gets a single readonly and read-write API token that can be used for automation (e.g. CI or local verification).
You probably only need 1 user seat per human logging into the UI. Readonly tokens can be generated for use by team members that don?t need UI access.
heymega
2019-05-15 09:21
@matt.fellows
I'm just looking at PactFlow and I'm a little confused
Is PactFlow just a managed broker? If so, how does it differ from the existing broker we've come to know and love?
vk.regs
2019-05-15 09:21
Hi
I want to use pact files from pact broker for pact stub.
Is it possible to get link to pact files in part broker?
matt.fellows
2019-05-15 09:21
> What will happen if there are many people login to pact broker at the same time?
At the moment, the limit is absolute, not concurrent. So if you have more than 5 users needing access but not at the same time, this will exceed the limit
bethskurrie
2019-05-15 09:22
If you want to hand craft it, it will look something like `http://BROKER/pacts/provider/PROVIDER/consumer/CONSUMER/latest`
bethskurrie
2019-05-15 09:23
or if you're using tags `http://BROKER/pacts/provider/PROVIDER/consumer/CONSUMER/latest/TAG`
bethskurrie
2019-05-15 09:24
if you open it in a browser, you get an HTML rendering. If you use the header "Accept: application/hal+json" you get the JSON
matt.fellows
2019-05-15 09:24
> What will happen if the pact broker is unavailable? Will we have a timely support only with chat and email?
We provide email support for this tier and are implementing chat very soon. We typically respond within a few hours AEST. Our SLAs are documented in the T&Cs. As for downtime, we have invested a lot this year into the resilience and security of our infrastructure. We have zero downtime deployments and will give you at least 48 hours notice.
matt.fellows
2019-05-15 09:26
The TL;DR is that the Developer and Team plans are hardened, highly available and secured variants of the open source broker. They have social integration (e.g. GitHub), API tokens and also a new UX
matt.fellows
2019-05-15 09:27
The business tier (which is not generally available) is where we are adding features that are _not_ Pact specific - e.g. Swagger / OAS integration
heymega
2019-05-15 09:29
Also with it being managed would you provide upgrades as new version of the specification change?
vk.regs
2019-05-15 09:30
One more general question: what is the best practice prepare pact files for pact stub (manually, may be some generator exists)?
bethskurrie
2019-05-15 09:31
Well, to be exact, the HTML rendering of the pact cares about the spec version, but if it can't parse it, it just displays the JSON.
matt.fellows
2019-05-15 09:31
But you can assume the broker will update as new changes make their way into the OSS broker. I don?t have the numbers, but I would suggest we release updates multiple times a week at a _minimum_
bethskurrie
2019-05-15 09:31
But yes, pactflow will always have the latest version of the Pact Broker code.
bethskurrie
2019-05-15 09:31
In fact, sometimes it has the code before the OSS codebase, because I'll try things out in pactflow before I do an official release of the OSS code :wink:
heymega
2019-05-15 09:32
Cool.
Are the API calls still protected by basic auth or is now using something like bearer tokens?
franklin.huynh
2019-05-15 09:32
thanks Matt. Could you explain this a bit
```
So if you have more than 5 users needing access but not at the same time, this will exceed the limit
```
franklin.huynh
2019-05-15 09:34
- Do you mean 5 users using 1 credential?
- How can it still exceed the limit if they are not accessing at the same time?
matt.fellows
2019-05-15 09:35
Each User that requires access to the UI should have their own username/password
heymega
2019-05-15 09:35
Sweet!
Last question before I try and steal my boss' credit card.
I work for a registered charity in the UK in the education sector.
Do you offer discounts?
matt.fellows
2019-05-15 09:35
> Do you mean 5 users using 1 credential?
No - we wouldn?t recommend that sort of security practice
franklin.huynh
2019-05-15 09:37
and each user can generate the token to use in term of Readonly and read-write permission?
matt.fellows
2019-05-15 09:37
There would be 5 users registered in the system, each with their own set of credentials to authenticate (or users registered through Social login via GitHub). Each user can also create API tokens for automation
franklin.huynh
2019-05-15 09:38
so if I understand correctly, the participants of a user will not be accessible by other users
matt.fellows
2019-05-15 09:42
We haven?t had that question yet - but let?s chat offline. Can you contact us at ? If you send us what you need (i.e. number of users and anything else that comes to mind) we?ll work something out.
richard.peckett
2019-05-15 09:57
peeps, it looks like a pull request has been completed for AMQP for Neil's pact dot net implementation; assuming will this play nicely with the new broker? :smile:
richard.peckett
2019-05-15 10:06
I was going to have a play with this this afternoon by just signing up for your free tier pact flow broker
matt.fellows
2019-05-15 10:07
If it is still producing the correct pact files publishing shouldn't be hard though
matt.fellows
2019-05-15 11:37
No there is no generator. The contracts are generated by the pact tests themselves
matt.fellows
2019-05-15 11:40
See how you go. In theory there's no reason why it can't work with the broker, even if not using the implementation in Ruby/JS etc
matt.fellows
2019-05-15 11:41
As long as you can pull in and publish the contracts independently it should be ok - we have CLI tools to communicate with the broker and then Pact Net can do the bits in between
franklin.huynh
2019-05-16 03:58
Hi, do you guys have example for webhook for trigger bitbucket pipeline
matt.fellows
2019-05-16 03:59
I haven?t seen one myself, but if you get it working, we?d love to see it make its way to https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library :pray:
franklin.huynh
2019-05-16 05:31
Please ignore my question, I already found the solution
~hey @matt.fellows I'm trying debugging about the webhook stuff. But I receieve this message~
```
"message": "For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See /doc/webhooks#whitelist for more information."
```
~I'm running docker-compose up on my local for testing but could not enable the whitelist. I update the docker-compose.yml as below but still not able to see the error message. Could you please help me?~
```
version: "3"
services:
postgres:
image: postgres
healthcheck:
test: psql postgres --command "select 1" -U postgres
ports:
- "5432:5432"
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_DB: postgres
broker_app:
image: dius/pact-broker
links:
- postgres
# If you remove nginx, enable the following
ports:
- "80:80"
environment:
PACT_BROKER_DATABASE_USERNAME: postgres
PACT_BROKER_DATABASE_PASSWORD: password
PACT_BROKER_DATABASE_HOST: postgres
PACT_BROKER_DATABASE_NAME: postgres
webhook_host_whitelist: http://api.bitbucket.org
# Nginx is not necessary, but demonstrates how
# one might use a reverse proxy in front of the broker,
# and includes the use of a self-signed TLS certificate
# nginx:
# image: nginx:alpine
# links:
# - broker_app:broker
# volumes:
# - ./ssl/nginx.conf:/etc/nginx/conf.d/default.conf:ro
# - ./ssl:/etc/nginx/ssl
# ports:
# - "8443:443"
# - "80:80"
```
franklin.huynh
2019-05-16 05:33
~I added the webhook_host_whitelist environment variable with the whitelist host~
mtissot79
2019-05-16 08:35
Hi Beth
The docker image works now but I met some troubles with the security policy that my company put in kubernetes.
The security policy don't allow root user or user without uid.
I pulled the code from git and change a little bit the docker file:
Add '-u 1000' in the useradd command
Change the line 'USER ruby' to 'USER 1000'
After repackaging the image, all works in k8.
Maybe this could help you if other companies put this kind of policy in k8
Cheers
Michael
bethskurrie
2019-05-16 08:35
Thanks. Is there any reason why we woulnd't put that in to the main code?
mtissot79
2019-05-16 11:31
First the user iud should be a parameter, and I m not a kubernetes policy expert. If a policy allow only user by username for exemple, the container will not start in k8 because of 'USER 1000'.
Because I m lacking knowledge on that part, I can not submit my local modifications as a pull request.
bethskurrie
2019-05-16 12:35
Hm. OK. Maybe we could have a branch of the code and have a kubernetes tag.
bethskurrie
2019-05-16 22:07
@arunkumarpoonia the broker does not do any verification. It is a service for exchanging the contracts and the verification results. The problem you are having is during pact verification. If you look lower down in the error message you received, there is a list of the descriptions of the differences. It will include a message that says something like "array is too long". That is the problem. Your provider is return and array that is longer than the consumer expected. Your consumer should use an "each like" to say that they don't care how long the array is.
bethskurrie
2019-05-16 22:08
Hey @vitaliy.grigoruk I've updated the section in the Effective Pact Setup Guide on getting the builds set up. Can you tell me what you think of this section? https://docs.pact.io/best_practices/pact_nirvana#4-automate-the-contract-and-verification-results-exchange
heymega
2019-05-18 16:58
Couple of questions regarding PactFlows auth...
I understand it supports bearer tokens. Is this using Oauth?
If so, do you support non user grant types like client credentials grant? Sometimes a user won't be present especially when making calls in deployment pipelines.
If not, are you planning on still supporting basic authentication alongside it?
matt.fellows
2019-05-18 22:41
The bearer token are simply API keys which can be generated by users. You can create read only and read write tokens
matt.fellows
2019-05-18 22:42
We actually support openid connect but have only inplemented GitHub (which is actually oauth2) at the moment as it was the most requested. We also support standard authentication via user/pass.
heymega
2019-05-19 17:27
Kinda!
So if these tokens need to be generated by users (by logging into GitHub), how do incorporate that into a build pipeline where a user context doesn't exist?
Or are you saying we can generate long lived tokens after we've logged in?
Github and Azure DevOps allow you to generate PAT (Personal Access Tokens) for this reason. Will the broker allow us to to generate these kinds of long lived tokens?
vitaliy.grigoruk
2019-05-20 09:11
Hi everybody.
I?ve set up pact broker webhook for github commit status https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library#github---publish-commit-status
So the workflow looks the following way:
1. developer pushes a code change to a feature branch of consumer codebase.
2. consumer CI executes tests for that commit and uploads generated contract file to pact broker.
3. if published pact is different from latest one:
a - pact broker executes a webhook that creates `pending` ?Pact verification? status for that github commit.
b - pact broker executes a webhook that triggers provider?s CI job that verifies recently published contract.
4. provider?s CI job publishes verification results back to pact broker.
5. pact broker executes a webhook that updates consumer commit ?Pact verification? status to `passed` or `failed`.
This workflow allows us to pre-verify contracts before consumer feature branches are merged into master. We use Github PRs that are merged only if all status checks are green. Github statuses for consumer commits work correctly when contract is changed (as in workflow described above). However, when it doesn?t change - there are no status checks created. I understand that new contract version inherits verification results from previous one if contract doesn?t change. It will be still nice to have a way to create a webhook event for the case when contract is published but content didn?t change. Then we can use this event to create status checks for consumer github commits even in cases if contract hasn?t changed.
Any thoughts on this, @bethskurrie?
bethskurrie
2019-05-20 09:26
And secondly, yes, there is an event for pact published (rather than changed). You should use that for your github status updates. Have a look at the webhooks api docs, and you'll find it.
vitaliy.grigoruk
2019-05-20 09:54
I guess using `pact published` event instead of `pact changed` will help me to get commit statuses for all consumer commits. However, this means that provider verification CI job will be triggered every time when contract is published, rather than when contract is changed. It is fine for us for now, as we don?t have many services ?pactified?. But in a long term I?d like to avoid redundant provider verifications for the same pact contract.
It would be cool if there are more events available to attach webhooks to. E.g. `contract_content_not_changed` or `provider_verification_inherited`
bethskurrie
2019-05-20 09:55
No... You have one webhook to trigger ci (pact changed) and one webhook for github statuses (pact published).
vitaliy.grigoruk
2019-05-20 10:06
hm? I think I know why it doesn?t work fo me? I?m triggering 2 provider verification jobs (one is running with latest `master ` branch, other with `release` branch, which correspond to `staging` and `production` provider versions). I?ve setup a webhook like this first: https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library#github---publish-commit-status
and as a result I get 1 `pending` status check when new contract version is published with `context: api ` and then when both `staging` and `production` provider verifications are finished and results are published to a broker, I get 2 more statuses `context: api staging` and `context: api production`. However, pending status still remains?
vitaliy.grigoruk
2019-05-20 10:08
so, I split https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library#github---publish-commit-status webhook into 3:
- 2 `contract_content_changed` webhooks that create `pending` status check for `context: api staging` and `context: api production`
- 1 `provider_verification_published` webhook (same as in webhook library, but without `contract_content_changed` event.
arunkumarpoonia
2019-05-20 11:13
I am unable to create webhook for http url , Below error is returned :
arunkumarpoonia
2019-05-20 11:13
"scheme must be https. See /doc/webhooks#whitelist for more information."
arunkumarpoonia
2019-05-20 11:14
Is it possible to create webhook for http url, @bethskurrie can you help here pls ?
bethskurrie
2019-05-20 11:21
I'm still confused. You should only need 2 webhooks. One that updates github on contract published and provider verification published. And one that triggers the ci on contract content changed.
bethskurrie
2019-05-20 11:22
Can you go the the url on your own broker that the error message tells you to?
arunkumarpoonia
2019-05-20 11:29
its fine, i am able to see details on this screen - hal-browser/browser.html#/webhooks/provider/-test-API/consumer/test-UI
arunkumarpoonia
2019-05-20 11:30
I am looking at this page npw- https://github.com/pact-foundation/pact_broker/wiki/Configuration#webhook-whitelists
vitaliy.grigoruk
2019-05-20 11:30
yeah, this works well when I?m verifying contract with only one version of provider.
When I?m triggering 2 CI provider verification jobs (master and release branches), this setup doesn?t work as desired. I?d like to get 2 statuses for each consumer github commit:
- `provider release branch`
- `provider master branch`
bethskurrie
2019-05-20 11:38
Maybe you could take a series of screenshots of the github PR statuses for me, and send me the json for the webhooks you're working on, and I'll see if I can nut it out.
bethskurrie
2019-05-20 11:40
I've got to go to bed ( :flag-au:) but send what you can to and I'll have a look in the morning.
vitaliy.grigoruk
2019-05-20 20:45
I?ve decided it would be better to make it publicly available instead @bethskurrie
sankalan13
2019-05-21 06:01
Hi guys
Very new to pact and I'm trying to create webhooks from the free hosted pact-broker "Pact-flow". I want to know how I can set the 'PACT_BROKER_WEBHOOK_HOST_WHITELIST' env variable when I am using the hosted broker. For the docker-compose broker, I can easily set it in the compose file itself.
bethskurrie
2019-05-21 06:03
Let me look into it and see if I can made this customisable at a tenant level though.
bethskurrie
2019-05-21 06:04
Can I ask what you're connecting to that's on the public internet but isn't https?
sankalan13
2019-05-21 06:08
Thank you for the quick response :slightly_smiling_face:
I wanted to make webhook triggers for slack and github but in the locally hosted docker pact-broker, i could not make the webhook triggers work unless I whitelisted the urls.
I was thinking its the same case with pact-flow. (Asked the question without trying out first)
Have these URLs already been whitelisted in pact-flow? @bethskurrie
sankalan13
2019-05-21 06:11
Awesome thank you so much for that.
Is there any documentation for pact-flow currently?
bethskurrie
2019-05-21 06:12
All the OSS documentation applies to pactflow currently. We're working on creating separate docs, as we add new features that aren't available in the OSS version.
sankalan13
2019-05-21 11:20
Hi guys
I am using the pact-verifier to get my pact file from pact-flow and use it to verify my provider. This is the exact code I have been using:
```pact-verifier --provider-base-url="http://localhost:8000" --pact-url="https://springboard.pact.dius.com.au/pacts/provider/paymentcallutilityservice/consumer/ui/latest/" --provider-states-setup-url="http://localhost:8000/_pact/provider_states/" --custom-provider-header="Authorization: Bearer ***********" -a "0.0.2" -r```
Here are a few things I have tried:
1) Changing the bearer token on the --custom-provider-header tag and putting it in the URL
2) Added and removed --pact-broker-username="********" --pact-broker-password="******"
3) Used the ruby pact-provider-verifier gem instead of the one with python
4) used the actual version of the pact in the pact flow instead of /latest/ tag
5) changed the localhost base urls to actual server running on kubernetes
6) using the old --broker-token from pact-provider-verifier
None of the above has resolved the issue. The error I am getting is
```Error reading file from https://springboard.pact.dius.com.au/pacts/provider/paymentcallutilityservice/consumer/ui/latest/
HTTP request failed: status=401 /Users/Sankalan/.virtualenvs/work/lib/python2.7/site-packages/pact/bin/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.7.2/lib/pact/consumer_contract/pact_file.rb:69:in `block in get_remote_with_retry'```
With stack trace to follow.
P.S.
Is this the right channel for these questions or should I direct them to some other channel. :slightly_smiling_face:
sankalan13
2019-05-21 11:28
Yes I am using pact python.
Okay trying it :slightly_smiling_face: thank you
sankalan13
2019-05-21 12:09
Hey @bethskurrie
Thank you for guiding me in the right direction.
I updated the latest version of pact-provider-verifier and now the --broker-token is visible to me. I am using this command now:
```pact-provider-verifier --pact-broker-base-url="https://springboard.pact.dius.com.au/" --provider-base-url="http://localhost:8000" -c "http://localhost:8000/_pact/provider_states" --broker-token="**********" -a "0.0.1" -r -v --provider=paymentcallutilityservice```
The error changed, before I wasn't able to retrieve the URL but I am still getting a 401 unauthorized. I am not able to get my pact file from the pact-flow server using my bearer token. I even tried using the basic auth but that also doesnt seem to work.
```INFO: Fetching pacts for paymentcallutilityservice from https://springboard.pact.dius.com.au/ for tags: latest 0.0.2
opening connection to http://springboard.pact.dius.com.au:443...
opened
starting SSL for http://springboard.pact.dius.com.au:443...
SSL established
<- "GET /? HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nAuthorization: Basic amluYWxAc3ByaW5nYm9hcmQuY29tOkppbmFsQDEyMw==\r\nHost: http://springboard.pact.dius.com.au\r\n\r\n"
-> "HTTP/1.1 401 Unauthorized\r\n"
-> "Date: Tue, 21 May 2019 12:02:27 GMT\r\n"
-> "Content-Type: text/plain\r\n"
-> "Content-Length: 0\r\n"
-> "Connection: keep-alive\r\n"
-> "Status: 401 Unauthorized\r\n"
-> "X-Pact-Broker-Git-Sha: 742d506c8cd63cc4c7e25aecfb0e31ab2af3a7e5\r\n"
-> "WWW-Authenticate: Basic realm=\"Restricted area\"\r\n"
-> "X-Saas-Broker-Git-Sha: deb11516a75e3b5052b6f634fa71603e35b4add7\r\n"
-> "X-Pact-Broker-Version: 2.31.0\r\n"
-> "X-Request-Id: ab2e290d9bae7a74fdb0fb3d12b9124d\r\n"
-> "X-Frame-Options: SAMEORIGIN\r\n"
-> "X-XSS-Protection: 1; mode=block\r\n"
-> "X-Content-Type-Options: nosniff\r\n"
-> "Referrer-Policy: strict-origin\r\n"
-> "Strict-Transport-Security: max-age=31536000 ; includeSubDomains\r\n"
-> "\r\n"
reading 0 bytes...```
pactfoundation/pact-cli only has a publish option and a can-i-deploy option. It does not have an option from where I can verify my provider.
matt.fellows
2019-05-21 21:10
Would the verifier at https://github.com/pact-foundation/pact-ruby-standalone help?
sankalan13
2019-05-22 03:48
Thanks Matt. I will try that too. I found the problem yesterday (I guess? :p)
Pact version release 1.40.0 supports broker token but pact-provider-verifier gem uses pact 1.38.0 version release. I think this is the problem. When I remove 1.38 and install 1.40, pact mock service gem collides and raises version conflict.
```Unable to activate pact-message-0.5.0, because pact-mock_service-3.1.0 conflicts with pact-mock_service (~> 2.6) (Gem::ConflictError)```
because pact-mock_service depends on pact-message 0.5.0.
I am not sure if the current pact-broker-verifier is compatible with the --broker-token field.
bethskurrie
2019-05-22 03:50
The verification process executes a command, and that command gets printed to the terminal. I didn't want to have the token printed to the terminal - hence the use of the env var.
sankalan13
2019-05-22 05:22
Thanks Beth. Can you give a tentative estimate as to when the fix will be out?
sankalan13
2019-05-22 05:46
I am using the pact-provider-verifier gem and I see that the fix is out as pact-provider-verifier is using pact 1.40.0 but the provider verification is still failing for me somewhere in the pact-support 1.10.2 version. I'm trying to get to the bottom of it but I have a hunch that the broker token is not propagating through.
Will send a screenshot of the stack trace
sankalan13
2019-05-22 05:52
This is the stack trace I am getting. The first two times, the broker token is being propagated to the header when accessing the pactflow url and then the /provider/name/latest url. But as soon as the verifier tries to access the actual pact file url, the broker token is not passed with it. Because of which I am not able to read the file. I am still trying to find the exact problem. Maybe you guys will know it quicker if there is a problem here.
sankalan13
2019-05-22 05:55
@matt.fellows pact standalone is still using pact 1.38.0 so pact-provider-verifier is failing on it.
sankalan13
2019-05-22 07:27
Pact support is awesome!! You guys are so proactive!! Highly appreciated :smile:
qatrera
2019-05-22 10:51
Hi! We are wondering if this endpoint `DELETE /pacts/provider/{provider}/consumer/{consumer}/tag/{tag}` will delete a pact that has more than one tag. For instance, I have a pact tagged with `['production', 'my_branch_name']` and I delete the pacts with tag `'my_branch_name'` using the mentioned endpoint, will my pact be deleted too? or it will only remove the `'my_branch_name'` tag?
bethskurrie
2019-05-22 11:27
I have had the thought though that it would be better to make it just remove the tag if there are other tags attached, so you can keep all your prod pacts, but remove ones from a branch you're no longer using.
bethskurrie
2019-05-22 11:28
I'm not sure when I'll get around to it, but can you raise it as a feature request?
qatrera
2019-05-22 12:03
> I have had the thought though that it would be better to make it just remove the tag if there are other tags attached, so you can keep all your prod pacts, but remove ones from a branch you're no longer using.
that's the use case we were thinking (still trying to figure some things out around Pact) but we were concerned we could potentially overload the broker with no longer used pacts.
qatrera
2019-05-22 12:25
we'll investigate a bit more and create the feature request if we need to (and try to create a PR for it)
detert
2019-05-22 15:59
Hi. I call the `pact-provider-verifier` with a https broker url, however the publish-verify-results call seems to try to call http (I get a redirect from my webserver at port 80). Is that a known issue?
matt.fellows
2019-05-22 21:24
Can you prove/demonstrate this? That would definitely be a new bug and is not intended behavior
matt.fellows
2019-05-24 06:11
that would imply that you were configuring it with an http url - I?m concerned if you?re removing that redirect (seems like a good security practice)
detert
2019-05-24 06:24
The successful version even states published to http:// even if I provide https://
qatrera
2019-05-24 09:51
Hi again! :wave: Context: we are using pact_broker_docker FROM dius/pact-broker:2.31.0-1. Our Jenkins has 'Prevent Cross Site Request Forgery' enabled so in order to trigger a Jenkins job from a webhook we also need to pass a valid `crumb` . This `crumb` is obtained by doing an extra request. Has someone configured a broker webhook successfully with this setting enabled? As far as I know this `crumb` has a TTL, so we can't avoid to perform the auth request first. But in the webhook we can only configure one request. We would really like to avoid to create a proxy service for this if possible. If someone has more ideas we would really appreciate it :blush:
bethskurrie
2019-05-24 10:46
Also, check out the latest broker image at pactfoundation/pact-broker. It's much smaller and runs without root permissions. We'll be retiring the one you're using @qatrera
bethskurrie
2019-05-24 10:46
The same configuration options apply to the new one, you can literally just swap pactfoundation for dius.
qatrera
2019-05-24 11:15
Following this comment by @bethskurrie https://pact-foundation.slack.com/archives/C9VPNUJR2/p1558694762008600?thread_ts=1558691514.007300&cid=C9VPNUJR2 we saw that for the new `pactfoundation/pact-broker` there aren't any tags published https://hub.docker.com/r/pactfoundation/pact-broker/tags (compared with the dius one https://hub.docker.com/r/dius/pact-broker/tags). Would it be possible to have some version tags there? It would help debugging (among other things :slightly_smiling_face: ). Thanks!
bethskurrie
2019-05-24 11:25
Good point @qatrera. We've just been running it in beta for the last few weeks to make sure there weren't any issues.
bethskurrie
2019-05-24 11:25
That's why there's only the edge tag. Nobody has reported anything however, so I reckon we can make an official release.
borsuk.artem034
2019-05-24 15:05
~Hi folks, I need get latest provider version for webhook, I'm try to use ${pactbroker.providerVersionNumber}, but it is empty~ Never mind :slightly_smiling_face: it works when you publish contract and webhook triggered, but not work when you do debugging
borsuk.artem034
2019-05-24 15:09
~more details: I have separate job for running "pact-provider-verifier" which I want to run via webhook in bamboo ...rest/api/latest/queue/PLAN?&bamboo.ENVIRONMENT=${pactbroker.consumerVersionTags}&bamboo.variable.PROVIDER_VERSION=${pactbroker.providerVersionNumber}~
borsuk.artem034
2019-05-25 06:15
Question regarding the previous one, do we have a possibility for new consumer contract set the latest provider version by the same tag as a new consumer?
bethskurrie
2019-05-25 06:17
@borsuk.artem034 are you triggering a provider verification from a webhook? You should pass the URL of the changed pact to the verification job.
borsuk.artem034
2019-05-25 06:46
@bethskurrie np, my fault, I should describe the problem with details. So:
1. Consumer change the contract and version
2. In pact broker, we can see a new line with the version of consumer and empty provider version
3. For trigger "pact-provider-verifier" via webhook in CI, I need pass the TAG and Provider-version
The problem in step 3, I don't know how I can specify a provider version
bethskurrie
2019-05-25 06:47
typically you'd trigger a CI job, and that would just use the latest version of the code (or a set branch/git tag)
bethskurrie
2019-05-25 06:50
are you following the instructions from https://docs.pact.io/best_practices/pact_nirvana#d-configure-pact-to-be-verified-when-contract-changes ?
bethskurrie
2019-05-25 06:51
The consumer doesn't tell the provider which version it should be verified by - the provider decides that.
borsuk.artem034
2019-05-25 06:55
yep, I read already, in that case verification result will be not published, because for publishing require parameter --provider-app-version
bethskurrie
2019-05-25 06:57
the pact gets generated by the consumer tests, published to the broker, the broker triggers a provider verification job in the provider's CI, which checks out the latest version of the code, and verifies the pact at the URL that was passed to it from the webhook. That's the job that needs to know the provider version. It publishes the verification result back to the pact broker with the provider version.
borsuk.artem034
2019-05-25 07:11
mmm, let's proceed with example (sorry for annoying you, i just want solid understanding)
3. webhook pass TAG and run Provider verifying
4. Provider verifying job should checkout latest code base and take branch name and hash commit
Is the correct way?
bethskurrie
2019-05-25 07:12
> Provider verifying job should checkout latest code base and take branch name and hash commit
Yes.
bethskurrie
2019-05-25 07:13
The job for the webhooks (when the pact changes) is different from your normal provider CI pipeline.
bethskurrie
2019-05-25 07:14
The normal provider pipeline is triggered when you commit your provider, and that's the one where you give it specific consumer version tags to verify.
bethskurrie
2019-05-25 07:14
These are described in https://github.com/pact-foundation/pact_broker/wiki/Webhooks
borsuk.artem034
2019-05-25 07:15
In tag I'm specify environment (like test1, test2, stage...) so, if contract changed on test2 then provider to verifing will be on test2 too
bethskurrie
2019-05-25 07:15
if you want to put smarts into the logic, then you'll need an intermediate CI job to trigger the right provider job.
bethskurrie
2019-05-25 07:19
typically you'd go
1. generate pact
2. publish pact (you don't know if it will pass verification yet) and tag with branch name
3. use can-i-deploy to check the status of the pact
4. deploy if it is green
5. tag with the environment name
borsuk.artem034
2019-05-25 07:31
Some kind, we have separate build plans which create a docker images(during build pact generated), then deploy images on environment(during deploy - pact published with version (imageName-commitHash) and runed can-i-deploy)
borsuk.artem034
2019-05-25 07:33
I thought it will be suitable solution, but after talk with you I don't know
bethskurrie
2019-05-25 07:34
you need to publish and get the verification results before you know you're safe to deploy.
bethskurrie
2019-05-25 07:35
otherwise, you could put whatever you liked in a pact, and deploy it to the environment - but it would not work with the provider.
borsuk.artem034
2019-05-25 07:43
yeah, I made a big mistake, many thanks for your time and returning me in the right direction
s1apped
2019-05-28 09:47
Hi. I'm trying to run pact broker docker on aks cluster and postgres database. Looks like pod and service is up and running but unable to connect to HAL and there is nothing in logs ( running it in DEBUG ). I suspect some issues with DB connection but I'm not able to troubleshoot. cat /var/log/nginx/access.log is empty.
bethskurrie
2019-05-28 09:54
I'm not sure how much we can help you because it sounds like you're having problems with the environment more so than the broker itself.
bethskurrie
2019-05-28 09:58
If it had started up and was unable to connect, you should see some logs somewhere indicating that. It seems to me like the broker process isn't even starting.
s1apped
2019-05-28 09:59
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
*** Running /etc/my_init.d/10_syslog-ng.init...
May 28 09:16:10 pactbroker-5b8f46c966-89w67 syslog-ng[13]: syslog-ng starting up; version='3.13.2'
*** Running /etc/my_init.d/30_presetup_nginx.sh...
*** Booting runit daemon...
*** Runit started as PID 22
May 28 09:16:11 pactbroker-5b8f46c966-89w67 cron[27]: (CRON) INFO (pidfile fd = 3)
May 28 09:16:11 pactbroker-5b8f46c966-89w67 cron[27]: (CRON) INFO (Running @reboot jobs)
ok: run: /etc/service/nginx-log-forwarder: (pid 31) 0s
May 28 09:17:01 pactbroker-5b8f46c966-89w67 CRON[57]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
bethskurrie
2019-05-28 10:08
the new one is a fork of the dius one, which one of our contributors converted from nginx to puma, and made it a heap smaller.
antonello
2019-05-28 11:01
Hi! My client and I are investigating how do tagging in the Pact Broker during deploys/flips from blue to green in production. Since the `latest` tag is determined by the version number being tagged, we are unsure how to handle situations in which we decide to flip back to the old version. Here?s an example to illustrate this:
1. Latest `prod` tag is `2.5.0`
```$ pact-broker describe-version --pacticipant a_pacticipant --latest prod --broker-base-url http://localhost:5080
NUMBER | TAGS
-------|-----
2.5.0 | prod```
2. I deploy `2.6.0` and tag it as `prod`:
```$ pact-broker create-version-tag --pacticipant= a_pacticipant --broker-base-url=http://localhost:5080/ --version=2.6.0 --tag prod
Tagging a_pacticipant version 2.6.0 as prod```
3. Pact Broker is now reporting 2.6.0 as the latest `prod` tag. All good
```$ pact-broker describe-version --pacticipant a_pacticipant --latest prod --broker-base-url http://localhost:5080
NUMBER | TAGS
-------|-----
2.6.0 | prod```
4. Let?s assume something is wrong and I want to flip back to 2.5.0. I retag 2.5.0 as prod. (This is a no-op I assume)
```$ pact-broker create-version-tag --pacticipant= a_pacticipant --broker-base-url=http://localhost:5080/ --version=2.5.0 --tag prod
Tagging a_pacticipant version 2.5.0 as prod```
5. But the Pact Broker reports that latest `prod` is still ´2.6.0` !
```$ pact-broker describe-version --pacticipant a_pacticipant --latest prod --broker-base-url http://localhost:5080
NUMBER | TAGS
-------|-----
2.6.0 | prod```
bethskurrie
2019-05-28 11:01
If you want to return to a previous version, you need to delete the prod tag from the version you un-deployed.
antonello
2019-05-28 11:02
I was looking for documentation on how to delete a tag, but couldn?t find any. Will the HAL browser give me the answer I?m looking for? :slightly_smiling_face:
bethskurrie
2019-05-28 11:02
I have been considering altering the behaviour of "latest" so that it could work like you said.
bethskurrie
2019-05-28 11:04
I was just checking if I'd done a delete in the CLI, but it seems not yet
antonello
2019-05-28 11:04
well, making an API call these days is cheap, but I will also suggest a PR :slightly_smiling_face:
bethskurrie
2019-05-28 11:05
warning, I'm crazy busy with Pactflow right now, but hopefully I'll get to it!
antonello
2019-05-28 11:07
Well, the guys at Treatwell could look into creating a PR to add the ability to delete a TAG via che pact broker cli. It shouldn?t be too bad
bethskurrie
2019-05-28 11:08
it should be quite straightforward, though the code in that repo is a mix of old Beth code (6 years ago) and new Beth code (shiny!) so not all of it in there is a good pattern to copy!
s1apped
2019-05-28 12:20
is there an option to change url root path from http://my.broker.com to http://my.broker.com/pact?
matt.fellows
2019-05-28 12:23
if you?re hosting your own, you?d probably need to do some magic with whatever reverse proxy you put in front of it (e.g. rewrite rules) or modification to the Ruby app itself (it?s probably possible with some magic in http://config.ru or a separate piece of middlelware)
diandra
2019-05-28 19:00
Hi , im starting with pact, I want to publish my pact in Pactflow, I have copnfiguration my publish.js file, when I run it I get an authentication failure (the username and password is correct), some idea that could be wrong :disappointed:
matt.fellows
2019-05-28 22:12
You should be authenticating using the bearer token mechanism. My guess is that you?re trying to use your username (email address) + password.
matt.fellows
2019-05-28 22:13
Head to settings, grab a token (read/write) and then user the `pactBrokerToken` property
detert
2019-05-29 06:11
Two thoughts: Did you try to fix the warning "Insecure world writeable"? And are you able to publish contracts using just CURL?
bart.schotten
2019-05-29 09:35
We're using version 2.31.0-1 of the dius/pact-broker docker image, no custom configuration. We using only Git hashes as pacticipant versions (no semver). According to https://github.com/pact-foundation/pact_broker/wiki/Configuration#ordering-versions-by-date it should sort by date by default, but... it doesn't. Even after uploading a new version. Am I wrong about the expected behavior here?
bethskurrie
2019-05-29 09:39
It should default to true if not set https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/docker_configuration.rb#L42
bethskurrie
2019-05-29 09:41
What ordering are you seeing @bart.schotten? Random? Can you create a script to recreate the issue, and raise an issue in the pact-broker-docker repository, I'll have a look at it.
bart.schotten
2019-05-29 10:47
It might be relevant that most of these were uploaded when we had an old version deployed (without the default sorting by date).
bethskurrie
2019-05-29 10:48
As long as the new ones are going in the right order, it's working as expected.
bart.schotten
2019-05-29 10:48
Ok, that clears things up at least. I guess I'll have to delete older versions then.
bethskurrie
2019-05-29 10:49
Usually you only deal with the latest version, or the latest tagged version. Anything else becomes irrelevant.
bethskurrie
2019-05-29 10:52
Having semantic versioning at all turned out to be the wrong decision! It was written in an environment where everything was semantically versioned. You live and learn!
shalygai.a
2019-05-29 15:58
Hi! Is there any support for https://www.npmjs.com/package/@mattersight/karma-pact-reporter ?
matt.fellows
2019-05-29 22:04
Looks like a personal project of a maintainers, but if you had issues I'm sure they'll support it if it doesn't get answered here
bethskurrie
2019-05-30 04:35
The newer, smaller, sleeker, un-rootier, and downright sexier Pact Broker Docker image is now officially released. Get yours at `pactfoundation/pact-broker:2.32.0-2`. It is fully backwards compatible with the environment variables from the previous `dius/pact-broker` image, but now runs on port 9292 by default so it doesn't need root (and this port is configurable). Many thanks to @stipud for his work on this!
bethskurrie
2019-05-30 04:42
While I've got your attention, some new features that have been added to the UI recently:
? Delete a single pact
? Delete all pacts between a consumer/provider
? Delete an entire integration and all related objects (consumer/provider/webhooks etc)
bethskurrie
2019-05-30 04:43
So go crazy, DELETE ALL THE THINGS! You can just republish them anyway...
bethskurrie
2019-05-30 23:42
The buttons haven't been added to the new UI yet @sankalan13, but you can always switch to the old (OSS) UI to access them. There's an "old ui" toggle button at the top of the page.
bethskurrie
2019-05-30 23:44
@vitaliy.grigoruk I can't remember anyone specific, but I can't see a reason why it wouldn't work.
bethskurrie
2019-05-30 23:45
The pact-jvm and ruby clients have retries built into them so if it takes a while to come up, there shouldn't be any noticeable side effects.
detert
2019-05-31 13:03
Does someone use Gitlab together with pact-broker? I am searching for ideas on how to integrate can-i-deploy before a merge request might be merged into master
bethskurrie
2019-06-01 03:49
If you want to get complex about it, this approach may help you @detert https://github.com/pact-foundation/pact_broker/issues/273#issuecomment-494184798
bethskurrie
2019-06-01 21:51
Hey broker users. I'm coming up with a design for webhook secrets that can be substituted into the webhooks at runtime (eg tokens, passwords, auth headers). Can anyone see a use for *non-secret* user defined parameters in webhooks?
bethskurrie
2019-06-01 23:57
You know how you can use predefined webhook template parameters? Eg ${pactbroker.consumerVersionNumber} ? I'm making user defined ones that will be encrypted and redacted from the logs for things like api tokens.
bethskurrie
2019-06-01 23:58
But that made me wonder if there was a use case for user defined template parameters that weren't secret. Like ${repositoryBaseUrl}
pact.io
2019-06-02 00:35
Well, that is a good question. Do I understand it right that the main point is: "should all user defined variables be encrypted in the logs?"
vitaliy.grigoruk
2019-06-03 11:59
The only case where I would use ?non-secret? user-defined params are ?githubOrgName?, ?ci base url?, ?bot usernames for CI / github?.
Are these user-defined params shared for all webhooks or maybe somehow scoped to consumer or provider?
bethskurrie
2019-06-03 12:07
Yes, those are the kinds of things I'd imagine using global parameters for. But does anyone ever actually use them? :-P
bethskurrie
2019-06-03 12:09
@detert anything user defined that isn't secret would not be redacted from the logs, the way thing like pacticipant names are not redacted from the logs.
bheemreddy181
2019-06-03 18:28
Can I consider can-i-deploy something like can-i-merge? i don't want to merge bad contract changes to master
bheemreddy181
2019-06-03 20:06
Cool - Can you do a write-up regards to the same or if you have a write up can you share it for the workflow ?
bheemreddy181
2019-06-03 20:35
@bethskurrie Can i pass a dynamic tag name in here for consumer on provider_verification ? https://github.com/pact-foundation/pact-ruby/wiki/Verifying-pacts#fetching-pacts-from-a-pact-broker
bethskurrie
2019-06-03 23:17
@bheemreddy181 yes, absolutely. Some people follow a branch based consumer/provider workflow where the consumer branches, creates a tag with the branch name, then the provider makes a branch with a matching name, and then pulls in the pact for that tag (as well as prod).
bethskurrie
2019-06-03 23:18
One of my workmates wrote up a blog about it https://dius.com.au/2018/05/04/pact-testing-git-workflow-and-continuous-integration/
bethskurrie
2019-06-03 23:21
If you follow a build pipeline like this https://github.com/pact-foundation/pact_broker/wiki/Webhooks#consumer-ci that calls "can-i-deploy" directly after all the isolated tests, then it will cause any branch builds with new expectations to fail because they're not yet verified.
kristofer.landgren
2019-06-04 11:23
I am getting the following error message when I try to run the dius/pact-broker container in AWS ECS (fargate). It has worked before but I haven't restarted the server for a few months. Now when I start my pactbroker logs says this:
```
2019-06-04 13:17:18*** Init system aborted.
*** Init system aborted.
2019-06-04 13:17:18*** Killing all processes...
*** Killing all processes...
2019-06-04 13:17:17Jun 4 11:17:17 ip-10-0-10-90 syslog-ng[14]: syslog-ng shutting down; version='3.13.2'
Jun 4 11:17:17 ip-10-0-10-90 syslog-ng[14]: syslog-ng shutting down; version='3.13.2'
2019-06-04 13:17:17*** Running /etc/my_init.post_shutdown.d/10_syslog-ng.shutdown...
*** Running /etc/my_init.post_shutdown.d/10_syslog-ng.shutdown...
2019-06-04 13:17:17*** Shutting down runit daemon (PID 23)...
*** Shutting down runit daemon (PID 23)...
2019-06-04 13:17:01Jun 4 11:17:01 ip-10-0-10-90 CRON[2438]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Jun 4 11:17:01 ip-10-0-10-90 CRON[2438]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
2019-06-04 13:14:44ok: run: /etc/service/nginx-log-forwarder: (pid 32) 1s
ok: run: /etc/service/nginx-log-forwarder: (pid 32) 1s
2019-06-04 13:14:42Jun 4 11:14:42 ip-10-0-10-90 cron[30]: (CRON) INFO (Running @reboot jobs)
2019-06-04 13:14:42Jun 4 11:14:42 ip-10-0-10-90 cron[30]: (CRON) INFO (pidfile fd = 3)
2019-06-04 13:14:42*** Runit started as PID 23
2019-06-04 13:14:42*** Booting runit daemon...
2019-06-04 13:14:42*** Running /etc/my_init.d/30_presetup_nginx.sh...
2019-06-04 13:14:41Jun 4 11:14:41 ip-10-0-10-90 syslog-ng[14]: syslog-ng starting up; version='3.13.2'
Jun 4 11:14:41 ip-10-0-10-90 syslog-ng[14]: syslog-ng starting up; version='3.13.2'
2019-06-04 13:14:41*** Running /etc/my_init.d/10_syslog-ng.init...
*** Running /etc/my_init.d/10_syslog-ng.init...
2019-06-04 13:14:41*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
```
The DB is up and running and the credentials are correct ( I get an error message in the DB logs when I try with invalid credentials). The web page says "We're sorry, but something went wrong.
The issue has been logged for investigation. Please try again later."
I'm pretty clueless what to do to be honest, any suggestions?
uglyog
2019-06-04 11:33
@kristofer.landgren try to work out what has changed since it was last running
yousafn
2019-06-04 13:34
Try running with log level of debug to give you a bit more info :) check the docs for how to set it
bheemreddy181
2019-06-04 14:03
Why does provider needs to make a matching branch name when consumer creates a pull request then provider master build is invoken where I pass consumer tag name which should be verified as path parameter
kristofer.landgren
2019-06-05 05:25
I believe it was a problem when i changed my container image from dius/pact-broker to pactfoundation/pact-broker . I have reverted to an old DB snapshot and dius/pact-broker image and it is working now.
bethskurrie
2019-06-05 05:26
@kristofer.landgren the default port has changed from 80 to 9292 - this might have meant that your health check and routing were looking at the wrong port
kristofer.landgren
2019-06-05 05:36
@bethskurrie Sounds likely. I'll have to give it a go later on. Thanks
kristofer.landgren
2019-06-05 06:45
@bethskurrie You were right. I'll probably have to read instructions more carefully next time. I just read "so you should just be able to switch from dius/pact-broker to pactfoundation/pact-broker" and ran with it :slightly_smiling_face:
borsuk.artem034
2019-06-05 07:49
Hi, as I understand dius/pact-broker will not be supported? And should move to pactfoundation/pact-broker?
uglyog
2019-06-05 07:54
dius/pact-broker is the old image based on Fusion Passenger. pactfoundation/pact-broker is the newer image based on Puma. We think the Puma one is better, but will still have the old one around in case someone needs a Fusion Passenger based image.
uglyog
2019-06-05 07:54
But hopefully the Puma one works for everyone and we can deprecate the other one
bethskurrie
2019-06-05 07:57
@borsuk.artem034 I'm planning on keeping the Dius one up to date for a while.
bethskurrie
2019-06-05 11:17
We are now offering paid plans, with extra features on top of the OSS codebase, like social login, better UI, auth tokens etc.
richard.jones
2019-06-06 23:54
I?m trying to use the HAL interface to submit tags to our broker, but the `pb:tag-version` link is not marked `templated` so the hal navigator doesn?t let me template in the tag. Is this a bug that?s been fixed, or should I file a new bug?
richard.jones
2019-06-07 00:51
Also, I?m trying to figure out how the Ruby cli?s `--consumer-version-tag` ability to be specified multiple times works. I can see the broker has a `latest-provider-pacts-with-tag` endpoint which I was intending to use until I noticed the multiple times caveat. AFAICT that endpoint does not accept multiple tags.
bethskurrie
2019-06-07 00:54
What you need to do is get the pacticipant, and then call the `pb:version-tag` relation.
bethskurrie
2019-06-07 00:56
though having said that, there is no relation in the index to get the pacticipant :stuck_out_tongue:
bethskurrie
2019-06-07 00:57
the tag needs to be there beofre you publish, so that when the webhook fires, the right tags are in place.
richard.jones
2019-06-07 00:57
I?ll try to see where I might?ve seen that. But yeah, for a new pacticipant, that tag operation is going to break, yes?
richard.jones
2019-06-07 01:02
quick question while I?ve got you - what?s the set operation (union or intersection) for multiple `-consumer-version-tag` - I couldn?t find it in the docs
bethskurrie
2019-06-07 01:02
but that logic will be all done for you by the new "pacts for verification" endpoint that is coming soon
bethskurrie
2019-06-07 01:04
Have a think about how you might run a pact verification test that does not actually fail the build if it fails execution.
bethskurrie
2019-06-07 01:06
Here's an example of the workflow for a pact with the new "pending" feature https://github.com/pact-foundation/pact_broker/blob/feat/verifiable-pacts/spec/features/pending_pacts_spec.rb
bethskurrie
2019-06-07 01:08
The URL to fetch the list of pacts for verification will be "/pacts/provider/Bar/for-verification" and you'll provide a list of consumer version selectors and a list of provider version tags, and the broker will work out which pacts are "pending" for the given provider tags.
bethskurrie
2019-06-07 01:10
I'll do some better implementation notes once I've validated the design with Ron and pact jvm
richard.jones
2019-06-07 01:14
I?m just re-reading the ?pending? blog post in light of what I?ve learned about tagging in the last few days and I?m now a little confused. There seems to be some fuzziness around pending being a tag, and there?s a `verificationProperties` in the code you posted above, and provider version tags are new to me, I thought tags were only on consumer pact versions.
richard.jones
2019-06-07 01:14
I think I need to do a bunch more reading about tagging, I?m clearly not getting something.
richard.jones
2019-06-07 04:50
@bethskurrie I?ve been poking around the API some more, and I?m just limiting myself to getting the tagging correct for now, and cleaning up some other things where we?ve got hard-coded URLs. I?m trying to discover the HAL path to get to a pacticipant. I know ?pb:pacticipants? at the root will give me a list of them all, which I can navigate to get a single one, but it?s very slow :slightly_smiling_face: I can also use ?pb:latest-version? and then follow its ?pb:pacticipant? link to get there. I can?t see a more direct link though, am I just missing it? :slightly_smiling_face:
bethskurrie
2019-06-07 07:15
What I've done when I have existing client code, and a relation that I've only just added is that I use the relation if it exists (which allows the API to evolved without breaking the client) but then provide a handcoded backup url if the relation does not exist. This should be safe, as you know that if the relation doesn't exist, it's a version of the broker that uses the URL that you handcoded.
bethskurrie
2019-06-07 07:16
I've just added
```
"pb:pacticipant-version-tag" :
{
"href": "https://broker/pacticipants/{pacticipant}/versions/{version}/tags/{tag}",
"title": "Get, create or delete a tag for a pacticipant version",
"templated" : true
}
```
so you can go straight form the index to tagging a pacticipant version without having to go via the pacticipant.
davidmolinero.com
2019-06-08 08:00
Is anyone using the pact-broker on http://pactflow.io experiencing issues with the hooks?
davidmolinero.com
2019-06-08 08:26
It seems that are not been triggered, and I can?t see anything in the logs
davidmolinero.com
2019-06-08 08:26
I?ve just done a test in a local broker and I am not experiencing the same issues
matt.fellows
2019-06-08 11:31
We?re not aware of issues on the platform, but we?d be happy to investigate:
thomas.heilbronner
2019-06-09 16:28
Exactly the feature I?m looking for.
We use the same user/token across projects for calls to jenkins.
I want to use it for
- *jenkins_base_url* (public)
- *jenkins_user* (public/secret)
- *jenkins_token* (secret)
thomas.heilbronner
2019-06-09 16:29
having this in a single place would really help in case we have to switch the token or user
s1apped
2019-06-11 10:46
Hi. Does anyone have issue with contract_content_changed webhook event? :disappointed:
bethskurrie
2019-06-11 10:52
Yes @s1apped we discovered an issue over the weekend with webhooks not firing. They're fixed now though.
bethskurrie
2019-06-11 10:54
If you're running your own instance, then there are no issues that I'm aware of in the docker image.
s1apped
2019-06-11 10:56
Well I have problem that it's firing without contract change. What should trigger this event? Difference in contract (published json) or commit?
bethskurrie
2019-06-11 10:57
The things that trigger it are content changing compared to any of the previous pact versions with the same tag.
bethskurrie
2019-06-11 10:59
There's logging that will tell you why it's triggered, but I need to know where you're running your broker before I can tell you how to access it
bethskurrie
2019-06-11 11:01
If you're reasonably up to date, and you turn the log level up to debug, you'll see some logs that tell you why the webhook got triggered.
s1apped
2019-06-11 11:03
So if content didn't change but every published pact is tagged with new commit hash it will
bethskurrie
2019-06-11 11:05
It goes through all the tags that have been applied to the consumer version, and it checks if the content has changed since the previous latest pact for that tag.
s1apped
2019-06-11 11:11
Webhook triggered for the following reasons: first time untagged pact published
antonello
2019-06-11 11:24
@bethskurrie What they will probably end up doing is to keep the idempotence of their flip script is to always delete the tag from the version they are flipping from and add it to the version they?re flipping to.
antonello
2019-06-11 11:24
Also, they?re writing a lightweight client for the pact broker in python. I?m encouraging them to open source it.
bethskurrie
2019-06-11 11:25
I don't guarantee the urls won't change. But the hal relations are fixed.
bethskurrie
2019-06-11 11:26
I generally prefer people to use the existing clients where possible, because keeping everything up to date is much easier when there are fewer clients.
bethskurrie
2019-06-11 11:27
Keeping all the libraries up to date with maintainers scattered around the world is like herding cats :joy:
antonello
2019-06-11 11:27
The main reason is that they would like to avoid having a dependence on ruby on their build servers.
bethskurrie
2019-06-11 11:29
Also, the pact ruby standalone has ruby bundled with it - also no ruby required on the client machine.
bethskurrie
2019-06-11 11:33
this is a pact publication line
`127.0.0.1 - - [11/Jun/2019:20:40:41 +1000] "PUT /pacts/provider/Bar/consumer/Foo/version/1 HTTP/1.1" 201 2926 0.0285`
bethskurrie
2019-06-11 11:34
Here's the docker version https://cloud.docker.com/u/pactfoundation/repository/docker/pactfoundation/pact-cli
bethskurrie
2019-06-11 11:34
I love people to contribute, but new implementations end up making more work for me. People who contribute to existing implementations make less work for me!
bethskurrie
2019-06-11 11:38
Let me know if you can work out which order the tag and pact calls are made in.
s1apped
2019-06-11 12:14
Upserting version 828c719d13691b2259ec28pgc4ccff2dd02daaf7 for pacticipant_id=4
Creating new pact publication with params {:consumer_name=>"test1", :provider_name=>"test2", :revision_number=>nil, :consumer_version_number=>"828c719d13691b2259ec28pgc4ccff2dd02daaf7", :pact_version_sha=>nil, :consumer_name_in_pact=>"test1", :provider_name_in_pact=>"test2"}
No webhook found for consumer "test1" and provider "test2"
Webhook triggered for the following reasons: first time untagged pact published
aniela.cole
2019-06-11 23:30
Hi. Does anyone have issue publishing pacts to pactflow? :disappointed:
My code:
```
const pact = require('@pact-foundation/pact-node');
const path = require('path');
const opts = {
pactFilesOrDirs: [path.resolve(__dirname, '../tests/pact/pacts/')],
pactBroker: 'https://moveteam1pactbroker.pact.dius.com.au/',
pactBrokerToken: 'Bearer READ WRITE TOKEN',
tags: ['test'],
consumerVersion: require('../package').version,
};
pact.publishPacts(opts).then(() => {
console.log('Pact contract publishing complete!');
})
.catch((e) => {
console.log('Pact contract publishing failed: ', e);
});```
Error:
`Could not publish pact:
Failed to tag version 1.0.0 of Magneto due to error: PactBroker::Client::Error - Authentication failed}`
richard.jones
2019-06-12 01:05
Would it be possible to have the broker remember a user?s preference in the Matrix for ?Show latest result for each consumer version/provider?? We find that view to be a less confusing default view than the ?Show all results? view.
richard.jones
2019-06-12 01:06
yes please :slightly_smiling_face: [I just had a half hour conversation with some folks explaining why the default Matrix was displaying ?all these confusing results?]
richard.jones
2019-06-12 01:08
(I only just discovered while explaining that to them that there?s a tooltip over ?older? Pact Published values)
richard.jones
2019-06-12 01:09
We often end up there trying to figure out a failure of a feature branch, and the Matrix is the only way to see all ?active? consumer versions easily
bethskurrie
2019-06-12 01:12
so, if the default view was to show the latest versions for all of the tags, would that be more useful?
richard.jones
2019-06-12 01:18
They?re *cough* all branch builds in *this* broker (as opposed to the other broker, which just has master branch). They *do* currently cause provider builds to fail (much to the ire of the ?no failing builds? brigade). And yeah, we?re pulling in ?latest? each time (another thing I need to address in our webhook usage). I?m currently writing up a plan to address our current pact workflow problems, which starts with ?implement tagging?, has several interim steps, and ends with ?shut down the unnecessary second broker?. Once I have written the plan, then I need to get actual buy-in from all the people, which is going to be the hard part :sweat_smile:
bethskurrie
2019-06-12 01:23
You're feeling all the pain of using contracts, and not using the features that alleviate it!
richard.jones
2019-06-12 01:23
just so many things not understood correctly right at the start resulting in a bad implementation that?s really hard to fix now
bethskurrie
2019-06-12 01:23
Your team will love the new pending pacts feature. No more consumers breaking provider builds.
bethskurrie
2019-06-12 01:24
Could you just gorilla hack in the tags in a couple of codebases... don't use them, just add them.
bethskurrie
2019-06-12 01:26
Have you guys read this recently? https://docs.pact.io/best_practices/pact_nirvana
matt.fellows
2019-06-12 01:34
Sorry I was at a meetup this morning @aniela.cole. I hear your problem is sorted, thanks Beth!
s1apped
2019-06-12 07:00
Hi @bethskurrie don't know if you have seen this but I wasn't able to find pact calls in logs.. wondering if I'm missing something?
s1apped
2019-06-12 07:31
I thought thye might be in some other place but didn't have luck finding them :confused:
bheemreddy181
2019-06-12 23:36
I created a webhook on dius hosted pact broker using pb:create but the webhook didn?t get saved automatically is there something I am missing while creating a webhook ? @bethskurrie @matt.fellows
bethskurrie
2019-06-12 23:38
personally, I find it easier to use https://github.com/pact-foundation/pact_broker-client#create-webhook
bethskurrie
2019-06-12 23:49
Unless I can see your screen, I'm not sure how to help you. You could take screenshots and PM them to me?
s1apped
2019-06-13 06:39
@bethskurrie thank you for investigating. Is there a change it will be fixed in near future?
bethskurrie
2019-06-13 06:42
Hopefully Ron can get the fix out soon. Watch that issue so you get notified when it's closed.
thirumal.net
2019-06-13 18:27
Hi @beth @matt.fellows @yousafn
i am looking for consumer and provider naming convention guidelines for pact broker. i would like to publish naming comvention guidelines to the internal teams since every team is following their own way( different teams are using different names like consumer_projectname_Client , service-name , servicename_provider ..etc. )
could you please help me where can i find out more details about Pact broker Guidelines on naming conventions for consumer and provider names ?
richard.jones
2019-06-14 01:20
Would it be possible to include a mapping of verification status to bitbucket status names (like the github names) in the broker?s `provider_verification_published` webhook? (edit) Would a PR be accepted? (edit) I?ve written one, just need to install all the tooling to test it :sweat_smile:
richard.jones
2019-06-14 02:38
`chruby` complains `chruby: unknown Ruby: 2.4.0` when I cd into the pact-broker dir now. Any objections to me changing the `.ruby-version` to just `2.4`? I don?t really know what the ramifications of that might be though.
richard.jones
2019-06-14 02:49
I?m trying to figure out how to run the test suite, but I can?t see the test command in either DEVELOPER_* doc. Any hints?
richard.jones
2019-06-14 02:54
I got a couple of failures, related to database connection and tables missing, so I?m going to ignore those and submit the PR
oswald.quek
2019-06-14 10:00
for some reason the pact broker has just stopped tagging pacts when my CI performs `curl -H 'Content-Type: application/json' -X PUT -k --user ${PACT_BROKER_USERNAME}:${PACT_BROKER_PASSWORD} https://<url>/pacticipants/${serviceName}/versions/${version}/tags/${tag}`
taranovskyi.anton
2019-06-14 14:49
hi guys. I am facing issue while updating pact file for message verification - I am publishing new version of pact file with new consumer version and new tag, but pact-broker just add new version of message to previous pact file
matt.fellows
2019-06-14 23:47
Which language are you using @taranovskyi.anton? The issue would be unrelated to the broker, it would be merged into the existing pact file prior to publishing
bheemreddy181
2019-06-16 04:21
```pact_broker_base_url 'https://bheemreddy.pact.dius.com.au/pacts/provider/PGS/consumer/Portfolio/', {username: '----', password: '-----'}
consumer_version_tags [{name: ENV['TRAVIS_BRANCH'], all: false, fallback: 'master'}]
```
bheemreddy181
2019-06-16 13:30
Any idea how can I pass query params for travis API for triggerring a build , i get the below response
bheemreddy181
2019-06-16 13:30
```"@warnings": [
{
"@type": "warning",
"message": "query parameter pactConsumerTags not safelisted, ignored",
"warning_type": "ignored_parameter",
"parameter": "pactConsumerTags"
}
]```
bheemreddy181
2019-06-16 13:34
And when i trigger the the webhook from the broker browser , i get the below error , is this because the endpoint shoould be whitelisted to trigger the builid ?
bheemreddy181
2019-06-16 13:34
```SSL_connect returned=1 errno=0 state=error: certificate verify failed```
bethskurrie
2019-06-16 21:41
@bheemreddy181 no it's because you have a self signed certificate for your CI
bethskurrie
2019-06-16 21:41
You'll need to load the certificate into the broker. Have a look at the webhook or configuration docs for how to do this.
bethskurrie
2019-06-16 21:42
The first error is coming from your own CI instance. It looks like you need to whitelist the incoming parameters.
bethskurrie
2019-06-16 21:42
You'll need to read the Travis documentation for working out how to whitelist a parameter.
bethskurrie
2019-06-16 21:44
@taranovskyi.anton can you please provide an executable example to demonstrate your issue please?
bethskurrie
2019-06-16 21:44
Also, read this: https://docs.pact.io/getting_started/versioning_in_the_pact_broker
bethskurrie
2019-06-16 21:45
You can call it whatever you like @thirumal.net. I'd recommend using whatever your repository name is, however.
bethskurrie
2019-06-16 21:46
It means you can create global webhooks where ${consumerName} or ${providerName} can be substituted in to the webhook body.
bheemreddy181
2019-06-16 21:51
The broker is hosted by DIUS ( by you people ) can you load the certificate for me
bethskurrie
2019-06-16 21:51
@s1apped Please upgrade to the latest pact-jvm version https://github.com/DiUS/pact-jvm/issues/892#issuecomment-502343767
james.hattersley-dyke
2019-06-17 09:03
Hi, does anyone know of any guides to set up the broker on ECS?
yousafn
2019-06-17 10:10
I run it on ecs at work, we use cloud formation templates to create our rds database, a cluster and a service. In the service we add in env vars for our database/login credentials and health check. We also use an application load balancer. I would really use someone who familiar with AWS to set it up. I looked at open sourcing cloud formation templates but as each workplace has different security profiles, there is no universal solution.
I did post up some info before - here is a cut and paste
Regarding running on an ELB, ideally use cloud formation templates. You want to clear a cluster with a network stack including vpcs, route 53 for dns and roles with ecs access to execute the containers, then service template?s to run fargate ecs and rds tasks. Deploy via AWS-cli to allow you to pass in environment variables at runtime into the docker container for the pact broker to pick up. Additionally you can store your env vars in amazons parameter store
This is a good place to start for the CF templates. You can deploy your db with CF templates too
https://github.com/nathanpeck/aws-cloudformation-fargate#private-subnet-public-load-balancer
Unfortunately I can?t share my work CF templates. Best of luck with playing with AWS but please do be mindful that you don?t want to leave your resources insecure for too long.
Feel free to drop me a pm if you want help with any specifics.
james.hattersley-dyke
2019-06-17 10:53
cheers! I eventually sorted it. I'm running the tasks on Fargate with a small RDS instance - will ultimately create CF templates as that's the way we want to do things. Secrets are all stored in secrets manager too.
james.hattersley-dyke
2019-06-17 10:54
It was my security groups which were the problem. I was using IP addresses for each one when I should (as a colleague pointed out) be referencing other SGs
yousafn
2019-06-17 11:03
Spot on fella! We just recently switched to the new puma based image too which is running really well!
matt.fellows
2019-06-18 07:45
I read his problem that it?s appending the content to the same pact file locally (i.e. the `merge` mode, instead of `overwrite`)
taranovskyi.anton
2019-06-18 09:15
@bethskurrie agree to @matt.fellows message, it is reproducible for local pact json file
looks like issue on Pact .Net library side
bethskurrie
2019-06-18 09:17
So, the CLI does not know if the pact file is there because it's mid way though a test run or if it's left over from the previous test
bethskurrie
2019-06-18 09:18
As the author of the native code, you'll have to find the right point before the test to delete any existing file
taranovskyi.anton
2019-06-18 09:22
sure, will take a look
however, there is some existing verification for file existing https://github.com/pact-foundation/pact-net/blob/message-pact/PactNet/Builders/MessagePactBuilder.cs#L86
will double check
thanks for a help
james.hattersley-dyke
2019-06-19 09:32
Hi, just wanted to ask if this is a viable solution to running provider verification or if I've gone totally left field with this one... So, our jenkins instances aren't publicly accessible, so webhooks aren't an option without some fancy aws network foo (which I don't posses) - What I did do though instead of a webhook, is have the consumer build kick off another generic build job which takes the repo and branch of the provider you want to run... it has the added benefit that the consumer build will pass / fail based on the provider verification.
Is this good / bad? It's the only way I could think of to automatically kick off provider verification job:
```
build job: 'pact-verify-provider-gradle', parameters: [
string(name: 'GIT_REPO', value: 'git@bitbucket.AcmeCorp/product-command.git'),
string(name: 'GIT_BRANCH', value: 'pact-sqs')
]
```
iruben91
2019-06-19 14:58
In terms of Pact Broker setup, how critical is the database resilience? Meaning, if by accident a data loss was to happen, how important would having a form of backup be?
james.hattersley-dyke
2019-06-20 07:16
does anyone have any feedback on this approach to provider verification please?
abubics
2019-06-20 07:22
I think we've set it up kinda like that when our broker/CI couldn't both see each other
james.hattersley-dyke
2019-06-20 07:51
cool, yeah - I couldn't think of a way around the whole not being able to see each other. I thought it was quite inventive - just wasn't 100% sure it was valid :slightly_smiling_face:
mui_ume
2019-06-24 11:56
when I run npm run publish:pact
> tlstellaclientapp@0.0.1 publish:pact /Users/tohlaymui/Desktop/tl_stella-client_app
> node ./pact/publish.js
/Users/tohlaymui/Desktop/tl_stella-client_app/pact/publish.js:6
pactFilesOrDirs: [path.resolve(process.cwd(), 'pacts')],
^
mui_ume
2019-06-24 11:56
my pact/publish.js content: ```const { publisher } = require('@pact-foundation/pact-node');
const { path } = require('path');
const opts = {
providerBaseUrl: 'http://localhost:8080',
pactFilesOrDirs: [path.resolve(process.cwd(), 'pacts')],
pactBroker: 'https://localhost:3000',
consumerVersion: '2.0.0',
};
publisher.publishPacts(opts).then(() => console.log('Pacts successfully published'));
```
mui_ume
2019-06-24 12:30
can someone explain this step here at https://github.com/pact-foundation/pact_broker The generated pact is then published to the Pact Broker. Most Pact libraries will make a task available for you to do this easily, however, at its simplest, it is a PUT to a resource that specifies the consumer name and application version, and the provider name. eg http://my-pact-broker/pacts/provider/Animal%20Service/consumer/Zoo%20App/version/1.0.0 (Note that you are specifying the consumer application version in the URL, not the pact version. The broker will take care of versioning the pact behind the scenes when its content changes. It is expected that the consumer application version will increment with every CI build.)
matt.fellows
2019-06-24 22:43
(you need to be able to show the errors to others for help).
in any case, I?m pretty sure it?s because it should be `pactUrls`
antonello
2019-06-26 06:29
Morning! Any reason why the latest image is only tagged as `edge`, without any semantic version?
https://hub.docker.com/r/pactfoundation/pact-broker/tags
antonello
2019-06-26 06:35
Or to rephrase my question in a different way, I?m assuming it?s recommended that we use the ?new? docker image (`pactfoundation`), but the latest semantic version that is published is `2.32.0-2 `, however, the lastest pact broker release is `2.34.0 `
antonello
2019-06-26 09:46
@bethskurrie perhaps you could shed some light before it?s night time in Australia? :blush:
bethskurrie
2019-06-27 02:18
there's nothing major in the releases. just little race condition fixes and some new relations in the hal resources.
antonello
2019-06-27 05:42
out of curiosity, is there any way to see which version of the broker you?re running besides checking which image you?re running? something like a version endpoint?
detert
2019-06-27 14:21
I have a question regarding webhooks.
We use feature-branches and I implemented the webhook so that a pact change in a feature-branch of service A triggers the pipeline of the according feature-branch of service B
I see several retry for the webhook, if service B does not have that feature-branch. How do you handle that situation? Can I avoid to trigger the webhook, if no feature branch exists?
franklin.huynh
2019-06-27 23:36
Hi @bethskurrie and @matt.fellows could I have a question? do you have any idea of getting the list of services communicating with each other? I want to know how many service integrations haven't covered by contract tests.
bethskurrie
2019-06-27 23:37
Hi @franklin.huynh. You can use the `/integrations` endpoint to get this info.
matt.fellows
2019-06-28 00:05
FYI I spoke to Beth yesterday when we had this conversation Franklin. Were you looking for something more?
bethskurrie
2019-06-28 00:06
I'd just suggested to ask in the public channels so other people could learn.
phall
2019-06-28 19:53
I?m setting up and testing webhooks with the broker. I?ve created a webhook with `"method": "POST"` - and the same is present when I GET the webhook UUID - but when I test this call (by POSTing to the `/webhooks/?/execute` URL, it seems to attempting a GET. I see a 415 response, and no mention of method. Has anyone seen this behaviour?
phall
2019-06-28 20:00
To answer my own question. I had omitted the `application/json` header. I added this, and everything started to work. :confused:
matt.fellows
2019-06-29 04:47
:point_up: any takers? We would _love_ to get more contributors, and this is an easy win! :smile:
bethskurrie
2019-07-01 08:38
It probably should only need the Accept header. I'll have a look at that.
pact.io
2019-07-01 19:04
I currently try to understand how `pact-provider-verifier --publish-verification-results` works with tags. I currently publish the tag according to my feature branch after I published the provider results. Is that correct? Do I need to publish a tag here at all?
detert
2019-07-02 14:29
Alright. I just see at `contract content changed` explains that "One side effect of this is that brand new tags will trigger a pact changed event". Is there any option to avoid that? We work with feature branches and I trigger a master build if a pact changed to ensure compatibility. Every feature branch triggers a master pipeline now. Is that necessary?
antonello
2019-07-02 14:49
@detert I think you may want this?
https://github.com/pact-foundation/pact_broker/issues/224
detert
2019-07-02 14:51
@antonello Thank you. I don't think so. I want the other pacticipant's master and feature branch pipelines to run. But only if the pact contents really changed
detert
2019-07-02 14:52
As far as I understand: That issue does something else. It restricts a webhook to certain tags
detert
2019-07-02 14:54
My configuration is that every build triggers the master build of the other pacticipant. And every feature branch triggers the feature branch of the other pacticipant. However that is not needed, if nothing changed. Maybe that does not make sence, I just found no better way to revalidate all pact changes
antonello
2019-07-02 15:00
it does make sense, but if the web hooks were restricted to specific tags, you could have (for example) a webhook that always triggers for pact changes with only a master tag (and/or other known tags), but then create a webhook for each feature branch.
detert
2019-07-02 15:02
Well, I added a webhook that always triggers master. And I have a webhook that always triggers a feature-branch. If that feature branch does not exists, that webhook fails or is kind of ignored. That is fine. However I do not understand why the issue should help to avoid triggering a build if in fact nothing changed (only a new tag was added to an existing pact). Maybe I miss something
phall
2019-07-02 15:06
If you are triggering on the `contract_content_changed` event, the docs state ?contract_content_changed: triggered when the content of the contract, or tags applied to the contract have changed since the previous publication? - which is the same behaviour as you?re seeing.
detert
2019-07-02 15:22
Exactly. And I search a possibility that the build is not triggered, if a new tag was applied. Only if the pact content changed
franklin.huynh
2019-07-03 01:58
hi @matt.fellows and @bethskurrie
I have a pact between pacticipants and provider verification result has been published. Could you suggest me which API to check if the pact (latest) has been verified?
bethskurrie
2019-07-03 02:01
You'll find some docs for it under the pact broker section of http://docs.pact.io
bethskurrie
2019-07-03 02:05
bethskurrie
2019-07-03 02:06
It triggered because the content for the previous version of the tag did not exist.
bethskurrie
2019-07-03 02:08
If you want to get smart about it, have the webhook trigger an intermediate build that works out if the matching provider branch exists or not.
franklin.huynh
2019-07-03 03:33
Do you have more basic API. I just want to know if that pact has the verified result or not. Like
**/pact/version/{version}
And I can get the result from that.
For example, I want to get these information via API
Consumer - Provider - Latest pact verified (Failed/Passed) / Or Null
bethskurrie
2019-07-03 03:42
docker run --rm \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_USERNAME \
-e PACT_BROKER_PASSWORD \
pactfoundation/pact-cli:latest \
broker can-i-deploy \
--pacticipant Foo \
--latest
bethskurrie
2019-07-03 03:44
If you're not using docker, then you can install the pact ruby standalone (no ruby required)
franklin.huynh
2019-07-03 03:47
Let's say I have services (this is outside of pactflow because we haven't written contract test for these services)
for example
(1) Service A ==> Service B (have contract test)
Service C ==> Service B (have contract test)
Service A ==> Service C (not have yet)
What I want is to get below information from PactFlow
(2) Service A ==> Service B (Provider verified passed/failed)
Service C ==> Service B (Provider verified passed/failed)
Then I will compare (1) and (2), I will know the gap that I should write contract tests
bethskurrie
2019-07-03 03:48
Try the command that I said, it will give you what you want. You can give it multiple names.
bethskurrie
2019-07-03 03:50
It will tell you whether each pair's verification is success, failure or missing.
bethskurrie
2019-07-03 03:55
If you just pass one, it calculates the integrations for you. If you pass more than one, it just gives you the results that you asked for.
franklin.huynh
2019-07-03 04:15
I have a question
I passed 2 pacticipant
When run can-i-deploy alone, pacticipant 1 is "Computer says yes \o/ "
pacticipant 2 is "Computer says no ¯\_(?)_/¯ ....There is no verified pact..."
But when I put these pactcicpants together, it says
```
Computer says yes \o/
There are no missing dependencies
```
franklin.huynh
2019-07-03 04:43
@bethskurrie I suspect it's a bug. Could you take a look or you want me to raise a ticket?
bethskurrie
2019-07-03 05:26
You can deploy the provider without the consumer, but not that other way around.
detert
2019-07-03 06:06
Is there anything against adding a new event type, which does not trigger with new tags, but only when the content of the pact changes?
bethskurrie
2019-07-03 06:10
If you just compare to the previous version according to time, ignoring tags, then if you have different branches pushing different content all mixed up, you'll get unpredictable results.
bethskurrie
2019-07-03 06:11
If you say, only trigger when there was already an existing version, and it has changed, then you won't end up triggering a webhook for the very first version.
detert
2019-07-03 06:11
Well. Maybe I misunderstand something fundamentally. I would assume that an event is triggered if the request or the expected response changes. If request and expected response remain the same, nothing should break. Thus I do not understand why a new tag should trigger a webhook. According to https://docs.pact.io/getting_started/versioning_in_the_pact_broker
bethskurrie
2019-07-03 06:12
People rely on the trigger for the first tag, because that's likely the first time a consumer branch has been pushed.
detert
2019-07-03 06:13
But a new branch, in my case, does not mean that I want to change the contract
detert
2019-07-03 06:15
The issue is, that our build pipelines are triggered a lot now. That causes a lot of unnecessary builds. Unfortunatley some of our build pipelines are very slow. That's why I wanna try to avoid it.
bethskurrie
2019-07-03 06:17
it shouldn't trigger an entire pipeline. it should just do the verification step.
detert
2019-07-03 06:17
I did run only the verification at first. However I changed that and run unit tests as well currently, to avoid problems that could occur if several branches were merged. Maybe I need to think about that
bethskurrie
2019-07-03 06:19
what you can do is put a can-i-deploy check at the start of the build to see if you've already verified that particular content with the sha you've got.
detert
2019-07-03 06:23
That sounds interesting. I guess that I have to include ${pactbroker.providerVersionNumber} in the webhook and use can-i-deploy with --version then?
bethskurrie
2019-07-03 06:23
you know the provider number - it's whatever you're currently running the build for.
bethskurrie
2019-07-03 06:25
I'm trying to think of a way to support your usecase by adding a different event type, but there's no real way to make a new event type that makes sense without changing the existing one, and that would affect all the existing builds that depend on it.
detert
2019-07-03 06:28
Would something like this make sense?
```
"events": [{
"name": "contract_content_changed",
"options": "ignore_additional_tags"
}]
```
antonello
2019-07-03 08:21
Hi @bethskurrie. We?ve running into performance issues with the broker. Basically we have some participants with so many versions that loading some of the matrixes takes a very long time, but even worse, some queries end up making the whole host machine unusable.
I know any resources can be deleted, but do you have any tips on how to reasonably approach a clean-up? I imagine we?re not the first to come across this.
bethskurrie
2019-07-03 08:41
I have written some clean up scripts in the past, but it's hard to generalise because people use their brokers differently.
antonello
2019-07-03 08:42
yes, we use tags - each pipeline (master and feature branches) publishes and/or verifies
bethskurrie
2019-07-03 08:44
ok, so you can delete anything that isn't the latest for any tag, except for the ones that are on master that might be promoted to prod
bethskurrie
2019-07-03 08:47
also, side note, is it rendering the matrix page in the browser that takes ages, or is it the can-i-deploy?
antonello
2019-07-03 08:55
rendering the matrix - we have just started using can-i-deploy but not for the problematic pacticipants
antonello
2019-07-03 08:56
but also getting the list of all versions, which actually brings the host ?down?
bethskurrie
2019-07-03 08:56
what it really needs is paging, but I don't think I have the time for that right now
bethskurrie
2019-07-03 09:00
if you hop into your docker container and go to `/home/app/pact_broker/` and execute `bundle exec rake pact_broker:db:clean` it will delete stuff.
bethskurrie
2019-07-03 09:01
I'm not 100% sure it will delete the right stuff. I have unit tested it, but when I pulled down a live database, extracted the data that's on the index page, ran the script, and then looked at the index page again, there were some diffs, and there shouldn't have been.
bethskurrie
2019-07-03 09:01
Nobody was jumping up and down about needing the clean, so at the time, I didn't go any further with it.
bethskurrie
2019-07-03 09:02
what it was supposed to do was get rid of every pact publication that was not the latest for it's tag.
bethskurrie
2019-07-03 09:02
I think it did that ok, but from memory, some of the verifications were different.
antonello
2019-07-03 09:06
So that would be your recommended approach, aside from it potentially not deleting exactly the right stuff.
antonello
2019-07-03 09:08
we have backups for the dockerised postgres instances we?re running as a sidecar.
bethskurrie
2019-07-03 09:58
alessandrobuggin
2019-07-03 10:53
Hello, is there a way to test a new pact ?on a branch? without ?making it official?/publishing it?
I do think the answer is no, because the provider approves a pact asynchronously.
james.hattersley-dyke
2019-07-03 15:29
Hi I'm having a weird issue between my CI and my local environment... I've attached a pic as it'll explain it far better. Basically, different results between CI and the CLI locally.
sandhyarani.gabbi
2019-07-03 16:18
Hi, PACT Broker is returning a 500 when trying to Publish(Works after several retries though). This is happening only on one of three services. Is there any reason why this could happen?
pact.io
2019-07-03 20:27
@bethskurrie I take a look at the implementation for some time now. I understand that the contract_content_changed event is triggered at PactBroker:Webhooks:TriggerService if the pact_version_sha changes. I understand as well that this method is called by PactBroker:Pacts:Service:update_pact. But I have no idea how or why the tag affects the pact_version_sha. As far as I see only params[:json_content] is used. Could you help me to understand what's going on?
pact.io
2019-07-03 21:02
As I think about this, I think that consumer_version.id changes every time as I use the last git hash as recommended in the docs. Thus PactBroker:Pacts:Service:create_pact might be called every time instead of update_pact. And then pact_repository.find_previous_pacts does not find a previous_pact if a new tag is provided which triggers the event. Does that make sense?
matt.fellows
2019-07-03 21:32
What do your logs say? Or are you using our hosted broker at http://pactflow.io?
james.hattersley-dyke
2019-07-03 21:42
I did run it with the verbose flag, I'll upload the output tomorrow morning...
bethskurrie
2019-07-03 21:56
Also @sandhyarani.gabbi which library are you using to publish? The latest versions of pact-jvm and go/js/.net have retires built in.
bethskurrie
2019-07-03 22:27
I'm very confused @james.hattersley-dyke. Check the X-Request-Id header and make sure that it's changing each time - that will rule out caching issues.
james.hattersley-dyke
2019-07-04 10:57
https://gist.github.com/jameshd/8ded31e46940740cb0bafa352754335d
Does that help? I'm clueless
james.hattersley-dyke
2019-07-04 11:02
i noticed the CI was running before the local call . I updated the gist to show it's not an ci running after.
bethskurrie
2019-07-04 11:16
Are you publishing multiple times with the same consumer version, or are you incrementing the version each time?
bethskurrie
2019-07-04 11:18
Are you sure the verification result is not coming in after the ci ran, and before you checked from local.
bethskurrie
2019-07-04 11:19
It looks like you're publishing the pact then waiting a while for the verification to come back, but not long enough.
bethskurrie
2019-07-04 11:20
I meant to ask, and it's probably too late now, but do you have any idea how many pact publications you had?
antonello
2019-07-04 11:21
We might even run it regularly as a cron job.
The only issue I can foresee (which doesn?t affect us yet) is for any participants that we may have not built or released in the last n (e.g 60) days.
bethskurrie
2019-07-04 11:23
The script just needs to be a bit smarter to avoid deleting pacts that are the latest for their tag, even if they're over 60 dayan
bethskurrie
2019-07-04 11:24
Your latest prod pact might easily be over 60 days with a stable integration.
antonello
2019-07-04 11:32
absolutely - once the script is smarter, you can also be more aggressive in terms of retention window
bethskurrie
2019-07-04 11:39
Then you publish a new version of the pact and the content has changed, so it goes back to being unverified.
bethskurrie
2019-07-04 11:55
If you add the git sha into the version number, you may get more predictable results. Eg 1.2.3±fjjdisjebfhfu
matt.fellows
2019-07-05 06:55
Last day to cast your votes: https://pact-foundation.slack.com/archives/C5F4KFKR8/p1561782293368400
fun_rajesh
2019-07-05 12:29
Hi, I received a mail from with a temporoary password. However, when i signed in https://<myusername>.http://pact.dius.com.au , the credentials were not identified.
May I know how to start using the pact broker hosted in the cloud by Pact team.
james.hattersley-dyke
2019-07-08 08:37
Hey, sorry been on paternity leave with a new Dog! p.s kids are way easier than puppies!
Thanks for looking into this @bethskurrie / @matt.fellows I've been using semantic versions as with each change the dev is required to increment the version number. That is enforced by the CI.
I think this issue arose when two devs used the same version number as they were changing separate parts of the codebase in tandem.
I'll try adding the git-sha to the version, I'll keep you posted how we get on!
bethskurrie
2019-07-08 08:52
@fun_rajesh send an email to Your credentials are only valid for 7 days and may have expired.
james.hattersley-dyke
2019-07-08 14:32
~Hey Beth, when the provider verification kicks off - does the broker return a 'pending state'? I've simply up the number of retries while waiting for the provider verification to happen and the CI passed. I'd previously had 3 retries but upped to 10. Which lead me to wonder if while verification is running the broker returns false?~
james.hattersley-dyke
2019-07-08 14:35
> It looks like you're publishing the pact then waiting a while for the verification to come back, but not long enough.
phall
2019-07-08 20:59
Hi all, I?m trying to set up the Pact Broker to trigger Bitbucket pipeline builds. So far, so good. The issue I?m having is in triggering the correct branch. We are tagging Pacts based on their branch, and would like to verify ?feature_a? provider against ?feature_a? consumer, and ?master? against ?master? etc.
The Bitbucket pipeline API call expects a single branch name to build, but the closest I can find from the ?contract_content_changed? event is ?${pactbroker.consumerVersionTags}? which gives ALL the tags. (e.g. ?master, stage, feature_a? as a single string)
Is there a way to get just the last/latest tag when executing a webhook?
matt.fellows
2019-07-08 22:36
> Hey, sorry been on paternity leave with a new Dog! p.s kids are way easier than puppies!
OK then that justifies my decision to have #2 :stuck_out_tongue:
laverya
2019-07-08 23:11
Is there a way to get a list of pact consumer version tags?
Or, more concretely? I want to test a provider against all published versions of a consumer, so as to avoid any possible breakage of old versions. (I cannot, unfortunately, force users to use the latest version) Is there a recommended way to do this?
laverya
2019-07-08 23:14
Ideally I?d prefer to run the test suite for for each unique set of pact content, but I?m fine with running more times than strictly necessary
laverya
2019-07-09 00:11
Currently the best solution I?ve found is this:
```
curl --silent --show-error --fail --user ${PACT_BROKER_BASE_URL_USERNAME}:${PACT_BROKER_BASE_URL_PASSWORD} -X GET -H "Content-Type: application/json" https://replicated-pact-broker.herokuapp.com/pacts/provider/prem-graphql-api/ | jq '._links."pb:pacts"' | sed -n 's/.*ship\/version\/\(v[^"]*\).*/\1/p'
```
But I?m not really happy with that for a variety of reasons
bethskurrie
2019-07-09 00:40
@phall typically when you publish a pact, you just start by tagging it with the branch name. What other tag names are you finding in there?
laverya
2019-07-09 00:44
I don?t think we?re using tags in the manner you mean, just creating a different consumer version for each release
laverya
2019-07-09 00:46
(if I need to add tags to the consumers in order to make this easier, I can do that)
bethskurrie
2019-07-09 00:47
If your consumer tags every pact they want to be backwards compatible as "prod" then you can verify all prod pacts.
laverya
2019-07-09 00:48
Oh interesting
I hadn?t realized that multiple versions could be tagged as prod (or at least that they would be returned together)
bethskurrie
2019-07-09 00:48
usually you only care about the latest tagged version if the consumer is running on a single server, but for mobile consumers, you care about all the prod versions.
bethskurrie
2019-07-09 00:49
Have a think about it though, and think if you could verify the first prod pact and the last prod pact - if both of those were valid, do the intermediate ones matter?
laverya
2019-07-09 00:50
> if both of those were valid, do the intermediate ones matter?
They don?t, until we make more than one change to the same query
Which means they do :disappointed:
bethskurrie
2019-07-09 00:50
if, at each time you released a new prod version, you knew it was compatible with the first prod pact, and the most recent prod pact, then it might actually be enough.
laverya
2019-07-09 00:51
In our case CI time isn?t really something I?m going to worry about yet
Only if it becomes a problem
bethskurrie
2019-07-09 00:52
I think I'll have to do a little work to make the thing you want available, but it shouldn't be much.
bethskurrie
2019-07-09 00:53
If you can wait a few days, I'll get back to you. I give you permission to ping me directly to remind me about it if I forget! (usually I don't like it if people do that!)
laverya
2019-07-09 00:56
Awesome, thank you!
But before you do
I just want to make sure we?re thinking of the same pact provider
And it seems to be `@pact-foundation/pact-node`
phall
2019-07-09 13:20
Our branching strategy is typically `feature_a` merged into `master`. If the pact is published by CI, we see the same pact tagged with `feature_a` and `master`. Deployment happens from `master`. Sometimes we deploy to additional environments by merging into a branch (e.g. `stage` or `test`) - if this is the case, CI will also tag the pacts with these branch names.
phall
2019-07-09 13:22
:point_up: This means that if the same pact test is merged `feature_a` -> `test`, then -> `master`, it will have three tags.
phall
2019-07-10 14:48
@bethskurrie just to follow up on this, is our branching/tagging strategy different from what you?d expect? An alternative approach would be for the webhook to trigger a special job, which would parse the tags and trigger the CI build.
sandhyarani.gabbi
2019-07-10 16:36
@matt.fellows We are pulling the docker image from https://hub.docker.com/r/dius/pact-broker and then hosting it with AWS ECS.
sandhyarani.gabbi
2019-07-10 16:40
@beth We are using PACT JVM 3.6.0 Version. We are planning on upgrading to newer version in sometime. The error message I get is "FAILED! 500 Internal Server Error - Unknown error" [ERROR] Failed to execute goal au.com.dius:pact-jvm-provider-maven_2.12:3.6.0:publish (default-cli) on project xxx: One or more of the pact files were rejected by the pact broker
bethskurrie
2019-07-15 04:00
@phall So, the tags belong to the consumer version, not the pact. This tells me that you're using the same consumer version in multiple branches. That's your problem.
bethskurrie
2019-07-15 04:00
thakkarjinal29
2019-07-15 15:00
Hello, I am facing a weird issue. When I pass the flag `--custom-provider-header` with a basic auth token, it tries to authenticate my `provider state url` instead of using it for a test within.
However, once I run the test without the `--custom-provider-header` flag and then re-run it with the same, it does what it is supposed to and not try and authenticate my `provider state url`
this is the command I am using
```
./pact-provider-verifier --pact-broker-base-url="https://test.pact.dius.com.au/" --provider-base-url="http://127.0.0.1:8000" -c "http://127.0.0.1:8000/_pact/provider_states/" -a $CIRCLE_SHA1 -v --provider=testprovider --broker-token=$BROKER_TOKEN --custom-provider-header='Authorization: Basic XYZ='
```
Would be great if someone could help
bethskurrie
2019-07-15 21:59
@thakkarjinal29 can you provide an executable example in a github repo and raise an issue in the pact-provider-verifier repository please?
bart.schotten
2019-07-16 13:12
I may be misunderstanding things, but it seems strange to me that can-i-deploy fails when there is no version of a provider yet that is tagged with the environment you want to deploy to. If services A and B are each other's consumers, this seems to cause a deadlock situation where you can never deploy one before you deploy the other.
I would expect can-i-deploy to only check for any existing integrations that fail.
sandhyarani.gabbi
2019-07-24 20:27
Closing this thread as changing the PACT Broker port has resolved my issue.
pkuang
2019-07-26 20:13
Hi can someone take a look at the issue I reported above and confirm if my assumptions are correct for this bug?
tjones
2019-08-04 02:06
For can-i-deploy, is it meaningful / useful to specify both a version and a tag?
bethskurrie
2019-08-06 09:50
@tjones it's an invalid query. If you're talking about, for the same app.
bethskurrie
2019-08-06 09:50
You could specify one app with a tag, and another with a version number, if you were listing your apps explicitly.
mohindroo.deepak
2019-08-06 14:49
How to install pact broker in azure devops? I do not want to use docker image. Want to do installation manually?
matt.fellows
2019-08-06 21:11
Deepak, I?m not sure how to do it in Azure DevOps specifically, but there are instructions on the wiki on how to run it
matt.fellows
2019-08-06 21:11
it?s a Ruby App, so you will need to automate a Ruby environment setup and run it behind a web server (e.g. nginx)
matt.fellows
2019-08-06 21:12
If you don?t want to run Docker, that?s OK, but you might want to look at how the Docker app is structured - that has most of the moving parts in it
matt.fellows
2019-08-06 21:12
Alternatively, you could look at using http://pactflow.io which is a fully managed pact broker with extras
mohindroo.deepak
2019-08-07 05:07
Can you share the wiki page of instructions?
Can i install this on windows machine manually?
What is the alternative if we do not use broker here?
matt.fellows
2019-08-07 05:09
you could store the pacts in Git / version control, use build artifacts, or upload them to a blob store like S3 (or build your own thing - but at that point, you?re better off just using the broker)
mohindroo.deepak
2019-08-07 06:03
Any samples for storing in blob ? How pact verifier will fetch from there? Do we need to write our own code for storing and fetching?
matt.fellows
2019-08-07 06:25
If you?re just trying to get a demo going, just store the files somewhere everyone can access them. The verifier can point to the URL of the pacts and off you go
matt.fellows
2019-08-07 06:25
if you want to do proper CI/CD with it, Pact Broker is your best bet by a long shot. You?ll eventually start wanting to do most of the things it does
mohindroo.deepak
2019-08-07 06:54
Actuall i have already tried with fileshare but now we need to look into permanent solution. We cannot do any outside hosting due to company policy.
We need to setup pact broker in our systems.
Is Pact broker installation really difficult to do?
Another point: if we use fileshare then whats the issue in cicd pipelines
matt.fellows
2019-08-07 07:03
> Is Pact broker installation really difficult to do?
No, but you?ll need somebody who knows how to run / operate a Ruby app properly
> Another point: if we use fileshare then whats the issue in cicd pipelines
See https://docs.pact.io/best_practices/pact_nirvana. You?ll often want to be able to version contracts, test against different versions of contracts, orchestrate deployment pipelines by knowing which components are compatible with others etc. This gets harder when all you have is a file system. The broker represents all of these and more as first class citizens.
> We cannot do any outside hosting due to company policy.
That?s OK, you don?t have to use Pactflow (but if there is something we can do to make it easier do let us know). I?d go with self-hosting a broker then, it?s the best move.
matt.fellows
2019-08-07 23:37
It?s a linux container. So wherever you can run the linux container it should run. We?ve never tested it on a Windows underlying host, but the whole point of Docker is that it shouldn?t matter.
matt.fellows
2019-08-09 10:29
This is the official image: https://hub.docker.com/r/pactfoundation/pact-broker (we?ve recently migrated from the DiUS image - hence the 500k+ pulls)
matt.fellows
2019-08-09 10:29
You?re safe with both, but we are pushing new changes to the foundation - so I?d start there
matt.fellows
2019-08-09 10:30
?certified? isn?t a thing, the closest is our managed broker at https://pactflow.io. If you need / want ?support?, we could probably discuss how we help with that situation
enrique
2019-08-09 12:32
I think it is ?deprecated?. The new one seems to be: https://hub.docker.com/r/pactfoundation/pact-broker/
mohindroo.deepak
2019-08-16 15:42
I am trying to run the pact verify code in dotnet and it works with pact file but not working with url. Giving some ruby files error? Need some help or code snippet to do that.
matt.fellows
2019-08-17 02:42
What are you doing (show us code and relevant logs)? What have you tried to remediate? What docs have you read? is the broker local or a hosted one? ?
mohindroo.deepak
2019-08-18 16:01
I am using hosted pact broker and when i try to verify using standard pact verify code, i got this error. Can you refer any link where i can see the code snippet how to fetch from hosted pact broker?
matt.fellows
2019-08-18 22:50
Publishing examples for most languages can be seen at https://docs.pactflow.io/docs/troubleshooting/#getting-a-401-unauthorized-when-publishing-or-retrieving-pacts
mohindroo.deepak
2019-08-19 05:45
I cannot find any dotnet example here. Is it possible to publish using dotnet?
mohindroo.deepak
2019-08-19 10:12
I have done verification of pact in dotnet core code using pactnet but how will i publish this to pact broker?
mohindroo.deepak
2019-08-19 11:49
So when publish will come here? From verify function i am getting success or exception in loger so what info i should send to broker?
ben.minter
2019-08-21 08:33
Hey, we are planning on using the https://hub.docker.com/r/pactfoundation/pact-cli but it looks like it only has a `latest` tag and no concrete versions, is this intentional or could versioning be added? Thanks!
gopinathlangote11
2019-08-21 10:37
Hello Pact Maintainer - I have a question about Pact Broker
? Does pact broker support `access management` - Read, Write as separate permissions!
bethskurrie
2019-08-21 10:42
The OSS docker image supports a read only basic auth user and a read/write basic auth user. Anything more than that will require you to write custom Ruby middleware. Full permissions support is planned for Pactflow however (the commercial fork of the Pact Broker that Ron, Matt and I are working on).
thomas.heilbronner
2019-08-21 13:21
Is the open source pact broker still the base for pact flow or is it a hard fork?
mohindroo.deepak
2019-08-21 15:30
Is pact work for amqp messaging. My use case is that i am sending lot of messages to azure service bus/kafka so how will i handle those contracts? Any samples for that?
matt.fellows
2019-08-22 10:30
Ok you'll need to look at the current outstanding PR then. It's being used by some but not yet merged into the mainline. Your feedback on it would be welcomed
deshdeepdivakar
2019-08-27 02:16
hi @here guys, where to specify `pact.verifier.publishResults=true` I don't want to have it in my gradle script. Cheers
deshdeepdivakar
2019-08-27 02:37
Found it I just needed to set them in my test file ``` val props = System.getProperties()
props["pact.provider.version"] = "1.0.2"
props["pact.verifier.publishResults"] = "true"
System.setProperties(props)```
bethskurrie
2019-08-27 08:46
Some features get released in pactflow first because I do the dev in the OSS codebase and then beta them in pactflow before I do a release of the oss gem.
davidjgmendes
2019-08-28 17:31
Greetings, I have an issue with webhooks in pact_broker. I currently have the broker in the same machine as jenkins. I'm trying to trigger a jenkins job with the webhook but I get the message "Failed to open TCP connection to localhost:5656 (Address not available - connect(2) for \"localhost\" port 5656)". Jenkins is running on port 5656 and it seems I am not able to reach it. I have already disabled cors and whitelisted the http method. Any ideas?
matt.fellows
2019-08-28 21:49
Localhost might also be blocked. I can't recall, but worth checking if that's in the host whitelist
matt.fellows
2019-08-28 22:49
Oh that's a bummer! I'm not in front of my laptop but will see if I can repro when I land at my desk
evman182
2019-08-28 22:53
is there an additional step spinning up the example application to setup the sqlite db?
evman182
2019-08-28 22:59
I'm following the exact instructions in https://github.com/pact-foundation/pact_broker/blob/master/DEVELOPER_SETUP.md
evman182
2019-08-28 23:09
I'm gonna try running it with postgres just for the sake of trying to move on
bethskurrie
2019-08-28 23:10
there's an existing pact_broker_database.sqlite3 file in the example directory. Delete it.
bethskurrie
2019-08-28 23:28
I don't use docker to develop, Tan set this up recently. He should be able to help.
evman182
2019-08-28 23:32
lol, in the UI, when you're looking at the list of Pacts, because the `Latest pact published` column contains strings like `2 months ago` rather than a date, sorting that column doesn't work as you'd expect as it's sorting those english strings
bethskurrie
2019-08-28 23:34
You'll find that the matrix works properly because of this:
```
$("#matrix").tablesorter({
textExtraction : function(node, table, cellIndex){
n = $(node);
return n.attr('data-sort-value') || n.text();
}
});
```
bethskurrie
2019-08-28 23:35
The index doesn't have the logic that allows it to sort on the data-sort-value attribute
bethskurrie
2019-08-28 23:36
This is the view model that you'll need to add the sort field to lib/pact_broker/ui/view_models/index_item.rb
bethskurrie
2019-08-28 23:37
It's currently sorting on this:
```
def publication_date_of_latest_pact
date = @relationship.latest_pact.created_at
PactBroker::DateHelper.distance_of_time_in_words(date, DateTime.now) + " ago"
end
```
evman182
2019-08-28 23:45
yep, but I think with the version of tablesorter being used there's a cleaner option, but once I get it running I'll see
bethskurrie
2019-08-29 00:05
I think we need an EXPOSE 9292 in the docker file to allow the runnning broker instance to be accessed from outside the container
tanle.oz
2019-08-29 00:08
Or you can run `-p 9292:9292` as @evman182 suggested as a work-around for the time being.
tanle.oz
2019-08-29 00:13
`EXPOSE` only defines incoming ports inside the container, to access this internal port we still need to define what port on the host this one is bound to, hence `- p`
tanle.oz
2019-08-29 00:17
Can you try this @evman182
```
docker run --rm -p 9292:9292 -v $(PWD):/app -it pact_broker:dev bash
# On docker
bundle exec rackup -o 0.0.0.0
```
davidjgmendes
2019-08-29 08:44
I made sure anonymous users are capable of triggering this specific job to test
davidjgmendes
2019-08-29 08:45
Modified the http://conifg.ru to have config.webhook_host_whitelist = [/.*/].
Still does not work
bethskurrie
2019-08-29 08:59
```
require 'net/http'
require 'uri'
uri = URI("https://postman-echo.com/post")
req = Net::HTTP::Post.new(uri)
response = Net::HTTP.start(uri.hostname, uri.port, :ENV, use_ssl: true) do |http|
http.request req
end
puts response.code
puts response.to_hash
puts response.body
```
davidjgmendes
2019-08-29 09:18
I used the docker-compose provided here https://github.com/DiUS/pact_broker-docker
I am quite new to docker tbh
bethskurrie
2019-08-29 09:19
OK, so the localhost from within your docker container is not the same localhost as the machine you're running docker on.
matt.fellows
2019-08-29 10:14
I was going to say if it's binding to 127.0.0.1 it won't be externally available
matt.fellows
2019-08-29 10:18
Another approach is to look at using another network mode that bridges the host machine, so then it would be the same network and localhost would work. If the Jenkins machine has a DNS name though, that would be best
bart.schotten
2019-08-29 11:14
I get a 500 error when trying to delete a pacticipant version. Deleting a tag for example works fine. Unfortunately I don't have access to the logs, but what could cause this? https://github.com/pact-foundation/pact_broker/wiki/Deleting-resources suggests it should be possible. We are running dius/pact-broker 2.31.0-1
bart.schotten
2019-08-29 12:59
Ah, I now have access to the logs and there we go:
ERROR -- : PG::ForeignKeyViolation: ERROR: update or delete on table "pact_publications" violates foreign key constraint "triggered_webhooks_pact_publication_id_fkey" on table "triggered_webhooks"
Looks like a bug.
bethskurrie
2019-08-29 20:53
Yes it does @bart.schotten. Can you raise an issue in the pact broker repository please?
priyank.shah217
2019-08-30 06:04
i am using docker image of pact broker.. and its running fine CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
c177c7535618 dius/pact-broker ?/sbin/my_init? 9 hours ago Up 9 hours 0.0.0.0:80->80/tcp, 443/tcp pactbroker
6afa398705a3 postgres ?docker-entrypoint.s?? 9 hours ago Up 9 hours 5432/tcp kind_bohr
538ad6d3f68c postgres ?docker-entrypoint.s?? 9 hours ago Up 9 hours 5432/tcp pactbroker-db
priyank.shah217
2019-08-30 06:05
so now issue is that i want to publish pact file to pact broker? so my question is that shall i used ?pactbroker? as hostname of pactbroker
priyank.shah217
2019-08-30 06:06
`<plugin>`
` <groupId>au.com.dius</groupId>`
` <artifactId>pact-jvm-provider-maven</artifactId>`
` <!-- 4.0.0-beta.5-->`
` <version>${pact.version}</version>`
` <configuration>`
` <pactBrokerUrl>http://pactbroker/</pactBrokerUrl>`
` <pactDirectory>${project.build.directory}/pacts</pactDirectory>`
` <projectVersion>${project.version}</projectVersion>`
` <trimSnapshot>true</trimSnapshot> <!-- Defaults to false -->`
` </configuration>`
` </plugin>`
bethskurrie
2019-08-30 06:07
It's going to be where you mapped it to when you started your docker instance.
priyank.shah217
2019-08-30 09:33
`<plugin>`
` <groupId>au.com.dius</groupId>`
` <artifactId>pact-jvm-provider-maven</artifactId>`
` <version>${pact.version}</version>`
` <configuration>`
` <pactBrokerUrl>http://localhost</pactBrokerUrl>`
` <serviceProviders>`
` <!-- You can define as many as you need, but each must have a unique name -->`
` <serviceProvider>`
` <name>TweetProvider</name>`
` <consumers>`
` <consumer>`
` <name>TweetConsumer</name>`
` <!-- currently supports a file path using pactFile or a URL using pactUrl -->`
` <pactUrl>http://localhost/pacts/provider/TweetProvider/consumer/TweetConsumer</pactUrl>`
` </consumer>`
` </consumers>`
` </serviceProvider>`
` </serviceProviders>`
` </configuration>`
` </plugin>`
priyank.shah217
2019-08-30 09:33
@bethskurrie, is it correct way to provide path of pact file ?http://localhost/pacts/provider/TweetProvider/consumer/TweetConsumer???
priyank.shah217
2019-08-30 09:34
I m hosting pactfile using broker.. so able to publish contract from consumer side.. now i want to validiate it from producer side
uglyog
2019-08-30 09:36
@priyank.shah217 refer to the docs here: https://github.com/DiUS/pact-jvm/tree/master/provider/pact-jvm-provider-maven#verifying-pact-files-from-a-pact-broker
gaurav
2019-09-03 02:52
Hello.. are there helm charts for pact broker deployment with kubernetes? Thanks.
bethskurrie
2019-09-03 04:00
Given that I've never heard of them until I googled it just then, no, unfortunately.
gaurav
2019-09-03 04:01
I found it actually: https://github.com/qamatic/helm-charts/tree/master/qamatic/pact-broker looks good so far.
priyank.shah217
2019-09-05 07:08
Hi all, I am not able to trigger producer test using webhooks {
?consumer?: {
?name?: ?TweetConsumer?
},
?provider?: {
?name?: ?TweetProvider?
},
?request?: {
?method?: ?POST?,
?url?: ?http://localhost:8080/job/ContractProducer/job/master/build?token=<SOME_TOKEN>?,
?username?: ?<USERNAME>?,
?password?: ?<SOME_TOKEN>?,
?headers?: {
?Accept?: ?application/json?
}
},
?events?: [
{
?name?: ?contract_published?
}
]
}
is not trigger producer job, but when i tried the same thing using cURL it triggered job. Please find below is my cURL
`curl -X POST -u ?USERNAME:TOKEN? ?http://localhost:8080/job/ContractProducer/job/master/build?token=TOKEN?
Is there any changed in request body of web-hook?
Note: I already whitelisted HTTP while launching pact-broker.
priyank.shah217
2019-09-05 07:10
priyank.shah217
2019-09-05 07:28
but now question is why i m allow to do same request using cURL command?
priyank.shah217
2019-09-05 07:29
here i m starting pact-broker.. `docker run --name pactbroker --link pactbroker-db:postgres -e PACT_BROKER_LOG_LEVEL="DEBUG" -e PACT_BROKER_WEBHOOK_SCHEME_WHITELIST="http https" -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD=TheUserPassword -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -d -p 80:80 dius/pact-broker`
priyank.shah217
2019-09-05 07:41
i have setup consumer and producer jobs in jenkins.. consumer jobs publish contract on broker and it should trigger producer jobs? so to make it happen i created hooks on pact-broker
priyank.shah217
2019-09-05 07:46
[2019-09-05T07:22:37Z] INFO: HTTP/1.1 POST http://localhost:8080/job/ContractProducer/job/master/build?token=111e424489b848f888d2df0226dec40aba
[2019-09-05T07:22:37Z] INFO: accept-encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
[2019-09-05T07:22:37Z] INFO: accept: application/json
[2019-09-05T07:22:37Z] INFO: user-agent: Ruby
[2019-09-05T07:22:37Z] INFO: authorization: **********
[2019-09-05T07:22:37Z] INFO: null
[2019-09-05T07:22:37Z] ERROR: Error executing webhook Jig0cm3F-2aGf_7poVMqwQ. For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See /doc/webhooks#whitelist for more information.
[2019-09-05T07:22:37Z] INFO: Retrying webhook in 10 seconds
priyank.shah217
2019-09-05 08:43
its new learning.. :slightly_smiling_face: will make do and don?ts for sure
priyank.shah217
2019-09-05 08:44
so basically i changed `docker run --name pactbroker --link pactbroker-db:postgres -e PACT_BROKER_LOG_LEVEL="DEBUG" -e PACT_BROKER_WEBHOOK_HOST_WHITELIST=XXX.XXX.XX.XX/YY -e PACT_BROKER_WEBHOOK_SCHEME_WHITELIST="http https" -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD=TheUserPassword -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -d -p 80:80 dius/pact-broker`
pkuang
2019-09-12 19:39
Hi I was wondering if there are any plans/work in progress to expose a user-friendly view of the verification results on the broker. Currently clicking on the results returns the json response in the HAL browser. It would be nice to be able to view this in a UI similar to the Pact contract view
bethskurrie
2019-09-12 22:24
Not yet in the OSS @pkuang. You can see them in http://pactflow.io though. It's just been released.
pkuang
2019-09-13 14:54
Thanks @bethskurrie, are there any plans on implementing this on the OSS broker? I'm weighing whether I should implement my own UI to parse the verification json and/or attempt to put up a PR to integrate it into the OSS broker
borsuk.artem034
2019-09-16 12:41
Hello, faced with issue in pact-broker when try to change version, database is external MySQL with data, when pact broker fetch webhooks got error:
```Did you mean? to_s
! Unable to load application: NoMethodError: undefined method `to_json' for {"Accept"=>"application/json"}:Hash
12:32:13.322549 D [7:47301919996420] root -- (0.000372s) SELECT * FROM `webhooks` WHERE (`id` = 9) LIMIT 1 FOR UPDATE
12:32:13.321983 D [7:47301919996420] root -- (0.000362s) SELECT * FROM `webhook_headers` FOR UPDATE
12:32:13.320723 D [7:47301919996420] root -- (0.000280s) SELECT NULL
12:32:13.321158 D [7:47301919996420] root -- (0.000303s) SELECT NULL AS `nil` FROM `webhook_headers` LIMIT 1
12:32:13.321588 D [7:47301919996420] root -- (0.000271s) SELECT NULL
12:32:13.320312 D [7:47301919996420] root -- (0.000335s) SELECT NULL AS `nil` FROM `webhook_headers` LIMIT 1
2019-09-16 12:32:13.319882 D [7:47301919996420] root -- (0.000276s) SELECT NULL
2019-09-16 12:32:13.319410 D [7:47301919996420] root -- (0.000483s) DESCRIBE `webhook_headers`
```
downgrade versions give the same result.
Anybody have the same? or can help?
borsuk.artem034
2019-09-16 12:52
detert
2019-09-18 10:16
Hi there. What is the proper way to call `pact-broker can-i-deploy` in the way that only those pact versions are checked that are tagged with a specific tag, for both pacticipants?
I currently use `./pact-broker can-i-deploy -a myconsumer -l master -b http://mybroker` but it fails, because there is one untagged provider version which did not succeed the test so far
detert
2019-09-18 10:25
Alright. As you can see, the latest provider version that is tagged as master is green. However, can-i-deploy fails, because the one version that is not tagged as master is red. I want to check only those pacts that are labeled as master
detert
2019-09-18 10:26
./scripts/pact/bin/pact-broker can-i-deploy -a bookingengine.mietwagen -l master -b https://pact-broker
```
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
------------------------|--------------------------------|-------------------------------|--------------------------------|---------
bookingengine.mietwagen | 1.0.0-adf757b0aff78c2910e4c... | bookingengine.customerprofile | 1.0.0-bd6e7f008aeedd30f65e6... | true
bookingengine.mietwagen | 1.0.0-adf757b0aff78c2910e4c... | bookingengine.pci | 1.0.0-715595c410379f10b8972... | false
```
bethskurrie
2019-09-18 10:27
BTW, the command you're using there is saying "I want to deploy the latest version of the consumer that has the master tag with the latest version of everything else".
detert
2019-09-18 10:28
Yeah, maybe I do it wrong. That why I am asking. I found it difficult to understand the docs to be honest.
bethskurrie
2019-09-18 10:29
Then it will be saying, I want to deploy the latest version of the consumer with the tag master, to an environment that has the latest master version of everything else.
detert
2019-09-18 10:31
Alright. This is the output for the latest version of bookingengine.mietwagen
./scripts/pact/bin/pact-broker can-i-deploy -a bookingengine.mietwagen -e 1.0.0-adf757b0aff78c2910e4c2a34d8e536b767a3aaf --to master -b https://pact-broker
Is that line correct? If yes, why does it check customerprofile with pci? I would not expect that
```
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
------------------------------|--------------------------------|-------------------------------|--------------------------------|---------
bookingengine.customerprofile | 1.0.0-bd6e7f008aeedd30f65e6... | bookingengine.pci | 1.0.0-171dc6e439031d55cce09... | true
bookingengine.mietwagen | 1.0.0-adf757b0aff78c2910e4c... | bookingengine.customerprofile | 1.0.0-bd6e7f008aeedd30f65e6... | true
bookingengine.mietwagen | 1.0.0-adf757b0aff78c2910e4c... | bookingengine.pci | 1.0.0-171dc6e439031d55cce09... | true
```
bethskurrie
2019-09-18 10:31
It's confusing me because typically your tags for deployment would reflect an environment name.
bethskurrie
2019-09-18 10:32
When you're using tags for dev, they map to a branch, but for deployment, they map to an environment.
detert
2019-09-18 10:32
master=prod here. Everything that we merge into master goes to production. I just use the branch name to simplify the usage and testing of feature branches
detert
2019-09-18 10:34
Well. Yes. I tried to implement that check before a branch is merged into master and right before master would be deployed to production
bethskurrie
2019-09-18 10:35
Ah, so there is a gap between merging into master and then deploying to prod?
detert
2019-09-18 10:37
Well, the gap is just a few minutes but there might be merge conflicts. What is the difference between naming the tag master or prod? We consider everything in master as "this is on production"
bethskurrie
2019-09-18 10:39
It's probably OK. I'm just getting my head around it. And it makes the can I deploy line unusual.
detert
2019-09-18 10:41
I see. What I do is tagging each pact with the current branch name. Then I want to test if all consumer/provider pairs with the same tag are green. If yes, then my master release or feature branch is good. Does that make sense?
detert
2019-09-18 10:41
Great. I just do not know, if and how I have to use can-i-deploy for that use case
bethskurrie
2019-09-18 10:42
Usually you'd deploy to prod, tag with prod, and then for the next deployment, you'd say, can I deploy this new version with all the other prod versions.
bethskurrie
2019-09-18 10:42
I can't help you with your command until I can see the text unfortunately.
detert
2019-09-18 10:44
That is the output of the pact-broker can-i-deploy call `./scripts/pact/bin/pact-broker can-i-deploy -a bookingengine.mietwagen -e 1.0.0-adf757b0aff78c2910e4c2a34d8e536b767a3aaf --to master -b https://pact-broker`
detert
2019-09-18 10:46
Formatting is difficult
As you said: This command tests all the pacts that are tagged as master. However, if I deploy service A, I do not care about the status of the consumer/provider pair from service B and C, I am interested in A/B and A/C, but not B/C
detert
2019-09-18 10:48
In the given case, I want to deploy service A. A cosnumes B and C. B does consume C as well. But the conenction from B to C is irrelevant, if I want to release A
bethskurrie
2019-09-18 10:50
There was a bug where the other dependency was being returned, but it's been fixed.
bethskurrie
2019-09-18 10:55
ensure unrelated dependencies are not included in a matrix result when three pacticipants each have dependencies on each other (a086ffec)
bethskurrie
2019-09-18 10:55
You need this fix https://github.com/pact-foundation/pact_broker/commit/a086ffec
detert
2019-09-18 10:56
Great. I will pull the latest pact-broker-docker version and see if that helps. Thank you very much
detert
2019-09-18 11:03
You are right. The reason is that we are moving parts from service A to B and we are not done yet
mohindroo.deepak
2019-09-20 17:15
How can i use can-i-deploy with PactNet consumer ? How to use in ci/cd pipeline?
matt.fellows
2019-09-21 02:36
can-i-deploy has nothing to do with PactNet, you just need to download the CLI tools and execute them like you would any other tool
tritorto
2019-09-24 01:21
Hi guys, wondering if anyone can point me to any details with setting up the pact broker webhook for TeamCity integration (i.e trigger a build when the pact changes) - Im looking at the wiki webhook template library atm (https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library), but nothing on Teamcity - any help would be appreciated..
bethskurrie
2019-09-24 01:23
A quick google finds this: https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-TriggeringaBuild
tritorto
2019-09-24 01:35
Thanks Beth - I was just looking at it :slightly_smiling_face: Im trying to send a test webhook with the XML needed in PactFlow UI - I've come up with this Body so far, but it is failing with a 400 Bad Request:
Headers:
```
"Content-Type": "application/xml"
```
Body:
```
<build branchName=\"develop\">
<buildType id=\"TEST\"\/>
<comment><text>New version of pact created for ${pactbroker.consumerName}/${pactbroker.providerName}.</text></comment>
<properties><property name=\"env.pactVersionUrl\" value=\"$pactbroker.pactUrl\"\/><\/properties>
</build>
```
matt.fellows
2019-09-24 01:38
Looks like your use of `$pactbroker.pactUrl` is missing the enclosing template braces `{`, `}`
bethskurrie
2019-09-24 01:40
I'd personally start by writing a curl request, doing the simplest thing possible (no properties) and once that was working, move it into pactflow
tritorto
2019-09-24 01:55
for anyone interested - I have it sending successfully now (just got to hook it up to TC :crossed_fingers:)
bethskurrie
2019-09-24 03:37
@tritorto I notice that you put the body in single quotes. You shouldn't have to do that - what were you noticing when you didn't use the quotes?
samuel.hodgkinson
2019-09-24 12:43
Hi, I'm not sure I posted this in the right place. Can anyone assist me with this issue?
pkuang
2019-09-24 13:41
Hi @bethskurrie, was wondering if you had a response for my previous question?
antonello
2019-09-24 17:46
@bethskurrie We?ve noticed that even simple can-i-deploy calls for a consumer with only one provider take several seconds. We didn?t measure, but sometimes >10s. Is it expected? Is there anything we may be doing wrong?
bethskurrie
2019-09-25 02:36
It will be due to combinationatorial explosion @antonello. The most sane way to handle it is to remove old data. I did do some recent work on that query that might speed it up for you. Are you on the latest version?
bethskurrie
2019-09-25 02:40
This is the version with the relevant changes https://github.com/pact-foundation/pact_broker/blob/master/CHANGELOG.md#v2360-2019-08-30
bethskurrie
2019-09-25 02:42
If that doesn't help, maybe you'd be able to send me a redacted copy of your database so I can do some analysis on it.
antonello
2019-09-25 06:54
Thanks Beth, I?ll check when I get to the office in a bit but I?m almost certain that we are on a version greater than the one that includes that fix.
bethskurrie
2019-09-25 07:27
If you're able to get an export and blank out all the actual pact contents, I can run some analysis on it.
bethskurrie
2019-09-25 07:28
Processing power makes a big difference. On my mac, the queries for even large datasets come back super fast, but on the RDS instance for Pactflow, it was significantly slower.
bethskurrie
2019-09-25 07:28
I had to put the data in a docker container with reduced specs just to reproduce the slowness.
antonello
2019-09-25 07:39
Any recommendations on what type of CPU you?d recommend. Looking at the performance stats of the machine that hosts the broker and the DB, the CPU usage stays ~20% when running those query.
antonello
2019-09-25 07:40
However, and I wanted to mention that as well, last week someone managed to bring the broker down by running to concurrent can I deploy requests.
bethskurrie
2019-09-25 08:19
Yes, if you've got debug logging on, it will log the requests and request times.
bethskurrie
2019-09-25 08:21
If the http request is taking 10 seconds, but the SQL is taking significantly less, that tells us where the problem is.
mohindroo.deepak
2019-09-26 16:55
Is there any sort of authentication for stop accessing pact broker site?
matt.fellows
2019-09-27 03:52
Are you hosting your own? If so no, there is no auth or permission on the OSS broker. We have a number of authentication mechanisms on Pactflow
ruben.perezg
2019-09-27 08:54
Hi!
We are trying to complete the adoption of Pact, and currently what we have missing is the `can-i-deploy` functionality:
- Check whether intended deploy is safe (checking the Pact Matrix with the `can-i-deploy`)
- Tag with the production stage once the deploy has succeed.
In our case, it would be way simpler for us if we could use the API instead of the _can-i-deploy_ CLI.
I have been fighting with this, trying to find out how to do that using the API. I have found this [1] as the only point of documentation for what I am trying to do. There, there is an example that says `A request for the compatibility matrix for Foo version 1.2.3 and the latest prod versions of all other pacticipants`, that I think is exactly what I'm looking for in order to check whether the new version to deploy is safe.
For that, there is this example:
```
{
"method": "get",
"path": "/matrix",
"query": "q[][pacticipant]=Foo&q[][version]=1.2.3&latestby=cvp&latest=true&tag=prod"
}```
My guess is that I have to create a `GET` request like this:
`http://myPactBroker/matrix?pacticipant=myPacticipant&version=myCommitId&latestby=cvp&latest=true&tag=pro`
But that is not working, as I'm getting a `400` status code, with this body:
```
{
"errors": [
"Please provide 1 or more version selectors."
]
}```
Could anyone point my what I'm doing wrong, or any documentation of the Broker API that I have not found? :slightly_smiling_face:
1 -> https://github.com/pact-foundation/pact_broker-client/blob/master/doc/pacts/markdown/Pact%20Broker%20Client%20-%20Pact%20Broker.md
ruben.perezg
2019-09-27 08:59
our scenario includes a Monolith with its own CI and deploy system, and Microservices, with their own CI and CD system.
For our microservices, we use Spinnaker, and in our current setup I'm not sure if it's possible to execute any CLI there. But it is quite straightforward to make API requests... so that's why I am looking into using the API instead of the CLI
bethskurrie
2019-09-27 09:01
q[][pacticipant]=Foo&q[][version]=1.2.3&latestby=cvp&latest=true&tag=prod
ruben.perezg
2019-09-27 09:01
I already thought that the `q[]` was important, but I haven't been able to get it right :slightly_smiling_face:
bethskurrie
2019-09-27 09:03
If you run can I deploy with verbose on, you'll see the exact query it's making
ruben.perezg
2019-09-27 09:05
to be honest, I haven't seen this kind of query before:
`"query": "q[][pacticipant]=Foo&q[][version]=1.2.3&latestby=cvp&latest=true&tag=prod"`
So I was pretty lost trying to "translate" that. But if the can I deploy logs the requests, then I will try that
bethskurrie
2019-09-27 09:07
You can just copy paste and swap the name and version of your application, and tag.
ruben.perezg
2019-09-27 09:12
that is indeed working with a quick test directly from the browser. Thank you very much Beth! :slightly_smiling_face:
mohindroo.deepak
2019-09-27 19:57
That is interesting. So we do not need canideploy tool to verify consumer pacts by using above urls?
bethskurrie
2019-09-29 23:33
You can call the API directly, but it's not very user friendly. I need to abstract some of the logic in a "can i deploy" endpoint. At the moment, it's calling the matrix endpoint with specific parameters.
borsuk.artem034
2019-09-30 10:39
Hello, can some one give example how to use OAuth in webhook for bitbuket?
bethskurrie
2019-09-30 10:41
I don't think it will possible from the broker side, because you only get one request, and as far as I know, oauth requires a multi step flow.
bethskurrie
2019-09-30 10:42
I've always understood oauth to be a user auth mechanism, rather than a machine to machine auth mechanism. Is there another way of authenticating to bit bucket?
mohindroo.deepak
2019-09-30 16:17
I was trying to run can-i-deploy tool to check consumer pact veriifcation. My broker is using certificate. It fails with certicate_verification_fail error. Any clue?
mohindroo.deepak
2019-09-30 16:32
Actual error
Error: Error making request - OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: certificate verify failed
bethskurrie
2019-10-01 00:01
@mohindroo.deepak `To connect to a Pact Broker that uses custom SSL cerificates, set the environment variable $SSL_CERT_FILE or $SSL_CERT_DIR to a path that contains the appropriate certificate.`
bethskurrie
2019-10-01 00:03
Hey all, does anyone use the network diagram (either directly, or by exporting the integrations data into another tool)?
abubics
2019-10-01 00:21
I used to, but didn't find it super helpful on my small networks :stuck_out_tongue:
mohindroo.deepak
2019-10-01 04:45
I have set this environment variable in powershell before calling can-i-deploy command but it did not work. Only difference is that my certificate extension is .cer not .crt.
tritorto
2019-10-01 05:19
exporting it into Powerpoint :wink: - I really like the feature actually :+1:
tritorto
2019-10-01 05:24
Hey guys - first off absolutely loving the pact-broker / pactflow - our team has started using it and so far so good :slightly_smiling_face: a quick question however, with regards to webhook integration - I was thinking of adding a webhook to post verification results to Slack - I noticed in the webhook template documentation, we are only able to use the verification result url, and not the actual status value - is this correct? Would be nice to display the result directly in Slack
tritorto
2019-10-01 05:28
I was looking at this page:
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown
bethskurrie
2019-10-01 05:28
`${pactbroker.githubVerificationStatus}: the verification status using the correct keywords for posting to the the Github commit status API.`
mohindroo.deepak
2019-10-01 05:34
Yes we are also started using that and absolutely great feature :+1:
bethskurrie
2019-10-01 06:45
Powershell, hey.. I think there was an issue with windows. Let me see if I can find the issue on github.
bethskurrie
2019-10-01 06:49
bethskurrie
2019-10-01 06:57
It's not fixed - I don't have a windows environment to test on, and nobody was able to verify a code fix from my suggestions. There's just that workaround.
bethskurrie
2019-10-01 06:58
I don't know. I'd stick with the same format personally. But it doesn't hurt to try.
bethskurrie
2019-10-01 06:58
I still think that `set "ORIG_SSL_CERT_FILE=%SSL_CERT_FILE" to pact-provider-verifier.bat` in should work.
mohindroo.deepak
2019-10-01 07:13
I have actually replaced my certificate file with lib\ruby/lib/ca-bundle.cry
bethskurrie
2019-10-01 07:16
I thought it used the underlying pact broker client code to publish the pacts. but perhaps not.
mohindroo.deepak
2019-10-01 07:18
That will be great if i can get some api. This is required at consumer side to validate
pltran875
2019-10-01 16:04
I am receiving 429 status code too many requests when publishing up to 3 contracts in a row - is there a limit? thanks.
angela.gloyna
2019-10-01 23:46
Hi, I might be completely overlooking something, but I'm having trouble tagging provider versions in pact-broker (docker image). hitting this endpoint has been returning 404: `https://{pact_broker_url}/pacticipants/{provider}/versions/{version}/tags/prod`
angela.gloyna
2019-10-01 23:53
... and by asking for help, I just figured out the body needs to include the provider, version, and tags. Resolved!
bethskurrie
2019-10-02 00:41
That url looks fine. To tag a resource you just need to do a put to that url.
angela.gloyna
2019-10-02 01:32
It was a put. Didn?t seem to work via postman until I reiterated the parameters in the body.
angela.gloyna
2019-10-02 01:36
just retried it without the content-type. that was the culprit. Thanks for the quick response!
g.maguire85
2019-10-02 22:58
on OSS pact broker is there to enable only a read/write basic auth user say for a CI system to have write access for publishing pacts. Then just leaving pact broker open with read access with no user auth prompt?
bethskurrie
2019-10-02 23:25
Would just need to make this a bit smarter https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/basic_auth.rb#L22
bethskurrie
2019-10-02 23:27
Actually, now I think about it, if you didn't set the env vars for the read only username and password, it might give you public read access. Try it and see what happens @g.maguire85
pltran875
2019-10-03 09:48
So I originally signed up and am using the DiUS Hosted Pact Broker public beta version (before Pactflow) - just to clarify are there any limitations or plans to eventually discontinue that we should be aware of?
bethskurrie
2019-10-03 10:21
There was a migration issue where limits were accidentally applied to the beta users, but that has been fixed.
bethskurrie
2019-10-03 10:22
Whether or not the free version will continue indefinitely is not yet decided.
g.maguire85
2019-10-03 16:17
@bethskurrie - so if you dont set the read only env vars, you are still presented with the prompt. though you can access the app by just clicking sign-in without entering any creds
bethskurrie
2019-10-06 23:46
@g.maguire85 I've updated the code to not present a basic auth prompt when the read creds are empty
yosevuk
2019-10-07 18:27
Hello! I have a question about when to use `pactBrokerUrl` versus `pactUrls` when setting up provider [verification options](https://github.com/pact-foundation/pact-js#verification-options).
Are you supposed to use `pactUrls` when you have a provider with more than one consumer pact broker URLs that you want to be able to verify independently?
pravera
2019-10-08 19:28
Hi! In the docs it says `The latest production pact for provider Bar can then be retrieved from /pacts/provider/Bar/consumer/Foo/latest/prod.` after tagging it as `/prod`. But whenever I tag the version and then retrieve it, `/latest/tag` I?m getting an old app version. Any thoughts?
https://github.com/pact-foundation/pact_broker/wiki/Using-tags
uglyog
2019-10-08 22:29
Not currently, as it is tied to the Pactflow service and is part of a commercial offering
tjones
2019-10-08 22:30
What are the versions, and when were they published? It might be that the broker thinks that the older version is more recent
tmok01842
2019-10-09 00:23
Hi all - I've got an error to report. My company has a pact broker account and when people are attempting to view the matrices they're getting 'internal server error'
bethskurrie
2019-10-09 01:17
Btw, you're still on the beta offering. We've released the official Pactflow product now, which has some extra goodies including display of line level verification results, secrets, webhook testing and editing https://pactflow.io/oss/
tmok01842
2019-10-09 01:18
that looks good - but what's the status of our license etc w.r.t. this new product?
bethskurrie
2019-10-09 01:19
You're able stay on your current free beta plan for now. We haven't decided how long that will run for yet, now the official release is out.
bethskurrie
2019-10-09 01:19
Beta customers will get a discount if they want to move over to a paid plan however.
tmok01842
2019-10-09 01:21
Ok. We may well do so. We're right on the cusp of beginning to try to use PB in anger for all our applications. If it works out ok, we'll probably want to move to the official product sooner or later
pravera
2019-10-09 13:35
Hi @tjones thanks for the answer! The versions are `APP_VERSION.BUILD_NUMBER`, say `2.0.0.123`. We have `order_by_date setting=true` now, so it should be ordering by the versions. But it?s only considering `X.X.X` and not the BUILD_NUMBER when ordering, so when that changes, we still can?t get the latest pact.
vitaliy.grigoruk
2019-10-09 14:24
Hey folk, is there any practice regarding cleanup of old participant versions, tags in pact broker?
yosevuk
2019-10-09 14:25
Hey! I have a question about pact verification for the provider after reading: https://docs.pact.io/getting_started/verifying_pacts#verifying-pacts-from-a-pact-broker.
Once a pact is published and I see it in the pact-broker, what has to happen for it to be verified? I assume that the team responsible for the provider service has to make updates on the provider side to verify the new consumer pact. Is that accurate?
pravera
2019-10-09 17:34
Is this going to be implemented at some point? https://github.com/pact-foundation/pact_broker/issues/175 cause if we want to follow the pact nirvana guides, and the best practices in the `app_version` form (using build number or git sha) for now it does not change anything right? As having `PACT_BROKER_ORDER_VERSIONS_BY_DATE=false` to order by semantic version will only consider `X.X.X` part of the version and not the change in the build number or git sha
mauricio.galeas
2019-10-09 18:33
Hell! I have a question. I'm using a hosted pact-broker in go, but when i execute the test it crashes in the same part
`=== RUN TestProvider`
`2019/10/09 15:31:46 [ERROR] service exec: "pact-broker": executable file not found in $PATH`
`--- PASS: TestProvider (0.11s)` Did i miss to install something?
bethskurrie
2019-10-09 21:55
Given that its a local path issue, I can't see that it makes a difference where the pact broker is running @mauricio.galeas?
bethskurrie
2019-10-09 21:58
I've been meaning to add this to the code, but for now, there's an SQL script in the pact broker repo @vitaliy.grigoruk
bethskurrie
2019-10-09 22:17
@pravera it does the ordering on insert, so after you change that setting, you'll need to publish another pact for it to redo the ordering.
pravera
2019-10-10 00:18
Thanks for the response! @bethskurrie I?ve set it back to `true`. We?re using `app_version.build_number` to tag consumer versions so when pushing multiple changes, the versions are `1.0.0.1234`, `1.0.0.1235` and then `1.0.0.1236` . Each version is tagged with `branch_name`, but the `/latest/branch_name` we retrieve is always the pact corresponding to `1.0.0.1234`. The pacts (with changes) for the other ones can?t be retrieved by `latest/branch_name` . Is this the expected behaviour?
vitaliy.grigoruk
2019-10-10 07:16
let me please clarify your question, @yosevuk. Are you interested in ?how to trigger provider verification when contract is published? or ?how provider team should implement verification process on their side?
dannybrown2710
2019-10-10 10:39
Hi Team, I need help. I want to setup the pact broker in Pivotal cloud foundry and use Oracle as database in certain tablespace . I am new to Ruby and I am not able to proceed. Can someone give me steps to set it up ?
Thanks in advance
matt.fellows
2019-10-10 10:52
We only support (test for) Postgres and MySQL, so it's likely this setup isn't possible
yosevuk
2019-10-10 16:51
"How to trigger the provider verification when the contract is published". If there is already a provider with tests, does it need to do anything to verify a pact with a new consumer or should that happen automatically when the new pact is published?
Perhaps it depends on how the provider is set up :thinking_face:
pravera
2019-10-10 17:03
I would really appreciate some help with this, as it?s been an actual blocker
bethskurrie
2019-10-10 20:15
I've heard of issues before when people have changed versioning approaches mid way.
bethskurrie
2019-10-10 20:17
@dannybrown2710 the example folder uses Sqlite, which is not a production database.
bethskurrie
2019-10-10 20:18
If you are unfamiliar with running Ruby applications, please use the docker image pactfoundation/pact-broker or get a hosted broker at http://pactflow.io. We cannot assist you with a custom deployment. That is the job of a (paid) ops person.
pravera
2019-10-10 20:19
Thanks! We have 19 consumers with their providers being tested using the pact-broker, so if the approach is to delete all of them, builds will start to fail. This makes me think of the need to have a backup or a way to do this gracefully.
bethskurrie
2019-10-10 20:23
I'm assuming you've restarted the broker after making the configuration change?
bethskurrie
2019-10-10 20:26
BTW, what version of the broker are you using? The semantic ordering has been not on by default for ages.
pravera
2019-10-10 20:31
Indeed, deployed the broker with the new config change. Will try that, and also publishing pacts for other services and try to retrieve them with `latest/branch_name`. We?re using 2.15.0 version
pravera
2019-10-10 21:20
Tried deleting the consumer with all of the pacts and published two different pacts with `/develop` tag and versions: `X.X.X+1111` and `X.X.X+1112` but still `latest/develop` returns pact from `X.X.X+1111'
pravera
2019-10-10 21:23
createdAt:
`X.X.X+1111` ?2019-10-10T21:13:24+00:00?
`X.X.X+1112` ?2019-10-10T21:14:08+00:00"
bethskurrie
2019-10-10 21:24
either way, it would be best to upgrade, because there are known vulnerabilities with the webhooks in older versions
bethskurrie
2019-10-10 21:24
* change version ordering to sort by date by default ([6552b46](/../../commit/6552b46))
pravera
2019-10-10 21:28
Cool I?m headed to that changelog and check to upgrade the version. In case the default was being false in this version, I tried before to set `PACT_BROKER_ORDER_VERSIONS_BY_DATE=true`. To delete in this version had to delete the pacticipant, which in this case was only consumer so no problem.
bethskurrie
2019-10-11 00:38
@g.maguire85 an issue was raised which lead me to realise there was potential for a security vulnerability if the READ_ONLY credentials weren't set. I've changed the latest docker images to require an explicit enabling of public read.
dannybrown2710
2019-10-11 06:43
Sure. I will look into it. Thanks alot for your help :slightly_smiling_face:
detert
2019-10-11 07:37
When using pact-broker webhooks with GitLab, I have to add a GitLab Token to the according URL. Is there a way to hide that token? It should not be visible for everyone.
bethskurrie
2019-10-11 08:13
There was some work done to redact the tokens in the logs. I'll see if that can be revived.
bethskurrie
2019-10-11 08:13
Best if you can scope the token with the least possible permissions in the meantime.
detert
2019-10-11 08:14
Do the logs affect the HAL browser as well? I guess it is possible to take a look at all webhooks via REST
I think there was a possibility to add credentials to pact-broker to limit the access. Is that right?
bethskurrie
2019-10-11 08:15
Oh, sorry, yes, if you're using the docker image, it's got built in basic auth
pravera
2019-10-11 20:34
Updated from broker version `2.15.0` to the latest version and now the behavior is the expected! Now after each build publishes and generates pacts with consumer version: `1.2.3-12345` and tags `/branch_name`, which we can properly retrieve and verify with `/latest/branch_name`. Thank you @bethskurrie! It?s good to know there?s a community here willing to help :slightly_smiling_face:
darragh.grace
2019-10-14 11:18
Hi there, I am trying to figure out if I can specify a schema to use in a Postgres DB for the Pact Broker. When running the Dockerised Broker I can specify `PACT_BROKER_DATABASE_NAME`, is there functionality to specify the schema in that DB to use?
darragh.grace
2019-10-14 11:20
Looks like it is possible in jdbc connection url for Postgres - `jdbc:` - https://stackoverflow.com/questions/4168689/is-it-possible-to-specify-the-schema-when-connecting-to-postgres-with-jdbc
yosevuk
2019-10-16 19:47
Hello! I'm not sure if I should be asking here, but wondering: How do I use the `can-i-deploy` script in pact-node CLI if there isn't a basic auth username and password set up with the pact broker?
detert
2019-10-17 06:09
or does the pact-node differ from https://github.com/pact-foundation/pact_broker-client?
yosevuk
2019-10-17 13:56
Yeah, it doesn't work ignoring them, but I'll ask in an issue pact-node. Thanks!
me_pact
2019-10-20 17:18
Hi! A question about the `/pacts/provider/{{provider}}/consumer/{{consumer}}/tag/{{tag}}` endpoint. This endpoint currently returns the pacts with versions, and a field called "createdAt". This field, however, has the initial creation date of the version, when the version has multiple revisions. To get the latest updated version, I need to query `/pacts/provider/{{provider}}/consumer/{{consumer}}/version/{{version}}` for each of the returned results. Would it be possible to add "updatedAt" field to this endpoint so that we can reduce the amount of API calls?
james.hattersley-dyke
2019-10-21 07:49
Hi, does anyone have any examples of what to `POST` to this end point in a webhook?
`https://pactbroker.management.mydomain.net/webhooks/xFISu7ec7SfGYCDssjVt1g/execute`
I've set up the webhook, but whenever I come to trigger it using a non-get request there's an empty post body waiting to be filled in. Do I need a payload or; is whatever is configured at setup time e.g. events, consumer and provider names etc enough to trigger the webhook?
bethskurrie
2019-10-21 08:34
@me_pact i know from the other conversation you're doing something unusual. Can you tell me what you're trying to achieve?
james.hattersley-dyke
2019-10-21 08:42
:+1: cool, wasn't sure. I was looking for something staring me in the face saying / demo'ing that... :slightly_smiling_face:
james.hattersley-dyke
2019-10-21 08:43
while I've got your attention, sorry have you ever had to deal with Jenkins CSRF crumbs with webhooks?
bethskurrie
2019-10-21 08:43
It's just a generic API browser - it doesn't know whether the endpoint takes a payload or not
james.hattersley-dyke
2019-10-21 08:45
no worries, I think it's more of an issue with the way we have Jenkins set up here using the 'bitbucket branch source' plugin
james.hattersley-dyke
2019-10-21 08:46
it creates multi branch projects by default, which can't use an API token, so have to use the crumbIssuer
james.hattersley-dyke
2019-10-21 08:57
yeah - Ideally I'd like the consumer builds to create the webhooks too at build time. It'd check the existence first then, create if a webhook didn't exist. We've got shared pipeline libraries to contend with too so there's a node pipeline, java pipeline etc... each project just uses those base pipelines rather than having an individual jenkins file
bethskurrie
2019-10-21 08:57
So you'd be interested in this: https://github.com/pact-foundation/pact_broker-client/issues/54
james.hattersley-dyke
2019-10-21 08:59
I don't mind the delete and recreate right now, it's all this battling with API keys / crumbs etc
bethskurrie
2019-10-21 08:59
In the past, I've recommended putting in a proxy that could handle the CSRF stuff.
james.hattersley-dyke
2019-10-21 09:00
yeah, we could do that. I think personally it would be safe to turn off CSRF protection in Jenkins as it's all in a VPC controlled by AWs security groups etc
james.hattersley-dyke
2019-10-21 09:01
no me neither, nor do my aws skills extend to understanding the devops chap's terraform code :slightly_smiling_face:
james.hattersley-dyke
2019-10-21 09:31
Think I've cracked it, discovered all the users in Jenkins aren't config as code and can have their own API tokens configured
james.hattersley-dyke
2019-10-21 09:31
yeah i've triggered a build remotely through postman so should be all good!
james.hattersley-dyke
2019-10-21 09:33
I'm calling jenkins with something like `/myjob/buildWithParameters?service=my-provider`
james.hattersley-dyke
2019-10-21 09:34
could I create one generic webhook, at a top level which uses the variable subsitutions so it would be configured like `/myjob/buildWithParameters?service=${pactbroker.providerName}`
james.hattersley-dyke
2019-10-21 09:38
Never really had a problem... mainly just questions :slightly_smiling_face:
me_pact
2019-10-21 15:14
So, I'm building a Concourse CI Pact resource type. [1]
In summary, the resource tries to pull new versions from the source provider when invoked, which in this case it's the Pact Broker. The question it needs to answer is "Given provider X, consumer(s) Y, and tag Z, are there any new unverified Pacts?".
In my use case, when I open a PR for the consumer side, and the CI runs the consumer tests, I'd like to invoke the provider and run the Pact tests. In order to do this, I have set up a webhook for the broker to invoke the Concourse resource on the provider side, and tell it to pull and find a new version.
So far, this works nice with immutable Pact versions and the first endpoint that I mentioned above. However, since I can't obtain the time of the latest overwritten version through the first endpoint, I have to loop through all returned results, and query each one of them to get the `createdAt` time. In order to make a unique enough version in the Concourse resource, so that it can distinguish between versions, I have chosen a combination of `consumer`, `consumerVersion`, and the `createdAt` field.
It's a convention at our company to name and overwrite the PR artifacts with the PR number on updates, that's why I would like to apply this to Pact as well. I know that this can be circumvented by appending Git hash at the end of the version, for example `PR-15-ad2344f` or similar, but this way there might be lots of versions aggregated in the Pact broker over time.
What would your suggestion be in this kind of a use case? Thanks for reading, and sorry for the wall of text, I know context is important :slightly_smiling_face: I still have some other questions, but this is the most pressing one I have so far.
[1]: https://concourse-ci.org/implementing-resource-types.html
james.hattersley-dyke
2019-10-21 15:52
Can anyone confirm if this is a known issue? I set up a webhook thusly:
```
{
"request": {
"headers": {
"accept-encoding": "gzip;q=1.0,deflate;q=0.6,identity;q=0.3",
"accept": "*/*",
"user-agent": "Ruby",
"content-type": "application/json",
"authorization": "**********",
"host": "http://jenkins.management.cldinf.net",
"content-length": "31"
},
"body": {
"SERVICE_NAME": "user-insight"
},
"url": "https://jenkins/job/webapp/job/pact-verify-provider-gradle/job/master/buildWithParameters"
},
```
This successfully trigger the build and the build is set up to take the service name parameter. It's a dynamic replacement on `${pactbroker.providerName}` which is getting replaced however, it's not getting populated in the post body of the request to Jenkins... the same request works in Postman and when I use a POST request with a querystring (my work around)
james.hattersley-dyke
2019-10-21 15:55
`INFO: content-length: 31\n[2019-10-21T15:37:46Z] INFO: {\"SERVICE_NAME\":\"user-insight\"}\n`
bethskurrie
2019-10-22 01:06
I've just put out a new release of the Pact Broker and the docker images with a MASSIVELY OPTIMIZED matrix query for the can-i-deploy tool (like, we're talking 50 seconds down to 0.7 seconds). Lesson learnt - start with the rows you're interested and build up the dataset from that base, rather than building up the entire dataset and then finding the rows you're interested in.
bethskurrie
2019-10-22 02:43
Ok, it sounds like you need some features that are coming out as soon as I have time to finish them.
bethskurrie
2019-10-22 02:46
For some reason I've half written 2 posts on this http://blog.pact.io/p/51906e22-ccce-486b-9993-c21794e557d4/
bethskurrie
2019-10-22 02:47
The other option is to query the matrix resource to find out what you want.
bethskurrie
2019-10-22 02:50
you can use the can-i-deploy CLI with the JSON output to find out which pacts are missing verification results
bethskurrie
2019-10-22 02:54
```
export PACT_BROKER_BASE_URL="https://test.pact.dius.com.au"
export PACT_BROKER_USERNAME="dXfltyFMgNOFZAxr8io9wJ37iUpY42M"
export PACT_BROKER_PASSWORD="O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1"
docker run --rm \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_USERNAME \
-e PACT_BROKER_PASSWORD \
pactfoundation/pact-cli:latest \
broker can-i-deploy \
--pacticipant Foo \
--latest master \
--pacticipant Bar \
--latest master \
--output json
```
bethskurrie
2019-10-22 02:55
It asks "is there a valid verification result between latest latest master version of Foo and the latest master version of Bar"
me_pact
2019-10-22 09:49
Thanks for the input Beth! For the time being, I believe I will switch to using the git hash from the latest commit on the GitHub PR as a consumer version, and use the HTTP version of `can-i-deploy`. If this works, I'll keep it and periodically do version clean up, as I can imagine that there will be quite a lot of versions created over the time.
bethskurrie
2019-10-22 09:50
Grab the very latest copy of the broker. It has some serious optimisation to help with the large amount of data.
antonello
2019-10-23 08:23
Hi @bethskurrie? I may have lost track of its progress. What?s the status of the pending pacts feature? Is there now any official documentation beyond the original blog post?
bethskurrie
2019-10-23 09:58
I've got it released in the Ruby, but feature toggled off until Ron has made sure he can implement it in Java the way I've designed it.
bethskurrie
2019-10-23 09:59
If you're using one of the languages that wraps the Ruby standalone, you can try it, but it may change.
antonello
2019-10-23 10:17
consumers are a mix - some Java, some JS, some iOS (which would be the only one that wraps ruby standalone)
antonello
2019-10-23 10:17
I saw you renamed pending pacts to pacts for verification in the latest release
stevi.deter
2019-10-23 16:37
Hi, all. I just did a demo of Pact to my org yesterday and there's a lot of interest. We're leaning towards hosting our own, which leads to questions about the ops side of it. Specifically, are there any recommendations/details on best practices for ops for the database (we'll use Postgres). Expected size and rate of grown, memory needs, compaction, log rotation needs.
matt.fellows
2019-10-23 21:33
Not really, the pact broker github has the minimum requirements but as you say, you?ll need to figure all of those things out (Postgres is the right choice, btw!)
matt.fellows
2019-10-23 21:34
All of those factors really depend on how many projects and builds you have, and how important history is etc. etc.
bethskurrie
2019-10-23 21:37
Yes, theres's now a single endpoint to retrieve the list of pacts to verify in one go, rather than making a separate call for each tag.
bethskurrie
2019-10-23 21:39
You tell the endpoint what consumer version tags you want to verify and what provider version tag you're going to tag the results with, and it works out which pacts are "pending" for that provider tag (ie. which should run without breaking the provider build because they've never been successfully verified before).
bethskurrie
2019-10-23 21:44
I haven't yet added in the "WIP" pacts in to that response yet, but it won't be much work. (The "wip pacts" is the feature that automatically brings in the recently changed pacts to verify in pending mode so that the provider team doesn't have to change the list of tags they verify).
bethskurrie
2019-10-25 23:46
New release of the pact broker + docker containers with a fix for a bug that was introduced with the latest matrix optimisations. 2.40.0-1.
adrian.mace
2019-10-30 01:13
Hi all, do you foresee any issues upgrading pact-broker from `2.35.0-1` straight to `2.40.0-1` deployed using the `dius/pact-broker` docker image?
lwillmeth
2019-10-30 18:57
Can the Pactflow broker begin Provider verification if someone queries can-i-deploy for an unresolved version?
Or is it left to the human to check and start that process?
lwillmeth
2019-10-31 21:19
The best practices page talks about this a bit, suggesting using CI and webhooks to validate changing contracts:
https://docs.pact.io/best_practices/pact_nirvana#d-configure-pact-to-be-verified-when-contract-changes
The can-i-deploy wiki talks about true/false results. It sounds like it may not distinguish between a false result and no result?
bethskurrie
2019-11-01 03:40
@lwillmeth if you use --output json you can get the underlying JSON response. In it you can tell if there is no result (because the verificationResult is null) or a failed result (because verificationResult is present and has a success of false).
bethskurrie
2019-11-01 03:41
The more recent versions of the Pact Broker should give you some very clear text describing whether the result is missing or failed also.
bethskurrie
2019-11-01 03:42
> Can the Pactflow broker begin Provider verification if someone queries can-i-deploy for an unresolved version?
Can you explain your usecase?
yosevuk
2019-11-01 16:07
Hello! I was just wondering, is there a way to few the Pact file for a contract in a pact broker URL?
lwillmeth
2019-11-04 17:06
My understanding is that webhooks should trigger provider build tests when a consumer contract changes. This resolves all consumer contracts against the current provider version.
If we wanted to roll back the provider for whatever reason, we wouldn't know the outcome of the latest consumer vs an older provider, because the latest consumer didn't exist when the older provider built.
It seems like can-i-deploy would catch this scenario, and to fix it, we'd re-run the (older) provider build.
It sounds like this is an edge case that shouldn't be happening often, and a human could resolve if it does.
bethskurrie
2019-11-04 19:48
Yes, that sounds right @lwillmeth. If you roll back, remember to remove the prod tag from the previously deployed version so that the "latest" prod version is accurate again.
yosevuk
2019-11-05 13:07
oh typo! I meant is there a way to view the generated pact file itself, but I see you can get to a history of test results when you "View Matrix"
thomas.scheuchzer2
2019-11-11 13:55
is this already fully implemented? http://blog.pact.io/p/d7c9601f-e2ca-4208-b1c0-f02eaf96c3c2/ I can see some stuff in the source-code but I can't find it in the HAL-browser
brentbarker9
2019-11-11 18:57
Hi! Does the pact-broker support v3 pacts?
I'm locked into using v2.24 because we use v3 pacts and the broker fails to load those with newer versions - granted I haven't tried upgrading since last year but instead I've been keeping an eye on https://github.com/pact-foundation/pact_broker/issues/241
bethskurrie
2019-11-11 21:35
@thomas.scheuchzer2 it's out in limited beta if you're using pact-js or pact-go. Talk to @matt.fellows about it if you're interested.
bethskurrie
2019-11-11 21:37
It's feature toggled off for now, as I don't want anyone relying on an API that will mostly likely have changes. We've already decided to make the GET into a POST as the query params are too complicated.
bethskurrie
2019-11-11 21:40
Can you post the redacted content of one of the pacts that causes the problems? I haven't been able to replicate it.
brentbarker9
2019-11-11 22:18
No problem! You do a ton! I'll get a pact put together that exposes this problem.
rafael.anachoreta
2019-11-13 15:59
hello! perhaps a silly question, but is there any implementation of the broker client that supports the `can-i-deploy` command that I can run programmatically with groovy?
Similar to what I can do atm with `pact-node`
I want to add a try/catch in the code to either trigger a new run on my provider or not depending on whether the pact has been verified (either resulting in SUCCESS or FAILURE) or is UNKNOWN
rafael.anachoreta
2019-11-13 15:59
alternatively, is there a better way to do what I?m trying? :thinking_face:
matt.fellows
2019-11-14 01:00
As Andras said, I?d just do something like this:
```
if [ $(pact-broker ...) = 0 ]; then
# exit 0
else
# do other thing
fi
```
bethskurrie
2019-11-14 06:07
@rafael.anachoreta The command line can-i-deploy tool uses a fairly complicated query to the /matrix endpoint. I've made a simpler endpoint specifically for the can-i-deploy usecase. The docs are in the HAL browser, but here is the source. https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/can-i-deploy.markdown
bethskurrie
2019-11-14 06:09
It currently only works with the simplest usecase of one application, a known version number and an environment tag.
bethskurrie
2019-11-14 06:11
Btw, what is your usecase for this? Most people use webhooks to trigger provider builds.
bart.schotten
2019-11-14 08:14
Am I correct that the pact broker does not offer a way to search/filter pacts based on some text in the content?
rafael.anachoreta
2019-11-14 08:42
Let me try to describe my use case in details.
We have all of our (internal) providers and consumers built and deployed within our internal Jenkins (i.e. not public). We also have our internal pact broker running in docker (`FROM dius/pact-broker:2.29.0-1`, but we could update it if necessary).
For all of our consumers and providers, we have a Jenkinsfile built with a scripted pipeline that we?ve built in groovy and that describes what is supposed to happen when a job is run (build, test, deployment, etc). I?m currently adding Pact runs to this pipeline library that we have.
My idea is to have all the consumers always publishing the pact when their build is run (no matter if feature branch) and then having the capability to request a re-run on their provider?s verification step if their published pact results in UNKNOWN. That?s when the can-i-deploy step would come into play. If unknown, then the consumer should be able to trigger a re-build on the provider?s job directly, except we don?t want that to re-trigger a deployment (for projects where we have CD), so I?m passing in a variable that will split our scripted pipeline - ?Should pact verification run?? PACT boolean. For that we need parameterized jobs, but that should also be fine since the default will remain as is.
So far I have three new steps that should be generic enough for them to work on all of our projects, regardless if they are using Java, Kotlin, JS etc:
`def publishPacts(String path, String tags = env.BRANCH_NAME, String consumerVersion = env.GIT_COMMIT, String mode = overwrite)`
`def canIDeployPact(String consumer, String provider, String providerBranch = "master", String version = env.GIT_COMMIT, Predicate predicate = { env -> true })`
`def publishPactVerificationResults(Closure step, Predicate predicate = { env -> env.PACT_VERIFICATION })`
The predicate passed in allows me to decide whether or not the step should be run, so it gives projects more customization options.
I?ve considered hooks but decided against it as they felt like a bit of overhead since in the end the goal would still be to re-trigger the job. By running them directly I also can wait until the run is finished instead of having to poll for an update on the version, for example (though there might be a hook to address this)
bethskurrie
2019-11-14 08:46
There's actually a "poll while waiting" feature on can-i-deploy if you want it.
rafael.anachoreta
2019-11-14 08:47
will do! :slightly_smiling_face: what would you suggest instead? because what I was having trouble with the hooks is that I couldn?t really pass the consumer info to the provider without parameterizing my Jenkins provider anyway
bethskurrie
2019-11-14 08:48
I woulnd't pass the consumer info, I would pass the pact URL to verify - but yes, that's requires a parameterised build. It's assumed that the verification build for the "pact changed" workflow would be parameterised.
rafael.anachoreta
2019-11-14 08:48
I?ve gone through the Pact Nirvana (thanks for that btw :pray:) and I thought I was using the standard flow, but apparently not
bethskurrie
2019-11-14 08:49
So, I need a diagram for this. I think someone did a good one, and I need to see if I can include it in the docs.
rafael.anachoreta
2019-11-14 08:51
hmmmm I see what you mean, that would make more sense, yes
> Having this as a separate job rather than bundling it in with the test or deploy jobs means that the reason for a ?failure? is obvious at a glance.
rafael.anachoreta
2019-11-14 15:34
quick update - it seems the `/can-i-deploy endpoint` is exactly what I need :slightly_smiling_face:
I?ve bumped our image to latest but sadly I haven?t been able to successfully use that endpoint :confused: might be related to me not having versioned my provider properly
will check the logs and continue tomorrow!
bethskurrie
2019-11-18 00:01
@bart.schotten not yet, but it's something that I've always intended to add. You're the first person to actually ask for it though.
bethskurrie
2019-11-18 00:02
Would you like to raise a feature request issue in https://github.com/pact-foundation/pact_broker ?
bethskurrie
2019-11-18 00:03
@rafael.anachoreta I have to admit, I just threw that endpoint out there to help someone out, and I haven't extensively tested it. What are you seeing?
bart.schotten
2019-11-18 07:05
Will do that :+1: It's funny how you only realize you need this when you have > 100 integrations.
rafael.anachoreta
2019-11-18 08:30
in a nutshell, it took me a while to realize I needed the tag of the *provider* there to be able to really use the endpoint. To be fair, the documentation you added does make that clear, it is just that I could never tell there were differences between provider and consumer tags
I?ve commented on #pact-jvm how currently that?s not intuitive at all, but hey it works once you have everything in place.
https://pact-foundation.slack.com/archives/C9UN99H24/p1573750562133500
bethskurrie
2019-11-19 03:01
@antonello sorry, I didn't see this. I can't remember now! But you'll want the next release I do because the pagination will stop your server falling over if someone views the "index with latest tags" page.
rbhati
2019-11-19 23:10
Hi #pact-broker , need some help please:
Steps:
1. Build fresh instance of pact-broker using docker-compose
2. Run consumer side test, pact.json pushed to pact-broker - version *consumer-1.0*
3. Run provider side test via pactman-verifier, thus result Passed & pushed to pact-broker with version *provider-1.0* [Please continue to read]
4. Intentionally I made change in consumer side test that must fails the test; So I run and pushed pact.json with new version *consumer-1.1* to pact-broker
5. Run provider test, pushed result to pact-broker, Result turned Red
6. Revert changes in consumer test, run test, and push result to pact-broker with version *consumer-1.2*
Now when I look into - Matrix, I see *consumer-1.2* is green with provider version *provider-1.0* :exploding_head:
I have not run any provider test after I got *consumer-1.2*, and there is no webhook setup. Then how come the result appear *Green*
Please help me understand this phenomenon of pact-broker
bethskurrie
2019-11-19 23:21
bethskurrie
2019-11-19 23:22
Your two application versions use the same pact content, and hence the same underlying pact version in the database. The verification is attached to the pact version.
bethskurrie
2019-11-19 23:23
If you publish a pact with the same contents as a previous one, it inherits all the same verifications.
bethskurrie
2019-11-19 23:42
This means that you don't need to do a verification cycle if you're publishing a pact with the same content as previously. You get instant feedback, and can deploy straight away.
matt.fellows
2019-11-20 04:55
As @bethskurrie says - magic! That is the secret sauce of the broker, and why it?s so powerful!
bethskurrie
2019-11-20 05:16
@rbhati and others. There is some pop up text for pre-verified pacts on the matrix page, but it's not obvious that there is anything to see unless you happen to hover over the cell. I'm making it more obvious. Trying to find an appropriate bootstrap icon for the pre-verified pacts. Currently the best on I can find is a clock. Can anyone suggest anything more applicable? https://getbootstrap.com/docs/3.3/components/
bethskurrie
2019-11-20 05:22
Not sure what is the most obvious to someone unfamiliar with the concept.
bethskurrie
2019-11-20 05:23
`"This pact was "pre-verified" as it has identical content to a previously verified pact."`
bethskurrie
2019-11-20 05:23
`"This verification has been inherited from a previously verified pact with identical content."`
kevin.meiresonne
2019-11-21 09:38
I think I prefer
"This pact was pre-verified as it has identical content to ~a~ _the_ previously verified pact."
bethskurrie
2019-11-21 20:45
@kevin.meiresonne it is technically "a" because it doesn't have to be the most recent pact content for it to be pre-verified.
bethskurrie
2019-11-22 08:04
To be very accurate, it's not even that there is a pre-verification action, it's just that the new pact publication object references the existing pact version object (which has the content), which already has the verification results attached to it.
kv
2019-12-02 14:52
Hey hello, I was wondering if anyone have some experience with setting up a GitLab pipeline with pact and pact broker? I have a postgres container running on an AWS EC2 instance, and need to link that to the pact container I spin up in the test phase of my pipeline, but I'm having some issues doing so... Please pm :slightly_smiling_face:
bethskurrie
2019-12-02 20:52
@kv i'm confused as to what your issue is. Are you talking about starting and stopping the Pact Broker during your test? Or are you talking about one of the pact-cli docker containers?
kv
2019-12-03 11:43
@bethskurrie Saw that my msg was a bit cryptic maybe, didn't take into consideration the time difference so thought I could explain more in detail when I got in contact with someone yesterday :slightly_smiling_face:
I have followed the documentation to set up the pact broker locally. It works to run the docker commands provided, spin up a postgres container and I can get the verification to work between 2 services. :the_horns: The problem I'm facing now though is to publish the pact from the consumer tests pipeline on GitLab. I have an EC2 instance where I'm running the postgres container, and in my pipeline, I have a step that looks like this:
```contract-test:consumer:
services:
- name: pactfoundation/pact-broker:latest
command: ["--link", "my-pact-postgres:postgres", "-p", "9292:9292"]
alias: pact-broker
stage: contract-test-consumer
image: my-registry/pact-node-ruby
script:
- yarn add jest
- yarn contract:test
- yarn contract:publish
except:
variables:
- $DISABLE_CONTRACT_TESTING_CONSUMER```
`publish.js`:
```let publisher = require("@pact-foundation/pact-node")
let path = require("path")
let opts = {
pactFilesOrDirs: [path.resolve(process.cwd(), "pacts")],
pactBroker: "http://pact-broker:9292",
consumerVersion: "2.0.0"
}
publisher.publishPacts(opts).then(() => done())```
It could be that the error is due to the gitlab part, but since I haven't used gitlab nor pact extensively, I'm not sure. The error I get in the pipeline is this:
```$ yarn contract:publish
yarn run v1.19.1
$ node ./publish.js
[2019-12-03T11:18:55.511Z] INFO: pact-node@10.0.1/130 on runner-Kd24fm4z-project-8-concurrent-0: Publishing Pacts to Broker
[2019-12-03T11:18:55.513Z] INFO: pact-node@10.0.1/130 on runner-Kd24fm4z-project-8-concurrent-0: Publishing pacts to broker at: http://pact-broker:9292
[2019-12-03T11:19:06.422Z] WARN: pact-node@10.0.1/130 on runner-Kd24fm4z-project-8-concurrent-0: Pact exited with code 1.
[2019-12-03T11:19:06.423Z] ERROR: pact-node@10.0.1/130 on runner-Kd24fm4z-project-8-concurrent-0:
Could not publish pact:
/builds/services/api-gateway/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.70.2/lib/ruby/lib/ruby/gems/2.2.0/gems/bundler-1.9.9/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /builds/services/api-gateway in PATH, mode 040777
Error making request - Errno::EBUSY Device or resource busy - getaddrinfo /builds/services/api-gateway/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.70.2/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.20.0/lib/pact_broker/client/pacts.rb:35:in `get', attempt 1 of 3
Error making request - Errno::EBUSY Device or resource busy - getaddrinfo /builds/services/api-gateway/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.70.2/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.20.0/lib/pact_broker/client/pacts.rb:35:in `get', attempt 2 of 3
Error making request - Errno::EBUSY Device or resource busy - getaddrinfo /builds/services/api-gateway/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.70.2/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.20.0/lib/pact_broker/client/pacts.rb:35:in `get', attempt 3 of 3
Failed to publish API Gateway/Role Service pact due to error: Errno::EBUSY - Device or resource busy - getaddrinfo
One or more pacts failed to be published```
Maybe this is not related to pact, sorry if so. But maybe someone ran in to a similar issue before.. :face_with_rolling_eyes:
idamasce
2019-12-04 13:50
Hello everyone, has anyone gone through problems with bundler while trying to use the pack broker on openshift container platform?
bethskurrie
2019-12-04 20:13
Are you following this example? https://github.com/jaimeniswonger/pact-broker-openshift
idamasce
2019-12-05 13:38
Hey @bethskurrie! Yes I was following this example. For some reason the bundler was not being recognised inside the pod on Openshift. However I have found out another openshift template that solved my problem. Thanks for your response anyways!
samuel.hodgkinson
2019-12-06 14:19
Has anyone tried adding token auth in front of the open source broker?
justaburneremailforso
2019-12-06 16:22
I am trying to run and publish the provider side results on our broker which has authentication turned on. I am passing in credentials using the example in the link below but it is not working. These variables are replaced at runtime in our CI tool.
The error I get is au.com.dius.pact.pactbroker.RequestFailedException: Request to path '/' failed with the response 'HTTP/1.1 400 Bad Request'.
I am using mvn clean test to run the provider side tests and have pact.verifier.publishresults value set to true in the maven surefire plugin in my pom.
The broker is not getting updated with any results, the LastVerified section is blank, it doesn't even show up as failed.
I'm assuming the http error above is the issue but I don't know why it's happening. Anyone else seen this?
https://github.com/DiUS/pact-jvm/tree/master/provider/pact-jvm-provider-junit#using-authentication-with-the-with-the-pact-broker
bethskurrie
2019-12-09 00:14
Hi @justaburneremailforso can you provide a gist with the code you're using?
bethskurrie
2019-12-09 00:15
Better yet, running code to demon the issue. 400 is interesting. It means something is wrong with the request, not necessarily auth
bethskurrie
2019-12-09 00:16
@idamasce if there are changes that need to be made to that template, future openshift users would appreciate a PR I'm sure!
justaburneremailforso
2019-12-09 09:38
Hello, unfortunately for disclosure reasons I can't post any code. We haven't had this issue when running with a broker that has auth switched off however we want to use authentication which is why it's on.
When you say set the prover version number, where is that set? In our junit class we have the @PactBroker annotation and specify the host, port etc as well as adding the relevant section to our pom file. Our junit class also uses the @Provider annotation where we add in the correct provider name.
bethskurrie
2019-12-09 09:44
Sorry, I can't remove the preview from my phone client. It's very annoying.
bethskurrie
2019-12-09 09:44
"You need to set the version of the provider that is verified using the pact.provider.version system property."
justaburneremailforso
2019-12-09 16:26
Yeah it's a strange error. I pointed the same code to a different broker that doesn't have auth switched on and mvn clean test and it runs and updates the broker last verified status. Three only change on my side is the broker details. Perhaps it's some sort of config difference.
bethskurrie
2019-12-10 09:06
I'm pretty sure there's a way to print out the request and response. Why the response body isn't printed out is strange.
bethskurrie
2019-12-10 09:07
I'm sure Ron would appreciate a PR if you have a few minutes to find the point of the error.
justaburneremailforso
2019-12-10 09:08
I will check it today to see if I can debug and get more info. I will also check with our team who looks after the broker to see if there is some config difference between the two (other than auth).
bethskurrie
2019-12-10 09:10
Can you make sure you're using the latest Pact JVM version, and the latest broker if possible?
bethskurrie
2019-12-10 09:11
You can get the pact broker version from the response headers in the Hal browser.
justaburneremailforso
2019-12-10 09:16
I have a few pact dependencies in my pom for the provider side but not sure if I need them all.
justaburneremailforso
2019-12-10 09:18
I have pact-jvm-provider-spring_2.12 version 3.6.7
Pact-jvm-model 3.6.7
Pact-jvm-provider-junit_2.11 version 3.5.0
justaburneremailforso
2019-12-10 11:56
Just an FYI, got this working. Posted the following in the pact-jvm as a response.
"Got this resolved. We needed to set the scheme as Https and the full hostname in the @PactBroker annotation section of the junit class. Previously we were using a shortened hostname and not setting the scheme as anything. We are still using the @PactBrokerAuth authentication piece."
bethskurrie
2019-12-16 02:55
sorry for the channel at-ing, but I'd like to grab the attention of anyone who has talked to me about automating webhook creation in a build pipeline. @james.hattersley-dyke I think you were one of them. Can you add your usecases here? https://github.com/pact-foundation/pact_broker-client/issues/54
bheemreddy181
2019-12-16 03:18
This is great start @bethskurrie@bethskurrie@bethskurrie I will put in some use cases
bethskurrie
2019-12-16 08:48
That question doesn't really make sense @mui_ume. But I'm going to say, "yes"!
mui_ume
2019-12-16 08:51
The next question is how do I publish the pact file to the docker container ?
mui_ume
2019-12-16 08:52
If not how can I setup my pact broker easily ?
I need to publish my pact file
bethskurrie
2019-12-16 08:55
If you're not sure how to use docker, you can sign up for a free hosted Pact Broker at http://pactflow.io
bethskurrie
2019-12-16 08:56
You'll need to look at the documentation for the language you're using. There will be a section on publishing and verifying pacts from a broker.
mui_ume
2019-12-16 09:18
I have signed up at pactflow
How can I setup ?
My consumer is using Javascript
mui_ume
2019-12-16 09:24
I should be something like this
"publish:pact": "pact-broker publish ./pacts -a 2.0.0 -b https://taiger.pact.dius.com.au/",
mui_ume
2019-12-16 09:28
Do you have an example to show
What the package.json look like and the pactSetup.js ?
mui_ume
2019-12-16 09:50
something like this ?
"publish:pact": "pact-broker publish ./pacts -a 2.0.0 -b https://taiger.pact.dius.com.au/",
bethskurrie
2019-12-16 09:50
mui_ume
2019-12-16 09:56
Still didn?t work
Here is the content of my pactSetup.js
```// ./pact/setup.js
// To configure the Pact mock provider
const path = require('path');
const { Pact } = require('@pact-foundation/pact');
global.port = 8081
global.host = '127.0.0.1';
global.Platform = new Pact({
cors: true,
port: global.port,
log: path.resolve(process.cwd(), 'logs', 'pact.log'),
loglevel: 'debug',
dir: path.resolve(process.cwd(), 'pacts'),
spec: 2,
pactfileWriteMode: 'update',
consumer: 'iconverse frontend',
provider: 'iconverse backend',
host: global.host,
pactBroker: 'https://myco.pact.dius.com.au/',
pactBrokerToken: 'xxxx'
});```
bethskurrie
2019-12-16 10:01
I don't think you can put the broker options into the mock service configuration
bethskurrie
2019-12-16 10:03
It's very hard to help someone who is not a developer learn how to code via chat.
bethskurrie
2019-12-16 10:04
If you can't follow them, I don't think I can help you any more than that.
mui_ume
2019-12-16 10:16
I will try to figure out later
The example show pactbrokerUsername
This is the login name to http://pactflow.io ?
dannybrown2710
2019-12-16 10:42
@channel can we use the pact mock server initiated in consumer for actually mocking API for UI functionality? Can we actually hit the server and get the response which already has interactions added to it? Or is it just for testing interactions against test cases?
matt.fellows
2019-12-16 10:43
do you mean something like this: https://docs.pact.io/getting_started/stubs ?
matt.fellows
2019-12-16 10:51
@mui_ume see the publishing documentation at https://github.com/pact-foundation/pact-node/#pact-broker-publishing
matt.fellows
2019-12-16 10:53
you need to specify the `pactBrokerToken` property, which you can get from the API tokens screen (note it must be a read/write token)
rbhati
2019-12-16 22:41
hi there: qq: every time i run
`$ pact-broker can-i-deploy --participant "consumer_app" --version "ba433a1" --participant "provider_abc" --version "1.2" --broker-base-url https://pact-broker.myoffice.com/`
I get
`No value provided for required options '--pacticipant'`
Not sure, the cause of error; did tried `--broker-base-url https://username:/`
but still no luck
bethskurrie
2019-12-16 22:43
When I wrote this software 6 years ago, I had no idea it would be this widely used, and it was just a little pun "a participant in a pact" => "pacticipant".
bethskurrie
2019-12-16 22:43
If/when I make version 2 of the API, it will just be called "application". That's why the short option is `-a`.
bethskurrie
2019-12-16 22:45
if an application is both consumer and provider, you're not deploying it just in its consumer role, you're also deploying it in its provider role.
dannybrown2710
2019-12-17 07:26
Alright, so the mock server that starts to run these tests cannot be used, but another stub server can be used. I was enquiring about that, but never mind , it anyhow solves the purpose
bethskurrie
2019-12-20 19:13
Running it locally requires a fair bit of expertise. You'd at least need to know how to use docker.
bethskurrie
2019-12-20 19:13
I'd recommend you stick with the hosted one, given you're not an experienced developer.
mui_ume
2019-12-23 06:22
Could someone explain why I?m getting this ?
Could not publish pact:
Failed to publish Consumer/Provider pact due to error: PactBroker::Client::Error - This is the first time a pact has been published for "Consumer".
The name "Consumer" is very similar to the following existing consumers/providers:
* consumer
If you meant to specify one of the above names, please correct the pact configuration, and re-publish the pact.
If the pact is intended to be for a new consumer or provider, please manually create "Consumer" using the following command, and then re-publish the pact:
$ curl -v -XPOST -H "Content-Type: application/json" -d "{\"name\": \"Consumer\"}" https://taiger.pact.dius.com.au/pacticipants
If the pact broker requires basic authentication, add '-u <username:password>' to the command.
To disable this check, set `check_for_potential_duplicate_pacticipant_names` to false in the configuration.
This is the first time a pact has been published for "Provider".
The name "Provider" is very similar to the following existing consumers/providers:
* provider
If you meant to specify one of the above names, please correct the pact configuration, and re-publish the pact.
If the pact is intended to be for a new consumer or provider, please manually create "Provider" using the following command, and then re-publish the pact:
$ curl -v -XPOST -H "Content-Type: application/json" -d "{\"name\": \"Provider\"}" https://taiger.pact.dius.com.au/pacticipants
If the pact broker requires basic authentication, add '-u <username:password>' to the command.
To disable this check, set `check_for_potential_duplicate_pacticipant_names` to false in the configuration.
One or more pacts failed to be published
mui_ume
2019-12-23 06:39
Here is my publish.js-
let publisher = require("@pact-foundation/pact-node")
let path = require("path")
let opts = {
providerBaseUrl: "http://localhost:8082",
pactFilesOrDirs: [path.resolve(process.cwd(), "pacts")],
pactBroker: "https://taiger.pact.dius.com.au/",
pactBrokerToken: process.env.PACT_TOKEN,
consumerVersion: "2.0.0",
}
publisher.publishPacts(opts)
mui_ume
2019-12-23 06:42
Could not publish pact:
Failed to publish Consumer/Provider pact due to error: PactBroker::Client::Error - This is the first time a pact has been published for "Consumer".
The name "Consumer" is very similar to the following existing consumers/providers:
* consumer
matt.fellows
2019-12-23 07:07
You're publishing another very similar consumer and by default the pact broker will reject it to prevent confusion
bethskurrie
2019-12-23 07:35
There should be a second line to that message that says how to force create the consumer with the name you want. Is it there?
mui_ume
2019-12-23 07:40
The name "Consumer" is very similar to the following existing consumers/providers:
* consumer
If you meant to specify one of the above names, please correct the pact configuration, and re-publish the pact.
If the pact is intended to be for a new consumer or provider, please manually create "Consumer" using the following command, and then re-publish the pact:
$ curl -v -XPOST -H "Content-Type: application/json" -d "{\"name\": \"Consumer\"}" https://taiger.pact.dius.com.au/pacticipants
If the pact broker requires basic authentication, add '-u <username:password>' to the command.
To disable this check, set `check_for_potential_duplicate_pacticipant_names` to false in the configuration.
mui_ume
2019-12-23 07:42
I set this line at publishPact.js -
check_for_potential_duplicate_pacticipant_names: "false",
bethskurrie
2019-12-23 07:43
`check_for_potential_duplicate_pacticipant_names` is a setting in the Pact Broker - it's not something you set in the client javascript.
bethskurrie
2019-12-24 10:42
Just happened to be here! It doesn't mean someone else hasn't made their own, but there's no officially supported version.
marco
2019-12-24 10:44
This distro is unfortunately a constraint for the project I'm working on :disappointed:
bethskurrie
2019-12-24 10:45
It shouldn't be too tricky to roll your own based on the pactfoundation/pact-broker one
bethskurrie
2019-12-24 10:46
If you get it working, I don't mind adding it to the officially supported versions.
marco
2019-12-24 10:52
I'll try rolling my own! :slightly_smiling_face: I really would like to use Pactflow but that has to be OKed which is going to take some time..
bethskurrie
2019-12-24 19:32
So, you're going to need Ruby, obviously, but also the postgres client lib.
agarwalatrisha1212
2019-12-26 18:27
Hi All, i have sign up for pact and i havent received the password to login and access the broker, I will appreciate the help
agarwalatrisha1212
2019-12-26 18:29
usually people receive two email as my friend @mui_ume shared while sharing her experience setting up pact for the project but i dont receive two email with pacts
bethskurrie
2019-12-26 22:12
If you can't find it, we can do a manual reset for you. Please send an email to
bethskurrie
2019-12-26 22:20
We've had a few people recently not receive the email. We might have to take it up with AWS.
agarwalatrisha1212
2019-12-26 22:22
Thank you , I assumed it because of holidays and not much people are actively working and that why i have pinged here too.
mui_ume
2019-12-28 03:39
May I know where I can set check_for_potential_duplicate_pacticipants_names? Thank
bethskurrie
2019-12-28 05:21
If you're hosting your own, it's here: https://github.com/pact-foundation/pact_broker/wiki/Configuration#checking-for-potential-duplicate-pacticipant-names
mui_ume
2019-12-28 05:21
If I need to run CI server
This pact broker hosted on pactflow is good ?
Can I have the option to use pact broker docker for Ci server ?
bethskurrie
2019-12-28 05:23
You can use the hosted service (pactflow) or run your own, but I'd recommend that you get your ops department to help you run it if you choose to run your own. It's something that requires experience to operate.
mui_ume
2019-12-28 05:23
Thanks this can be done later
But now I?m trying to work on the provider side
bethskurrie
2019-12-28 05:23
The warning is not something you want to turn off - it's to stop you getting bad data in your broker.
bethskurrie
2019-12-28 05:24
If you have Consumer and consumer they are NOT the same thing, and you will have a lot of confusion.
mui_ume
2019-12-28 06:55
When I run my pact provider in js
I noticed the result at the pact broker hosted on pactflow Keep flickering
There are some error in the terminal from where I run the provider command
bethskurrie
2019-12-28 07:21
Can you please read this Lay? https://coderanch.com/wiki/660111/Doesnt-Work-Useless
mui_ume
2019-12-28 08:32
This occurred when i was trying to run the provider to verify the pact file
It?s written in JS
I will post to pact-js channel
bethskurrie
2020-01-06 00:29
Hey peeps. There was a vulnerability found in Rack (https://github.com/advisories/GHSA-hrqr-hxpp-chr3) It does not affect the Pact Broker as it doesn't use sessions, but if your vulnerability scanner is going off, you can upgrade to the latest gem/docker image and it will have the fixed Rack gem in it.
pavel.azarau
2020-01-06 21:44
Hey guys. Does anybody know if the list of Pactflow IP addresses provided here https://pactflow.io/faq/ is up to date?
bethskurrie
2020-01-09 22:57
Hey guys. If you're using tags when you specify which pacts you want to verify, do you ever have some consumers which use tags, and others which just use the latest pact?
justaburneremailforso
2020-01-13 21:16
Once you have added a tag to a pact using the create version tag tool, is there a way to change or remove the tag without deleting the entire consumer and provider from the broker?
bethskurrie
2020-01-13 21:16
There's no cli for it, but just send a DELETE to `/pacticipants/PACTICIPANT/versions/VERSION/tags/TAG`
matt.fellows
2020-01-13 21:18
If you want to automate it in a CI pipeline though you?ll need to find a way without mouse clicks of course
bethskurrie
2020-01-13 21:19
Click on the NON-GET button next to the "self" relation, and send a DELETE request ot it.
justaburneremailforso
2020-01-13 21:20
Might be a nice feature to add to the broker UI, like a click and edit or delete function of some sort.
s1apped
2020-01-14 14:01
Hi. After publishing contract to pact-broker I'm seeing below message
```Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.```
and
`Could not parse the following content to a Pact due to TypeError no implicit conversion of String into Integer, showing raw content instead`
When I try to run provider verification it fails with below but when I run locally using @PactFolder everything works.
```http://au.com.dius.pact.provider.junit.MissingStateChangeMethod```
Do you have any idea what might the issue?
s1apped
2020-01-14 18:20
Looks like broker has some issues with regex / matchPath
```return builder
.given("This is valid regex")
.uponReceiving("Some test request")
.matchPath("/test/1/regex/(this|that)")
.method("GET")
.willRespondWith()
.status(200)
.toPact();```
Above will cause issues for broker.
When I replace matchPath with path it will work
```.path("/test/1/regex/this")```
bethskurrie
2020-01-14 19:40
@s1apped yeah, the display of v3 pacts is not working. Someone was going to find me an example so I could fix it, but they never got around to it. If you could PM me a redacted copy of yours, I'll fix it.
bethskurrie
2020-01-14 19:41
That has nothing to do with why it would pass locally and not from the broker though. It's just a display issue - the API works fine.
bethskurrie
2020-01-14 19:42
If you're able to make a github project to demonstrate the issue someone in pact-jvm might be able to help.
igalbenardete
2020-01-15 08:16
I had the same issue while I was generating Pact Files with the SBT plugin. The problem is that the generated JSON file does not have the following block:
``` "metadata": {
"pactSpecification": {
"version": "4.0.0"
}```
Then I?ve added this manually and pushed it to the broker and it started parsing the JSON properly
simone.cusimano92
2020-01-15 08:25
Hi all,
I'm looking for the Pact Broker on Docker Hub, but I'm getting a 404. Has it been moved?
https://hub.docker.com/r/pactfoundation/pact-broker/
matt.fellows
2020-01-15 09:55
It?s linked to from https://github.com/pact-foundation/pact-broker-docker
bethskurrie
2020-01-15 09:57
The other day I was searching for an image, and it returned nothing until I'd logged in. I'm not sure why it shoes a search bar if you can't get results without logging in :man-shrugging:
simone.cusimano92
2020-01-15 10:37
Thank you guys! I log in and find it.
It doesn't make sense to me either, but I take note of it :slightly_smiling_face:
adrian.mace
2020-01-21 03:35
Just looking to schedule in some maintenance on the Amazon RDS instance backing our pact-broker installation and looking for advice. This maintenance requires a reboot of the RDS instance to rotate the TLS CA certificate. The reboot is approximately 1 minute.
Will pact-broker throw a fit or gracefully reconnect once the database reboots? Cheers :slightly_smiling_face:
bethskurrie
2020-01-21 03:42
Funnily enough, we've just been doing the CA updates ourselves today on some other systems.
bethskurrie
2020-01-21 03:43
I do not know the answer to that question. Let me try on my local machine and see what happens.
bethskurrie
2020-01-21 03:43
Which docker image are you using @adrian.mace? dius/pact-broker or pact-foundation/pact-broker?
bethskurrie
2020-01-21 03:44
Ok, so that's running Passenger. To my knowledge, it will just respawn new threads until the db comes up again.
matt.fellows
2020-01-21 03:45
obviously, take a backup of the RDS instance before you do this :stuck_out_tongue:
matt.fellows
2020-01-21 03:45
Just looking through our code commits for Pactflow to see if we?ve done anything specific for this change
bethskurrie
2020-01-21 03:45
I'm not actually sure if the passenger image will have the new CA certs however :thinking_face:
bethskurrie
2020-01-21 03:46
So, you can test the restart using this docker compose file https://github.com/DiUS/pact-broker-docker-private/blob/master/docker-compose.yml
adrian.mace
2020-01-21 03:49
as far as I can tell, pact broker does not automatically connect over TLS? defaults to regular unencrypted connection?
bethskurrie
2020-01-21 03:51
Yes. I remember something about this. I didn't want to change the defaults in a way that would break existing deployments.
bethskurrie
2020-01-21 03:53
So, the pact-foundation/pact-broker image has support for
```PACT_BROKER_DATABASE_SSLMODE```
adrian.mace
2020-01-21 03:55
the docker-compose file you linked gave us the confidence to run with it - looks like it should just handle it fine :slightly_smiling_face:
adrian.mace
2020-01-21 03:55
that's good to know, as long as it's not _currently_ using TLS I'm confident to upgrade the CA
bethskurrie
2020-01-21 03:55
We're just having an internal conversation about whether or not the docker image has the updated CA cert or not though. Ours "just worked" TM, but we're not sure how!
adrian.mace
2020-01-21 03:57
not sure how it's configured to connect when specifying SSLMODE but you won't have issues unless it's a) connecting via TLS and b) also performing strict CA verifications
adrian.mace
2020-01-21 03:57
you can connect to a database via TLS without verifying the CA - it's the same as connecting to a website with a self-signed certificate
kong
2020-01-21 03:59
When connecting to an RDS instance, AWS will automatically default to a non SSL mode connection if
a) force_ssl is not on with RDS Parameter
b) SSL mode is not specified in the client connecting in
kong
2020-01-21 03:59
It is always advisable to set `force_ssl` on RDS to on to force client SSL connections.
bethskurrie
2020-01-21 04:02
I've gone through postgres and pg gems, and they don't set a default sslmode. From https://ankane.org/postgres-sslmode-explained it seems the default is "prefer"
bethskurrie
2020-01-21 04:03
Ok, it's taken us a while, but we're on the same page as you now @adrian.mace
kong
2020-01-21 04:12
ah, right. I forgot `verify-full` is not a default in SSL connections :facepalm:
matt.fellows
2020-01-21 04:17
For posterity, the latest `dius/pact-broker` image that I can pull via the docker registry has all of the latest AWS CA?s in the trust store
sliu7
2020-01-21 04:21
Hey guys.
I've been trying out some of the PactBroker webhooks and was trying to trigger a slack webhook when provider verification fails. When I test out the webhook using the execute endpoint, it works. But it doesn't seem to get triggered when the provider verification is failing in the CI pipeline. For the verification result, the 'Webhooks triggered by the publication of this verification result' is empty. Not sure if I'm missing some other config?
Webhook configured:
```{
"description": "POST http://hooks.slack.com",
"consumer": {
"name": "TestConsumer"
},
"provider": {
"name": "TestProvider"
},
"enabled": true,
"request": {
"method": "POST",
"url": "slackwebhookurl",
"headers": {
"Content-Type": "application/json"
},
"body": {
"text": "Test pact verification failed"
}
},
"events": [
{
"name": "provider_verification_failed"
}
],
"createdAt": "2020-01-20T23:53:23+00:00"
}```
sliu7
2020-01-21 04:23
yup. Just checking.. the image version we're running is pactfoundation/pact-broker:2.37.0-1
bethskurrie
2020-01-21 04:26
The logs go to stdout, and the container manager will send them somewhere.
s1apped
2020-01-21 13:56
Hi. do you have some examples (pipelines) how to properly setup CI with feature branches and Pact Broker?
bethskurrie
2020-01-22 21:55
@s1apped not a fully sophisticated one, but there is a simple demo. Let me find it.
s1apped
2020-01-23 11:54
Hi. I have some problem with can-i-deploy --retry-while-unknown. Pact Publish triggers verification job via webhook but can-i-deploy doesn't wait for verification to be completed. Please see below:
```sh "docker run --rm pactfoundation/pact-cli:latest broker can-i-deploy --retry-while-unknown=10 --retry-interval=30 -b http://10.0.0.0 -a ${env.SERVICE_NAME} -e ${env.GIT_COMMIT}"```
```Computer says no ¯\_(?)_/¯
No pacts or verifications have been published for version ....```
Once verification job is completed contract is verified.. I'm using pact Broker 2.43.0-1. Any ideas? Thanks
antonello
2020-01-27 14:12
@bethskurrie When you have a chance, could you publish the docker images for v2.44, please? :slightly_smiling_face:
adrian.mace
2020-01-28 22:24
Hi, does this commit mean that a new field is required as of the recent version? or does it also come with a default value?
Would this affect consumers uploading pacts or producers downloading and running against them?
https://github.com/pact-foundation/pact_broker/commit/ebbbbec9
bethskurrie
2020-01-28 22:43
It's for a new api that's only being used in beta, and only currently enabled in http://pactflow.io so it won't affect general users @adrian.mace
bethskurrie
2020-01-28 22:44
Thanks for for reminding me though, I need to reverse that change now, as I'm adding support for "all pacts for a given tag" in the service.
adrian.mace
2020-01-28 23:12
ah fantastic! glad I could help lol so in terms of updating pact broker, should be no breaking changes then!
bethskurrie
2020-01-29 04:21
I will never make a breaking change to a publicly released endpoint unless it's a major version bump @adrian.mace.
bethskurrie
2020-01-30 00:17
@antonello grab 2.45.0-1 as there was a bug in the logic for can-i-deploy introduced when I added support for using multiple selectors with a `--to ENV`
bheemreddy181
2020-01-31 01:25
Hey Team , I am trying to run https://github.com/pact-foundation/pact-broker-docker/blob/master/script/test.sh on a linux machine having issues with Dockerfile, Can somee one help ?
bheemreddy181
2020-01-31 01:26
```bvennapureddy@pact_broker:~$ ./test.sh
Will build the pact broker
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/bvennapureddy/Dockerfile: no such file or directory```
bheemreddy181
2020-01-31 01:32
Well do i need to fork the repo ? i was in an assumption that i need to pull the docker image and then set the Env variables and then just run test.sh
bheemreddy181
2020-01-31 01:40
```postgres_1 | 2020-01-31 01:36:56.797 UTC [58] ERROR: relation "schema_migrations" does not exist at character 27
postgres_1 | 2020-01-31 01:36:56.797 UTC [58] STATEMENT: SELECT NULL AS "nil" FROM "schema_migrations" LIMIT 1
postgres_1 | 2020-01-31 01:36:56.807 UTC [58] ERROR: relation "schema_info" does not exist at character 27
postgres_1 | 2020-01-31 01:36:56.807 UTC [58] STATEMENT: SELECT NULL AS "nil" FROM "schema_info" LIMIT 1```
Do i need to worry about the above errors ?
bethskurrie
2020-01-31 01:41
Do you mind if I ask what you are your reasons for running your own broker @bheemreddy181?
bheemreddy181
2020-01-31 01:41
II recently gave a presentation and it was well-received they want me to bring these things up
bheemreddy181
2020-01-31 01:42
well they want to see the usage and then think about the paid version of it
matt.fellows
2020-01-31 01:42
If you want us to increase the limits on your free one to avoid you having to spend time setting up an on-prem one, let us know
bheemreddy181
2020-01-31 01:43
Once it is built into CICD pipeline migration will not be a problem i feel
matt.fellows
2020-01-31 01:43
possibly, webhook executions can sometimes present challenges. Also you don?t have secrets in the OSS one, so you would need to recreate all of those etc.
bheemreddy181
2020-01-31 01:44
sure but for now they don't want to talk to outside systems some kind of compliance stuff
bethskurrie
2020-01-31 01:44
strangely enough, we're just looking at building an on-prem version of Pactflow.
bheemreddy181
2020-01-31 01:46
It would be great if you people can start some good presentations on Async Systems
matt.fellows
2020-01-31 01:47
what tech specifically? I know you guys use Ruby, what async - e.g. websockets, kinesis, kafka? ?
bheemreddy181
2020-01-31 01:47
And Some presentations on how we can easily push this into Any CICD pipeline
matt.fellows
2020-01-31 01:50
In any case, we?ve recently put together a Kinesis workshop for Golang. It?s basically the same for Kafka, so that might be helpful
matt.fellows
2020-01-31 01:51
It?s the project that works along side https://github.com/pact-foundation/pact-workshop-go/
justaburneremailforso
2020-01-31 09:30
Hello, if I have a provider with multiple consumers, how do I run can I deploy on all the consumers? I have a sample set up and from the documentation it seems like I can just pass in multiple consumers like this "can-i-deploy -a consumer1 -l -a consumer2 -l -a consumer3 -l" etc. However if I run this, I get a message saying "there are no missing dependencies" and passed even though verification has failed on them all and it shows that on the broker. If I change the command to specify one consumer, it works as expected and fails saying verification has failed.
Is there a way to specify multiple consumers in one can-i-deploy command?
Thanks!
justaburneremailforso
2020-01-31 09:40
Ah ok. Is that why can I deploy passes if you pass in multiple consumers to the command?
justaburneremailforso
2020-01-31 09:43
Well I'm approaching it from a provider perspective. The provider wants to run can I deploy on all its consumers before the provider deploys
bethskurrie
2020-01-31 09:43
So, if you just list pacticipants with no "to" then it only looks at integrations that only have the applications you specified
bethskurrie
2020-01-31 09:44
Really, you need to use tags and just give it the provider name, but maybe you have some reason for doing it manually?
justaburneremailforso
2020-01-31 09:46
I'm still learning how to use it correctly/fully, sounds like I need to tweak my command and use tags
bethskurrie
2020-01-31 09:46
If you specify one consumer, it automatically calculates the dependencies. Because you're specifying multiple, you're in "manual mode".
bethskurrie
2020-01-31 10:22
Tagging with "prod" on deploy, and then using "can-i-deploy -- pacticipant Foo -- version 123 -- to prod" is the most common and easiest way to do it.
bethskurrie
2020-01-31 10:22
The broker knows what's in prod and calculates your dependencies for you.
matt.fellows
2020-01-31 22:23
Yeah, we have incremental build numbers so just pull the latest and you should be golden. Of course, always take a RB snapshot etc just in case
bethskurrie
2020-02-02 19:57
Typically you don't run docker compose in production @bheemreddy181. You'd use something like Fargate, or Kubernetes. The number were talking about is the tag. It looks like 2.46.0-1 for the Pact Broker.
matt.fellows
2020-02-02 22:43
(but of course you don?t, because nobody does - that?s why Mirantis bought them out?)
bheemreddy181
2020-02-03 03:07
Well smaller companies like us can?t still do a docker compose unless there is a need for it to scale ? @bethskurrie @matt.fellows
bethskurrie
2020-02-03 04:19
It's not so much about scale as I'm not sure that using docker compose is the right way to run a production system. For example, you don't want the database to disappear when you do docker-compose down. You want it to be monitored, and for it to come back up if the process goes down. You need to give it a proper hostname and SSL certificate and make sure it's deployed in a network that's accessible from CI systems... it's not just a matter of running 'docker-compose up' on a developer's machine somewhere.
matt.fellows
2020-02-03 10:52
haha no of course not. You can choose what you want, I just wouldn?t recommend it for a ?production grade? system.
matt.fellows
2020-02-03 10:52
(I was making a dig at Docker who, despite creating the technology, was unable to really capitalise on the commercial front)
bheemreddy181
2020-02-03 14:40
That makes complete sense, what I mean is just use docker compose but connect to remote host database . In which you will not have a database going down which is still accessible
bheemreddy181
2020-02-03 14:45
Quick question : when ever we run contract tests form either side ( consumer or provider ) the idea is to run can-I-deploy separately as a different job rather than hooking it with contract generation , publishing and running provider job on consumer / pulling contracts , verifying contracts and provider
simone.cusimano92
2020-02-03 16:01
Hi all,
why is the v2.47.1 pactbroker's docker image not yet on the Docker Hub?
bethskurrie
2020-02-03 20:48
I'll put it out today @simone.cusimano92. There's only a very small bug fix that's unlikely to affect you.
bethskurrie
2020-02-03 20:49
@bheemreddy181 there's a example set up here https://github.com/pact-foundation/pact_broker/wiki/Webhooks#consumer-ci
bethskurrie
2020-02-03 20:50
The pact tests generally run after the unit tests, and before deploying. Can I deploy runs before deploying.
bheemreddy181
2020-02-03 20:52
We want this before merge post merge we want to deploy , we want the feedback loop faster
bethskurrie
2020-02-03 22:32
> we want the feedback loop faster
You can publish your pact statuses to github and make them a requirement for merging http://blog.pact.io/2018/07/16/publishing-pact-verification-statuses-to-github/
bethskurrie
2020-02-03 22:32
If you do this, make sure you upgrade to the very latest docker image, as I've just released a bug fix related to this.
bheemreddy181
2020-02-03 23:00
@matt.fellows my actual question was more like I want the trigger point to be part of of GitHub Pull request for the contracts tests to run along with your unit tests + functional test + anything else lets take an example 1. From consumers perspective- consumer uploads a contracts as part of new pull request then which triggers a job on provider to pull the contract and verify it all this is initiated by one job which is part of Travis or Circle CI
bheemreddy181
2020-02-03 23:02
Now do I have another job on github as part of my Travis or Jenkins run which will just run can-I-deploy which is inter-dependent on the above run and it?s typically waiting because of jobs triggered parallel
bethskurrie
2020-02-03 23:03
maybe it would make sense if you drew us a diagram, and then explained where the problem was.
matt.fellows
2020-02-03 23:11
If the feedback loop is what you?re after, `can-i-deploy` should be run on all builds - branches included. This way, you have the feedback prior to merge. As Beth mentioned, you can hookup github statuses also
matt.fellows
2020-02-03 23:12
It is common to setup a specific provider build that _just_ performs the Pact verification for a given contract, triggered by a Webhook. I wouldn?t have can-i-deploy as a separate thing
bheemreddy181
2020-02-04 00:42
So when I use this http://blog.pact.io/2018/07/16/publishing-pact-verification-statuses-to-github/ there is no need of a can-i-deploy tool, I will end up having my job waiting for the provider to verify and publish the results back to consumer CI from broker
bethskurrie
2020-02-04 00:43
you'll want can-i-deploy for deployments to an environment, but the git statuses should remove the need to use can-i-deploy for PRs.
bethskurrie
2020-02-04 00:44
Also, if your verifications are taking that long, it suggests to me that you might be running the entire verification suite instead of just verifying the pact that has changed?
bheemreddy181
2020-02-04 00:44
once my PR is green I will go ahead and merge my PR there ends the loop?
bethskurrie
2020-02-04 00:46
once master has verified the pact, the status will be reported back to Github, and the PR should be green.
bethskurrie
2020-02-04 00:47
For it to work properly thought, you need to be using the pact URL that comes from the webhook to verify thought, as it contains metadata in it that will make the verification result come back to the right commit.
bethskurrie
2020-02-04 00:49
remember, verification results belong to the *content* of the pact, not the consumer version, so if your pact content has been published by many consumer versions, then it will just do the github status update for the most recent consumer version unless you verify the pactURL that is supplied from the pact changed webhook.
bheemreddy181
2020-02-04 00:49
So on the provider side, we will have pact verification job itself to tell whether anything is broken and we can eliminate can-i-deploy there as well ?
bheemreddy181
2020-02-04 00:50
multiple consumer versions can end up having the same content if the pact is not changed
bheemreddy181
2020-02-04 00:57
well there is no fetch results at the end on the consumer side because the webhook itself can update the status back on consumer CI either red/green
bethskurrie
2020-02-04 19:55
The "contract changed" webhook has parameters like the consumer name, provider name etc that you can use in the body of the webhook. There's also a url of the Pact that has changed. That url has some metadata in it (the current tags and the consumer version number). That url should be passed through to the verification job, and for a speedy feedback loop, only that pact should be verified.
bethskurrie
2020-02-04 19:56
When the verification results are posted back, it will know which consumer version number the results belong to.
bethskurrie
2020-02-04 20:00
If you just do the normal "verify all", it will firstly, take a long time, and secondly, if the pact content has been published by many consumer versions, it will send the results back to the *last* consumer version, which may or may not be the one you want. If you've pushed the pact multiple times before the results come back (eg you did a push 1 minute apart, and the verification results took 3 minutes to come back) then your original commit won't get its results - only the second one will.
shilpa3006
2020-02-04 23:10
Hi, we are interested in pact broker and looking forward to push pact broker to PCF(Pivotal Cloud Foundation) and we are not encouraged to use docker. Can I know how can I do that and what all I would need?
matt.fellows
2020-02-04 23:24
I?m afraid you?re unlikely to get any help from the core maintainers. We don?t use PCF here and recommend generally going down the container path
matt.fellows
2020-02-04 23:25
I?m guessing something like https://docs.pivotal.io/pivotalcf/2-6/buildpacks/ruby/gsg-ruby.html will help
matt.fellows
2020-02-04 23:27
Then it?s just a matter of exporting any environment variables and/or modifying `http://config.ru` to suit your needs
shilpa3006
2020-02-04 23:43
Another dumb question. As this is not docker solution, what all prerequisites needed for pact broker up and running in pcf
bethskurrie
2020-02-04 23:51
@shilpa3006 have you read https://github.com/pact-foundation/pact_broker/blob/master/README.md#rolling-your-own
matt.fellows
2020-02-04 23:54
You can run it locally without having to do anything (see this example: https://github.com/pact-foundation/pact_broker/blob/master/README.md#to-have-a-play-around-on-your-local-machine) , but to run anything in Production you?re probably going to need to harden it for your environment, something which we can?t tell you how to do from here
kong
2020-02-05 00:01
I?ve not used PCF with the ruby buildpack but I believe it will automatically read the Gemfile and lockfiles to build it?s package. You will need to setup your database separately though
bheemreddy181
2020-02-05 15:59
Once the pact is green on PR , we have to tag the pact as master on the merge correct , so that provider verification can always verify master on the provider PR ?
sagupta
2020-02-05 16:16
Hello Team,
May be a repeated question. I am doing the pact-js workshop and I want to use PACT broker. However from the documentation , looks like either I can use the pact broker hosted or on my local machine or a docker image?
I am guessing , I need to buy a subscription if i use the hosted pact broker so May i know which is the recommended method if I want to try it out first to do a POC? Also any documentation link for easy setup will be helpful
sam774
2020-02-05 21:12
Perhaps a dumb question, but does the pact broker docker create the database schema upon first startup?
I'm just wondering as in gcp I've hooked up pact broker with cloud SQL proxy to a postgres database and I can see it connecting, but there's nothing in the db
bethskurrie
2020-02-05 21:14
You either need to run and support your own broker or use pactflow @sagupta
bethskurrie
2020-02-05 21:15
when you say "the schema", what exactly do you mean? (the term "schema" is overloaded)
bethskurrie
2020-02-05 21:15
You need to create the database already, but it will create the tables and views.
matt.fellows
2020-02-05 21:16
The workshop has documentation for how to run locally. The hosted broker will have a public URL and you'll need to grab a token from the settings page
matt.fellows
2020-02-05 21:17
Use a token generated from here https://docs.pactflow.io/docs/user-interface/#settings-api-tokens
bethskurrie
2020-02-06 23:27
In my experience, there would be a build that runs on master after the merge. It would be the one that publishes the pact and tags it with master.
bethskurrie
2020-02-06 23:28
It should have the same content as the one from the PR, so it will inherit the previous verification status.
bheemreddy181
2020-02-06 23:29
Yes there will a build on travis post-merge on master and the content will be same
bheemreddy181
2020-02-07 05:02
Any idea we can pass parameters for triggering a travis build from the webhook by passing the path pramaters similar to jenkins as below , i don't see anything the documentation
```http://jenkins:8080/job/<provider-job-name>/buildWithParameters?pactConsumerTags=${pactbroker.consumerVersionTags}```
bethskurrie
2020-02-07 05:52
There are these docs that show up in the HAL browser https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution
bheemreddy181
2020-02-07 14:43
Jenkins support path parameters where as Travis doesn?t support that I am asking if you anyone tried using Travis for passing path variables or some other way
justaburneremailforso
2020-02-07 15:13
Hello, I have a quick question about the broker and Can I Deploy. If we make a consumer contract change and publish it to the broker, we can see the status changes to "Pact has changed since last successful verification" and the last verified status changes to yellow. Provider verification has not been re-run since the contract changed.
If I run Can I Deploy now, it passes. Is that expected behaviour? In that can I deploy only fails when verification has never happened or when verification has failed? In the scenario above where the last verify status has changed but is not failed, can I deploy will pass?
Thanks
bheemreddy181
2020-02-07 16:20
@justaburneremailforso did you already set up your webhook for triggering the job on the provider, if so when contract changes the job should be triggered. how are you running your can-i-deploy?
bheemreddy181
2020-02-07 16:21
Team any idea i am getting 405 response when executing the webhook from broker , this is what i see in the logs
bheemreddy181
2020-02-07 16:21
```nginx_1 | 10.226.32.51 - - [07/Feb/2020:16:16:47 +0000] "GET /webhooks/ENdZ3UmsnibGo-05_YRAKw/execute HTTP/1.1" 405 0 "http://pact_broker.dev.com/hal-browser/browser.html" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36" "-"```
bheemreddy181
2020-02-07 16:31
this is what i did for white_listing on the docker image
```PACT_BROKER_WEBHOOK_HOST_WHITELIST="http://travis.staging.sample.com","http://travis.sample.com","http://pipeline.sample.com","http://jenkins.sample.com","http://git.sample.com","http://slack.sample.com"```
matt.fellows
2020-02-07 22:21
405 is method not allowed. I can?t remember off the top of my head, but that is probably a `POST` instead of a `GET`
justaburneremailforso
2020-02-07 22:50
Yeah we have a webhook but was wondering what should happen if the contract has changed but verify hasn't run yet.
bheemreddy181
2020-02-07 23:14
@matt.fellows I see that response when I try to execute the webhook manually to verify if that?s working
bheemreddy181
2020-02-07 23:22
It depends on which version of consumer you are running your can-I-deploy on
bheemreddy181
2020-02-07 23:23
What I will do is record a session to explain more what?s going wrong here
bethskurrie
2020-02-08 03:25
But if you're doing can-i-deploy on a different version, you'll get different results.
bethskurrie
2020-02-08 03:26
Have a look at the matrix page rather than the index - it might be clearer.
bethskurrie
2020-02-08 03:27
If you can recreate the scenario and post some screenshots we might be able to work it out.
bethskurrie
2020-02-08 03:28
The output from can-i-deploy will tell you which consumer/provider versions it thinks are applicable. Check those versions and see if they make sense.
bethskurrie
2020-02-08 03:29
@bheemreddy181 Please read the documentation more closely. `PACT_BROKER_WEBHOOK_HOST_WHITELIST - a space delimited list of hosts`
bheemreddy181
2020-02-08 03:34
i was confused with https://github.com/pact-foundation/pact_broker/wiki/Configuration#webhook-whitelists sorry for the inconvenience
bheemreddy181
2020-02-08 03:58
whenever i bring down the docker image and bring it back up I don't see the old pact files, is there something i am doing wrong
matt.fellows
2020-02-08 04:00
It can be in the docker compose file, but you need to persist volumes and things
bheemreddy181
2020-02-08 04:00
nope , i was in an assumption it brings the data back up from the existing postgres file on the machine
matt.fellows
2020-02-08 04:01
You'll need to check the postgres rocker docs to ensure you persist any volumes. Otherwise they'll disappear
bethskurrie
2020-02-08 04:02
Trying to teach someone how to use Docker is beyond what we're really able to do over this channel.
bheemreddy181
2020-02-08 04:02
yes, there are, I will get in touch with someone for sure :slightly_smiling_face:
bethskurrie
2020-02-08 09:11
Do you mean dynamic job parameters in the request? Yes, you an definitely do that.
sliu7
2020-02-10 02:49
Hi guys. I'm trying to use the pact broker CLI - installed the latest version (tried pact-1.77.0 and pact-1.78.0) for windows.
I had a read through selectors (https://docs.pact.io/pact_broker/advanced_topics/selectors) and thought that by specifying --consumer-version-selector, it should verify only consumer contracts with the specified tag in the selector. However, it seems to be verifying the latest version irrespective of what tag I provide. Am I missing something?
Eg: I have a consumer for a provider with 2 tags - the provider verification is successful for consumer contract with 'master' tag but fails for the contract with 'test' contract
1. pact-provider-verifier --provider-base-url=https://localhost:5001 --pact-broker-base-url=<<broker-url>> --provider=SampleProvider --consumer-version-tag=master [*Verification successful*]
2. pact-provider-verifier --provider-base-url=https://localhost:5001 --pact-broker-base-url=<<broker-url>> --provider=SampleProvider --consumer-version-selector='{"tag": "master", "latest": true}' [*Verification failed*. I thought that this should give a successful verification since it should filter based on the latest contract with master tag]
3. pact-provider-verifier --provider-base-url=https://localhost:5001 --pact-broker-base-url=<<broker-url>> --provider=SampleProvider --consumer-version-selector='{"tag": "test123", "latest": true}' [*Verification failed*. I thought that this should give an error relating to could not find contract since I don't have any contract with the corresponding tag]
bethskurrie
2020-02-10 02:49
@sliu7 you're using a feature that's not publicly released in the OSS yet.
bethskurrie
2020-02-10 02:51
It should be out soon. We need to get pact-jvm using it before we go public, because at the moment, we're doing a beta with the ruby clients, but we need to make sure pact-jvm can use the api before we go public, in case there has to be breaking changes.
sliu7
2020-02-10 02:52
yup, will just use --consumer-version-tag for now. Thanks :slightly_smiling_face:
matt.fellows
2020-02-10 11:50
What languages are you using Shiraine? It will be supported in Pact Go in the next couple of days, and in JS in the next few weeks
justaburneremailforso
2020-02-11 13:02
Hello,
I am currently writing a pact Kafka consumer test and when I publish it to the broker and examine it on the broker there's a message that says "Note: this contract could not be parsed to a v1 or v2 pact, showing raw content instead".
I'm using pact-jvm-consumer-junit_211 version 3.5.0 in my pom file. I'm also using pact-jvm-provider-maven_2.12 version 3.5.11 as a plugin in my pom file.
Does anyone know why I am getting that message? Is it because of some issue with the versions I am using in my pom and/or the broker version or something else?
Thanks.
shilpa3006
2020-02-12 03:26
@matt.fellows @bethskurrie Thanks Matt and Beth for your inputs. I am able to setup pact broker on my machine.
bethskurrie
2020-02-12 03:41
It actually used to display, and then it stopped at some version for some reason. People kept reporting it, but then not supplying me with an example of the Pact that caused it.
bethskurrie
2020-02-12 03:41
I'll have a look at it tomorrow, because there's another v3 parsing bug that someone has raised for the stub service.
justaburneremailforso
2020-02-12 08:47
I'm not sure what version of the broker we have. Is there a way for me to check through the UI?
ahmadw
2020-02-12 11:33
```@PactBroker(host = "http://mashreq.pact.dius.com.au/", port = "8089", protocol = "https",
authentication = @PactBrokerAuth(username = "Read/Write Toke", password = "abcd"))```
I am getting 401 error for this Pactbroker configuration, can anyone help
ahmadw
2020-02-12 12:19
https://docs.pact.io/getting_started/sharing_pacts
Pact-JVM Junit
According to documentation, how can i publish pact file to PactBroker for verification from provider?
justaburneremailforso
2020-02-12 19:11
Our pact is quite basic, it's something like this:
```@Pact(provider = "provider", consumer = "consumer")
public MessagePact testPact(MessagePactBuilder builder) {
PactDslJsonBody body = new PactDslJsonBody()
.stringType("test", "item")
.integerType("number", 1234);
return builder
.expectsToReceive("test message")
.withContent(body)
.toPact();
}```
bheemreddy181
2020-02-13 04:06
one last question here if you don?t mind given the contract creation and publish job are technically synchronous but it?s still not a blocking call as per the below picture how will my job on GitHub will be waiting for the results to comeback even if I am using publishing verifications status from GitHub using http://blog.pact.io/2018/07/16/publishing-pact-verification-statuses-to-github/
bethskurrie
2020-02-13 04:07
You go straight on to can-i-deploy, and that either aborts your pipeline (because the pact hasn't been verified) or keep going because it is.
bethskurrie
2020-02-13 04:08
If you want to tell it to wait for the verification results to come back, you can tell it to wait and poll.
bheemreddy181
2020-02-13 04:12
As you said we won?t need it here if I use git verifying webhook https://pact-foundation.slack.com/archives/C9VPNUJR2/p1580776993077200?thread_ts=1580741114.061700&channel=C9VPNUJR2&message_ts=1580776993.077200
bheemreddy181
2020-02-13 04:14
Typically I don?t want my PR checks to go green even before provider verification job completes
bheemreddy181
2020-02-13 04:15
That?s true but if it is not (not pre-verified) I should poll for the initial integration
bethskurrie
2020-02-13 04:16
if you have a contract_published webhook, it will send 'pending' if it's not verified yet.
bethskurrie
2020-02-13 04:17
it will only go green once the provider_verification_published webhook fires and updates the status to success.
bheemreddy181
2020-02-13 04:17
I don?t see pact:publish job waiting when I run this locally with all the webhook integration present
bethskurrie
2020-02-13 04:20
The words here are more accurate: https://github.com/pact-foundation/pact_broker/wiki/Webhooks#consumer-ci
bheemreddy181
2020-02-13 04:20
:confused::confused::confused: I know I am eating all your brain I have demo due for this Friday I want to be slightly clear with what I present for my deployment team so
bethskurrie
2020-02-13 04:21
usually, you'd go "unit test, pact tests, can-i-deploy to test, deploy to test, can-i-deploy to prod, deploy to prod"
bethskurrie
2020-02-13 04:22
on a branch, the can-i-deploy to test would stop you deploying an unverified pact to the test env if you had new functionality.
bheemreddy181
2020-02-13 04:23
usually, my PR checks goes this way "unit test, pact tests, dB lints " with in my pact tests it will ? create contract , publish contract ? this is what I expected with all webhooks in place
bethskurrie
2020-02-13 04:23
if you wanted to poll in can-i-deploy, it would wait for however long you wanted for the successful verification to come back.
bheemreddy181
2020-02-13 04:26
usually, my PR checks goes this way "unit test, pact tests, dB lints " with in my pact tests it will ? run tests , create contract , publish contract ? this is what I expected with all webhooks in place
sagupta
2020-02-13 13:54
I am getting {*PactBroker::Client::Error - Authentication failed*} when i try to publish pact json to the pact broker using my account credentials. when i use the username and password for ?https://test.pact.dius.com.au?? and it works fine . Can anyone tell me what i might be doing wrong here?
bernardoguerr
2020-02-13 16:15
You may want to protect your credentials a bit better, that's still quite readable.
Are you using Pactflow? Otherwise I think you don't need pactBrokerToken. Either way, I don't think you need to include Bearer there
sagupta
2020-02-13 17:37
I am using pactflow yes. I tried without using Bearer but I get same error .I am able to log in to Pactflow using the same credentials via ui.
bethskurrie
2020-02-16 22:15
Also, @sagupta make sure you have the very latest pact-js. The token support has only been added recently.
sagupta
2020-02-17 09:32
@bethskurrie Do you mean pact version , I am using 9.6.1 version pact . Is it the latest version?
sagupta
2020-02-17 09:34
Also I am not adding BEARER in token and still getting ?Authentication failed? error
bethskurrie
2020-02-17 09:43
I'm not the maintainer of pact-js, so I don't know what the latest version is. Have a look at the npm site, or the package.json in the pact-js github repository.
bethskurrie
2020-02-17 09:44
99% of pactflow authentication failures are due to old versions of pact-js though
sagupta
2020-02-17 09:49
I checked the version at the npm site and I am using the latest version of pact. Will ask this question in pact js channel then
bethskurrie
2020-02-17 09:52
@matt.fellows may be able to check for you before I can. (it's 9pm Australia time!)
matt.fellows
2020-02-17 11:35
@sagupta you have specified the username/password and token. You can?t use both modes of authentication at the same time. If you?re using Pactflow, just use the token
sagupta
2020-02-17 12:24
Hi Matt, yes indeed that was the problem. I didnt know that and Beth helped me with it. Its working now :slightly_smiling_face:
bheemreddy181
2020-02-19 00:51
Do we need a Stub Server and Mock Service along with pact broker setup internally ?
bethskurrie
2020-02-19 00:52
Mock and stub services just run for the duration of the test on the machine that that tests are running on.
bheemreddy181
2020-02-19 00:57
Given if your services are containerised ? Do we see any value of just running these without your services being containerised
bethskurrie
2020-02-19 00:58
When you say containerised, do you mean, running your pact tests within a docker container, or, running the pact tests on a dockerized version of your application?
bethskurrie
2020-02-19 02:30
I'm assuming you're talking about the verification step, and not the consumer tests here?
bethskurrie
2020-02-19 02:30
You can do pact verification on a dockerised service, but it may make it more difficult to stub parts of your application.
bethskurrie
2020-02-19 02:31
Also, if you have a dockerised app, it suggests you've already got to the "packaging" step of your build, to get the earliest feedback possible, you want to run your pact tests as close to your "unit" (isolated) tests as possible.
bethskurrie
2020-02-19 02:32
you'd genererally go "isolated tests" (eg the ones that just run on your local dev machine), pact tests, package, can-i-deploy to test, deploy to test, can-i-deploy to prod, deploy to prod.
shilpa3006
2020-02-19 19:12
@matt.fellows Hi Matt, I am not seeing last verified column updated even though verification is passing or successful. Any idea why?
matt.fellows
2020-02-19 21:03
Have a look at the matrix. It's possible you've verified a version that's different than latest or haven't published a result. Can you please share as much detail so we can help. E.g. output of can I deploy, matrix view etx
shilpa3006
2020-02-19 21:57
@matt.fellows in matrix, I see provider version and pact verified as empty
shilpa3006
2020-02-19 23:09
@bheemreddy181 I thought when we run provider verification - .verify will take care of verification of pact file published on pact broker...I see webhook status as create but provider version and last verified is showing empty..I am sure I am missing some connecting part here. Where should I run can I deploy?
shilpa3006
2020-02-19 23:10
@matt.fellows I feel I am almost there but still feel I am no where near. Can you pls help Matt?
shilpa3006
2020-02-19 23:16
I have executed command- bundle exec rack up -p 8080 this initiated pact broker at local host 8080 and then I published consumer pact..now I run my provider verification- verification passes but I don?t see last verification updated in broker
matt.fellows
2020-02-20 06:46
Can I ask, if you weren't looking for the option on GitHub where were you? Do we need to update docs somewhere else?
agarwalatrisha1212
2020-02-22 17:03
I have installed prost gres and started locally but unable to set up connection
bheemreddy181
2020-02-23 17:54
refer this thread https://pact-foundation.slack.com/archives/C9VPNUJR2/p1580433999014900
agarwalatrisha1212
2020-02-23 21:27
thank you @bethskurrie, i looking all suggestion shared in @bheemreddy181 thread
agarwalatrisha1212
2020-02-23 21:29
okay ! i will ask question it is not working out for me ! Thank you for asking !
pkuang
2020-02-27 21:30
Hi, Is it possible/does it make sense to provide a way to create a webhook for a provider that does not yet exists within the broker? We want to setup a provider project with Pact testing and set up a verification job to be triggered when a consumer contract is published referencing that provider via a webhook. Currently it fails with "pacticipant" not found. Does this mean we we have to wait for the consumer side to set up Pact testing first and publish the initial contract?
pkuang
2020-02-27 21:32
ah ok thanks @bethskurrie! I wasn't aware you can explicitly create pacticipants outside of publishing a contract to create them
amitojduggal
2020-02-29 13:57
Hello :slightly_smiling_face: , do we have an option to download all the pacts from the pact broker, and use all of those as mocks with pact-stub-server? or its something we have to write a script for?
matt.fellows
2020-02-29 20:07
When you say download all pacts, do you mean "download all pacts for a particular consumer with a particular tag?"
amitojduggal
2020-02-29 20:58
Okay let me be more specific, ?download pacts for all consumers with one particular tag? :slightly_smiling_face:
matt.fellows
2020-02-29 21:15
Out of interest, why would you want it for _all_ consumers at the same time?
matt.fellows
2020-02-29 21:16
Usually, when you stub something out, you?re stubbing out a single consumer (e.g. to do UI tests or something)
matt.fellows
2020-02-29 21:17
In any case, it?s not currently supported. Feel free to raise an issue or submit a PR!
amitojduggal
2020-02-29 22:47
Thank you :slightly_smiling_face: the only reason to do this is , i was planning if we could fetch all pacts, put those in as part of a docker container. and use it with TestContainers to write integration tests against other services. If we fetch all of pacts, we dont have to create docker containers catering to each and every microservice.
i will take a look, raise a issue and possible create a PR.
bethskurrie
2020-02-29 22:53
@amitojduggal if you look at the index resource in the API browser you'll find a list of all the endpoints you can hit.
bethskurrie
2020-02-29 22:54
You'll be able to achieve what you want, but you'll need to write a script for it.
bethskurrie
2020-02-29 22:56
Be careful that you only stub with successfully verified pacts, otherwise, you could be stubbing with an invalid contract.
franklin.huynh
2020-03-05 00:49
hi @bethskurrie and @matt.fellows I think I may have an issue with our PactFlow instance. Could you please let me know where should I contact for support?
bethskurrie
2020-03-05 03:20
@franklin.huynh I can restore your db to 7am this morning, or you can keep what you have now. Which would be more useful?
jarmy
2020-03-05 19:48
Hello. I?m following the ?Rolling your own? instructions here: https://github.com/pact-foundation/pact_broker/blob/master/README.md#rolling-your-own and had some questions around the database set up/wiring.
I have an external Postgres DB already set up that I want to connect to. Do I need to include `gem "pg", "~>1.0"` in the Gemfile in order to connect to the remote DB or is it required for just installing the db?
Let me give some context to the problem I faced. In order to deploy to our internal cloud, we need to use a base image built off of _debian:9.0_. This required me to migrate the Dockerfile from _alpine._ I then ran into a ruby versioning issue with _bundle install_ which led me to install and compile ruby 2.6.5 onto the image https://github.com/docker-library/ruby/blob/82eecb7596c3cb466dd87d4b0350d189a330b925/2.6/stretch/slim/Dockerfile.
matt.fellows
2020-03-05 23:38
if your database is postgres, then that Gem is absolutely necessary (because it needs to be able to speak the Postgres dialect) - creating tables, issues queries etc.
bethskurrie
2020-03-06 09:52
You need that gem for the app to connect to the database, as well as to run the migrations.
sjdl
2020-03-06 12:12
:pensive: have this exact issue
Are there any maintained/recent Openshift/Helm deployments? Hard to find a working example that isn't 2+ years old...difficult to get started when you've limited knowledge with docker/ruby.
slimak2387
2020-03-09 13:50
Hello guys,
I'm wondering what should I add to the `whitelist` to create a webhook sending Slack notification like on the example from https://docs.pact.io/pact_broker/advanced_topics/webhooks/template_lib. I can whitelist IP or hostname so probably
```https://hooks.slack.com/services/T(team_id_prefixed_with_T)/.*```
is not the correct answer. Can you point me needed hostname? Is the following good enough?
```http://hooks.slack.com```
matt.fellows
2020-03-09 20:02
What do the docs say? I don't think You don't need to whitelist it. All https is whitelisted by default from memory
bheemreddy181
2020-03-09 21:31
Quick pr on pact broker if one of you matt/beth can help me with this by giving some review comments https://github.com/pact-foundation/pact-broker-docker/pull/21
slimak2387
2020-03-10 08:45
I'll try with whitelisting `http://hooks.slack.com` and let you know if it helps.
matt.fellows
2020-03-10 09:32
Ok so if you have already set a whitelist, then slack must be added as per this rule
ahsan_bhai
2020-03-10 17:05
I have noticed something weird with `can-i-deploy` command. Not sure if this is as designed. When I run the command with `--to` option set to `invalid-tag` the command returns successful with status code as 0. However, no table is printed.
```pact-broker can-i-deploy -a XXXXXX -b http://XXXXXX -e a81980d379c665071cf1668fa3bde9a22aeebf9d --to prod
Computer says yes \o/
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
------------------|--------------------------------|-------------------|--------------------------------|---------
XXXXXXXXX | 6e37c21959bf66792d21b794353... | XXXXXXXXXXX | a81980d379c665071cf1668fa3b... | true
can-i-deploy -a XXXXXX -b http://XXXXXX -e a81980d379c665071cf1668fa3bde9a22aeebf9d --to invalid-tag
Computer says yes \o/
There are no missing dependencies```
In first command, the result is expected. However, in second command `invalid-tag` doesn't exist in pact-broker. However, in both cases `a81980d379c665071cf1668fa3bde9a22aeebf9d` is a valid version
bethskurrie
2020-03-10 19:35
There's no table because there are no verifications with any application in "invalid-tag" environment, but also, there are no missing dependencies in that environment that would prevent you from deploying to it.
slimak2387
2020-03-11 15:18
Whitelisting `http://hooks.slack.com` solves the issue. Thank you for colaboration :right-facing_fist::left-facing_fist:
pkuang
2020-03-17 14:54
Hi, how do I configure the pact broker to log to stdout instead of a log file?
tjones
2020-03-18 03:44
I don?t know if there?s an easy way to configure this (the broker isn?t my area), but I?d start here: https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/logger.rb
bethskurrie
2020-03-18 21:13
You must be rolling your own @pkuang because the docker version logs to stdout by default.
thakkarjinal29
2020-03-20 08:12
Is it possible to use `can-i-deploy` with verification result url from pact broker? Does that even make sense? My use-case is to check if particular versions of consumer and provider are compatible! Thanks
thakkarjinal29
2020-03-20 08:16
Thanks! And I should be using the webhook to tell the provider CI what the consumer name and version is?
bethskurrie
2020-03-20 08:18
What are you trying to achieve by running can-i-deploy? It sounds like you have a non standard use case.
thakkarjinal29
2020-03-20 09:09
So the way I was thinking of going about this is:
1. Run consumer tests, publish the pact
2. If the contract content changed, trigger the webhook, to run the provider ci (circle ci job)
3. Publish the validation result
4. Use can-i-deploy to make sure the provider and consumer are compatible.
However, I realize now the 4th step does not make very much sense, does it?
I think I am mostly deciding what or where the right way to use can-i-deploy should be. Should it be when you run your ci? or during the deployment?
bethskurrie
2020-03-20 09:10
But you've missed the thing that makes the can-i-deploy easy, and that's the tagging
bethskurrie
2020-03-20 09:11
If you don't use tags, you have to somehow work out which version of the other application you need to put in to the command
thakkarjinal29
2020-03-20 09:11
Yep, I did tag both the consumer and provider, however, what I am confused is, how would the provider ci know the tag of the consumer, unless both have the same tags?
thakkarjinal29
2020-03-20 09:21
These are super helpful! Thanks!
One last question! In what case, would tagging a pacticipant with it?s branch be helpful?
bethskurrie
2020-03-20 09:28
rule of thumb @thakkarjinal29 - tag with the branch name when you publish pact/verification, tag with the environment name when you deply. With these done, you'll be prepared for anything.
bheemreddy181
2020-03-20 16:00
Quick Question on Github publish commit status https://github.com/pact-foundation/pact_broker/wiki/Webhook-template-library#github---publish-commit-status - does this report back to the publish task ?
bheemreddy181
2020-03-21 01:41
I mean how can I setup this as required check on GITHUB commits , should there be something listening to this request coming from broker @bethskurrie ?
bethskurrie
2020-03-21 01:41
You'll have to look at the github docs to see how to make it a required check.
bheemreddy181
2020-03-21 01:46
By Default i expect a pending check - until the webhook result renders back something like below
bethskurrie
2020-03-21 01:48
if the pact is pre-verified, then when it is published, it will publish a verified github status
bethskurrie
2020-03-21 01:49
a webhook should trigger your provider build, and then when the verificaiton is published, it will update the status with the results of the verification
bethskurrie
2020-03-21 01:49
you have to be using the dynamic URL that was passed through from the webhook for this to work
bheemreddy181
2020-03-21 01:49
these are some logs what i see
```[2020-03-20T22:20:09Z] INFO: HTTP/1.1 POST https://git.sample.com/bvennapureddy/portfolio/statuses/6bc856e96c75a44a54c4b09e72bc75e411342ed2
[2020-03-20T22:20:09Z] INFO: accept-encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
[2020-03-20T22:20:09Z] INFO: accept: */*
[2020-03-20T22:20:09Z] INFO: user-agent: Ruby
[2020-03-20T22:20:09Z] INFO: content-type: application/json
[2020-03-20T22:20:09Z] INFO: authorization: **********
[2020-03-20T22:20:09Z] INFO: host: http://git.enova.com
[2020-03-20T22:20:09Z] INFO: content-length: 245
[2020-03-20T22:20:09Z] INFO: {"state":"success","description":"Pact Verification Tests","context":"pgs ","target_url":"http://pact-broker-poc.dev.com/pacts/provider/pgs/consumer/portfolio/pact-version/490e930bfc0cdf2e1abfc615d19bfb12f4a98fc2/verification-results/116"}
[2020-03-20T22:20:09Z] INFO: For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See /doc/webhooks#whitelist for more information.
[2020-03-20T22:20:09Z] INFO: Retrying webhook in 10 seconds
[2020-03-20T22:20:19Z] INFO: HTTP/1.1 POST https://git.sample.com/bvennapureddy/portfolio/statuses/6bc856e96c75a44a54c4b09e72bc75e411342ed2
[2020-03-20T22:20:19Z] INFO: accept-encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
[2020-03-20T22:20:19Z] INFO: accept: */*
[2020-03-20T22:20:19Z] INFO: user-agent: Ruby
[2020-03-20T22:20:19Z] INFO: content-type: application/json
[2020-03-20T22:20:19Z] INFO: authorization: **********
[2020-03-20T22:20:19Z] INFO: host: http://git.enova.com
[2020-03-20T22:20:19Z] INFO: content-length: 245
[2020-03-20T22:20:19Z] INFO: {"state":"success","description":"Pact Verification Tests","context":"pgs ","target_url":"http://pact-broker-poc.dev.com/pacts/provider/pgs/consumer/portfolio/pact-version/490e930bfc0cdf2e1abfc615d19bfb12f4a98fc2/verification-results/116"}
[2020-03-20T22:20:19Z] INFO: For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See /doc/webhooks#whitelist for more information.
[2020-03-20T22:20:19Z] INFO: Retrying webhook in 60 seconds```
bethskurrie
2020-03-21 01:52
`[2020-03-20T22:20:19Z] INFO: For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See /doc/webhooks#whitelist for more information.`
bethskurrie
2020-03-21 01:52
This is frustrating me because it is written right there want you need to do.
bethskurrie
2020-03-21 01:53
And you've pasted the text to me without having read it, and you're asking me for help.
bheemreddy181
2020-03-21 01:54
well i read that i assumed that there is whitelisting issue but i don?t see that as an issue because i was able to ping the git ip from the node
bethskurrie
2020-03-21 01:54
And from memory, you were using the wrong format for your whitelist, last time we discussed this. You were trying to use the Ruby format for an environment variable.
bethskurrie
2020-03-21 01:55
"INFO: For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property."
bethskurrie
2020-03-21 01:56
Just because you can ping the git doesn't mean that your request is working.
bethskurrie
2020-03-21 01:56
Why would it say `INFO: Retrying webhook in 10 seconds` `INFO: Retrying webhook in 60 seconds` etc unless there was an error?
bheemreddy181
2020-03-21 01:58
fyi i see these logs
```INFO: For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See /doc/webhooks#whitelist for more information.\n",```
even for successful requests
bheemreddy181
2020-03-21 01:59
Sure will try my best thanks for the help Beth, Happy weekend :slightly_smiling_face:
carolyn.biggar
2020-03-21 14:23
Hello, is there a way to make the Pact broker show "not run" or similar if there's a runtime error rather than a test failure?
We're using the junit5 library and the most recent pact broker, the main example is if a consumer adds in a new "given" without us having a matching state.
The tests don't run, but the results get pushed to the broker and show as verified succesfully. Thanks for any advice!
carolyn.biggar
2020-03-21 14:23
Dependencies in the provider test code:
```dependencies {
implementation "org.jetbrains.kotlin:kotlin-stdlib-jdk8"
testImplementation "org.junit.jupiter:junit-jupiter-api:5.4.2"
testImplementation "org.junit.jupiter:junit-jupiter-params:5.4.2"
testImplementation "org.junit.jupiter:junit-jupiter-engine:5.4.2"
testImplementation "org.assertj:assertj-core:3.11.1"
testImplementation "au.com.dius:pact-jvm-provider-junit5_2.12:3.6.11"```
borsuk.artem034
2020-03-21 18:04
Hello, have some issue with pact broker, for version take commit hash and send to pact broker, but pact broker save version with different lenth and we can't match versions
borsuk.artem034
2020-03-22 07:40
for sending pact I'm used pact-node, commit hash taken from bitbucket variable
bethskurrie
2020-03-22 07:54
Please raise a proper issue with steps to recreate. The broker does not change the version number in any way. It may display the short sha in the matrix however, in older versions. I can't remember.
bethskurrie
2020-03-22 07:57
If the tests show as a successful verification when there was a run time error @carolyn.biggar, that's an issue with pact JVM. Please raise an issue and provide an executable example to recreate the issue.
bethskurrie
2020-03-22 07:58
Broker base URL: https://test.pact.dius.com.au
username: dXfltyFMgNOFZAxr8io9wJ37iUpY42M
password: O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1
borsuk.artem034
2020-03-22 08:41
actually, i'm not using short version name, I'm just taking variable BITBUCKET_COMMIT https://confluence.atlassian.com/bitbucket/variables-in-pipelines-794502608.html and use it in bitbucket pipelines, then in pact broker UI and DB i see shot commit hash (7 symbols) for all services, and everything was good. But one new service for the first build send long hash, second run (without any code changes) send short hash
bethskurrie
2020-03-22 09:46
See if you can turn on verbose mode when publishing. You'll be able to see the http requests and responses.
bethskurrie
2020-03-22 09:47
Is this particular service both a consumer and a provider? You're not publishing a pact with a short sha and a verification with a long sha (or the other way around) are you?
bethskurrie
2020-03-22 09:51
Pact node doesn't do anything to the sha. I just checked. https://pact-foundation.slack.com/archives/C9VBGLUM9/p1584870500073000
borsuk.artem034
2020-03-22 10:28
I found the problem, bitbucket build after commit do
```git reset --hard 1a08b6146a51```
manual build run do
```git checkout 1a08b6146a51187bdb9c8c077f0fd850fc92e619```
borsuk.artem034
2020-03-22 10:29
so it was the difference, big thank you one more time :slightly_smiling_face:
audun.halland
2020-03-23 00:32
Hi, there?s two pacticipants in my broker and there used to be interactions between them, but after refactoring there are now 0 interactions there. This means the consumer no longer publishes a pact referencing this provider. However, that means the pacticipant pair does not get an updated version showing zero interactions between them in the broker. So now I have a ?stuck interactions?. Do I have to delete every single historical version between those pacticipants?
bethskurrie
2020-03-23 00:34
If you can't see that, you'll need to either upgrade, or send the delete request through the HAL browser.
bethskurrie
2020-03-23 00:46
it's worth keeping up to date. I put out releases at least a few times a month.
bethskurrie
2020-03-23 00:48
also, as time has gone on, and the amount of data that is returned in the matrix queries has increased, I've had to optimise that query a few times to stop it grinding to a halt!
audun.halland
2020-03-23 00:50
Nice. I can?t find my current version. I just have a docker image hash, which I can?t find on docker hub :grimacing:
bethskurrie
2020-03-23 00:51
You'll be on the dius/pact-broker instead of the pactfoundation/pact-broker probably
audun.halland
2020-03-23 01:10
no, my guess is some CSS caching issue after upgrading. It works now :slightly_smiling_face:
anja.kammer
2020-03-23 18:56
I am using the pact-broker image from Dockerhub. (https://hub.docker.com/r/pactfoundation/pact-broker)
How do I prevent the loading of the example data? Thanks for your help!
bheemreddy181
2020-03-24 02:29
Thanks a ton @bethskurrie I was able to successfully use the GIT webhooks for completing the loop ( typically branch verification ) I learnt a lot in this journey and as you said it was the whitelisting issue.
bheemreddy181
2020-03-24 02:39
Sorry for eating up all your time with all those questions, have a great day. Thanks again :)
aliihlail
2020-03-24 18:45
im trying a simple pact verigicationTest as attached. but im getting an error
java.lang.IllegalStateException: Failed to load ApplicationContext
at org.springframework.test.context.cache.DefaultCacheAwareContextLoaderDelegate.loadContext(DefaultCacheAwareContextLoaderDelegate.java:125)
at org.springframework.test.context.support.DefaultTestContext.getApplicationContext(DefaultTestContext.java:108)
at
bethskurrie
2020-03-26 09:58
Hey testers in this channel! I've done a big refactor of the auth code in the `pactfoundation/pact-broker` image, and I'd love to get someone to do a regression test on it for me before I release it. It is covered with automated tests, but you can never be too careful with authentication and authorization! I just want to make sure that all the basic auth credentials work as they did previously (and as documented in the README) with the little addition of the read only user being allowed to do a POST to the new `/pacts/provider/{PROVIDER}/for-verification` endpoint. The PR is here. https://github.com/pact-foundation/pact-broker-docker/pull/22 Reply to this chat if you're interested!
carolyn.biggar
2020-03-26 21:34
Hello again pact broker people - I'd like to set up a notification to slack if the broker receives a "verification failed" update.
I'd like to target a different slack channel per pact (the consumers'; the provider is getting notification via different means (ci pipeline failure).
I only want the notification to fire for a failure.
Is this possible, can you point me to any examples? Thanks!
bethskurrie
2020-03-26 21:43
Make one per consumer. Don't specify the provider (so it matches all providers).
pkuang
2020-03-27 20:15
Hi, what is the intended purpose for pacticipant labels and how do I set them? I cannot find any documentation for this feature. I'm assuming they are to add some metadata to the pacticipant. I was wondering if this could support a workflow where I want to add a particular label "x" to a set of pacticipants and be able to query the broker to give me all pacticipant names that have label "x"?
bethskurrie
2020-03-29 20:51
They were intended to allow you to group services by different areas of the business. It's not an area that has received much interest, so I didn't continue down that path.
bethskurrie
2020-03-29 20:52
You can query pacticipants by label using the URL `/pacticipants/label/{label}` and that's about all.
adadache
2020-03-29 22:29
Hey!
I am looking for help regarding pact-broker?s pending pacts feature.
Here is the setup:
? Consumers publishing pacts from `pact-js`
? Provider pulling pact from broker using `pact-jvm-gradle` plugin
What?s the next step?
bethskurrie
2020-03-29 22:30
Sorry, I did mention this in the other thread, but you must have missed that comment.
bethskurrie
2020-03-29 22:32
You could call the new API directly, and then run each pact verification separately, handling the exit code manually so that the tests don't fail the build when the pact is set to pending=true
bethskurrie
2020-03-29 22:35
It relies on a new API being used to collect the list of pacts to verify. That API is documented here: https://github.com/pact-foundation/pact_broker/issues/307
adadache
2020-03-30 00:40
@bethskurrie and what about using the `pact-provider-verifier` instead?
It seems that the above stuff supports pending pacts.
bethskurrie
2020-03-30 00:43
@adadache there is a standalone verifier process that you can use that supports the pending pacts feature. It's available as a CLI or a docker image https://github.com/pact-foundation/pact-provider-verifier
bethskurrie
2020-03-30 00:43
It only supports v2 pact specification, but if your consumers are javascript, then they're on v2 anyway
bethskurrie
2020-03-30 00:45
You'll also need to run your pact broker with the environment variable `PACT_BROKER_FEATURES=pacts_for_verification`
bethskurrie
2020-03-30 00:46
There's a little script for playing around with the new API here https://github.com/pact-foundation/pact-provider-verifier/blob/master/script/dev/broker.sh
adadache
2020-03-31 17:17
This ends up in Gradle, seriously.
@bethskurrie I?ve got working pendings and verifications are published! yaaay
adadache
2020-03-31 17:19
Eventually, what saves the day is your `--enable-pending` through the dockerized cli! You?ve just made our blog post much more longer :confused:
bethskurrie
2020-03-31 21:17
BTW, I appreciate that you got the self signed certificate working without raising any issues!
bethskurrie
2020-03-31 21:23
Did you have much time doing the verifications before you used the pending feature? I'd be interested to hear how it has affected your experience with Pact.
borsuk.artem034
2020-04-01 10:17
More info for future, inside bitbucket pipelinse when you specify action for
```pull-requests:
'**':
- step: .....```
bitbucket take first 11 symbols commit hash
for anothed action take long commit hash
and as result your verication can fails, for non version counsumer/provider
simon.nizov
2020-04-01 13:02
Hi!
My pactman-powered provider verification passes, but the verification result in the broker appears as failed.
Is there a way to get the verification result endpoint in the broker to display the details of the failure?
antonello
2020-04-01 14:30
I wonder if perhaps not all interactions of your pact are verified by your provider verification tests.
bethskurrie
2020-04-01 19:17
What would you want the broker to be able to do to support that? @borsuk.artem034?
bethskurrie
2020-04-01 19:20
Simon, pactman doesn't send the test level results to the pact broker, as far as I know. It's now unsupported, as the author has changed companies and isn't using pact any more.
borsuk.artem034
2020-04-02 06:38
actually it's bitbucket problem (bitbucket agent have different behavior for 'pull-request' stage).
for pact broker, we can do some matching, but I think its very bad idea, other people will have many problems
simon.nizov
2020-04-02 06:41
I remember when he announced his departure he introduced the person who will be taking over the project. Or am I mistaken? Also, there?s a commit in the project a month and a half ago :thinking_face:
bethskurrie
2020-04-02 07:36
We haven't found any official yet. Elliot Murray has done some work on pact-python, but he may or may not get around to having a look at pactman.
bethskurrie
2020-04-02 07:40
Yes. It uses the shared ruby impl under the hood, so we can easily update it with new features.
adadache
2020-04-02 08:19
@bethskurrie we did not have time with the standard workflow. We needed pending pacts immediately, as the guys are working async, but into a monorepo.
adadache
2020-04-02 08:20
We have an ?affected? pipeline which only executes the java verification once the backend is affected, the same applies on frontend applications (we have multiple clients)
adadache
2020-04-02 08:21
Runs in nightly builds, and prepared for local development too, as we are using tags and app versions for each publish/verification
bethskurrie
2020-04-02 08:35
Hm, that's annoying. The only thing I can think of is to consistently use 11 characters everywhere.
simon.nizov
2020-04-02 17:07
Ok.. too bad, I like `pactman`'s `pytest`-powered provider verification. Let me know if guys are planning anything similar, or other improvements to `pact-python`, I might be able to help out.
waquino
2020-04-02 20:50
Hi! :slightly_smiling_face:
i?m trying to implement the contract testing in my organization, at this point we are evaluating if we should host our own pact broker or just use the pact flow.
could any of you guys share your experience or recommendations?
ryan.dens
2020-04-02 20:54
My company went with pactflow based on a cost/benefit mainly considering developer maintenance. Can?t recommend it enough :slightly_smiling_face:
bethskurrie
2020-04-02 20:54
Hi @waquino I'm a little biased, but here is a list of features you get in Pactflow that you don't get in the OSS product https://pactflow.io/oss/ We're investigating adding things like metrics and OAS contract testing support in the future.
antonello
2020-04-03 06:31
I don?t think the broker has an endpoint to check verification of individual states or interaction, does it?
bethskurrie
2020-04-03 07:17
@antonello if the client supports it, interaction level results are published to the broker. But pactman does not support that, to my knowledge.
bethskurrie
2020-04-03 07:18
Any of the languages that wrap the standalone, and the rust, and I think pact-jvm do.
antonello
2020-04-03 07:18
It?s pact-jvm. But yes, it was a stupid question because I knew already that it wouldn?t publish that.
bethskurrie
2020-04-03 07:20
There will be a bit of code that does the calculation in pact-jvm - maybe you can put a breakpoint there?
bethskurrie
2020-04-03 07:31
@simon.nizov the end goal is for a python implementation that calls out to a shared rust library, from the native python code (so it can be used with pytest).
bethskurrie
2020-04-03 07:31
We might make pactman the base for that - we'll see how it goes when we come to pick up that work.
simon.nizov
2020-04-03 07:41
Sounds good.
Where can I follow the progress of the rust implementation? Is it this one - https://github.com/pact-foundation/pact-reference/ ?
bethskurrie
2020-04-03 07:42
The underling rust impl is done, but the work to make all the code nicely available for other languages and at the right level of abstraction is I think still in progress.
bethskurrie
2020-04-03 07:43
@matt.fellows and @uglyog are working on the pact-js/rust implementation first.
bethskurrie
2020-04-03 07:43
Probably following that work will give you the best idea of where things are at.
ina.lopez
2020-04-05 04:42
I downloaded pact-broker from https://github.com/pact-foundation/pact_broker/tree/master/example
And started it:
```bundle exec rackup```
I am getting:
```scheme must be https. See /doc/webhooks#whitelist for more information.```
Is there a way to enable HTTP for my webhooks?
I am having a lot of problems enabling https locally for my jenkins
ina.lopez
2020-04-07 17:10
Should I create webhooks for `contract_content_changed` and `contract_published`?
If so, broker knows when to run which one?
And both of these webhooks call the same job: Provider CI verify "${pactbroker.pactUrl}"?
rbenbolton
2020-04-07 21:25
Hey everyone,
I?m trying to set up a pact broker locally and instead of using local postgres, as I?ve done in the past, I thought of trying it with the postgres container. I?m trying to run the first command as outlined in the `pact-broker-docker` POSTGRESQL.md for setting up postgresql:
```docker run --name pactbroker-db -e POSTGRES_PASSWORD=ThePostgresPassword -e POSTGRES_USER=admin -e PGDATA=/var/lib/postgresql/data/pgdata -v /var/lib/postgresql/data:/var/lib/postgresql/data -d postgres```
but I keep getting the following error:
```docker: Error response from daemon: Mounts denied:
The path /var/lib/postgresql/data
is not shared from OS X and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> File Sharing.
See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.```
I created the dir `/var/lib/postgresql/data` and enabled file sharing in Docker for Mac which adds it as `/private/var/lib/postgresql/data` and re-ran the `docker run` command, but still get the same error. Thoughts?
rbenbolton
2020-04-07 22:38
This question may no longer need to be addressed. Using `docker-compose` pulls down the image for me and sets it up for the broker service. Still curious about the above, but no longer blocking me.
bethskurrie
2020-04-07 22:39
If you want to run a verification, then just trigger on the contract_content_changed.
bethskurrie
2020-04-07 22:41
You can have as many webhooks as you want, and all the webhooks that match will get fired.
ina.lopez
2020-04-07 23:32
contract-content-changed wouldn't trigger the very first time, correct? I created contract_created also
bethskurrie
2020-04-08 00:15
Here's a more detailed explanation https://docs.pactflow.io/docs/user-interface/#contract-published-with-changed-content-or-tags
siddharth.gupta
2020-04-08 07:40
Hi there , I am beginner with Pact , I have been able to run consumer and provider tests provided at https://github.com/pact-foundation/pact-net. But I have question for the experts , when we test the provider APIs which interacts with an external component for example a SQL db , how do we deal with such scenario when running contract tests on local developer machine . As we do not deploy the services instead use self hosted routing .
rahulpandey8920
2020-04-13 21:37
Hi Siddharth,
I am also a beginner with Pact and came across this interesting article:
https://www.infoq.com/articles/microservices-consumer-driven-contracts-pact-docker/
Where Harry Winser from Rightmove has written about how they are using stubs for any external dependencies of the provider.
> _This ?stub? is used instead of the production artefact throughout the CDC testing, as the artifact doesn?t require data sources or upstream dependencies; they?ve been stubbed out._
rahulpandey8920
2020-04-14 10:00
Is there an official helm chart for PactBroker ? I think this question has been asked before but I am not able to access the conversation history.
matt.fellows
2020-04-14 10:01
It has been asked. Someone had published one but we haven't officially endorsed it or anything
rahulpandey8920
2020-04-14 10:07
Thank you for your response. Is there a plan to publish an official helm chart for this in the roadmap ?
matt.fellows
2020-04-14 10:10
No, and Not that I'm aware. We'd accept it into the foundation of the community supported it and gave it a vote if confidence
bethskurrie
2020-04-14 10:11
Because we have the free version of slack, the answer has dropped out of our storage space.
matt.fellows
2020-04-14 10:41
Oh. I just realised I had a spelling error before. I meant 'np' to answering your q! ( On mobile)
paras.vora1801
2020-04-14 11:36
@bethskurrie I am trying to install the *pact-broker-docker* on my Mac OS, using command
`docker run --name pactbroker-db -e POSTGRES_PASSWORD=root -e POSTGRES_USER=admin -e PGDATA=/var/lib/postgresql/data/pgdata -v /var/lib/postgresql/data:/var/lib/postgresql/data -d postgres`
however, I encounter below error:
`docker: Error response from daemon: Mounts denied:`
`The path /var/lib/postgresql/data`
`is not shared from OS X and is not known to Docker.`
`You can configure shared paths from Docker -> Preferences... -> File Sharing.`
`See https://docs.docker.com/docker-for-mac/osxfs/#namespaces for more info.`
paras.vora1801
2020-04-14 11:39
Moreover, the folder `/var` & all inside, are having the 777 permissions
matt.fellows
2020-04-14 11:39
Is it really important that you use `/var/lib/postgresql/data/pgdata`on your host machine? Can you just bind to another path?
paras.vora1801
2020-04-14 11:40
`docker run --name pactbroker-db -e POSTGRES_PASSWORD=root -e POSTGRES_USER=admin -e PGDATA=/private/var/lib/postgresql/data/pgdata -v /private/var/lib/postgresql/data:/private/var/lib/postgresql/data -d postgres`
matt.fellows
2020-04-14 11:41
Annoying that Docker doesn?t resolve the path, because it?s a symlink anyway. But good that you?ve found a way
paras.vora1801
2020-04-14 11:43
Now, post `docker run --name pactbroker-db -e POSTGRES_PASSWORD=root -e POSTGRES_USER=admin -e PGDATA=/private/var/lib/postgresql/data/pgdata -v /private/var/lib/postgresql/data:/private/var/lib/postgresql/data -d postgres` a running container of the image is expected so that the procedure can be followed - `docker run -it --link pactbroker-db:postgres --rm postgres sh -c 'exec psql -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U admin'`
matt.fellows
2020-04-14 11:46
You don?t need to perform all of these linking and activities. It should just ?start up?
matt.fellows
2020-04-14 11:47
```version: "3"
services:
postgres:
image: postgres
healthcheck:
test: psql postgres --command "select 1" -U postgres
ports:
- "5432:5432"
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_DB: postgres
broker_app:
image: dius/pact-broker
links:
- postgres
ports:
- 80:80
environment:
PACT_BROKER_BASIC_AUTH_USERNAME: pact_workshop
PACT_BROKER_BASIC_AUTH_PASSWORD: pact_workshop
PACT_BROKER_DATABASE_USERNAME: postgres
PACT_BROKER_DATABASE_PASSWORD: password
PACT_BROKER_DATABASE_HOST: postgres
PACT_BROKER_DATABASE_NAME: postgres```
matt.fellows
2020-04-14 11:49
Step 1: Save the file above as `docker-compose.yml`
Step 2: Run the command `docker-compose up`
Step 3: ?wait a little?
Step 4: head to `http://localhost` in your browser
The credentials for access are `pact_workshop`/`pact_workshop` (customise as needed)
waquino
2020-04-16 02:29
Hi
i wonder is is possible to migrate data from the OSS to the pactflow and the other way around?
matt.fellows
2020-04-16 02:30
Data can be migrated both ways, but from Pactflow -> OSS there are limitations (e.g. things like Secrets, webhook configurations etc. won?t translate due to some of the features absent in the OSS version)
bethskurrie
2020-04-16 02:31
We'd be able to help you export from your oss database (assuming it's also Postgres) and import it into a Pactflow tenant.
bethskurrie
2020-04-17 09:47
I've run a script to iterate over the pacts and transfer them from one broker to another before.
bethskurrie
2020-04-17 09:48
It wasn't too difficult. You really only need the latest copies for the important tags.
shilpa3006
2020-04-24 00:40
Hi @bethskurrie I have created a web hook (linked bamboo build plan of provider)in pact broker. Ran consumer tests it created pact file and trying to run webhook...but we hook status shows Retrying
shilpa3006
2020-04-24 00:43
I have installed pact broker gem (ruby) on local...not sure if it?s Pactflow or OSS Pact Broker
bethskurrie
2020-04-24 00:43
```docker run --rm \
-e PACT_BROKER_BASE_URL \
pactfoundation/pact-cli:latest \
broker test-webhook \
--uuid ${WEBHOOK_UUID}```
bethskurrie
2020-04-24 00:45
Otherwise, follow these instructions: https://docs.pact.io/pact_broker/advanced_topics/webhooks/debugging_webhooks#pact-broker
shilpa3006
2020-04-24 00:52
The response details are not logged. To enable a response logging, configure the webhook_host_whitelist property
shilpa3006
2020-04-24 00:59
So, it says to update the config which I am assuming http://config.ru file
shilpa3006
2020-04-24 01:03
Should I restart broker or do I need to change pact file in order to trigger again?
bethskurrie
2020-04-24 02:01
If it's the request that the webhook is making, then it'll be your job to work out how to make the right request first. I'd recommend getting it working with curl first.
shilpa3006
2020-04-24 02:03
URI: http://bamboo.company.com/rest/api/latest/builplanname?os_authType=basic, statuscode:404
shilpa3006
2020-04-24 02:13
For now I am trying postman...not sure where to pass username and pass for bamboo?
mbieganski.infomatt
2020-04-24 13:15
Hey everyone,
I have read Pact Nirvana article :slightly_smiling_face: and now trying to setup Pact and Pact Broker with feature branches. If I understand correctly the idea is to have separate jobs to run tests triggered by web-hook on contract change and all providers pipelines from feature branches and master verify against stable master branch.
Lets have a scenario where I don't have stable tag yet and no separate provider pipeline:
1. Push contract to feature branch with tag
2. Feature branch pipeline pass
3. Push provider to feature branch with pactbroker.tags=master
4. Latest feature branch is verified
Does it mean that master branch will be preverified?
First I have to merge provider to master and then consumer. If I would merge feature provider to master branch with can-i-deploy in pipeline against master consumer it would pass?
bethskurrie
2020-04-24 22:36
Hi @mbieganski.infomatt there are a couple of things about your scenario that I don't understand.
bethskurrie
2020-04-24 22:37
In step 3, which tags are you talking about?The provider version tag, or the consumer?
bethskurrie
2020-04-24 22:38
If you have time to do this workshop, I think it will help you understand your scenario https://github.com/pactflow/ci-cd-workshop/
bethskurrie
2020-04-24 22:41
I'm not sure if you said you're tagging the provider's feature branch with `master` or whether you're verifying the `master` pacts, so it's hard to answer this question.
bethskurrie
2020-04-24 22:41
If you're tagging your provider version with `master` from a feature branch (which is not recommended!!!) then yes, the can-i-deploy query will think that the pact has been pre-verified by the `master` provider (which it hasn't).
bethskurrie
2020-04-24 22:44
The recommended usage would be to tag the provider version with the branch name, dynamically. That way, once the feature is implemented on the branch, the consumer gets the (correct) feedback that the code is done, but it's not yet merged. Then, once the provider feature branch has been merged, and they get a successful verification result from master, they know they're good to merge the consumer.
bethskurrie
2020-04-24 22:44
How these verification results get published is covered here: https://github.com/pactflow/ci-cd-workshop/blob/master/workshop/05_verifying_feature_pacts.md
praneethkumar
2020-04-27 10:33
Hi everyone, I am looking to install pact broker in our paas environment (open shift ). Is there any guide or document that can help ? I looked online but couldn?t find much info
Thanks
Praneeth
shilpa3006
2020-04-27 20:58
Hi Beth.. I have successfully created webhook on pact broker..whenever pact file gets changed, webhook will trigger and provider build gets kicked off for verification...I am clear on this but what happens when provider have changes and has to verify all consumer pacts? How or where should we configure that provider ci?
matt.fellows
2020-04-27 21:27
Look at the docs for provider verification in your language. There should be a configuration to pull pacts from a broker
shilpa3006
2020-04-27 21:37
@matt, I am aware of retrieving pacts for verification but my question was like configuring provider ci flow...like when provider commits changes to their api, in ci - it would trigger( in our case it?s bamboo)the verification of pacts- all this is independent of pact broker except getting pacts from broker right?
bethskurrie
2020-04-27 22:03
> When the provider changes, the pact verification task runs as part the provider's normal build pipeline, generally after the unit tests, and before any deployment takes place. This pact verification task is configured to dynamically fetch all the relevant pacts for the specified provider from Pactflow, verify them, and publish the results back to Pactflow.
> To ensure that a verification is also run whenever a pact changes, we create a webhook in Pactflow that triggers a provider build, and passes in the URL of the changed pact. Ideally, this would be a completely separate build from your normal provider pipeline, and it should just verify the changed pact.
aliihlail
2020-04-27 22:12
```
@ActiveProfiles("test")
@Provider("key-service")
@Consumer("document-service")
@PactBroker
@IgnoreNoPactsToVerify
public class DocumentVerificationTest {
private static final Logger LOGGER = LoggerFactory.getLogger(DocumentVerificationTest.class);
@TestTemplate
@ExtendWith(PactVerificationInvocationContextProvider.class)
void testTemplate(Pact pact, Interaction interaction, PactVerificationContext context) throws IOException {
http://LOGGER.info("testTemplate called: " + pact.getProvider().getName() + ", " + interaction);
context.verifyInteraction();
}
@BeforeEach
void setupTestTarget(PactVerificationContext context) throws IOException {
context.setTarget(new AmpqTestTarget());
}
----------------------
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.22.1</version>
</plugin>
<plugin>
<groupId>http://au.com.dius</groupId>
<artifactId>pact-jvm-provider-maven</artifactId>
<version>4.0.10</version>
<configuration>
<serviceProviders>
<serviceProvider>
<name>key-service</name>
<pactBroker>
<url>https://XXXXXXX.pact.dius.com.au:443/</url>
<authentication>
<scheme>bearer</scheme>
<token>1-A-XXXXXXXXXXX</token>
</authentication>
</pactBroker>
</serviceProvider>
</serviceProviders>
</configuration>
</plugin>
Im trying to run the code which i have cut part of it above. when i use the Spring it works. But when i use @ExtendWith(PactVerificationInvocationContextProvider.class)```
i got the following error : java.lang.IllegalArgumentException: Invalid pact broker host specified ('${pactbroker.host:}'). Please provide a valid host or specify the system property 'pactbroker.host'.
mbieganski.infomatt
2020-04-28 14:55
@bethskurrie Thank you very much. Workshop was really useful and I ended up with below setup:
1. Normal Provider pipeline run tests against consumer tagged master and prod. Additionally for master branch it runs can-i-deploy --to prod and creates version tag
2. Webhook provider pipeline - it's using pact url and consumer tags passed from webhook triggered by 'contract content changed'
3. Consumer pipeline - publish contract, can-i-deploy --to prod
Is it possible to use pending pacts and wip in junit implementation? I have noticed that url is supported from 4.0.6
waquino
2020-04-28 19:15
Hi :slightly_smiling_face:
does anybody know how big the POSTGRESQL database should be to deploy the OSS pact broker?
uglyog
2020-04-28 23:04
Not big at all. My calculations show that an empty broker database uses about 100Mb disk space, and for a broker that has been running for a while I've seen about 650Mb of disk space used by data
bethskurrie
2020-04-29 23:55
The pact content gets deduped, so only unique documents are saved in the database.
bethskurrie
2020-04-30 05:49
I believe that the ability to run a verification without it failing the build is not yet supported @mbieganski.infomatt
shilpa3006
2020-04-30 15:00
Hi Beth, Pact broker is on my local machine. So, able to access using local host url. When I tried with ip instead of localhost, it?s not working and hence not able to integrate in CI. Can you please let me know if I need to change any configuration to get this working?
matt.fellows
2020-04-30 22:11
Also, this is a networking question. You need to ensure your IP address within the network is publically accessible to the network
matt.fellows
2020-04-30 22:12
We can debug that for you I'm afraid, I'd recommend finding an operations like person that knows how it's all setup
shilpa3006
2020-05-01 00:13
Also, another question- if we don?t want to use pact broker and just use Common bitbucket repo between consumer and provider that should work right?
bethskurrie
2020-05-01 00:14
A CI/CD pipeline that prevents breaking changes being deployed is not possible without a Pact Broker.
bethskurrie
2020-05-01 00:15
You'll need to work out how to communicate the status of the verification results from the provider back to the consumer.
bethskurrie
2020-05-01 00:15
You'll need to work out how to trigger a verification build of the provider when the pact content changes (and ideally only when it changes).
bethskurrie
2020-05-01 00:16
You'll have to manually work out how to make the prod pact available so that you can ensure backwards compatibility.
bethskurrie
2020-05-01 00:18
You're not going to get the full value of using Pact. The actual Pact generation and verification is only a very small part of the overall picture.
shilpa3006
2020-05-01 00:18
We are not deploying in prod using ci/cd. We currently use it only in test regions
bethskurrie
2020-05-01 00:19
Well, pacts in repositories are better than no pacts - just keep in mind that there's a much bigger picture than just that.
shilpa3006
2020-05-01 00:26
As far as I understand, pact is very useful if a provider has multiple consumers and would give confidence to both providers( before deploying) and consumers (only when interactions change). If consumers are good with initial interactions or initial pact and if we don?t anticipate more changes from consumer then what would be the role of pact broker?
bethskurrie
2020-05-01 00:32
You're right, it's more useful when interactions are changing. For that particular consumer/provider, if there are no changes, you should be fine. The thing is... how far in the future can you see? :wink:
kaypee90
2020-05-01 13:51
I am trying to verify and publish my verification results to the pact broker but I am getting this message ```Cannot publish verification for Business-Report-BFF as there is no link named pb:publish-verification-results in the pact JSON. If you are using a pact broker, please upgrade to version 2.0.0 or later. ```
bethskurrie
2020-05-01 21:18
The answer is no - if it's a very old version of the broker, it doesn't support publishing verification results. You'll have to upgrade. It should be straightforward.
simon.nizov
2020-05-02 12:22
Hi all,
In my company we have multiple deployed environments, where each environemnt has a matching branch in each service repo. Each of these branches is considered a ?stable? branch that I would like to publish pacts and run pact verification for, seperately and independently.
I have recently set up our CI so that the consumer service publishes pacts with the tag of the branch, and the provider runs verification on the pact that has a tag that matches the environemnt being deployed.
For example, a push to the `qa` branch of the provider service will trigger a build that will run pact verification with the latest pact tagged with `qa`. If the verification is successful, the results will be published to the broker and the service will be deployed to the `qa` environment.
This works well so far, however, if I now publish a pact in the `develop` env/branch, it will be considered the latest pact and the broker will display the pact ?Last verified? column in yellow.
Due to this mismatch between envs, that column is yellow almost all the time :disappointed:.
Has anyone else encountered this? Looks like the broker is not built for this kind of use.
Should I be publishing results in only one branch/env?
mbieganski.infomatt
2020-05-03 12:24
Hi :slightly_smiling_face:
I have small problem with broker and I'm wondering if I haven't messed up the configuration somewhere along the way. It's running on k8s.
When I use below auth with scheme = "https" everything works just fine
```@PactBroker(host = "http://my.broker.eu", scheme = "https",
authentication = @PactBrokerAuth(username = "user", password = "passsword"))```
When I try to use token
```
@PactBroker(host = "http://my.broker.eu", scheme = "https",
authentication = @PactBrokerAuth(token = "sometoken"))```
I'm getting `Request to path '/' failed with response 'HTTP/1.1 400 Bad Request'`
When I remove scheme as it's deprecated in both scenarios I'm getting
`Request to path '/' failed with response 'HTTP/1.1 308 Permanent Redirect'`
Any ideas? Thanks!
matt.fellows
2020-05-03 23:18
Are you using a Pactflow broker or your own? Only Pactflow supports token based authentication
bethskurrie
2020-05-03 23:21
@simon.nizov you can switch to the tag view. There's a link at the top right that says "show latest tags".
bethskurrie
2020-05-03 23:22
You can choose which tags to show https://github.com/pact-foundation/pact_broker/wiki/UI-Documentation#v2110-and-later
srinivasan.sekar1990
2020-05-07 12:12
Hi @bethskurrie Hope you are doing good. Have a query. We have a consumer who consumes data from two different provider micro-services where two provider micro-services has a separate pact broker each. Is it possible to publish to two different broker?
srinivasan.sekar1990
2020-05-07 13:35
Consuming from different vendor's and they maintain it on their own :(
praneethkumar
2020-05-07 14:57
Hi All , we are trying to deploy pact broker in our open shift platform , but getting the below error . ?Error : container has runAsNonRoot and image has non-numeric user(Ruby) ,cannot verify user is non-root ? . Did anyone come across this issue ?
matt.fellows
2020-05-07 21:41
You may want our puma edition which doesn?t need this: https://github.com/pact-foundation/pact-broker-docker#notes-migration-from-diuspact-broker-image
bethskurrie
2020-05-07 21:49
Depending on your language, you should be able to filter to only publish the pacts that you want to each broker.
bethskurrie
2020-05-07 21:50
If you can't for some reason, you can just do a PUT to the correct URL like so: https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts#publish-using-http-requests
shilpa3006
2020-05-08 03:12
Hi Matt/Beth..I am able to access other website on my machine externally but not pact broker...Able to ping my machine from other machines as well...but unable to get to pact broker...can you let me know how I can overcome this issue?
bethskurrie
2020-05-08 03:14
But there could be any number of issues like firewalls, being on the wrong subnet... it's too hard to diagnose the issue on someone else's machine I'm afraid.
bethskurrie
2020-05-08 03:14
Your best bet is to ask an ops person in your company to give you a hand.
bethskurrie
2020-05-08 04:25
If you're starting it manually with the rack command (I have some memory that you're not using docker) then you need to add `-o 0.0.0.0`
matt.fellows
2020-05-08 05:02
We?d be keen to hear more about that use case if you?re able to elaborate.
srinivasan.sekar1990
2020-05-08 05:04
Sure Matt. Team consumes data from two different microservices from two different vendors. They have their own pact broker. So as a consumer of both microservices, we need to define individual contracts with each of the two broker.
matt.fellows
2020-05-08 05:05
Wow, so you have 2 separate vendors with Pact Brokers and they want you to publish pacts to them - may I ask who they are?
matt.fellows
2020-05-08 05:07
Interesting. It?s rare that one company would have a pact broker and make you publish to it. having two is also rare. If you?re willing to share in a DM I?d love to know more
matt.fellows
2020-05-08 05:08
Partly why it?s interesting, is that the broker isn?t optimised for this case, so it?s useful feedback
morten.hekkvang
2020-05-08 07:01
@bethskurrie Thanks for the fast response and merge of my Issue and PR on Github!
bethskurrie
2020-05-12 03:23
for those using the dockerized version of the Pact Broker, please note that the format of the tag has changed from `M.m.p-RELEASE` to `M.m.p.RELEASE` (dot instead of dash) so that Dependabot can pick up when there has been a version change.
borsuk.artem034
2020-05-12 13:17
Hello, I'm stack with deploy new app version(new pact stages was added). Can somebody help, maybe I missing something?
My setup are:
1. Pact-broker with tagged environments (prod)
2. Already running verification via can-i-deploy for both sides
```.... broker can-i-deploy \
--pacticipant $APP_NAME(frontend or backend) --version $version(SHA) --to $ENVIRONMENT(prod)```
Problem: when pact is updating for fronted(31f7415) and backend(8242455). As a result I have success verification in PB (first line on screenshot), I can't deploy new version to "prod" environment because "There is no verified pact between.... frontend with tag prod and backend"
What I should do for deploy new app versions? and save existing behavior with tagging?
matt.fellows
2020-05-12 13:31
`8242455` has not yet been deployed to production, assuming you create a version tag `prod` when that happens
matt.fellows
2020-05-12 13:32
that table says frontend version `31f7415` is compatible with the backend `8242455` but not the current `prod` version `f00dc94`
matt.fellows
2020-05-12 13:32
You need to a) deploy `8242455` to production b) tag it `prod` and then deploy your consumer
borsuk.artem034
2020-05-12 13:49
but for deploying `8242455` I need to disable "can-i-deploy" step on provider side, (or do the disabling on consumer), but I don't want do that(deploy scripts stored in repo, it is few more commits for pact), I don't see possibility to deploy new version without changing script and revert this changes
borsuk.artem034
2020-05-12 14:07
I need to deploy new version of backend, and I will have a broken environment until new frontend version will be deployed, in the same time pact (can-i-deploy) prevent that situation, I'm really confusing now
tyler.rasor
2020-05-12 14:13
can you verify backend `8242455` with the current prod-tagged frontend `ecca3b2`?
borsuk.artem034
2020-05-12 16:08
@tyler.rasor thanks for a good question, I was had missing verifications because provider do verification just for `latest` pact, but should be also checked `prod` tag (`ecca3b2` was no latest)
bethskurrie
2020-05-13 07:07
There was an issue a while ago that stopped the provider being deployed without the consumer, but that's been fixed for a while.
bethskurrie
2020-05-13 07:10
```* allow provider to be deployed to an environment without the consumer having to be deployed there already (125c2722)```
borsuk.artem034
2020-05-13 07:34
It is my fault for that issue, in provider I'm checked just `latest` contract, but we have 5 tagged environments. And as a result, missing verification has appeared, between old commits for `test` tag and `latest` contract version
borsuk.artem034
2020-05-13 08:20
yep, in provider jvm add tags in annotation
```@PactBroker(......., tags = {"test01", "test02", "test03", "superTest", "prod", "latest"})```
after build provider I will have verification results for each deployed version and latest contract
bethskurrie
2020-05-13 09:17
@siddharth.gupta it's the same. You just point the Pact Broker base url at your Pactflow account.
bethskurrie
2020-05-13 09:22
There's a new docker release out peeps. It's got a few little vulnerabilities fixed.
bethskurrie
2020-05-13 09:24
Remember to keep updated! Every few months github raises a vulnerability for some gem or another, so it's best to keep up to date.
dan.garland
2020-05-13 10:20
Hi all, what changes to the pact workflow are people using when using squash commits? We're currently having to re-publish pacts from our pipeline after merging into master to update the broker with the new sha created after squashing, so that it inherits the previous verification result. Is there a better way? What is the best practice?
bethskurrie
2020-05-13 10:20
You've made a new consumer version, effectively. You need to associate the new pact with that consumer version.
matt.fellows
2020-05-13 10:22
I don't see that causing issues, aside from maybe ggravating any inherent OCD it brings on knowing you have to do it twice :laughing:
bethskurrie
2020-05-13 10:24
If your CI runs on every commit, wouldn't it just automatically re-publish the pact anyway?
bethskurrie
2020-05-13 10:24
If I've got a PR open, and I squash all the commits in that PR, then the build runs when I push my squashed commit.
bethskurrie
2020-05-13 10:25
If I squash on merge, then the build runs for the merge commit too. Both of those would be publishing a pact without me having to take any action because the pact publication is part of the build anyway. I'd have to change to something to make it *not* publish a pact.
bethskurrie
2020-05-13 10:27
The broker detects duplicate pacts anyway, so it doesn't create a new JSON blob, it just creates a new association between the blob and the consumer version. You can republish the same pact as many times as you like without affecting the size of the database in any significant way.
dan.garland
2020-05-13 10:39
No that's our setup too - it's just if we were running merge commits the SHA wouldn't change from when the verification runs in the PR environment to when our master build pipeline runs, so there wouldn't be a need to re-publish the pact, whereas since we follow a squash commit strategy unless we republish the pact on master with identical content the broker won't know about the new SHA... so seems like publishing twice is the only way to do it
bethskurrie
2020-05-13 10:40
you'd have to write logic to detect it was a merge commit and then turn off the publishing... or am I missing something here?
bethskurrie
2020-05-13 10:41
pretty much every pact publication is identical to the one previous to it. think how many times you change the pact vs how many times you commit.
bethskurrie
2020-05-13 10:43
the fact that the content is generally identical to the previous commit is actually one of the value props of using a Pact Broker over some DIY workflow - the duplicate detection and "pre-validation" means you don't have to wait for the provider build to run and publish its results 99% of the time.
ppaduch
2020-05-13 20:08
Hi All , I would like to start using pending pacts. As far as I know it is in beta testing phase. On our site we have been tagging contracts and use can-i-deploy. Where could I get instructions how to implement and use this new interesting feature ? Thanks , Pawel
bethskurrie
2020-05-14 05:54
Follow this step of our CI/CD workshop https://github.com/pactflow/ci-cd-workshop/blob/master/workshop/02_protecting_the_provider.md
bethskurrie
2020-05-14 05:55
And if you're using the OSS Pact Broker (rather than pactflow) you'll need to set an environment variable for the broker.
antonello
2020-05-14 06:42
Hello! I was looking through the change log of recent releases and I found this:
https://github.com/pact-foundation/pact_broker/commit/bc457492
What clean feature is it referring to? Is there now some cleanup functionality available through the ui?
bethskurrie
2020-05-14 07:04
I've written the code, but haven't exposed it through an api yet @antonello
bethskurrie
2020-05-14 07:05
I want to add a configurable task that runs once a day on a cron to clean up old data.
antonello
2020-05-14 07:05
I did a bit of cleanup in the last couple of days and it it was quite laborious as it had to be done in batches
antonello
2020-05-14 07:27
I need to spend up some time to write some more selective queries based on tags
antonello
2020-05-14 16:10
Is it possible to delete a TAG completely for a pacticipant and not just delete it from a specific version?
bethskurrie
2020-05-14 21:56
Delete every single instance of that tag for a pacticipant @antonello? No - but feel free to raise a feature request issue for it.
antonello
2020-05-14 22:14
I assume that all versions can be deleted already? I think I saw somewhere a resource for all versions with a specific tag
raghu.alapati1
2020-05-16 01:40
HI Team, please can you some one shed some light on the below error when trying to publish... ""publish:pact": "pact-broker publish ./pacts --consumer-app-version=1.0.0 --broker-base-url --broker-base-url https://testbank.pact.dius.com.au --broker-token 91x4qt7fEK6slF_IvEEDaA". Error>>. Publishing Consumer/Provider pact to pact broker at https://testbank.pact.dius.com.au
Failed to publish Consumer/Provider pact due to error: PactBroker::Client::Error - Authentication failed
raghu.alapati1
2020-05-16 01:43
honestly tried before...but it failed. Sincere apologies for a silly question.
antonello
2020-05-18 08:45
Do you reckon it would be useful to just be able to remove a tag from all versions?
antonello
2020-05-18 08:46
it would be in our case, but I wonder if I should create an issue if it?s something that you think would be an isolated case
bethskurrie
2020-05-18 08:47
Nobody else has asked for it in 7 years. But you guys have more data than almost anyone else, so your use cases are different.
bethskurrie
2020-05-18 08:48
You could put it in http://pact.canny.io and see if anyone else votes for it
praneethkumar
2020-05-18 14:09
Hi All , if anyone has successfully deployed the pact broker puma version to open shift , can you please share the yml if you can ?
bethskurrie
2020-05-19 07:07
@praneethkumar does the example not work? https://github.com/pact-foundation/pact-broker-docker#running-with-openshift
mike.geeves
2020-05-20 10:43
Question - we are running the pact-broker via docker, where we deploy everything into a k8s cluster which then has an API gateway, and deployments are then wired in automatically. That works to an extent for pact-broker, but the UI is "broken" due to the fixed path, as per:
_PACT_BROKER_BASE_URL - optional. If you find that the URLs generated by the API are using an IP instead of a hostname, you can set this environment variable to force the desired base URL. Must include the port if it's a non-standard one. eg. `https://my-broker:9292`. Is not currently used for links in the UI._
For now I've just set it up as a special case to have an IP all to itself which works but isn't ideal (small additional cost, bypasses our auth etc).
I can't see anything in the issues about this - does anyone know if it's planned to be implemented at some point? (I haven't looked through the code to see if there's some horrible complexity that means it works ok for one part but not the rest)
bethskurrie
2020-05-20 21:33
I think the reason this happens is that the x forwarded headers aren't set, so when it's recreating the incoming request, it only knows about the last hop to the IP, not the original request to the host name.
bethskurrie
2020-05-20 21:33
It probably wouldn't be too hard to fix the UI links, it's just not bubbled to the top of the priority list.
bethskurrie
2020-05-20 21:34
I'm surprised it affects the UI though - I thought they were all relative links :thinking_face:
mike.geeves
2020-05-20 22:34
I think all the styling, it's an extra level of reverse proxy than is covered there, our general approach is project ag-pact-broker for example is wired in as http://our.api.com/ag-pact-broker i.e. the project name becomes the path. I didn't check the HAL browser :thinking_face:
Can try and provide a SSCCE / look at links in the morning if helpful (or possibly take a look if a issue+MR would be small enough?)
mike.geeves
2020-05-20 23:16
will attempt to take a look although dependence on how much ruby specific vs general dev skills involved :slightly_smiling_face:
bethskurrie
2020-05-20 23:54
I've started work here https://github.com/pact-foundation/pact_broker/pull/344
mike.geeves
2020-05-21 12:52
Oh thank you, I wasn't expecting a fix right away :slightly_smiling_face: I'm going through outcomes from our pact spikes to figure out what to plan in next etc.
I think I need to adjust my phrasing on here, I'm not used to.... quick positive interactions. Jaded :joy: Appreciated :slightly_smiling_face:
bethskurrie
2020-05-22 05:59
It should allow you to set PACT_BROKER_BASE_URL to something that has a path.
deepakverma
2020-05-26 00:42
So I have a working pact with postgres. followed the doc https://github.com/DiUS/pact_broker-docker/blob/master/POSTGRESQL.md and seems working fine. One question why pact need ALL permission on postgres. is there any suggested min permission we can set than using `GRANT ALL PRIVILEGES` . doc link will be great help
deepakverma
2020-05-26 00:45
Thanks @bethskurrie much appreciate it. if we explicitly provide create and delete that should do the trick as well. currently user has all the elevated privileges. and if i have to run the test through external CI it seems to be quite exposed
deepakverma
2020-05-26 00:52
yes you made a valid point. i am concerned that user has drop permission not on other but its own database. there is some level of disruption involved here.
bethskurrie
2020-05-26 00:54
well, just make sure you've given the user everything it needs if you're going to go down that route.
bethskurrie
2020-05-26 00:55
if you can delete a table... you can delete everything in the whole database though.
bethskurrie
2020-05-26 00:55
to give the app enough permissions to be useful, you already give it enough to be dangerous.
bethskurrie
2020-05-26 00:56
I think the best approach to mitigate this is to ensure you have a good backup scheduled.
bethskurrie
2020-05-26 00:58
the other alternative, now I think about it, is to turn off the automigrations, and run the rake task yourself with a completely different user than the one you configure the app with.
bethskurrie
2020-05-26 00:59
you'd need to ensure that you'd run the migrations before you applied any upgrade to the app code.
mike.geeves
2020-05-26 09:21
The pact broker goes in its own schema, so you only need to have perms for that schema rather than the whole db as far as I understood. We just created the schema, granted full access within the schema, and then it did the rest via the migration
(didn't do the steps myself, but that's my understanding from the person who went through the setup on our side)
bethskurrie
2020-05-26 09:22
The terminology is somewhat overloaded - I mean "schema" when I say "database".
mike.geeves
2020-05-26 09:24
you think that's a problem, we work in agriculture... so there's a "field" table :facepalm:
praneethkumar
2020-05-28 11:10
Hi all ,
I am trying to install broker in open shift and getting below error .
chmod: changing permissions of ?/var/lib/pgsql/data/userdata : Operation not permitted.
Did anyone face similar issue ?
matt.fellows
2020-05-28 11:31
My point is, basically, that you should google how to run postgres on OpenShift (it doesn?t look to be a Pact broker issue)
praneethkumar
2020-05-28 17:09
We managed to fix the issue ..now when I access the broker url it is asking for username & password . Are there any default values ?
bernardoguerr
2020-05-28 17:45
I think if you didn't set any , on the OSS you can just press enter with no values there (I think there's a flag to prevent that too, iirc)
samuel.hodgkinson
2020-05-29 16:26
Is there a way to track build url or git repository or something on the open source broker? Some extra metadata we can send when posting pacts or something? Would be useful for seeing who owns what and tracking down errors
bethskurrie
2020-05-29 22:02
Also, you can send the build url with the verification results, but not all clients make it available in the api. Raise an issue if it's missing in yours.
bheemreddy181
2020-06-02 22:26
Team , quick thought around pact broker - right now on pact broker when ever we look at each pact it shows the request from the consumer and the expected response but it doesn?t talk about the matchers in that unless I do GET on pacts. I think it will be good show the matchers as well directly when we look at each pact rather than doing a GET again thoughts ?
bheemreddy181
2020-06-03 00:51
Ah got it :) can you share the look and feel for it ? On the Pactflow will take a look and see if I can submit a PR
mbieganski.infomatt
2020-06-03 14:07
Hi. I have a question about displaying pending pacts in Pact Broker. Once this feature is enabled In my case when contract is changed it will trigger web-hook of provider verification job. Previously without this pending feature enabled job would fail but now it passes.
Is it correct that Broker on the Matrix shows that Pact was verified and main page that Pact has changed. Shouldn't fail status be displayed? Unless I'm doing something not right.
bethskurrie
2020-06-04 08:36
If there was a verification failure that is - if it passed, it'll be successful.
mbieganski.infomatt
2020-06-04 08:39
but with pending pacts should pipeline fail when verification test fail or it should still pass but in broker marked as failed?
bethskurrie
2020-06-04 08:41
Oh, on the webhook, if you're passing the URL through, it won't do the pending thing.
mbieganski.infomatt
2020-06-04 08:41
I read it that's why I'm confused. I have also asked @uglyog in this thread https://pact-foundation.slack.com/archives/C9UN99H24/p1591245684425900
bethskurrie
2020-06-04 08:42
One when the consumer changes, and the pact url gets passed directly to be verified, via the webhook.
bethskurrie
2020-06-04 08:42
Two, when the provider changes, and it fetches the configured pacts by tag name.
bethskurrie
2020-06-04 08:43
The webhook verification build is meant to be off side, not the main provider build
phil.endsley
2020-06-04 13:11
We're just starting to dip our toes into pacts. We're using Pact Broker and have some contracts being published and verified. Our next step was to start utilizing tagging and can-i-deploy.
For the most part, everything makes sense. The part I'm hung up on is tagging for prod. My understanding is that we would tag prod when we deploy. But what happens if a deployment/release needs to be rolled back?
From what I understand, we would still be verifying contracts and calling can-i-deploy against the latest prod tag, which would be the version/release that was rolled back. How is this situation supposed to be handled?
matt.fellows
2020-06-04 23:22
Standard advice is that you would always verify the `prod` tag and also the tag that represents what?s going out next (e.g. `master`)
matt.fellows
2020-06-04 23:22
If you rollback, you can always re-apply the `prod` tag to what is in prod (i.e. the rolled back version)
matt.fellows
2020-06-04 23:23
How you do that tagging is going to depend on how you rollback of course
matt.fellows
2020-06-04 23:23
if the rollback is a deployment, then that should be easy - tag the same way you do a normal release
matt.fellows
2020-06-04 23:23
if it?s different you?ll need to update the rollback process to add the version tag
bethskurrie
2020-06-04 23:26
The logic for "the latest prod pact" is done by finding the most recent application version that has a pact, that also has the 'prod' tag. The ordering is based on the order of the application (pacticipant) versions, not the ordering of when the tags were made.
bethskurrie
2020-06-04 23:26
If you need to rollback, you must delete the prod tag from the version you undeployed.
bethskurrie
2020-06-04 23:27
I've got an issue for making the CLI for that in the pact broker client, but in the meantime you can just send a DELETE to the tag resource which will be at `https://your-broker/pacticipants/PACTICIPANT/versions/VERSION/tags/prod`
matt.fellows
2020-06-04 23:29
Is that in our CI/CD guide? that would be a good addition to add (rollback)
bethskurrie
2020-06-04 23:29
Not many people rollback these days so it doesn't come up very often :stuck_out_tongue:
phil.endsley
2020-06-04 23:30
Thanks. This was the workaround I came up with today. I wish we were stable enough to avoid them :slightly_smiling_face:
phil.endsley
2020-06-04 23:30
It takes a lot of momentum to change a company's culture. We'll get there some day
slack.pact.io
2020-06-05 11:42
Hi all, I have question: for outgoing webhooks is there a way to skip ssl validation? something like `--insecure` on curl?
slack.pact.io
2020-06-05 12:57
Thanks Matt! I am trying to overcome what I think is a URL mismatch issue. But also I didn't know there is a whitelist for webhooks that I also need to setup :smile:
We are using the dockerised version (actually the old dius one) and I saw the `PACT_BROKER_DISABLE_SSL_VERIFICATION` env var on the docs for pact-foundation/pact-broker-docker. Just wondering if there is a way to set this up on case by case basis and not globally
bethskurrie
2020-06-05 21:21
There isn't an individual flag @slack.pact.io unfortunately. It's all or nothing. Is uploading the certificate not working?
arindam.datta
2020-06-06 05:14
Hi, can anyone please help me with a proven workflow of CI-CD for both Provider and Consumer? Just block diagram would do. I am finding this part pretty complex and hard to decide the flow. I know that probably I am asking for too much. But I found members of pact slack channel so helpful which gave me confidence to ask for such a help.
bethskurrie
2020-06-06 05:25
Sorry, this is not the page I want to send, but we've just converted our docs to a new site, and this image hasn't made its across yet
bethskurrie
2020-06-06 05:26
Also have you seen the ci/cd workshop? https://docs.pactflow.io/docs/workshops/ci-cd/
mbieganski.infomatt
2020-06-07 19:38
hi. How to handle can-i-deploy in cd when deploying provider first time for consumer with given tag e.g "prod" when it haven't been deployed yet as well?CI/CD pipeline after merging to master runs can-i-deploy, deploy and tag.
slack.pact.io
2020-06-08 09:49
Thanks Beth. I haven't tried with the custom certificate yet. Without being 100% certain, I don't it would work though, as my main problem is that the certificate is made for a different URL. I am trying to route the connection via a VPC endpoint (whose url is `http://something.vpce.amazonaws.com` that ultimately connects to a service presenting the certificate for `somethingelse.mydomain.local`).
One thing I could try for this would be to make a new certificate that includes the `http://amazonaws.com` URL but that might be an overkill.
bethskurrie
2020-06-08 09:52
You can raise a feature request at http://pact.canny.io and see if it get some votes.
bethskurrie
2020-06-08 09:53
@mbieganski.infomatt when it's a provider only, you can deploy to any environment for the first time.
bethskurrie
2020-06-08 09:54
You can't deploy a consumer for the first time to a given environment without the provider being present however.
bethskurrie
2020-06-08 09:55
So, basically, you can run "can-i-deploy --pacticipant some-app-that-is-only-a-provider --to <any-environment>" and it will pass.
bethskurrie
2020-06-08 09:56
If you tried that with a consumer, it would fail because it requires the provider to already be there.
mbieganski.infomatt
2020-06-09 15:18
Hi. Is it correct behaviour that even when contract hasn't changed after new commit there is warning in Pact Broker "Pact has changed since last successful verification by.." I might be crazy but I think it didnt work this way :thinking_face:
phil.endsley
2020-06-09 15:30
I'm relatively new to Pacts, but this is not how I understand it to work.
Are you sure the contract is identical? Here's a link on how to see what changed. https://github.com/pact-foundation/pact_broker/wiki/How-to-see-what-has-changed-in-a-pact
Pact Broker hashes the pact file. If the hash hasn't been seen, the contract has changed, and it needs to be verified. If it has been seen, Pact Broker will reuse the verification results for any versions that have already been verified. https://docs.pact.io/getting_started/versioning_in_the_pact_broker#consumer-application-versions
mbieganski.infomatt
2020-06-09 19:30
Looks like the problem `matchPath(String pathRegex)` . When I use `matchPath(String pathRegex, String path)` it works. I'm pretty sure it worked before.. wondering if it's Pact Broker, java implementation issue or expected behavior.
matt.fellows
2020-06-09 23:34
If you don?t pass a specific path (the second argument) Pact JVM generates a random one
matt.fellows
2020-06-09 23:34
that will be different each time, and so will result in a new contract each time
sandhyareddy019
2020-06-12 07:42
Hi, i am new to this tool. can any one help me how to go along with pact ? like how to install pact in windows and using jenkins i want to test pact, is there any plugin for pact in jenkins.
bethskurrie
2020-06-12 08:02
Reading http://docs.pact.io is the best way to learn about pact. There is no Jenkins plugin because it runs from within the test suite of the codebase.
bethskurrie
2020-06-12 08:05
You can you can try it out online here https://docs.pact.io/5-minute-getting-started-guide
bethskurrie
2020-06-12 08:07
Learn the theory, and then apply it to jenkins. There's nothing special about Pact on jenkins
bethskurrie
2020-06-12 08:09
It's like asking, "I want to learn how to run tests on jenkins". You run tests on jenkins the same way you run tests on any CI system.
sandhyareddy019
2020-06-12 08:10
yeah to test in jenkins is there any plugins to be added in jenkins for pact ?
matt.fellows
2020-06-12 10:39
Once you've got some tests running locally you can then install on jenkins
matt.fellows
2020-06-12 10:40
You're asking in the pact broker channel. Is that because you want to know how to install the pact broker?
mbieganski.infomatt
2020-06-12 14:16
@matt.fellows Was it always this way? I'm just wondering what is the point of having match implementation without example value?
sandhyareddy019
2020-06-15 06:56
Hi, i want to create API in mulesoft and use pact in it. later i want to test pact using jenkins platform . is that possible ? and i am confused how to start with pact in mulesoft.
matt.fellows
2020-06-15 06:57
If a) you can write a consumer test, b) you can verify the API and c) can script in Jenkins, then you can do anythnig
matt.fellows
2020-06-15 06:59
so if you can script in Jenkins, there is no reason why it wouldn?t work with Jenkins
matt.fellows
2020-06-15 06:59
This is a travis CI example though: https://docs.pactflow.io/docs/workshops/ci-cd/
matt.fellows
2020-06-15 07:00
are you talking about running the Pact Broker (or using http://Pactflow.io) or the CI/CD process altogether?
sandhyareddy019
2020-06-15 07:04
ok excluding mulesoft can you help me with any example file of how pact is implemented in an api . so using that i can create in mulesoft
matt.fellows
2020-06-15 07:05
have you read the docs? There is an entire workshop mentioned there that would be worth doing
sandhyareddy019
2020-06-15 07:09
i saw many articles mentioning about docker ? i didnt get that . is docker mandatory to get in with pact?
sandhyareddy019
2020-06-15 07:12
even in the above link in travis they mentioned docker service. i am unable to figure it out relation between docker and pact
matt.fellows
2020-06-15 07:14
It?s just a convenience thing. In that workshop, we use Pact CLI tools and run them in docker containers. Running things in docker makes it much more portable across CI systems, and because docker is so popular, we?ve made it part of our examples
matt.fellows
2020-06-15 07:14
Docker is just the runtime for CI and can be a runtime for the pact broker. It?s not required for Pact testing, albeit most people likely use Docker in their CI builds somewhere
matt.fellows
2020-06-15 07:15
Think of Pact as a unit testing framework, and Pact Broker (and related tooling) as a CI/CD tool
josh.mccure
2020-06-15 23:36
Hey all - a bit of a theoretical question here.
We've implemented PACT with the PACT broker and looking at how `can-i-deploy` fits into the CI/CD pipeline. Is it a good idea for this to be blocking the first deployment to an environment if it fails (This is Dev Environment for us)?
Interested to know how this fits into your deployment process from Dev -> Staging -> Production
abubics
2020-06-16 00:04
Yes, I usually block deploys to any environment that expects shared components to be able to talk to each other without error :slightly_smiling_face:
abubics
2020-06-16 00:05
But it also depends on what the intent of those envs is. What do y'all use that dev env for, how is it different to staging & prod, and do you run other tests in isolated envs before shared deployments?
matt.fellows
2020-06-16 00:10
I prefer to prevent the deployment, because that?s usually a sign the workflow isn?t setup right and you?re just kicking the problem can down the road (i.e. to prod)
matt.fellows
2020-06-16 00:10
also in case you haven?t seen it, https://docs.pactflow.io/docs/workshops/ci-cd/ might be helpful
josh.mccure
2020-06-16 00:14
Yeah my thinking is that it makes sense for this to be blocking for any deployment. Thanks for both your input.
I think we will slot it in before deployment to Dev environment.
bethskurrie
2020-06-16 00:18
@josh.mccure for a full blown set up, you'd do it before every environment, tag with the environment name when you deploy to that environment, and then make sure your provider verifies the pact for each environment. That way, you build up a complete matrix of compatibility between each application in each env, and you will be able to release at any time.
bethskurrie
2020-06-16 00:20
new docker images are out for 2.57.0 There have been a few vulnerabilities fixed in Rack over the last few months, so always make sure you're up to date!
mbieganski.infomatt
2020-06-17 14:00
Hi. Pact Broker can't parse AMQP contract `Could not parse the following content to a Pact due to Pact::UnrecognizePactFormatError This document does not use a recognised Pact format` and I'm nor really sure what is the issue, everything looks ok. It wouldn't be bad but looks like if there is more than interaction Provider can only handle first one and then throwing `1.1) Uncaught exception during scan` which is `java.lang.OutOfMemoryError: GC overhead limit exceeded`
a.smith
2020-06-17 16:49
What's the appropriate thing to do with the generated Pact definitions when a broker is in the mix? Should they still be committed to the repo, or ignored entirely?
phil.endsley
2020-06-17 16:58
We ignore them in the consumer repo (add them to .gitignore) and use Pact Broker as the repository for pact definitions. If something needs it, it pulls from broker
mike.geeves
2020-06-17 19:53
Our CI/CD pipeline builds a docker image which is then used to run the tests (including generating the pacts) so they aren't anywhere to worry about keeping either :)
matt.fellows
2020-06-17 23:22
It?s up to you. Sometimes it?s useful to commit because you can use them as stubs for the consumer much more easily
mbieganski.infomatt
2020-06-18 05:38
@uglyog @bethskurrie looks like it's not necessary broker issue. Even if I use `@PactFolder` and share the pact still same bahaviour on provider.
bethskurrie
2020-06-18 05:39
It looks like the json does not have the expected fields at the top level.
mbieganski.infomatt
2020-06-18 06:06
json does have below.
`{`
`"consumer": {`
`"name": "service1"`
`},`
`"provider": {`
`"name": "service2"`
`},`
`"messages": [],`
`"metadata": {`
`"pactSpecification": {`
`"version": "3.0.0"`
`},`
`"pact-jvm": {`
`"version": "4.0.10"`
`}`
`}`
`}`
bethskurrie
2020-06-18 06:08
I think the reason the broker isn't displaying it is that it doesn't have the pact-message gem which tells it how to parse the "messages" key.
uglyog
2020-06-18 06:14
Can you provide the interaction that is causing the `java.lang.OutOfMemoryError`?
mbieganski.infomatt
2020-06-18 06:17
funny part is that it might be the same as the 1st one that passed and it will throw error either way.
mbieganski.infomatt
2020-06-18 13:54
@uglyog below pact is causing the error. the original one is way "bigger" but looks like it doesn't matter
```@Pact(consumer = "service-consumer")
private MessagePact somePact(MessagePactBuilder builder) {
return builder
.given("AMQP message")
.expectsToReceive(""Test message 1"")
.withContent(newJsonBody(
o -> {
o.stringType("origin", "Some Origin");
o.datetime("nextStatusDate", "yyyy-MM-dd'T'HH:mm:ss", Instant.ofEpochMilli(1592317859528L));
o.datetime("documentDate", "yyyy-MM-dd'T'HH:mm:ss", Instant.ofEpochMilli(1592317859528L));
}).build())
toPact();
}```
mbieganski.infomatt
2020-06-18 13:54
```{
"consumer": {
"name": "service-consumer"
},
"provider": {
"name": "service-provider"
},
"messages": [
{
"_id": "22a41a401064b86feaf33fc13cf9da668f6ead22",
"description": "Test message 1",
"metaData": {
"contentType": "application/json"
},
"contents": {
"documentDate": "2020-06-16T16:30:59",
"nextStatusDate": "2020-06-16T16:30:59",
"origin": "Some Origin"
},
"providerStates": [
{
"name": "AMQP message"
}
],
"matchingRules": {
"body": {
"$.origin": {
"matchers": [
{
"match": "type"
}
],
"combine": "AND"
},
"$.nextStatusDate": {
"matchers": [
{
"match": "timestamp",
"timestamp": "yyyy-MM-dd'T'HH:mm:ss"
}
],
"combine": "AND"
},
"$.documentDate": {
"matchers": [
{
"match": "timestamp",
"timestamp": "yyyy-MM-dd'T'HH:mm:ss"
}
],
"combine": "AND"
}
}
}
},
{
"_id": "2b1e740b4475c94f7785940df82ff53801178c63",
"description": "Test message 2",
"metaData": {
"contentType": "application/json"
},
"contents": {
"documentDate": "2020-06-16T16:30",
"nextStatusDate": "2020-06-16T16:30",
"origin": "Some Origin"
},
"providerStates": [
{
"name": "AMQP message"
}
],
"matchingRules": {
"body": {
"$.origin": {
"matchers": [
{
"match": "type"
}
],
"combine": "AND"
},
"$.nextStatusDate": {
"matchers": [
{
"match": "timestamp",
"timestamp": "yyyy-MM-dd'T'HH:mm"
}
],
"combine": "AND"
},
"$.documentDate": {
"matchers": [
{
"match": "timestamp",
"timestamp": "yyyy-MM-dd'T'HH:mm"
}
],
"combine": "AND"
}
}
}
}
],
"metadata": {
"pactSpecification": {
"version": "3.0.0"
},
"pact-jvm": {
"version": "4.1.2"
}
}
}```
phil.endsley
2020-06-18 17:56
Another day, another pending pacts question :slightly_smiling_face:
I have pending pacts working now. What's the flow look like when implementing a new pact for providers?
1. Consumer publishes new pact
2. Provider has a feature branch. The build doesn't fail, because that feature branch has no prior verified pacts with the consumer pact.
3. Provider build always succeeds, even though I have some pending tests that still fail.
So far so good, all intended. My question is, how does the provider team get good feedback that the new feature is done?
Is the provider team supposed to examine the build results to look for pending failures? Turn off pending pacts when developing locally so they fail (but don't commit that)?
phil.endsley
2020-06-18 17:59
For my case specifically, we develop with intellij, and typically run our tests from the IDE. We get a nice list of tests with green checks.
The issue is some of these fail (because they're pending), and it doesn't seem like there's a good way to see what is still outstanding unless I disable pending pacts when running locally.
phil.endsley
2020-06-18 18:00
But then, if we use WIP Pacts as well, I'll start getting failures for other branches I don't care about, right?
phil.endsley
2020-06-19 20:26
I think what we're going to do is:
? Let our CI server set enablePending and includeWipPactsSince.
? The provider team will manually add the consumer feature branch tag to their list of tags to verify for their provider feature branch
? Before merging the provider feature branch, remove the consumer feature branch tag
Should keep CI builds green, but give devs the feedback they need when implementing the feature on the provider
antonello
2020-06-22 14:58
I?ve created this cheeky feature request :smile:
https://pact.canny.io/feature-requests/p/add-configurable-number-of-last-verified-per-tag-on-the-home-page
williamfslima
2020-06-22 19:33
Hi everyone! I'm trying to run contract tests using PactBroker, however I'm getting this error
phil.endsley
2020-06-22 19:48
Are you using Spring Boot? I ask because you mentioned having `application.properties`
phil.endsley
2020-06-22 19:54
The `@PactBroker` annotation uses its own `ValueResolver` to resolve property values. So by default, it won't use Spring's.
You can write your own resolver that delegates to Spring's `PropertyResolver`, and set it using the `valueResolver` field on the `@PactBroker` annotation. Or you can set those as system properties, which are supported by default. You can look at `@PactBroker` to see the properties to use (ex: pactbroker.scheme).
There's probably other alternatives too, but I'd ask in the #pact-jvm channel, since the issue you're running into is connecting to Pact Broker from your provider for verification. It doesn't look like an issue with the broker itself
williamfslima
2020-06-22 20:04
I forgot to mention that I'm using Maven. So, should I set those system properties in the pom.xml?
phil.endsley
2020-06-22 20:07
I've never used Maven before, so I'm not 100%, but I would think that's ok? We use gradle and set them in our build tasks.
williamfslima
2020-06-22 20:11
Based on this article https://doordash.engineering/2018/11/05/contract-testing-with-pact/, I think it may work. Thank you Phil for helping me!
mbieganski.infomatt
2020-06-23 12:17
@bethskurrie how to handle situation when there is no contract on master branch yet and when I merge provider to master first and run tests it will throw error saying `".NoPactsFoundException at PactJUnit5VerificationProvider".` There is an option to use `@IgnoreNoPactsToVerify` https://github.com/DiUS/pact-jvm/issues/768 introduced by @uglyog but wondering if it's best approach in CI or should I also add `latest` like tags = {"latest", "dev", "prod"}?
tyler.collins
2020-06-24 20:54
does anyone have experience with deploying the pact-broker-docker container to Heroku? I must be missing something in configuring either the Heroku app and/or the docker container. I ran
```docker-compose build
heroku container:push pact_broker
heroku container:release pact_broker```
and attached a Postgres dyno, but nothing appears in the browser when I open the app
tyler.collins
2020-06-24 20:56
I also tried
```heroku run docker-compose up```
but no luck there either
matt.fellows
2020-06-24 22:04
Have you set the appropriate env vars connecting the db? What do the logs say?
tyler.collins
2020-06-24 23:04
I didn?t set any environment vars in Heroku, but this is in the docker-compose.yml
```PACT_BROKER_DATABASE_URL_ENVIRONMENT_VARIABLE_NAME: DATABASE_URL
DATABASE_URL: ""```
tyler.collins
2020-06-24 23:07
there is actually a DATABASE_URL config var in heroku that seems to have been automatically set when I attached the postgres dyno
tyler.collins
2020-06-24 23:10
even if the db isn?t fully configured, I would expect to see some kind of rails error on screen tho right? that seems to be the first problem, I just have a blank screen as if there?s no rails app running
tyler.collins
2020-06-24 23:11
```at=error code=H14 desc="No web processes running" method=GET path="/" host=http://blah-blah-blah.herokuapp.com request_id=... fwd=<IP> dyno= connect= service= status=503 bytes= protocol=https```
tyler.collins
2020-06-24 23:13
^ this is the only thing in the logs?which seems to say that it?s looking for a container called `web`. so I tried `heroku container:push web` instead but still no luck
tyler.collins
2020-06-24 23:15
oh ok, I guess generally speaking, should I need to do any other configuration to the docker container other than the db config from above in heroku, to make the container work (or at least spit out some logs) when deployed?
tyler.collins
2020-06-24 23:16
I just cloned it from github, built it with docker-compose, and pushed it. It works fine locally without any tweaking
bethskurrie
2020-06-25 00:04
@tyler.collins it's because the docker image doesn't respond to the $PORT environment variable
bethskurrie
2020-06-25 02:12
@tyler.collins I've just put out a new version of the docker image tagged `2.57.0.1`
bethskurrie
2020-06-25 02:13
You can see how you can use it Heroku here: https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose-heroku.yml
bethskurrie
2020-06-25 02:14
It will allow you to use the PORT env var instead of the PACT_BROKER_PORT env var. Let me know how you go.
yousafn
2020-06-26 12:13
I?ve got it running on heroku but not tried with the docker image.
Repo here
https://github.com/YOU54F/pact-broker-heroku
tyler.collins
2020-06-26 16:55
Hi @bethskurrie I was able to get the pact_broker container hooked up to Postgres, however the $PORT environment variable is not binding. After some db queries this gets spit out in the logs:
```2020-06-26T16:51:12.869922+00:00 app[web.1]: * Listening on :
2020-06-26T16:51:12.870131+00:00 app[web.1]: Use Ctrl-C to stop
2020-06-26T16:52:04.942499+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2020-06-26T16:52:04.966728+00:00 heroku[web.1]: Stopping process with SIGKILL
2020-06-26T16:52:05.117237+00:00 heroku[web.1]: Process exited with status 137
2020-06-26T16:52:05.169800+00:00 heroku[web.1]: State changed from starting to crashed```
Do you have any ideas why that might happen?
tyler.collins
2020-06-26 16:56
I changed the final portion of the Dockerfile to look like this
```# Start Puma
ENV RACK_ENV=production
ENV PACT_BROKER_PORT_ENVIRONMENT_VARIABLE_NAME=PACT_BROKER_PORT
ENV PACT_BROKER_PORT=$PORT
ENV PACT_BROKER_DATABASE_URL_ENVIRONMENT_VARIABLE_NAME=DATABASE_URL
ENV DATABASE_URL=$DATABASE_URL
ENV PACT_BROKER_LOG_LEVEL=DEBUG
ENV PACT_BROKER_SQL_LOG_LEVEL=DEBUG
USER ruby
ENTRYPOINT ["./entrypoint.sh"]
CMD ["http://config.ru"]```
antonello
2020-06-29 21:16
I?ve noticed some behaviour that is either incorrect or that I just don?t understand. Running version 2.54.0 but from a quick check of the change log I haven?t since any changes in that area in more recent versions.
For multiple participants, if I search ?Latest version with tag? with a specific tag, I get no results. Even if there are definitely multiple versions with that tag. In fact, when I search for ?All versions with tag?, I get all the results that I expect.
I can observe a similar behaviour with can-i-deploy.
Sorry, it was the end of the day and I don?t have anything more specific than this. Does it ring any bells?
antonello
2020-06-30 07:13
did a clean up about a month ago following the script I used many times before (it?s in the broker repo)
antonello
2020-06-30 07:17
the latest version I see with the tag in question (master) is definitely the latest published version
antonello
2020-06-30 07:17
but I can only see it in the matrix when choosing to see all versions rather than latest
antonello
2020-07-01 22:20
Raised an issue https://github.com/pact-foundation/pact-broker-docker/issues/28
kristine.jetzke
2020-07-02 12:20
I remember having exactly this issue a while ago. It was something ?we did? I think the issue was that a newer version somehow existed but was not displayed. I?m trying to remember why?
antonello
2020-07-02 12:21
but we think it?s due to setting the version differently (by accident) when publishing pacts and when verification results
antonello
2020-07-02 12:40
and we think that the underlying cause is that `pact.provider.version.trimSnapshot` is not working when not using the maven plugin
kristine.jetzke
2020-07-02 12:47
ah i think in our case it could have been that we used the short git hash in one place and the complete one in another
antonello
2020-07-02 12:49
fair enough! same underlying problem, cause by something else upstream :slightly_smiling_face:
antonello
2020-07-03 11:36
Any suggestions on how to verify compatibility of a consumer only with its providers and not its consumers?
I?ve seen an endpoint - but is it supported by the pact broker client?
Use cases is to skip provider verification in the consumer?s pipeline if the pacts are verified already.
bethskurrie
2020-07-03 20:48
From memory, your pipeline runs the verification for each provider in parallel. Before each of them, do a can I deploy and specify the consumer name and that provider name. All other integrations will then be ignored.
bethskurrie
2020-07-03 20:51
In your case, because you have the exact version of the consumer, it would be something like `can-i-deploy -a myconsumer -v 1234 -a provider1 --latest master`
aliaksandr.valadzko
2020-07-06 21:30
Hello!
I have a question about Webhook.
I need to create a Webhook for triggering TeamCity job.
Specifying username and password is not enough, it is needed to add csfr header and pass session token there.
?If you need to send POST/PUT/DELETE requests via CORS, you should obtain a CSRF token using the authenticationTest.html?csrf call, and then provide this token with your modifying HTTP requests.?
Is there a possibility to use dynamic substitution in headers of Webhook?
Thanks in advance
matt.fellows
2020-07-06 23:21
The webhook isn?t going to be fired by CORS, it?s going to be executed on the server side.
matt.fellows
2020-07-06 23:22
In any case, there is no way that I know of to automatically obtain a CSRF token via a separate call first - I?m not sure how that would help with security, given that the system that would need to make that call is the very system that needs the token!
bethskurrie
2020-07-06 23:22
The only way you can achieve this is by send the request to a proxy endpoint that can handle cors @aliaksandr.valadzko
bethskurrie
2020-07-06 23:23
If you can't trigger a build via webhooks, you can use an alternative flow where you build the provider tests into the consumer pipeline.
matt.fellows
2020-07-06 23:23
Related memories for you Beth: https://github.com/pact-foundation/pact_broker/issues/54#issuecomment-247727766
bethskurrie
2020-07-07 00:16
If anyone has some free time and enthusiasm, we really need to upgrade the DiUS Pact Broker docker image to Ruby 2.6. I'd love someone to have a look at this issue if they have a moment. https://github.com/DiUS/pact_broker-docker/issues/98
aliaksandr.valadzko
2020-07-07 05:58
Thanks a lot for responding!
But it looks like my question is a bit confusing, let me rephrase a bit:slightly_smiling_face:
I have such a *Webhook*:
```{
"events": [
{
"name": "contract_content_changed"
}
],
"request": {
"method": "POST",
"url": "https://teamcity.to.call.net/app/rest/buildQueue?",
"headers": {
"Content-Type": "application/xml",
"X-TC-CSRF-Token": "token"
},
"body": "<build><buildType id='ProviderPactJob'\/><\/build>",
"username": "username",
"password": "password"
}
}```
Is it possible to use dynamic variable substitution to pass `X-TC-CSRF-Token` value?
All that I was able to find is dynamic variable substitution in body and parameters:
https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks#dynamic-variable-substitution
matt.fellows
2020-07-07 06:12
If you?re using Pactflow, you could create a secret and ensure it is up date date, and then use that secret in the webhook
matt.fellows
2020-07-07 06:12
But my guess is that the CSRF token is a per request thing, so that would be fairly complicated to achieve
bethskurrie
2020-07-07 06:13
As Matt says, there are no secrets/custom variables in the OSS broker @aliaksandr.valadzko. Only the predefined pact related ones.
matt.fellows
2020-07-07 06:14
This seems to indicate a CSRF token is not required, unless performing a CORS request (which you?re not).
matt.fellows
2020-07-07 06:14
You just need a bearer token: https://www.jetbrains.com/help/teamcity/rest-api.html#RESTAPI-RESTAuthentication
matt.fellows
2020-07-07 06:15
Just note, that in the open source broker you would need to store that token in plain text in the webhook configuration - so please be careful
aliaksandr.valadzko
2020-07-07 06:31
Cool, using bearer tokens instead of csfr-s makes sense!
Thanks a lot!
I use `dius/pact-broker` in docker
However, taking into account, that token value is dynamic, I still can't get how can I perform this substitution?
```{
"events": [
{
"name": "contract_content_changed"
}
],
"request": {
"method": "POST",
"url": "https://teamcity.to.call.net/app/rest/buildQueue?",
"headers": {
"Content-Type": "application/xml",
"Authorization": "bearer {tokenValue}"
},
"body": "<build><buildType id='ProviderPactJob'\/><\/build>",
"username": "username",
"password": "password"
}
}```
How can pass `tokenValue`?
aliaksandr.valadzko
2020-07-07 06:43
Ohhh, that's sad:slightly_smiling_face:
Also, unfortunately I can't use Pactflow for several reasons (customer restrictions, VPNs), so I use container `dius/pact-broker`
So, thanks a lot for your help
I will try to somehow hardcode token to Webhook
bethskurrie
2020-07-07 06:44
We've just made our first release of an on-premises version of Pactflow, if you're interested
aliaksandr.valadzko
2020-07-07 07:10
BTW
Triggering TeamCity job with bearer token - works
Thanks guys, you've saved my day:blush:
aliaksandr.valadzko
2020-07-07 08:24
They are missed here:
https://docs.pact.io/pact_broker/webhooks/template_library
But I was able to find some example (probably stackoverflow) and adjust it based on my postman request
aliaksandr.valadzko
2020-07-07 08:51
https://github.com/pact-foundation/docs.pact.io/pull/15
I've created PR
bethskurrie
2020-07-07 10:00
Must have been. I thought I'd manually merged them all, but hooman error.
antonello
2020-07-08 06:23
So far I?ve implemented the strategy above successfully for our consumer that build in Jenkins and will do it soon for the ones that build in gitlab ci.
bheemreddy181
2020-07-09 02:35
Is there a way webhooks can be automated , we are concerned on exposing CI credentials while manually adding webhooks to pact broker ( Github and Travis CI creds for non human user )
matt.fellows
2020-07-09 02:36
the credentials will always be exposed in the OSS broker though, even if you get them in securely in the first place. There is no concept of a ?secret?, so they will appear in logs etc.
bheemreddy181
2020-07-09 02:38
Ah OSS broker doesn?t expose credentials once the webhook is created but it is exposed when created for the first time manually
matt.fellows
2020-07-09 02:40
Anybody with access to the broker, is able to read the plain-text contents of the webhook configuration e.g.
matt.fellows
2020-07-09 02:43
ah cool, yes I do recall Beth (or maybe it was a cotnributor) did put some basic redactions in place here
bheemreddy181
2020-07-09 02:45
Got it makes sense , i will take a look at terraform seems interesting though
bethskurrie
2020-07-09 03:06
Any header with "auth" in it anywhere, and the password get "*****" when retrieving them again.
matt.fellows
2020-07-09 03:55
Also, don?t forget you can automate using the CLI tools: https://github.com/pact-foundation/pact-ruby-standalone/releases
ppaduch
2020-07-09 08:41
Hi All, I am trying to enable WIP (work in progress pacts), I think I misconfigured something . I am using Node.js version of pact and trying to test with MessageProviderPact . I have already enabled pending pacts, it's working so pact broker has been configured properly. This is how verification code of provider's site looks like:
```const pact = new MessageProviderPact({
messageProviders: {
'receive a preview': () => send(preview),
},
consumer: "llamas-pact-consumer",
provider: "llamas-pact-provider",
publishVerificationResult: true,
pactBroker: "https://mybroker.inside.com",
pactBrokerUrl: "https://mybroker.inside.com",
providerVersion: "5db00f8a55b6d0c620a95062c60ced6a682ff544",
providerVersionTags: [
"feature/WIP"
],
enablePending: true,
logLevel: "DEBUG",
includeWipPactsSince: "2020-7-7"
});
it('consume base article', () => pact.verify());```
I have created several feature branches on consumer's site, each of them defines some variations on contract. When I run verification on provider's only the latest published contract is verified . What have I misconfigured ? Thanks a lot
bethskurrie
2020-07-09 09:27
Nothing is standing out to me, but I'm not at my laptop. Have a look at https://docs.pactflow.io/docs/workshops/ci-cd/workshop/verifying-feature-pacts/
bethskurrie
2020-07-09 09:27
Are you seeing all the output that tells you which pacts have been included and why?
bethskurrie
2020-07-09 09:28
Like "this pact is being verified because it is the latest pact with tag x"
bethskurrie
2020-07-09 09:29
You may need to enable debug output, or print out the contents of the test that get returned in the verify callback
bethskurrie
2020-07-09 09:31
There's one extra piece of logic that I need to document. Wip pacts only includes pacts created after the first instance of the provider tag.
bethskurrie
2020-07-09 09:32
This is so that if you create a new branch of the provider, you don't suddenly get every single pact ever as a WIP pact.
bethskurrie
2020-07-09 09:33
So if you just made a brand new provider tag, it won't pull in any of those changed pacts.
ppaduch
2020-07-09 10:05
thanks Beth, it's working , the crucial was 'Wip pacts only includes pacts created after the first instance of the provider tag.'
ppaduch
2020-07-09 10:05
the both format dates are valid ncludeWipPactsSince: "2020-7-7" and includeWipPactsSince: "2020-07-07"
antonello
2020-07-10 10:24
now that we have more and more pacticipants and builds we?re hitting a connection pool bottleneck
bethskurrie
2020-07-10 10:58
I'm surprised you're hitting limits that we're not hitting in Pactflow though.
antonello
2020-07-10 11:00
```2020-07-09 16:14:00.065328 E [6:puma 016 logging.rb:36] pact-broker -- Error reference rVAtCHGqQI -- Exception: Sequel::PoolTimeout: timeout: 5.0, elapsed: 5.028458300977945```
```2020-07-02T15:19:46.781775936Z /pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.33.0/lib/sequel/connection_pool/threaded.rb:264:in `raise_pool_timeout'
2020-07-02T15:19:46.781782546Z /pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.33.0/lib/sequel/connection_pool/threaded.rb:155:in `acquire'```
bethskurrie
2020-07-10 11:02
bethskurrie
2020-07-10 11:04
Somewhere in here we'll need to set the max connections https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/database_connection.rb
matt.fellows
2020-07-10 11:06
but it seems like there must be another issue that this might paper over
matt.fellows
2020-07-10 11:07
for example, maybe there is some client somewhere just spamming the hell out of it.
matt.fellows
2020-07-10 11:07
Or maybe the database is really slow, so the connection pooling has back pressure on it
antonello
2020-07-10 11:10
I am working on a more selective cleaning strategy that we can run regularly
bethskurrie
2020-07-10 11:10
I've got to get that clean endpoint out. I just haven't gotten anything out in the last 5 months because I don't have my train time any more.
bethskurrie
2020-07-10 11:11
I've got most of the code to allow you to configure what to keep, and delete the rest.
bethskurrie
2020-07-10 21:21
@antonello `2.58.0.1` of the docker image is out with the new environment variables for setting the max connections and pool timeout.
antonello
2020-07-10 21:42
will you publish the pactfoundation one too? :slightly_smiling_face:
https://hub.docker.com/r/pactfoundation/pact-broker/
bethskurrie
2020-07-11 07:39
it tries to run `docker-compose-test.yml` in the build, and that fails, stopping the image from being published.
bethskurrie
2020-07-11 10:53
@antonello it's out. That was annoying. Docker hub was trying to be a bit too helpful.
bethskurrie
2020-07-12 00:03
Yeah, it was bugging me too. I just can't remember where it is configured.
bethskurrie
2020-07-12 00:11
I've changed the notification settings to only send when it fails - but I don't know if those settings relate to that webhook, because I can't see it anywhere.
uglyog
2020-07-12 04:10
@bethskurrie I'm currently fixing an issue where there is a slash in the consumer version, and I have noticed a few places where the links will be broken
uglyog
2020-07-12 04:10
for instance:
```"pb:tag": {
"href": "https://test.pact.dius.com.au/pacticipants/Foo%20Web%20Client/versions/1.2.3/AB/tags/{tag}",
"title": "Get, create or delete a tag for this pacticipant version",
"templated": true
},```
bethskurrie
2020-07-12 04:12
`"#{pacticipant_url(base_url, version.pacticipant)}/versions/#{version.number}"`
uglyog
2020-07-12 04:14
BTW, good news, the publish with Maven and Gradle is now printing out the bodies when there is an error
bethskurrie
2020-07-12 04:23
Ok, I've gone through the URL class and found 4 missing url encoded parameters. I've fixed them now.
phil.endsley
2020-07-12 21:01
I want to revisit the topic of good workflows with WIP Pacts enabled. Here's where I am right now:
Consumer publishes a new feature pact tagged `consumer-feat-x`
Provider CI build is configured to verify against:
? Consumer version selectors
? `{"tag": "develop", "latest": true}`
? `{"tag": "prod", "latest": true}`
? `enablePending: true`
? `includeWipPactsSince: 01/06/2020` - Back far enough to include the consumer pact
During development, the provider team adds another version selector to verify against when running locally:
? `{"tag": "consumer-feat-x", "latest": true}`
? This is never committed, we don't want it to go to the main provider branch
The provider team finishes their feature, and opens a PR (without the `consumer-feat-x` version selector)
? CI Runs, and verifies against: `latest develop` , `latest prod`, and `latest consumer-feat-x`
Oops, the Provider team has to make a change to their PR. They do so, and push the new commits
? CI runs, and verifies against: `latest develop` and `latest prod`
? `consumer-feat-x` is not included, because it has a successful result from the first commit. Now, we don't know if the latest version of the provider is compatible with `consumer-feat-x`
If the pact is broken, we won't know until the provider feature branch is merged (or we rely on someone running them locally with the added version selector), and we see the failure against `consumer-feat-x`. Ultimately, this still keeps everything safe, I'm just trying to figure out a workflow that prevents developer frustration, since that will slow/prevent the adoption of Pact
bethskurrie
2020-07-12 23:28
WIP pacts was extremely difficult to implement to that it does what logically right.
bethskurrie
2020-07-12 23:28
If you can think of a logical way to achieve what you want, then please do make a suggestion.
bethskurrie
2020-07-12 23:30
The pacts will be deduped, so it doesn't matter if the current branch is master already.
phil.endsley
2020-07-12 23:34
Ill think on it some more and might tinker with that. I think that makes the most sense, generally. For us specifically, we have a convention of naming our branches after the jira issues. So the consumer will be feature/CONS-new-feature and the provider will be feature/PROV-new-feature. We use all of atlassians products, so following that convention ties a lot of things together automatically
bethskurrie
2020-07-12 23:34
so you could imply the consumer tag name from the provider branch name easily. nice.
bethskurrie
2020-07-12 23:35
that way, any new pacts you don't know about get failed verifications sent back, but ones you do know about get matching feature branches.
phil.endsley
2020-07-12 23:51
What about adding support for a tagPattern, and matching with regex? Haven't thought this through yet, but want to write it down before I forget.
Adding regex support would let us do branch name matching with a fallback without any other config changes between builds. Since we have some providers for multiple consumers.
For our use case specifically, we could dynamically parse our branch name and look for pairs from any consumer.
feature/PROV-123-new-feature
tagPattern: .*-new-feature
On mobile now, but can elaborate in a few hours. Will also give me time to think it over more
bethskurrie
2020-07-12 23:59
When you've got your thoughts together, add it to http://pact.canny.io @phil.endsley
bethskurrie
2020-07-13 00:00
I'm not sure if it would help the situation you described above though, would it?
phil.endsley
2020-07-13 01:52
Some of our providers have multiple consumers. Our convention is to prefix our feature branches with the jira issue for each project, so it integrates with the rest of the atlassian products we use.
Ex:
Consumer1 would have a Jira CONS1-123 and start with a prefix of feature/CONS1-123-
Consumer2 would have a Jira CONS2-456 and start with a prefix of feature/CONS2-456-
> so you could imply the consumer tag name from the provider branch name easily. nice.
Almost. Since our providers can have multiple consumers, we don't know for sure which consumer we should be verifying against (i.e. `feature/CONS1-123-new-feature` or `feature/CONS2-456-some-other-new-feature`)
> I'm not sure if it would help the situation you described above though, would it?
I was thinking we would use what you proposed. Dynamic version selector, using regex with a fallback.
So for the provider, we would have a branch like `feature/PROV-789-new-feature`. We could start naming our consumer/provider branches to match each other. ex: `feature/CONS1-123-new-feature`. Then our provider could have a version selector with
`{"tagPattern": ".*-new-feature", "latest": true, "fallbackTag": "master"}` where the `-new-feature` part would be dynamically determined.
This would let us verify against either consumer when features are developed, as long as the suffix matches.
phil.endsley
2020-07-13 01:53
If we don't have regex, we would have to do some manual step to specify which consumer we want to verify against (cons1 vs cons2)
phil.endsley
2020-07-13 01:58
I think we still need to fully implement the rest of the version selector features in pact-jvm. Almost all our providers are jvm based
phil.endsley
2020-07-13 02:00
> but then you'd have to change the selectors for each feature
Yeah, I'm trying hard to find a way to "set it up once" and it's good for everything
bethskurrie
2020-07-13 02:02
the hard work has been done in pact-jvm to use the new 'pacts for verification' api, so adding in new options should be pretty easy too (she says with absolutely no experience in the pact-jvm codebase :laughing:)
bnacey
2020-07-14 21:35
I'm getting this error when attempting to publish
``` Failed to publish node-message-consumer/node-message-provider pact due to error: OpenSSL::SSL::SSLError - SSL_connect returned=1 errno=0 state=error: certificate verify failed
One or more pacts failed to be published```
matt.fellows
2020-07-14 22:04
If public, have you tried upgrading? Your pact version is a few years old.
matt.fellows
2020-07-14 22:05
If that doesn't work, we may need to see if the latest digicerts are packaged properly with the Ruby runtime we distribute
bethskurrie
2020-07-15 00:05
You can experiment by setting the SSL certificate to be used by setting the SSL_CERT_FILE env var @bnacey
matt.fellows
2020-07-15 01:09
Thanks Brian. I suspect it?s because the certificates are bundled in the Ruby runtime, and that runtime hasn?t changed for a while (more of a comment for Beth)
matt.fellows
2020-07-15 01:09
is the broker accessible by us for testing? (assume not, but thought I?d ask)
bnacey
2020-07-15 01:09
i can try, but ultimately I need a solution to use the host trust store as there will be many clients running the verification
bethskurrie
2020-07-15 01:10
I need to know if setting the env var fixes the problem, so we can tell if adding the cert to the bundle will help.
matt.fellows
2020-07-15 01:19
Looking at that, my guess will be the intermediate certificate is the culprit
matt.fellows
2020-07-15 01:22
Otherwise, you may need to append _both_ to the bundle (e.g. `./node_modules/@pact-foundation/pact-node/standalone/darwin-1.82.1/pact/lib/ruby/lib/ca-bundle.crt`)
bnacey
2020-07-15 01:23
is there a specific format the cert needs to be in? or just as I pull it from chrome?
bnacey
2020-07-15 01:27
are these the steps to bundle the certs? https://github.com/pact-foundation/pact-js/issues/203#issuecomment-532864024
matt.fellows
2020-07-15 01:28
I?d just replace the file with a copy of the latest from https://curl.haxx.se/docs/caextract.html
matt.fellows
2020-07-15 01:30
`./node_modules/@pact-foundation/pact-node/standalone/darwin-1.82.1/pact/lib/ruby/lib/ca-bundle.crt`
matt.fellows
2020-07-15 01:39
So that then points to the certificate itself being a problem. Are you able to share the certificate details?
matt.fellows
2020-07-15 01:40
(and I missed your comment before I apologies, yes they are the steps to bundling. You could attempt that with your specific set of certs and try that too!)
bnacey
2020-07-15 01:41
chrome says the cert is valid and there is no issue in the browser or with curl
bnacey
2020-07-15 01:47
with the bundled cert and SSL_CERT_FILE i'm now getting the expected authentication error
bnacey
2020-07-15 01:48
i guess that's the bit i really don't understand. We are not using a self signed cert
bethskurrie
2020-07-15 01:51
the "ruby standalone" uses Travelling Ruby to create an executable that runs without having to install ruby on the local machine.
bethskurrie
2020-07-15 01:51
It's quite an old version, and we're moving away from it to a shared rust implementation.
bethskurrie
2020-07-15 01:52
Can you raise an issue in the pact-foundation/pact-ruby-standalone repository with the full details of that missing cert?
bnacey
2020-07-15 01:53
thank you both so much for your help. I'll move forward with the bundled certs for now
matt.fellows
2020-07-15 01:54
I?m confused as to why the SSL_CERT needs to be set if it?s based on those chains already defined in the cacert. That?ll be for the bug to look into
sairsule
2020-07-15 16:12
Following Provider code works fine with local file but does not work with pack-broker
```
func TestProvider(t *testing.T) {
// Create Pact connecting to local Daemon
pact := &dsl.Pact{
Provider: "UserDataProvider",
DisableToolValidityCheck: false,
LogLevel: "INFO",
}
// Start provider API in the background
go startServer()
// Verify the Provider with local Pact Files
pact.VerifyProvider(t, types.VerifyRequest{
ProviderBaseURL: "http://localhost:8000",
//PactURLs: []string{filepath.ToSlash(fmt.Sprintf("%s/userdataconsumergo-userdataprovider.json", pactDir))},
BrokerURL: "http://localhost",
BrokerUsername: "myusername",
BrokerPassword: "mypassword",
PublishVerificationResults: true,
FailIfNoPactsFound: true,
//Tags: []string{"latest"},
StateHandlers: stateHandlers,
})
}```
sairsule
2020-07-15 16:12
I do have the pact in broker, but it says "pact.go:413: No pacts found to verify"
bethskurrie
2020-07-15 22:43
Or is that the way that particular implementation specifies to get the latest pact?
matt.fellows
2020-07-15 22:45
I'll check if that accidentally made it into any examples. I don't think so but just to be sure
bethskurrie
2020-07-15 23:35
I've just added a section on "latest" to the tags page https://github.com/pact-foundation/docs.pact.io/blob/master/docs/pact_broker/tags.md#latest-pacts
bethskurrie
2020-07-15 23:36
Dammit, I wish I could remove the preview from Github links. I think at one stage the "accept" got clicked and I cannot find out how to unclick it.
sairsule
2020-07-16 03:14
```pact-broker publish --consumer-app-version 1.0.0 --broker-base-url http://localhost -u myusername -p mypassword userdataconsumergo-userdataprovider.json --tag master```
bethskurrie
2020-07-16 03:14
You shoul definitely have the word "master" in your tag list, not "latest"
bethskurrie
2020-07-16 03:15
the fact that it doesn't return anything even when you have no tags is very weird.
sairsule
2020-07-16 03:16
```Running tool: C:\Go\bin\go.exe test -timeout 60s userdata/pact-tests -run ^TestProvider$
2020/07/16 08:46:00 [DEBUG] pact setup logging
2020/07/16 08:46:00 [DEBUG] pact setup
2020/07/16 08:46:00 [DEBUG] checking CLI compatability
2020/07/16 08:46:00 [INFO] checking pact-mock-service within range >= 3.5.0, < 4.0.0
2020/07/16 08:46:00 [DEBUG] running binary pact-mock-service
2020/07/16 08:46:06 [DEBUG] checking version for binary pact-mock-service version 3.6.1
2020/07/16 08:46:06 [DEBUG] checking if version 3.6.1 within semver range >= 3.5.0, < 4.0.0
2020/07/16 08:46:06 [DEBUG] 3.6.1 satisfies constraints 3.6.1 >= 3.5.0, < 4.0.0
2020/07/16 08:46:06 [INFO] checking pact-provider-verifier within range >= 1.30.0, < 2.0.0
2020/07/16 08:46:06 [DEBUG] running binary pact-provider-verifier
2020/07/16 08:46:14 [DEBUG] checking version for binary pact-provider-verifier version 1.30.1
2020/07/16 08:46:14 [DEBUG] checking if version 1.30.1 within semver range >= 1.30.0, < 2.0.0
2020/07/16 08:46:14 [DEBUG] 1.30.1 satisfies constraints 1.30.1 >= 1.30.0, < 2.0.0
2020/07/16 08:46:14 [INFO] checking pact-broker within range >= 1.22.3
2020/07/16 08:46:14 [DEBUG] running binary pact-broker
2020/07/16 08:46:15 [DEBUG] checking version for binary pact-broker version 1.26.0
2020/07/16 08:46:15 [DEBUG] checking if version 1.26.0 within semver range >= 1.22.3
2020/07/16 08:46:15 [DEBUG] 1.26.0 satisfies constraints 1.26.0 >= 1.22.3
2020/07/16 08:46:15 [DEBUG] setting up a service manager
2020/07/16 08:46:15 [DEBUG] setting up a service manager
2020/07/16 08:46:15 [DEBUG] setting up a service manager
2020/07/16 08:46:15 [DEBUG] setting up a service manager
2020/07/16 08:46:15 [DEBUG] starting service creation monitor
2020/07/16 08:46:15 [DEBUG] starting service removal monitor
2020/07/16 08:46:15 [DEBUG] starting service removal monitor
2020/07/16 08:46:15 [DEBUG] starting service creation monitor
2020/07/16 08:46:15 [DEBUG] starting service creation monitor
2020/07/16 08:46:15 [DEBUG] starting service removal monitor
2020/07/16 08:46:15 [DEBUG] starting service creation monitor
2020/07/16 08:46:15 [DEBUG] starting service removal monitor
2020/07/16 08:46:15 [DEBUG] starting new proxy with opts {http localhost:8000 0 [0x6e6830] /__setup <nil>}
2020/07/16 08:46:15 [DEBUG] starting reverse proxy on port 51025
2020/07/16 08:46:15 [DEBUG] waiting for port 51025 to become available
2020/07/16 08:46:15 [DEBUG] pact provider verification
2020/07/16 08:46:15 [DEBUG] client: verifying a provider
--- FAIL: TestProvider (14.46s)
pact.go:413: No pacts found to verify. Check the tags provided (master) for your broker (http://127.0.0.1) are correct
FAIL
FAIL userdata/pact-tests 18.745s
FAIL```
bethskurrie
2020-07-16 03:17
@matt.fellows is there a way to pass the --verbose flag to the underlying CLI?
bethskurrie
2020-07-16 03:23
also, the go library delegates to the "pact ruby standalone", which is installed separately. Can you find out the version, and upgrade it if it's not the latest.
sairsule
2020-07-16 03:45
I didn't had ruby installed. So installed latest version. Still the same issue.
bethskurrie
2020-07-16 03:45
it comes bundled with the package. That's why it's called the "pact ruby standalone"
bethskurrie
2020-07-16 03:47
If you can see how to set the verbose flag, can you try it, even if it breaks things.
matt.fellows
2020-07-16 04:03
What?s confusing about the above DEBUG output @sairsule is that there should be a debug output showing how it?s invoking the verification process, and the flags it?s using
matt.fellows
2020-07-16 04:03
If you haven?t already, please set your log level to `DEBUG` - that will help
matt.fellows
2020-07-16 04:04
The other thing is just remove pact-go altogether and invoke the verifier directly: e.g. something like `pact-provider-verifier --provider-base-url http://localhost:1234 --pact-broker-base-url http://localhost ?`
matt.fellows
2020-07-16 04:05
pass in any base url, because it will only try and talk to the base url if the pacts were found
sairsule
2020-07-16 04:44
```C:\tools\pact\bin>pact-provider-verifier --provider-base-url http://localhost:8080 userdataconsumergo-userdataprovider.json --tag master --broker-user myusername --broker-password mypassword --pact-broker-base-url localhost --provider UserDataProvider
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/hal/http_client.rb:38:in `create_request': undefined method `request_uri' for #<URI::Generic localhost> (NoMethodError)
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/hal/http_client.rb:24:in `get'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/hal/link.rb:49:in `get'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:50:in `index'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:37:in `call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:33:in `call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/pact_broker.rb:18:in `fetch_pact_uris_for_verification'```
sairsule
2020-07-16 05:03
```C:\tools\pact2\pact-1.86.0-win32\pact\bin>pact-provider-verifier --provider-base-url http://localhost:8080 userdataconsumergo-userdataprovider.json --tag master --broker-user myusername --broker-password mypassword --pact-broker-base-url http://localhost --provider UserDataProvider
C:/tools/pact2/pact-1.86.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact-1.50.1/lib/pact/hal/entity.rb:102:in `assert_success!': Error retrieving http://localhost status=401 (Pact::Hal::ErrorResponseReturned)
from C:/tools/pact2/pact-1.86.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact-1.50.1/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:50:in `index'
from C:/tools/pact2/pact-1.86.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact-1.50.1/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:37:in `call'
from C:/tools/pact2/pact-1.86.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact-1.50.1/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:33:in `call'
from C:/tools/pact2/pact-1.86.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact-1.50.1/lib/pact/pact_broker.rb:18:in `fetch_pact_uris_for_verification'```
sairsule
2020-07-16 05:26
```version: "3"
services:
postgres:
image: postgres
healthcheck:
test: psql postgres --command "select 1" -U postgres
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_DB: postgres
pact-broker:
image: dius/pact-broker
# build:
# context: .
depends_on:
- postgres
environment:
PACT_BROKER_DATABASE_USERNAME: postgres
PACT_BROKER_DATABASE_PASSWORD: password
PACT_BROKER_DATABASE_HOST: postgres
PACT_BROKER_DATABASE_NAME: postgres
PACT_BROKER_LOG_LEVEL: INFO
PACT_BROKER_BASIC_AUTH_USERNAME: myusername
PACT_BROKER_BASIC_AUTH_PASSWORD: mypassword
ports:
- "80:80"
```
matt.fellows
2020-07-16 05:49
what happens if you do something (equivalent) to `curl localhost --user myusername:mypassword` - do you get a JSON response?
matt.fellows
2020-07-16 05:50
```pact-provider-verifier --provider-base-url http://localhost:8080 userdataconsumergo-userdataprovider.json --tag master --broker-username myusername --broker-password mypassword --pact-broker-base-url http://localhost --provider UserDataProvider```
sairsule
2020-07-16 06:02
but now another error
```Error reading file from --tag
No such file or directory @ rb_sysopen - --tag C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:51:in `read'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:51:in `get_local'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:41:in `render_pact'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:22:in `read'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_source.rb:16:in `pact_json'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:115:in `collect'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:115:in `pact_jsons'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:78:in `configure_rspec'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:32:in `run'```
matt.fellows
2020-07-16 06:03
you have a .json file half way through that list of arguments. It shouldn?t be there at all, because you are pointing to a broker
sairsule
2020-07-16 06:35
```C:\tools\pact\bin>pact-provider-verifier --provider-base-url http://localhost:8080 --tag master --broker-username myusername --broker-password mypassword --pact-broker-base-url http://localhost --provider UserDataProvider
INFO: Fetching pacts for UserDataProvider from http://localhost
INFO: Reading pact at http://myusername:*****@localhost/pacts/provider/UserDataProvider/consumer/UserDataConsumerGo/version/1.0.0
Verifying a pact between UserDataConsumerGo and UserDataProvider
Given User with email exists
Send user address
with GET /users/user1@gmail.com
returns a response which
WARN: Skipping set up for provider state 'User with email exists' for consumer 'UserDataConsumerGo' as there is no --provider-states-setup-url specified.
has status code 200
has a matching body
includes headers
"Content-Type" which matches /application\/json/
1 interaction, 0 failures
Error reading file from --tag
No such file or directory @ rb_sysopen - --tag C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:51:in `read'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:51:in `get_local'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:41:in `render_pact'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:22:in `read'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_source.rb:16:in `pact_json'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:115:in `collect'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:115:in `pact_jsons'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:78:in `configure_rspec'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:32:in `run'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:69:in `run_with_pact_uri_object'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:50:in `run_specs'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:21:in `call'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:13:in `call'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:169:in `verify_pact'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:43:in `block in call'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:42:in `collect'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:42:in `call'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:34:in `call'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/cli/verify.rb:56:in `verify'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'
C:/tools/pact/lib/app/pact-provider-verifier.rb:33:in `<main>'
C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:51:in `read': No such file or directory @ rb_sysopen - --tag (Errno::ENOENT)
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:51:in `get_local'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:41:in `render_pact'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-support-1.15.0/lib/pact/consumer_contract/pact_file.rb:22:in `read'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_source.rb:16:in `pact_json'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:115:in `collect'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:115:in `pact_jsons'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:78:in `configure_rspec'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/provider/pact_spec_runner.rb:32:in `run'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:69:in `run_with_pact_uri_object'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:50:in `run_specs'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:21:in `call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-1.49.3/lib/pact/cli/run_pact_verification.rb:13:in `call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:169:in `verify_pact'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:43:in `block in call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:42:in `collect'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:42:in `call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/app.rb:34:in `call'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/cli/verify.rb:56:in `verify'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
from C:/tools/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.30.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'
from C:/tools/pact/lib/app/pact-provider-verifier.rb:33:in `<main>'```
matt.fellows
2020-07-16 06:39
if you could please set LogLevel to DEBUG and share the logs in the go tests that?d be great
sairsule
2020-07-16 06:44
```Running tool: C:\Go\bin\go.exe test -timeout 60s userdata/pact-tests -run ^TestProvider$
2020/07/16 12:13:44 [DEBUG] pact setup logging
2020/07/16 12:13:44 [DEBUG] pact setup
2020/07/16 12:13:44 [DEBUG] setting up a service manager
2020/07/16 12:13:44 [DEBUG] setting up a service manager
2020/07/16 12:13:44 [DEBUG] setting up a service manager
2020/07/16 12:13:44 [DEBUG] setting up a service manager
2020/07/16 12:13:44 [DEBUG] starting service removal monitor
2020/07/16 12:13:44 [DEBUG] starting service removal monitor
2020/07/16 12:13:44 [DEBUG] starting service creation monitor
2020/07/16 12:13:44 [DEBUG] starting service removal monitor
2020/07/16 12:13:44 [DEBUG] starting service creation monitor
2020/07/16 12:13:44 [DEBUG] starting service removal monitor
2020/07/16 12:13:44 [DEBUG] starting service creation monitor
2020/07/16 12:13:44 [DEBUG] starting service creation monitor
2020/07/16 12:13:44 [DEBUG] starting new proxy with opts {http localhost:8000 0 [0x6e6830] /__setup <nil>}
2020/07/16 12:13:44 [DEBUG] starting reverse proxy on port 53054
2020/07/16 12:13:44 [DEBUG] waiting for port 53054 to become available
2020/07/16 12:13:44 [DEBUG] pact provider verification
2020/07/16 12:13:44 [DEBUG] client: verifying a provider
--- FAIL: TestProvider (0.07s)
pact.go:413: No pacts found to verify. Check the tags provided (master) for your broker (http://localhost) are correct
FAIL
FAIL userdata/pact-tests 3.239s
FAIL```
matt.fellows
2020-07-16 07:08
something is not right, it should be printing out the verification arguments
matt.fellows
2020-07-16 07:11
For example, this is the output of one of the example tests in the repo:
```go test -v -tags=provider -count=1 http://github.com/pact-foundation/pact-go/examples/mux/... -run TestExample
=== RUN TestExample_MuxProvider
2020/07/16 17:09:57 [DEBUG] pact setup logging
2020/07/16 17:09:57 [DEBUG] pact setup
2020/07/16 17:09:57 API starting: port 60722 ([::]:60722)
2020/07/16 17:09:57 [DEBUG] checking CLI compatability
2020/07/16 17:09:57 [INFO] checking pact-mock-service within range >= 3.5.0, < 4.0.0
2020/07/16 17:09:57 [DEBUG] running binary pact-mock-service
2020/07/16 17:09:58 [DEBUG] checking version for binary pact-mock-service version 3.6.1
2020/07/16 17:09:58 [DEBUG] checking if version 3.6.1 within semver range >= 3.5.0, < 4.0.0
2020/07/16 17:09:58 [DEBUG] 3.6.1 satisfies constraints 3.6.1 >= 3.5.0, < 4.0.0
2020/07/16 17:09:58 [INFO] checking pact-provider-verifier within range >= 1.31.0, < 2.0.0
2020/07/16 17:09:58 [DEBUG] running binary pact-provider-verifier
2020/07/16 17:09:58 [DEBUG] checking version for binary pact-provider-verifier version 1.31.0
2020/07/16 17:09:58 [DEBUG] checking if version 1.31.0 within semver range >= 1.31.0, < 2.0.0
2020/07/16 17:09:58 [DEBUG] 1.31.0 satisfies constraints 1.31.0 >= 1.31.0, < 2.0.0
2020/07/16 17:09:58 [INFO] checking pact-broker within range >= 1.22.3
2020/07/16 17:09:58 [DEBUG] running binary pact-broker
2020/07/16 17:09:58 [DEBUG] checking version for binary pact-broker version 1.27.0
2020/07/16 17:09:58 [DEBUG] checking if version 1.27.0 within semver range >= 1.22.3
2020/07/16 17:09:58 [DEBUG] 1.27.0 satisfies constraints 1.27.0 >= 1.22.3
2020/07/16 17:09:58 [DEBUG] setting up a service manager
2020/07/16 17:09:58 [DEBUG] setting up a service manager
2020/07/16 17:09:58 [DEBUG] setting up a service manager
2020/07/16 17:09:58 [DEBUG] setting up a service manager
2020/07/16 17:09:58 [DEBUG] starting service creation monitor
2020/07/16 17:09:58 [DEBUG] starting service creation monitor
2020/07/16 17:09:58 [DEBUG] starting service creation monitor
2020/07/16 17:09:58 [DEBUG] starting service removal monitor
2020/07/16 17:09:58 [DEBUG] starting service creation monitor
2020/07/16 17:09:58 [DEBUG] starting service removal monitor
2020/07/16 17:09:58 [DEBUG] starting service removal monitor
2020/07/16 17:09:58 [DEBUG] starting service removal monitor
2020/07/16 17:09:58 [DEBUG] starting new proxy with opts {http localhost:60722 0 [0x12ebb10 0x12ebd50 0x12ec270 0x12ee4e0] /__setup <nil>}
2020/07/16 17:09:58 [DEBUG] starting reverse proxy on port 60725
2020/07/16 17:09:58 [DEBUG] waiting for port 60725 to become available
2020/07/16 17:09:58 [DEBUG] pact provider verification
2020/07/16 17:09:58 [DEBUG] client: verifying a provider
2020/07/16 17:09:58 [DEBUG] waiting for port 60725 to become available
2020/07/16 17:09:58 [DEBUG] starting verification service with args: [/Users/matthewfellows/go/src/github.com/pact-foundation/pact-go/examples/mux/provider/../../pacts/jmarie-loginprovider.json --format json --provider-base-url http://localhost:60725 --provider-states-setup-url http://localhost:60725/__setup --provider loginprovider]
2020/07/16 17:09:59 [DEBUG] executing before hook
2020/07/16 17:09:59 [DEBUG] skipping state handler for request /login/10?foo=bar
2020/07/16 17:09:59 [DEBUG] http reverse proxy received connection from [::1]:60729 on path /login/10?foo=bar
2020/07/16 17:09:59 [DEBUG] setting proxy to target
2020/07/16 17:09:59 [DEBUG] incoming request /login/10?foo=bar
2020/07/16 17:09:59 [DEBUG] outgoing request to target http://localhost:60722/login/10?foo=bar
2020/07/16 17:09:59 [DEBUG] executing after hook
2020/07/16 17:09:59 [DEBUG] executing before hook
2020/07/16 17:09:59 [DEBUG] skipping state handler for request /login/10?foo=anything
2020/07/16 17:09:59 [DEBUG] http reverse proxy received connection from [::1]:60732 on path /login/10?foo=anything
2020/07/16 17:09:59 [DEBUG] setting proxy to target```
sairsule
2020-07-16 07:15
:bananadance: found the issue. Provider version was missing. :slightly_smiling_face:
matt.fellows
2020-07-16 07:15
it doesn?t look like it?s allowed to start a port, and is timing out. but that error is being swallowed
matt.fellows
2020-07-16 07:22
The error contains feedback about what went wrong, so please don?t discard that
sairsule
2020-07-16 07:23
also realised, FailIfNoPactsFound option is not present in dsl.VerifyMessageRequest
bethskurrie
2020-07-19 22:09
Nice blog post from Harry Martland on can-i-deploy https://medium.com/better-programming/your-contract-tests-are-not-protecting-you-563a5d6cdfef
dattasai.chunduru
2020-07-20 09:37
for Pact broker. I am using Pactborker yml file for creating pact broker instance
dattasai.chunduru
2020-07-20 09:41
I am going through this http://localhost:8113/doc/webhooks#whitelist
yousafn
2020-07-20 10:46
I think you just need to add an env var for `PACT_BROKER_WEBHOOK_HOST_WHITELIST`
in your `broker_app`
https://github.com/pact-foundation/pact-broker-docker#webhook-whitelists
dattasai.chunduru
2020-07-20 11:28
Sorry for my slow understanding but I have to set PACT_BROKER_WEBHOOK_HOST_WHITELIST in my pactbroker url level ?
antonello
2020-07-20 13:01
http://pact-broker/?tags=prod shows also all the latest tagged pacticipants and not just the `prod` ones, is that expected behaviour?
dattasai.chunduru
2020-07-20 18:58
Hi All
I am able to create a Webhook for PACT CONTRACT file but when it is trying to trigger the PIPELINE build it is showing error as below
```Errno::EADDRNOTAVAIL - Failed to open TCP connection to localhost:8080 (Cannot assign requested address - connect(2) for "localhost" port 8080)```
Can anyone please help me on this .
dattasai.chunduru
2020-07-20 19:15
I have tried to open TCP connection for Port 8080 but still it is showing same error
phil.endsley
2020-07-20 19:17
I'm making a couple assumptions based on some of your previous posts.
1. You're running pactbroker with docker-compose
2. You have Jenkins running on your machine on port 8080?
3. Your webhook is configured to make a request to localhost:8080
PactBroker will make the call to localhost:8080, but since you're running this with Docker, it will be making this request to that container's localhost. It doesn't seem likely you're running Jenkins in the broker container
phil.endsley
2020-07-20 19:32
Disclaimer: I'm not an expert...I know just enough to be dangerous :slightly_smiling_face:
I'm pretty sure you need to configure your pactbroker docker network to use your host machine's network. You should be able to do this in the compose file. https://docs.docker.com/compose/compose-file/#network_mode
Once you do that, I think you'll also need to update your webhook from `localhost:8080` to `127.0.0.1:8080`
Note that if you do this, you won't be able to use port mapping (Because it's already running on your host machine's network), so you may also run into port conflicts if you have other applications using those ports. https://docs.docker.com/compose/compose-file/#ports
ashish_garg5
2020-07-21 06:28
Hi All,
```http://localhost:8500/pacts/provider/provider/consumer/consumer/version/1.0.0```
I am using this broker url to make a put request in python now i want to add pact-broker-username and pact-broker-password as well, how to do that ?
Can i pass in this same url or there is any other way.
Thanks.
matt.fellows
2020-07-21 06:28
the username and password are basic auth credentials, so you need to consult the docs for your Python HTTP client about how to add those
matt.fellows
2020-07-21 06:29
or use the docker variant: https://hub.docker.com/r/pactfoundation/pact-cli
ashish_garg5
2020-07-21 06:30
i have added the pact broker username and password using the https://hub.docker.com/r/pactfoundation/pact-cli
Now i want to pass these parameters in my code
abubics
2020-07-21 06:39
I guess there's 2 major lines of questioning here . . .
? What are you trying to do where you got it working by CLI, but also want to make it work from Python?
? What libraries are you using? (which has nothing to do with Pact, so maybe this isn't the best place to be asking)
sairsule
2020-07-21 06:46
I have self signed cert on pact-broker, I added the cert to ca-bundle.crt, still getting error while publishing pact.
```OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed C:/tools/pact_o/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/base_client.rb:101:in `put', attempt 1 of 3```
ashish_garg5
2020-07-21 06:49
ok so i have added PACT_BROKER_BASIC_AUTH_USERNAME and PACT_BROKER_BASIC_AUTH_PASSWORD in my docker-compose. Now my broker is having basic auth added.
Now from my python repo i want to pass these parameter values while making a put request to broker
```http://localhost:8500/pacts/provider/provider/consumer/consumer/version/1.0.0```
with these values i want to pass TAG, USERNAME and PASSWORD also.
ashish_garg5
2020-07-21 06:53
```requests.put(broker_url, data = open(pactfile, 'rb'), headers=headers)```
m doing something like this. Above url is my broker_url
abubics
2020-07-21 07:00
You could ask in #pact-python , maybe someone will be familiar with the library you're using?
abubics
2020-07-21 07:00
Or look up the docs of that library :slightly_smiling_face: there should be info on an auth DSL, or how to set custom headers for auth
matt.fellows
2020-07-21 07:33
> i have added the pact broker username and password using the https://hub.docker.com/r/pactfoundation/pact-cli
What does this mean, sorry? Are you using this CLI or still using the Python library?
matt.fellows
2020-07-21 07:36
as per the python channel, you may want to consider reading https://requests.readthedocs.io/en/master/user/authentication/#basic-authentication
matt.fellows
2020-07-21 07:37
(or get inspiration from that on whatever http client library you?re using)
siddharth.gupta
2020-07-21 14:35
Tagging version 1.0.0 of Event API Consumer as "Master1"
c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/pact_file.rb:32:in `read': No such file or directory @ rb_sysopen - -a, (Errno::ENOENT)
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/pact_file.rb:32:in `read'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/pact_file.rb:28:in `pact_hash'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/pact_file.rb:16:in `pact_name'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/rake-10.5.0/lib/rake/file_list.rb:81:in `each'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/rake-10.5.0/lib/rake/file_list.rb:81:in `group_by'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/rake-10.5.0/lib/rake/file_list.rb:81:in `group_by'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/publish_pacts.rb:41:in `publish_pacts'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/publish_pacts.rb:27:in `call'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/publish_pacts.rb:13:in `call'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/cli/broker.rb:196:in `publish_pacts'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/cli/broker.rb:57:in `publish'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
from c:/cloud/pact-1.84.0-win32/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.26.0/lib/pact_broker/client/cli/custom_thor.rb:15:in `start'
from c:/cloud/pact-1.84.0-win32/pact/lib/app/pact-broker.rb:28:in `<main>'
c:\cloud\pact-1.84.0-win32\pact\bin>how to resolve this error
siddharth.gupta
2020-07-21 14:37
will appreciate help on this , not sure whats the error but its coming back from the broker guess . Am I missing something . I suspect that provider details are missing but could not get help information from Pact ruby stand alone client help --?
siddharth.gupta
2020-07-21 14:47
publish C:\cloud\pact-net-master\Samples\EventApi\Consumer.Tests\pacts\event_api_consumer-event_api.json -a, --consumer-app-version=1.0.0 -b, --broker-base-url=xx.xxx.xxx.xx -u,--broker-username=pactbrokeruser -p,--broker-password=password -t, --tag=Master1
joel.whalen
2020-07-21 15:04
We are implementing verification in CICD and I noticed that we forgot to add provider tags during the verification step. It has been working fine, but since I added the `--provider-version-tag` option, I?m getting this error:
```Error reading file from --provider-version-tag=test
No such file or directory @ rb_sysopen - --provider-version-tag=test /usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:51:in `read'```
We are using the docker image here https://hub.docker.com/r/pactfoundation/pact-cli, which doesn?t even list `provider-version-tag` as an option - are we sure the docker image is compatible with the documentation here https://github.com/pact-foundation/pact-provider-verifier#usage?
joel.whalen
2020-07-21 15:05
Our `docker-compose.yml` looks extremely similar to this one https://github.com/pact-foundation/pact-ruby-cli/blob/master/docker-compose-verify.yml except we added the provider tag option as well
matt.fellows
2020-07-22 00:30
It looks like the value for the `-a` flag is not coming through or some value is not present
matt.fellows
2020-07-22 05:08
If you could please share the code you used that resulted in this failure, that would certainly help
siddharth.gupta
2020-07-22 05:09
publish C:\cloud\pact-net-master\Samples\EventApi\Consumer.Tests\pacts\event_api_consumer-event_api.json -a, --consumer-app-version=1.0.0 -b, --broker-base-url=xx.xxx.xxx.xx -u,--broker-username=pactbrokeruser -p,--broker-password=password -t, --tag=Master1
matt.fellows
2020-07-22 05:10
yes, it?s not common for any CLI tool to accept commas between arguments
siddharth.gupta
2020-07-22 05:13
bin>pact-broker.bat publish C:\cloud\pact-net-master\Samples\EventApi\Consumer.Tests\pacts\event_api_consumer-event_api.json -a --consumer-app-version=1.0.0 -b --broker-base-url=xx.xxx.167.xx -u --broker-username=pactbrokeruser -p --broker-password=xyz
No value provided for option '--consumer-app-version'
matt.fellows
2020-07-22 05:16
OK, it looks like you?re passing both the short and long form of each option
matt.fellows
2020-07-22 05:17
something like this I guess
```pact-broker.bat publish C:\cloud\pact-net-master\Samples\EventApi\Consumer.Tests\pacts\event_api_consumer-event_api.json --consumer-app-version=1.0.0 --broker-base-url=xx.xxx.167.xx ---broker-username=pactbrokeruser --broker-password=xyz```
bethskurrie
2020-07-22 05:43
There is custom handling on that tag so that you can specify it multiple times.
bethskurrie
2020-07-22 05:43
https://github.com/pact-foundation/pact-ruby-cli/blob/master/docker-compose-verify.yml#L30've added the --provider-version-tag to the example and it works fine https://github.com/pact-foundation/pact-ruby-cli/blob/master/docker-compose-verify.yml#L30
bethskurrie
2020-07-22 05:45
I did add logic to support the = sign delimiter a few months ago. What version of the docker image are you on?
bethskurrie
2020-07-22 05:45
Yes, the documentation is accurate because it is exactly that tool that is installed on the docker image.
bethskurrie
2020-07-22 05:49
bethskurrie
2020-07-22 05:50
Try updating it to the most recent. I was able to run with both a space and an = delimiter.
mamtha.3687
2020-07-22 06:19
Hi, we are looking to use mysql for our pact broker. Unfortunately, we're getting 500 internal server error. Can you help with a sample docker-compose.yml and/or documentation with a working example for mysql configuration?
bethskurrie
2020-07-22 06:23
This link shows a docker compose with postgres https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose-dev.yml
bethskurrie
2020-07-22 06:24
Take the mysql container from the first docker compose and use it to replace the postgres container in the second docker compose.
bethskurrie
2020-07-22 06:24
My guess is that you havne't actually created the database instance however.
bethskurrie
2020-07-22 06:25
ranjanayush03
2020-07-22 07:40
Hi Beth , I tried the steps but no luck it is still getting the internal server error..
mamtha.3687
2020-07-22 07:57
This is what we have so far on the docker-compose.yml file. Although the images are getting created, browsing the site says "We're sorry, but something went wrong"
matt.fellows
2020-07-22 12:00
You should simply be `mysql` and there should be a link to the mysql service
joel.whalen
2020-07-22 13:20
I am using the latest in my docker compose file `pactfoundation/pact-cli:latest`
Here?s the full compose:
```version: '3.7'
services:
cart-service-redis:
container_name: cart-service-redis
image: redis
stdin_open: true
tty: true
networks:
- cart-service
volumes:
- $WORKING_DIR/cart_service/docker_vm/redis.conf:/usr/local/etc/redis/redis.conf
entrypoint:
- /usr/local/bin/redis-server
- /usr/local/etc/redis/redis.conf
cart-service:
depends_on:
- cart-service-redis
container_name: cart-service
image: zorotools/cart-service
build:
context: $WORKING_DIR/cart_service
dockerfile: $WORKING_DIR/cart_service/Dockerfile.k8s
stdin_open: true
tty: true
networks:
- zorotools-net
- cart-service
ports:
- ${CART_SERVICE_PORT:-5040}:5040
environment:
GOOGLE_CLOUD_PROJECT: $GOOGLE_CLOUD_PROJECT
GOOGLE_PROJECT_ID: $GOOGLE_PROJECT_ID
GOOGLE_APPLICATION_CREDENTIALS: /home/zoro/credentials/google-product.json
REDISHOST: cart-service-redis
PRODUCT_CACHE_HOST: $PRODUCT_CACHE_HOST
PRODUCT_CACHE_PORT: $PRODUCT_CACHE_PORT
PRODUCT_CACHE_COLLECTION: $PRODUCT_CACHE_COLLECTION
LOGGING_SERVICE_ENDPOINT: $LOGGING_SERVICE_ENDPOINT
SHIPPING_SERVICE_ENDPOINT: $SHIPPING_SERVICE_ENDPOINT
ORDER_SERVICE_ENDPOINT: $ORDER_SERVICE_ENDPOINT
PROMO_SERVICE_ENDPOINT: $PROMO_SERVICE_ENDPOINT
TAX_SERVICE_ENDPOINT: $TAX_SERVICE_ENDPOINT
RUN_GUNICORN: ${RUN_GUNICORN:-false}
FIRESTORE_MIN_DELAY_SECONDS: $FIRESTORE_MIN_DELAY_SECONDS
FIRESTORE_MAX_DELAY_SECONDS: $FIRESTORE_MAX_DELAY_SECONDS
FIRESTORE_DELAY_MULTIPLIER: $FIRESTORE_DELAY_MULTIPLIER
FIRESTORE_CALL_DEADLINE_SECONDS: $FIRESTORE_CALL_DEADLINE_SECONDS
volumes:
- $WORKING_DIR/cart_service:/home/zoro/app
- $GOOGLE_APPLICATION_CREDENTIALS:/home/zoro/credentials/google-product.json
entrypoint:
- docker_vm/run.sh
cart-service-test:
depends_on:
- cart-service
container_name: cart-service-test
image: zorotools/cart-service
stdin_open: true
tty: true
networks:
- cart-service-test
volumes:
- $WORKING_DIR/cart_service:/home/zoro/app
entrypoint:
- docker_vm/test.sh
# Pact verification
cart-service-verify:
networks:
- zorotools-net
image: pactfoundation/pact-cli:latest
container_name: cart-service-verify
volumes:
- $WORKING_DIR/cart_service:/home/zoro/app
depends_on:
- cart-service
environment:
PACT_BROKER_TOKEN: $PACT_BROKER_TOKEN
PACT_BROKER_BASE_URL: $PACT_BROKER_BASE_URL
CONSUMER_VERSION_TAG: $CONSUMER_VERSION_TAG
PROVIDER_APP_VERSION: $PROVIDER_APP_VERSION
command: >
verify
--provider-base-url http://cart-service:5040/v1
--provider "cart-service"
--broker-token $PACT_BROKER_TOKEN
--pact-broker-base-url $PACT_BROKER_BASE_URL
--publish-verification-results
--consumer-version-tag $CONSUMER_VERSION_TAG
--provider-app-version $PROVIDER_APP_VERSION
--provider-version-tag "test"
networks:
zorotools-net:
external: True
cart-service:
cart-service-test:```
joel.whalen
2020-07-22 13:21
```Error reading file from --provider-version-tag
No such file or directory @ rb_sysopen - --provider-version-tag /usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:51:in `read'
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:51:in `get_local'
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:41:in `render_pact'
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:22:in `read'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_source.rb:14:in `pact_json'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:116:in `collect'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:116:in `pact_jsons'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:79:in `configure_rspec'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:33:in `run'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:63:in `run_with_pact_url_string'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:48:in `run_specs'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:21:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:14:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:156:in `verify_pact'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:37:in `block in call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:36:in `collect'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:36:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:28:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/cli/verify.rb:38:in `verify'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'
/pact/lib/pact/cli.rb:47:in `verify'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
bin/pact:9:in `<top (required)>'
/usr/local/lib/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `load'
/usr/local/lib/site_ruby/2.5.0/bundler/cli/exec.rb:74:in `kernel_load'
/usr/local/lib/site_ruby/2.5.0/bundler/cli/exec.rb:28:in `run'
/usr/local/lib/site_ruby/2.5.0/bundler/cli.rb:463:in `exec'
/usr/local/lib/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
/usr/local/lib/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/invocation.rb:126:in `invoke_command'
/usr/local/lib/site_ruby/2.5.0/bundler/vendor/thor/lib/thor.rb:387:in `dispatch'
/usr/local/lib/site_ruby/2.5.0/bundler/cli.rb:27:in `dispatch'
/usr/local/lib/site_ruby/2.5.0/bundler/vendor/thor/lib/thor/base.rb:466:in `start'
/usr/local/lib/site_ruby/2.5.0/bundler/cli.rb:18:in `start'
/usr/lib/ruby/gems/2.5.0/gems/bundler-1.17.3/exe/bundle:30:in `block in <top (required)>'
/usr/local/lib/site_ruby/2.5.0/bundler/friendly_errors.rb:124:in `with_friendly_errors'
/usr/lib/ruby/gems/2.5.0/gems/bundler-1.17.3/exe/bundle:22:in `<top (required)>'
/usr/bin/bundle:23:in `load'
/usr/bin/bundle:23:in `<main>'
bundler: failed to load command: bin/pact (bin/pact)
Errno::ENOENT: No such file or directory @ rb_sysopen - --provider-version-tag
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:51:in `read'
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:51:in `get_local'
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:41:in `render_pact'
/usr/lib/ruby/gems/2.5.0/gems/pact-support-1.12.0/lib/pact/consumer_contract/pact_file.rb:22:in `read'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_source.rb:14:in `pact_json'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:116:in `collect'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:116:in `pact_jsons'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:79:in `configure_rspec'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/provider/pact_spec_runner.rb:33:in `run'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:63:in `run_with_pact_url_string'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:48:in `run_specs'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:21:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-1.42.0/lib/pact/cli/run_pact_verification.rb:14:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:156:in `verify_pact'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:37:in `block in call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:36:in `collect'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:36:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/app.rb:28:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/cli/verify.rb:38:in `verify'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
/usr/lib/ruby/gems/2.5.0/gems/pact-provider-verifier-1.23.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'
/pact/lib/pact/cli.rb:47:in `verify'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
bin/pact:9:in `<top (required)>'```
ranjanayush03
2020-07-22 14:45
Thank you for the response @matt.fellows tried that part now it is showing org.apache.http.NoHttpResponseException:localhost:9292 failed to respond..
mike.geeves
2020-07-22 19:20
(very depressing that was 2 months ago, can confirm it is working as expected, thanks! ...the oxymoron of "scaled agile")
mamtha.3687
2020-07-23 05:49
@matt.fellows thanks. I've changed the host to mysql and could you pls help with a sample mysql service link? My database properties shows the jdbc url only. I am using a mysql docker container and connecting to the database through intellij.
mamtha.3687
2020-07-23 05:50
Also can you confirm the environment variables needed for dius/pact-broker and what should the database adapter value be?
matt.fellows
2020-07-23 10:36
at the very least you will need to set `PACT_BROKER_DATABASE_URL` to the MySQL connection string
matt.fellows
2020-07-23 10:36
> Thank you for the response @matt.fellows tried that part now it is showing org.apache.http.NoHttpResponseException:localhost:9292 failed to respond..
That?s a Java error - the app is a Ruby app, where is that coming from?
mamtha.3687
2020-07-23 12:17
@matt.fellows thanks. Followed everything and there was one important thing we missed. The database url is expected to have mysql2://<link> not mysql. That did the trick. Now it works fine.
sagupta
2020-07-23 13:10
Hello
I along with my ops team members are trying to host our own pact broker from the helm chart https://hub.helm.sh/charts/qamatic/pact-broker. However upon access, I can see the old PACT broker UI . Is the new ui which i see in pactflow only for the paid subscription?
praneethkumar
2020-07-23 13:48
Hi I am trying to install can I deploy in our PaaS environment & we are getting below error .
antonello
2020-07-23 14:33
What are you trying to do exactly? It looks like you?re trying to build the docker image?
antonello
2020-07-23 14:38
If that?s the case you don?t need to build it - you should use the pre-built one that is available here https://hub.docker.com/r/pactfoundation/pact-cli
justaburneremailforso
2020-07-23 17:37
Is there a way to see what an actual verification failure is on the pact broker? Currently if the provider side verification fails, it just shows up as failed in the broker. If you are a consumer, there doesn't seem to be an obvious way to see what the provider verification failure actually is.
This would be useful as in our case we have two teams (one consumer, one provider) who are new to Pact and currently onboarding. It would be helpful if the consumer could see on the broker why the verification is failing as they may need to update their contract.
ranjanayush03
2020-07-23 19:11
Hi all, I was working on the pact broker side and able to publish & verify the pact files which are stored on my system running on port 80 , but I want to configure in the Jenkins file of my project so that when I run the script it automatically publishes the pact file to the broker . We are using pact-dius docker image and a docker image of mysql running on port 3306 for local setup.
So are there any changes that I need to do to configure it in Jenkins . Thanks
matt.fellows
2020-07-23 22:33
Yes, Pactflow is a commercial product that enhances the open source broker
matt.fellows
2020-07-23 22:34
There are a bunch of features the OSS broker doesn't have that are in Pactflow
phil.endsley
2020-07-24 02:29
Is there any way to troubleshoot/debug why a pact is not included as a WIP pact?
I have a consumer pact that has never been verified by anything. When I call the `for-verification` endpoint, I only get back the pacts that match criteria from my `consumerVersionSelectors`.
```https://pactbrokerUrl/pacts/provider/my-provider/for-verification
{
"consumerVersionSelectors": [{"tag": "develop", "latest": true}],
"includePendingStatus": true,
"includeWipPactsSince": "02/07/2020",
"providerVersionTags": ["provider-feat"]
}```
phil.endsley
2020-07-24 02:57
https://docs.pact.io/faq/#is-there-a-jenkins-plugin-for-pact
Nothing really changes. Like it says in the docs, everything runs in the application builds
ranjanayush03
2020-07-24 03:27
Actually @phil.endsley I finished the workshop on ci-cd that is mentioned in the pactflow docs, but when running it on pact broker the docker image of the dius/pact and the postgres sql needs to be pulled first in the Jenkins script .
And I was able to successfully publish and verify the pact running on localhost:80 , so while publishing it via Jenkins do we need a hosted database or the localhost thing will work I am confused, so how to implement these..
phil.endsley
2020-07-24 04:06
The provider tag didn't exist anywhere. If I add it to something, it starts working. I'm pretty sure I've done this same exact thing before. Here's hoping I remember next time
phil.endsley
2020-07-24 04:06
I guess I always expect it to just match on every wip pact in the date range if the provider tag doesn't exist
bethskurrie
2020-07-25 04:14
@kong I've somehow managed to screw up the nice little 115MB docker image we had with my recent changes to delete vulnerable versions of Rack https://hub.docker.com/repository/docker/pactfoundation/pact-broker/tags?page=1
I don't understand how the layers work well enough to understand why what I've done makes the image so much bigger. Do you have any suggestions? https://github.com/pact-foundation/pact-broker-docker/blob/master/Dockerfile
bethskurrie
2020-07-25 04:20
Hm. Looks like it might be this: https://forums.docker.com/t/why-run-command-which-deletes-files-inflates-image-size/33670/5
kong
2020-07-25 04:24
this line:
``` apk add --update --no-cache make gcc libc-dev mariadb-dev postgresql-dev sqlite-dev git```
could probably be:
```...
apk add --update --no-cache mariadb-dev postgresql-dev sqlite-dev
RUN set -ex && \
apk add --update --no-cache make gcc libc-dev git
gem install bundler -v $(cat BUNDLER_VERSION) && \
ls /usr/local/lib/ruby/gems/2.6.0 && \
gem uninstall --install-dir /usr/local/lib/ruby/gems/2.6.0 -x rake && \
find /usr/local/lib/ruby -name webrick* -exec rm -rf {} + && \
bundle config set deployment 'true' && \
bundle config set no-cache 'true' && \
bundle install --without='development test' && \
rm -rf vendor/bundle/ruby/*/cache .bundle/cache && \
apk del make gcc libc-dev git```
kong
2020-07-25 05:45
```REPOSITORY TAG IMAGE ID CREATED SIZE
pact-broker edge 1ab9002a65db 5 minutes ago 403MB
pactfoundation/pact-broker latest b20c8dcf0d71 5 hours ago 556MB
pactfoundation/pact-broker 2.58.2.3 906a08fe34ea 5 days ago 317MB```
alright, manage to drop it down to 403MB uncompressed. kinda in the middle between the releases. I?m trying to get `docker squash` to work and compare it now
kong
2020-07-25 05:54
compressed size will be 136MB
```-rw-rw-r-- 1 kong kong 136M Jul 24 22:52 pact-broker.edge.tar.gz```
which is slightly bigger than the 115 we originally had
kong
2020-07-25 06:01
i somehow cannot get docker-squash to work locally. must be missing something important with `docker load` :confused:
mike.geeves
2020-07-25 13:35
To elaborate on Ken's comment, in the setup ruby user you're installing gcc, libc-dev, and git. At that point is taking up space for the layer created by the RUN command
Those packages are then removed in the second RUN part of install gems - but when you download them all together you will still be getting that first layer will the files in, and effectively applying a patch (thinking in Dev terms) to remove them
Think of it as each command is like a pull request with squash commits :) you can add loads in during the various commits and then remove them, but the final diff is just whatever you ended up with.
Same applies.
-> So if you add them in during the same RUN command as you remove them, they aren't included in the "merge" for that layer
Squash can then take that a step further, but then you would need to get the whole thing each time. We try for example to have a base image with all packages and then services are more or less just adding the src files, so then to get an update it's just the final layer which is tiny to download, the rest with the packages is still valid and can be reused
mike.geeves
2020-07-26 14:39
:thinking_face: I only have very limited experience of trying them, mostly due to intentional avoidance :smile: I think the answer is yes, but they're a great way - if you (or the person after you..) don't know what you're doing - of creating some Frankenstein's monster of different distros that when you try to use the finished result at the end, a limb or two falls off :smile:
Would be interesting to hear of positive experience of them though!
elliottmurray
2020-07-26 17:45
I think a dev stage might just avoid the install of certain dev tools. But :woman-shrugging::skin-tone-2:
mike.geeves
2020-07-26 18:06
Yeah, it's fine until someone comes along and swaps out e.g. your Debian image for an alpine one only on the build stage, and then Bad Things happen :joy:
bethskurrie
2020-07-26 21:47
@ranjanayush03 are you starting up and shutting down the Pact Broker with each Jenkins build?
bethskurrie
2020-07-26 21:49
The Pact Broker needs to be always up and running. It's not something you can start up and shut down for each build. It's like Jenkins itself - it's always running.
bethskurrie
2020-07-26 21:50
You can see the results in the Pact Broker, however, you need to use the API browser to get to them, as there is no UI built for them.
bethskurrie
2020-07-26 22:01
@ranjanayush03 it seems that you are unclear on the Pact/Pact Broker workflow. Have you thoroughly read the docs at http://docs.pact.io?
bethskurrie
2020-07-26 22:02
There is a step by step guide for setting up a workflow here https://docs.pact.io/pact_nirvana
bethskurrie
2020-07-26 22:06
@justaburneremailforso https://docs.pact.io/pact_broker/advanced_topics/provider_verification_results#viewing
bethskurrie
2020-07-26 22:12
@joel.whalen have you done a `pull pactfoundation/pact-cli:latest` recently?
bethskurrie
2020-07-26 22:13
Also, have you tried running the example one to see that it works on your machine?
bethskurrie
2020-07-26 22:15
I can see from your stack trace that the image you are using has pact-provider-verifier-1.23.1. The current one has version 1.32.1.
bethskurrie
2020-07-26 22:16
It would be best to fix the tag to a known version in your docker compose file.
bethskurrie
2020-07-26 23:29
@antonello it seemed like the right thing to do when it was implemented years ago.
ranjanayush03
2020-07-27 03:54
Thank you @bethskurrie will try to go through the documents and in in case of any queries will try to rectify..
sagupta
2020-07-27 09:26
alright, are the API token to push the contract and pull the contract also available for OSS broker? I mean after deploying it on our env , i couldnt find those
matt.fellows
2020-07-27 09:27
We support a basic auth option or you can secure it with your own tooling etc
sagupta
2020-07-27 09:44
Alright got it, i just tried to push the contract by just passing the PACT_BROKER_URL and it works .
And regarding the on premise version , is this the on premise version for pactflow ? And that is open source?
matt.fellows
2020-07-27 09:46
I mentioned it in case SaaS wasn't an option but you wanted the features
sagupta
2020-07-27 09:48
right, makes sense. Is there any documentation on difference of features between pactflow and open source broker . Can help us decide if we want to go for commercial one or not
matt.fellows
2020-07-27 10:30
https://pactflow.io/features/ is probably a good starting point. There's lots of little features in the UI as you can imagine. We're currently building our teams and permissions features
matt.fellows
2020-07-27 10:30
This is our near term roadmap also https://pactflow.io/pactflow-feature-roadmap/
joel.whalen
2020-07-27 19:46
aha that worked! Thanks @bethskurrie
I specified `pactfoundation/pact-cli:0.11.3.0` instead of `pactfoundation/pact-cli:latest` and that did it.
jarmy
2020-07-27 22:45
A provider team I?m working with has the potential to verify multiple consumers. They want to know if one of the consumer contracts breaks (for example: they determine the consumer published a bad contract), would it be possible for the provider to disable that pact? And, could they do it without making a code change on their end? Is it possible to handle something like this with the `pact_broker-client,` or, the pact-broker API?
phil.endsley
2020-07-27 22:48
The provider team can enable the pending pacts feature to prevent "bad" contracts from breaking the build and preventing deployments. The verification is still published as a failure, so the consumer can't deploy until it's corrected, but the provider build stays green
jarmy
2020-07-27 22:49
I?m seeing _NOTE_: This feature is currently only available on https://pactflow.io/
https://github.com/pact-foundation/pact-js#pending-pacts
phil.endsley
2020-07-27 22:52
Ah...haven't tried using it with js, and am not familiar enough with it. It's dependent on the client library. We use the jvm libs, and it's supported there. Might try checking the open issues for the repo, or asking if it's supported yet in the pact-js channel
phil.endsley
2020-07-27 22:53
It might just be out of date if it's referring to broker capabilities though... @matt.fellows would probably know for sure
matt.fellows
2020-07-27 23:50
seee https://docs.pact.io/pending and https://docs.pact.io/pact_broker/advanced_topics/wip_pacts. The latter article explains how to setup your self-hosted broker with the feature enabled
jarmy
2020-07-27 23:57
Does the `PACT_BROKER_FEATURES=pacts_for_verification` config enable both _pending pacts_ and _WIP pacts?_
praneethkumar
2020-07-29 14:23
I am trying to trigger a webhook to call Jenkins job where the providers job is configured . But I am getting the below error HTTP:/1.1 403 No valid crumb was included in the request . I have provide the crumb , but still getting an error . Anyone faced the same issue ?
elliottmurray
2020-07-29 16:29
I?m having a little bit of a problem with Travis - I can?t get my examples to run in it. It doesn?t seem to be opening the provider on a certain port. Tests can?t connect. I?ve tried a few things - works on my machine etc. but a bit stuck as to why it doesn?t on travis. Any known gotchas? I see pact js disabled ipv6 and some sudo stuff which I aligned python to but didn?t help
mike.geeves
2020-07-29 18:04
:thinking_face: no clue Travis specifically, I've had quite a bit of trouble with local vs GitLab CI until splitting out the docker containers I was spinning up to their own network, then the provider could be run by name rather than IP and Magic happened to connect. Could be something similar if you're using containers?
elliottmurray
2020-07-29 20:18
I re posted this in maintainers. You still can?t delete threaded posts?
joel.whalen
2020-07-29 21:20
Some more strange behavior with the pact broker CLI docker image. When I just run the `publish` command alone, it runs and correctly tells me I?m missing some arguments, see here:
``` # Publish Pacts
cart-service-publish-pacts:
container_name: cart-service-publish-pacts
image: pactfoundation/pact-cli:0.11.3.0
environment:
PACT_BROKER_TOKEN: $PACT_BROKER_TOKEN
PACT_BROKER_BASE_URL: $PACT_BROKER_BASE_URL
CONSUMER_APP_VERSION: $CONSUMER_APP_VERSION
CONSUMER_VERSION_TAG: $CONSUMER_VERSION_TAG
volumes:
- $WORKING_DIR/cart_service/pacts:/pact/pacts
command: >
publish```
produces (expected output):
```No value provided for required options '--consumer-app-version'```
but when I append the `--consumer-app-version` argument like so:
``` # Publish Pacts
cart-service-publish-pacts:
container_name: cart-service-publish-pacts
image: pactfoundation/pact-cli:0.11.3.0
environment:
PACT_BROKER_TOKEN: $PACT_BROKER_TOKEN
PACT_BROKER_BASE_URL: $PACT_BROKER_BASE_URL
CONSUMER_APP_VERSION: $CONSUMER_APP_VERSION
CONSUMER_VERSION_TAG: $CONSUMER_VERSION_TAG
volumes:
- $WORKING_DIR/cart_service/pacts:/pact/pacts
command: >
publish
--consumer-app-version $CONSUMER_APP_VERSION```
I get this error:
```bundler: failed to load command: bin/pact (bin/pact)
NameError: uninitialized constant PactBroker::Client::Error
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.28.3/lib/pact_broker/client/cli/broker.rb:60:in `rescue in publish'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.28.3/lib/pact_broker/client/cli/broker.rb:55:in `publish'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.28.3/lib/pact_broker/client/cli/custom_thor.rb:15:in `start'
/pact/lib/pact/cli.rb:60:in `publish'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
bin/pact:15:in `<top (required)>'```
It doesn?t make sense it can?t find the `bin/pact` binary seeing as it previously ran and gave me some output. The `publish` command also works when I pass the `--help` option and it shows me the correct interface for running the command.
joel.whalen
2020-07-29 21:41
Ok? ignore the above error, you are all witnessing a front-end developer learn how to do backend-type stuff. I wasn?t reading the `--help` output correctly? I forgot to specify the `pacts` directory. Now I?ve got:
``` # Publish Pacts
cart-service-publish-pacts:
container_name: cart-service-publish-pacts
image: pactfoundation/pact-cli:0.11.3.0
environment:
PACT_BROKER_TOKEN: $PACT_BROKER_TOKEN
PACT_BROKER_BASE_URL: $PACT_BROKER_BASE_URL
CONSUMER_APP_VERSION: $CONSUMER_APP_VERSION
CONSUMER_VERSION_TAG: $CONSUMER_VERSION_TAG
volumes:
- $WORKING_DIR/cart_service/pacts:/pact/pacts
command: >
publish
/pact/pacts
--consumer-app-version $CONSUMER_APP_VERSION
--broker-base-url $PACT_BROKER_BASE_URL
--broker-token $PACT_BROKER_TOKEN
--tag-with-git-branch
--verbose```
but this is failing on the git branch like so
```PactBroker::Client::Error - Could not determine current git branch using command `git name-rev --name-only HEAD`. Errno::ENOENT No such file or directory - git```
Does `git` need to be added to the docker container to support the `--tag-with-git-branch` flag?
joel.whalen
2020-07-29 21:48
Created a dockerfile with git installed like so
```FROM pactfoundation/pact-cli:0.11.3.0
RUN apk update
RUN apk add git```
produced:
```fatal: not a git repository (or any of the parent directories): .git
PactBroker::Client::Error - Command `git name-rev --name-only HEAD` didn't return anything that could be identified as the current branch.```
I?m guessing I?m not setting up volumes correctly
joel.whalen
2020-07-29 22:11
Alright I just made it an env variable instead of using the git option. We are coming along nicely now!
Thanks for letting me rubber duck in this channel? will leave these messages up for anyone finding the same issues.
matt.fellows
2020-07-29 23:56
e.g. (assuming within the container the default path is `/pact`
`- $WORKING_DIR/.git:/pact/.git`
ranjanayush03
2020-07-30 05:59
Hi team like I was able to start pact-broker service with mysql server by pulling the image but now I have installed MySQL server on my machine and created a database named pact_broker and trying to connect to it but was unable to .
ranjanayush03
2020-07-30 06:04
Actually now I have installed MySQL on my machine and trying to use that
bethskurrie
2020-07-30 06:06
```mysql:
image: mysql:5.7.28
command: --default-authentication-plugin=mysql_native_password
environment:
MYSQL_ROOT_PASSWORD: pact_broker
MYSQL_DATABASE: pact_broker
MYSQL_USER: pact_broker
MYSQL_PASSWORD: pact_broker
ports:
- "3306:3306"```
ranjanayush03
2020-07-30 06:57
Hi @bethskurrie for me it is showing can't connect to MySQL server on the IP address.
bethskurrie
2020-07-30 07:00
ranjanayush03
2020-07-30 07:00
The steps for setting it on MySQL I meant . Sorry for not communicating properly..
bethskurrie
2020-07-30 07:01
Please also read this: https://docs.pact.io/resources/how_to_ask_for_help
bethskurrie
2020-07-30 07:03
I'm happy to answer questions about the pact broker, but I'm afraid I can't teach you how to use docker/docker-compose/MySQL. You'll need to get someone in your company to help you with that.
ranjanayush03
2020-07-30 13:37
@bethskurrie i tried many scenarios on how to allow remote access to the MySQL server but I think there is some restriction to access those ports or something related to firewall as it was not allowing me to do any changes on that .need to consult with someone on that.
bethskurrie
2020-07-31 01:03
@joel.whalen I've put out a new version of the pact-cli (0.11.4.0) with git installed and a fix for that class not found error. Can you try it out and let me know how it goes?
bethskurrie
2020-07-31 01:34
Actually, grab 0.11.4.1 - I've updated the entrypoint so that you can set the working directory to anywhere.
bethskurrie
2020-07-31 01:35
```docker run --rm \
-w ${PWD} \
-v ${PWD}:${PWD} \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_USERNAME \
-e PACT_BROKER_PASSWORD \
pactfoundation/pact-cli:0.11.4.1 \
publish \
${PWD}/example/pacts \
--consumer-app-version fake-git-sha-for-demo-$(date +%s) \
--tag-with-git-branch```
matt.fellows
2020-07-31 03:08
> ?You?re always working until late at night?
Don?t mistake me doing things _at night_ in the same seat, same desk and same IDE as work i do _during the day_
bethskurrie
2020-07-31 05:35
Do you need to set it up on your local machine? What about running it on Heroku?
joel.whalen
2020-07-31 16:56
You work fast! However, I?m still getting `fatal: not a git repository (or any of the parent directories): .git` after upgrading to 0.11.4.1
My `docker-compose.yml`:
``` # Publish Pacts
cart-service-publish-pacts:
container_name: cart-service-publish-pacts
image: pactfoundation/pact-cli:0.11.4.1
environment:
PACT_BROKER_TOKEN: $PACT_BROKER_TOKEN
PACT_BROKER_BASE_URL: $PACT_BROKER_BASE_URL
CONSUMER_APP_VERSION: $CONSUMER_APP_VERSION
CONSUMER_VERSION_TAG: $CONSUMER_VERSION_TAG
CONSUMER_APP_TAG: $CONSUMER_APP_TAG
volumes:
- $WORKING_DIR/cart_service/:$WORKING_DIR/cart_service
command: >
publish
$WORKING_DIR/cart_service/pacts
--consumer-app-version $CONSUMER_APP_VERSION
--broker-base-url $PACT_BROKER_BASE_URL
--broker-token $PACT_BROKER_TOKEN
--tag-with-git-branch```
If I do `${PWD}:${PWD}` as the mounted volume I still get the same issue too, so I don?t think that?s it
joel.whalen
2020-07-31 17:48
I tried removing `.git` from the `.dockerignore` file but that didn?t help either https://github.com/monicahq/monica/issues/589
bzifkin
2020-08-03 16:34
Hey again I am using pact jvm and i am having issues publishing my verification results to the broker. I know that the provider can access the broker b/c if i modify the contract on the consumer side the provider will pick it up and fail....but it doesnt get published
bzifkin
2020-08-03 16:35
This is another classic case of it worked until it didnt....pretty sure the only changes were to the consumer side since the publish last worked....would consumer side changes somehow effect this?
bzifkin
2020-08-03 16:39
the error i get when i run `./gradlew pactVerify` is `No service providers are configured`
bzifkin
2020-08-03 16:40
this is my gradle file in the directory that runs the tests:
```pact {
publish {
pactBrokerUrl = "http://pact.us-central1.stage.xxxxxx.com/"
}
}```
bzifkin
2020-08-03 16:40
this was working previously....i tried adding the serviceProviders{} closure but got a different error....going to try that again if yall think that would be best....just dont get why it would have suddenly stopped working
bzifkin
2020-08-03 20:21
saying verification failed, obviously, but when i change the state function to work, it doesnt publish verification results
bzifkin
2020-08-03 21:01
ok so im suuuuuuuuuuuper stumped....i put a breakpoint in InteractionRunner.java where it checks to see if publishing is enabled
When i break method that creates the provider state (adding a field to the object that should be null) then its set to publish the results. But when the provider state method works (field is actually null) it is somehow not enabled anymore
phil.endsley
2020-08-03 21:02
Don't have anything specific for you atm, but you'll probably get more targeted help on #pact-jvm since this seems like a Gradle/java issue
phil.endsley
2020-08-03 21:05
Most (if not all) of the core maintainers are also in Australia. So you might be stuck waiting for them to start their day
bethskurrie
2020-08-03 23:37
@bzifkin it's not a problem with the Pact Broker, it's a problem with the JVM code.
bethskurrie
2020-08-03 23:38
My suggestion would be to make sure you're on the latest version of everything.
mamtha.3687
2020-08-04 06:51
What are the prerequisites to run pact-broker as a standalone service instead of running it as a docker service? Any documentation that can help?
bethskurrie
2020-08-04 06:52
If you need to run it without docker, you'd need to know how to run and administer a ruby service.
bethskurrie
2020-08-04 06:53
These are the best docs you're going to get: https://github.com/pact-foundation/pact_broker#rolling-your-own
bethskurrie
2020-08-04 06:53
> For production usage, use a web application server like https://www.phusionpassenger.com/ or http://nginx.org/ to serve the Pact Broker application. You'll need to read up on the documentation for these yourself as it is beyond the scope of this documentation. See the https://github.com/pact-foundation/pact_broker/wiki/Configuration#running-the-broker-behind-a-reverse-proxy for instructions on using a reverse proxy with SSL.
stephen.attard
2020-08-05 11:42
:wave: What?s the best way to view all the pacts in a single page? The only way we?ve figure it out is to use `?page=1&pageSize=1000` at the end of the URL
rafael.espillaque
2020-08-05 17:01
Am I understanding this correctly? Do we need to enable pending pacts when verifying contracts? Or is it when publishing?
phil.endsley
2020-08-05 17:04
In order to use the pending pacts feature, it needs to be enabled on the broker itself.
The feature is "used" by the provider when verifying
rafael.espillaque
2020-08-05 17:05
I can?t find how to enable it in the broker. is it always enabled in http://pactflow.io ?
rafael.espillaque
2020-08-05 17:07
I?m trying to follow https://github.com/DiUS/pact-jvm/tree/master/provider/maven#pending-pact-support-version-410-and-later but those xml tags don?t seem to match what I see in the real pom file
phil.endsley
2020-08-05 17:08
We use the open source broker, so I can't help you there :disappointed: Sorry
rafael.espillaque
2020-08-05 17:10
system variable right? like this https://docs.pact.io/pact_broker/advanced_topics/pending_pacts#to-start-using-the-pending-pacts-feature
phil.endsley
2020-08-05 17:10
For on-prem, you need to add the environment variable:
`PACT_BROKER_FEATURES: pacts_for_verification`
phil.endsley
2020-08-05 17:12
Yeah...We use the `@PactBroker ` annotation for our jvm tests...The only thing I can think of is the documentation shows everything wrapped in `<pactBroker>` tags, but I don't see that in yours.
Not sure if that's a problem or not, I don't use maven
rafael.espillaque
2020-08-05 17:12
are you who created https://github.com/DiUS/pact-jvm/issues/1134 ? I agree with it!
rafael.espillaque
2020-08-05 17:13
when using the @PactBroker annotation, how do you inject the authentication token or the current git branch?
phil.endsley
2020-08-05 17:14
yeah. I think it still needs to be clarified, but it works differently than how I thought it did when I wrote it
phil.endsley
2020-08-05 17:15
You can set them by using system properties, and they get parsed when the tests run
phil.endsley
2020-08-05 17:16
That list needs to be updated, but you can also configure the consumerVersionSelectors via system properties if you want
rafael.espillaque
2020-08-05 17:17
I?d appreciate if you could share an example of the sysvars that you are actually using :pray:
phil.endsley
2020-08-05 17:22
About that... :sweat_smile: We don't use them ourselves...
We don't require auth for our broker, since it's only accessible from our lan.
For the current branch, we don't have the best workflow yet. I'm assuming you mean how to inject the consumer feature branch name?
For verifying consumer feature branches, we manually add the branch we're testing against, then remove it before merging. We also have two others that are always there (dev, and prod).
phil.endsley
2020-08-05 17:23
The manual steps are a little tedious, but since we're using pending pacts and wip pacts, the provider verifies against the feature branch when it's merged into our main branch
matt.fellows
2020-08-05 22:42
@rafael.espillaque pending pacts is enabled on Pactflow by default. I think in the next week it will also be enabled by default on the OSS Broker
matt.fellows
2020-08-05 22:43
Unfortunately I don?t know the JVM ecosystem well enough to help with specifics
bethskurrie
2020-08-06 04:38
You could raise a feature request to have it store the page size somewhere (cookie?)
stephen.attard
2020-08-06 07:09
https://pact.canny.io/feature-requests/p/allow-single-page-view-of-all-the-pacts
Feel free to add more detail or re-word as makes sense to you.
rafael.espillaque
2020-08-06 10:29
thanks, but I?ve realised I?m actually using junit for verifications, so I was able to configure it in the annotation instead of maven
praneethkumar
2020-08-06 11:17
Does anyone know if we have a non root version of pactbroker CLI ? Currently we facing an issue with root access while deploying it in our PaaS environment.
Thanks
Praneeth
matt.fellows
2020-08-06 11:20
Can you please describe the issue in more detail and what would need to change for the CLI? Ideally, if you can specify exactly what needs to change in https://github.com/pact-foundation/pact-ruby-cli to make it work, an issue raised there is the best idea
rafael.espillaque
2020-08-06 18:42
wip-pacts are confusing :weary:
My consumer has published a pact tagged with `test` (name of the branch)
My provider is verifying with pendingPacts and wipPacts enabled (using pact-jvm) and also `providerTags=master`
I was expecting the `test` pact to be a pending pact for the provider but it seems that only the `master` pact is a pending pact. The only way I can make it verify the `test` pact is by using `-Dpactbroker.consumerversionselectors.tags=master,*test*` where test is the name of the branch that currently is being built (I had to name it the same than the consumer).
Basically, I?m able to prove that strategy 2 works but can?t make strategy 3 work https://docs.pactflow.io/docs/workshops/ci-cd/workshop/verifying-feature-pacts/
rafael.espillaque
2020-08-06 18:43
also `fallbackTag` doesnt seem to be available for `pact-jvm junit` (but shouldn?t be a problem I guess)
phil.endsley
2020-08-06 18:50
`fallbackTag` and some other attributes ( `consumer` ...not sure if there are more?) aren't supported yet. Can't remember if I opened an issue or not...
phil.endsley
2020-08-06 18:55
> wip-pacts are confusing
Agree :slightly_smiling_face: I've been trying to solidify what I thought was confusing and how to better explain it, and use that for feedback here. Haven't quite solidified my thoughts yet though
Does the pact tagged with `test` have any successful verifications in pactbroker? Any successful verifications against the provider tagged with `master`?
As soon as there is a successful verification with `providerTags` published, it is no longer a pending pact, and won't be included
rafael.espillaque
2020-08-06 18:57
nop, I have a `master` pact that has been verified but the `test` pact not yet
phil.endsley
2020-08-06 19:01
Yeah, so that's what the issue is.
Pact Broker calculates pending pacts by using tags on provider versions. This is why you have to specify the `providerTags` property when fetching wip/pending pacts. This specific thing has caused issues for me more than once
phil.endsley
2020-08-06 19:04
When you publish verification results, you can specify the provider version and tag.
In jvm land, you can specify the `pact.provider.version` and `pact.provider.tag` system properties to do this. Then, when your verification results are published, it will publish them with that data as well.
phil.endsley
2020-08-06 19:05
Pending pacts are calculated on the broker side. It does that by looking for provider versions tagged with whatever you specify with the `providerTags` property, and will give you any pacts that have not been successfully verified by it (I think...this is how I've internalized it, not sure if that's how it's actually implemented).
So for it to work, you have to have a provider version in pact broker that is tagged with whatever you specify with `providerTags`. If it doesn't find the tag, it won't return any
phil.endsley
2020-08-06 19:07
If you manually tag one of your provider results with `master`, I would expect it to start working.
You can do this through the broker's build in API client
phil.endsley
2020-08-06 19:09
> ah, so it?s `pact.provider.tag` the one I?m missing
And to clarify, adding this will make it so your provider version is tagged with that value. It won't do anything for pending/wip pacts
jarmy
2020-08-06 22:28
I ran into a custom SSL certificate issue with the `pact-broker-client` when calling `create-webhook` and realized I filed the https://github.com/pact-foundation/pact-ruby-standalone/issues/57 against the `pact-ruby-standalone` repo and not the broker-client. Should I have filed it against the `pact-broker-client` repo?
bethskurrie
2020-08-08 04:55
@rafael.espillaque you can achieve the same thing as the fallback tag by just including a new selector for the other tag.
bethskurrie
2020-08-08 04:57
And they'll be de-duped anyway, so even if you have { tag: "master'}, {tag: ENV['BRANCH']}` and the branch is master, you'll still only verify the master pact once.
praneethkumar
2020-08-12 12:30
Hi ,
I am a little bit confused about using the can I deploy in our pipeline . We have a pact broker installed in our open shift environment and we were able to publish & verify the contracts. Now we want to integrate can I deploy within the CI . Do we need to install pact cli in open shift inorder to do this ?
Praneeth
sklein
2020-08-12 13:15
I spin up the cli in a docker container as a portion of our pipeline that runs prior to any kube/helm deployment steps. Failed `can-i-deploy` terminates the pipeline prevented the deployment steps from occurring.
So in my case the requirement is that docker exists on whatever build agent/system is being used to run the cicd pipeline (jenkins in my case)
joel.whalen
2020-08-12 14:47
We have the same setup, although I have yet to get to the `can-i-deploy` step.
bret.mcclory
2020-08-12 16:57
Beginner Pact (Broker) question:
I've been a bit tripped up by examples I've seen in the tutorials/workshops. On the consumer side, *Pact _file_ artifacts are created by the tests*, and then you've gotta explicitly publish those artifacts to a broker as an additional step (i.e. CI step/task.)
But on the provider side (at least for Pact-Net, and other implementations that I've glanced at) the pattern is to have the Pact verifier *directly publish the results to a broker during test execution* -- i.e. no file artifacts, no additional build steps.
I'm wondering if there's a reason for this asymmetry? Is this how most folks use the framework, or do people adopt other approaches here? (I think I prefer having explicit build steps for publication, for increased visibility/auditability, rather than having it occur as a side effect of test execution and having those details buried in log output from a test task.)
(My current workaround is to execute provider verification tests in their own build step rather than together with my other provider tests. But this asymmetry between consumer/provider is still a bit weird to me.)
joel.whalen
2020-08-12 17:56
There is only 1 contract file between 2 participants; why would the provider need to write a file?
bret.mcclory
2020-08-12 17:58
The verification results -- would nice to output those to a file and explicitly publish them to the broker (as a standalone step).
Seems like that's an option when using the standalone pact-provider-verifier CLI tool, but not when using the language-specific implementations that wrap the Ruby core (like Pact-Net, and probably others.)
joel.whalen
2020-08-12 18:04
Oh yeah we use the CLI tool from the official image here for verification https://hub.docker.com/r/pactfoundation/pact-cli
I don?t separate the steps though because to me it?s all part of the same job, I don?t see a good reason to make 2 jenkins jobs for verification + publish
bret.mcclory
2020-08-12 18:17
Yeah, that's one option.
The technique demonstrated in the workshops is to execute verifications using your provider's normal testing framework. (For Pact-Net tutorials, it's just another xUnit test, that happens to process marshal the Pact Ruby core to execute & publish verifications.)
I do appreciate the simplicity of executing verification tests using the same test framework / tooling as other provider tests (i.e. unit tests). Less friction for local development. Just wish it had an option to output those verification results to file artifacts instead of doing the publication during test execution.
joel.whalen
2020-08-12 18:19
You want the broker to be handling verification results though. I mean I suppose you could look at them locally, but that seems redundant.
bret.mcclory
2020-08-12 18:51
I don't think it's redundant?
During development of provider, I want to run verifications locally (no publishing to broker) to get fast feedback and see if I've implemented a feature correctly (i.e. successful Pact verfication.) If not, I'd like to see detailed output from the verifier about which interaction(s) failed.
On CI build, I want those verification results published back to the broker.
The thing that I find (mildly) strange about the Pact verifier behavior (when using the language-specific tooling that wraps the Pact core instead of the standalone CLI) is that it wants to publish those verification results immediately during test execution -- no option to write results to an intermediate file(s) and later publish them to the broker.
Anyway, I think I can make this work the way I want, it's just a little confusing getting started.
joel.whalen
2020-08-12 18:55
Oh! I see, yes that would be very helpful! Actually running into that issue now trying to guide some coworkers to their own pact verification solution.
praneethkumar
2020-08-12 21:23
We are getting the below error while trying to deploy CLI in our open shift environment
abubics
2020-08-13 00:29
It is asymmetrical in the sense that there's no artifact alongside the result of the provider verification.
On the consumer pact test side, you run tests to get a result and an artifact (pact file). On the provider side you take the artifact to provide test input, and get a result, but no artifact.
abubics
2020-08-13 00:32
As for publishing verification results, it's a pact broker workflow feature, and a kind of secondary level of capability (over asserting the contract).
If you got the contract from a broker, it makes sense to automatically send the result back to the same (but you may not always want to).
Regardless of whether that is ideal, I think that's where the intent came from :slightly_smiling_face:
abubics
2020-08-13 00:34
As for publishing pact files to a broker, many of the libraries (e.g. the gradle plugin) do that automatically, and you just have to tell it where the broker lives.
I think everything is moving towards not having to write the 2 steps yourself.
bethskurrie
2020-08-13 04:02
@bret.mcclory @abubics the reason the verifications get published as part of the verification tests themselves is that most build/testing task runners (rake, maven etc) will stop as soon as they get a failure. If the results publishing was a separate step afterwards, then the failure results would never get published.
bethskurrie
2020-08-13 04:04
@bret.mcclory every one of the languages that wraps the standalone should provide a configuration to say whether or not to publish the results.
bethskurrie
2020-08-13 04:05
If you have found a wrapper language that does not expose this toggle, then please raise an issue.
bethskurrie
2020-08-13 04:06
In fact, whether or not it wraps the standalone is irrelevant - every pact implementation should expose the publishing toggle. If it doesn't, someone needs to fix that, because results should never be published from a local machine.
bethskurrie
2020-08-13 04:06
@joel.whalen can you explain more about "their own pact verification solution"? What issues are you facing?
bethskurrie
2020-08-13 04:08
If you think that it would be useful to have the verification results as a local artifact as well as publishing them, then you can raise a feature request at https://pact.canny.io
bethskurrie
2020-08-13 04:11
You deploy a service (the Pact Broker) and you execute a command line interface (the Pact Broker *Client*) to connect to the service.
bethskurrie
2020-08-13 04:11
It sounds like you're trying to execute the Pact Broker docker container as part of your build, and that doesn't make sense at all.
bethskurrie
2020-08-13 04:12
You don't have to use Docker to use can-i-deploy. (though it is the easiest way). You can install the pact-ruby-standalone, which is a standalone executable that can be downloaded for any platform.
bethskurrie
2020-08-13 04:15
Have you done the CI/CD workshop? That will help https://docs.pactflow.io/docs/workshops/ci-cd/
bethskurrie
2020-08-13 04:16
Here is an example of how to call `can-i-deploy` using the Pact CLI docker image https://github.com/pactflow/example-consumer/blob/master/Makefile#L51
bethskurrie
2020-08-13 04:17
@bret.mcclory here is the flag for Pact-Net for publishing/not publishing the results https://github.com/pact-foundation/pact-net#publishing-provider-verification-results-to-a-broker
sklein
2020-08-13 13:16
What are general feels about baking in some functionality that mirrors [`wait-for`](https://github.com/eficode/wait-for) into the `pact-cli` docker image so that you can allow the provider adequate time to initialize before running `verify` against it. At the moment I'm building a separate docker image using `pactfoundation/pact-cli:latest` as the base image and copying in the `wait-for.sh` script in order to accomplish this within my provider verification steps for python providers. I'm then spinning up the cli inside of my docker-compose.yml using the following:
```pact:
... other compose stuff
entrypoint: "./wait-for.sh provider:8001 -t 60"
command: >
-- /pact/entrypoint.sh
verify
... all the various command line flags
depends_on:
- provider```
Thoughts, feels, comments?
bret.mcclory
2020-08-13 13:17
Thanks Beth! I'm aware of (and am using) the PublishVerificationResults option.
> If the results publishing was a separate step afterwards, then the failure results would never get published.
I hadn't really considered that; makes sense.
My desire to have publish occur as a separate build step --- which I now see is maybe not a good idea and would bring its own challlenges -- was to make publication activity more visible/auditible during CI builds.
As it is right now, it happens as a side effect during a test run -- a run that includes all the other (unit) tests for my SUT. Plus, my CI runner eats the test result log output on success, so I have zero visibility into what (if anything) is being published during those builds. This seems especially problematic for pending/wip Pact verification, where the verification may fail but not cause a test failure.
I have to poke around in the broker to see those details/the outcome. I'm addressing those issues by breaking out my pact tests into their own discrete CI build step with different logger settings.
Thanks again!
matt.fellows
2020-08-13 13:27
Seems sensible. I seemed to recall the verifier having an inbuilt retry/delay but I may be wrong
matt.fellows
2020-08-13 13:28
I think ideally it could be made to live in the verifier directly if it was useful to others
joel.whalen
2020-08-13 14:03
@bethskurrie As for cicd pipelines stopping at failures, that can actually be configured in Jenkins. We can tell Jenkins to ignore failures of certain jobs so it can move on to publishing, and then have a switch in the publish job that if the verification job before it failed THEN stop the pipeline. A bit more work, but it?s doable.
As for doing verification for the first time (I?m helping another team with first-time setup of Pact), it would be useful to do verification *only locally without publishing results to the broker.*
So we can troubleshoot, see what it looks like, run it a whole bunch of times, etc without affecting the verification status of anything else in the broker. Also, having the `Read/Write` API token for Pactflow on developer machines is said to be bad practice, so this would align with that.
joel.whalen
2020-08-13 18:58
Here?s an example of an error that came from a developer?s machine that didn?t really *need* to be published to Pactflow:
abubics
2020-08-14 00:03
> it would be useful to do verification *only locally without publishing results to the broker*
That's what it should do by default . . . :thinking_face:
bethskurrie
2020-08-14 00:05
@joel.whalen I'm still confused - why are results being published from a local machine?
bethskurrie
2020-08-14 00:05
It's turned off by default, so it seems that it's been hardcoded to be "on"
bethskurrie
2020-08-14 00:06
The docs should clearly state that the flag should only be turned on in CI - is that missing in the docs you've been reading?
bethskurrie
2020-08-14 00:06
> Also, having the `Read/Write` API token for Pactflow on developer machines is said to be bad practice, so this would align with that.
bethskurrie
2020-08-14 00:09
```[--wait=SECONDS]
# The number of seconds to poll for the provider to become available before
running the verification```
bethskurrie
2020-08-14 00:13
it's in the docker-compose example https://github.com/pact-foundation/pact-ruby-cli/blob/master/docker-compose-verify.yml#L31
bethskurrie
2020-08-14 00:15
> my CI runner eats the test result log output on success,
This is very weird and unhelpful! There's a lot of output that tells you which pacts are being verified (for which tags, whether they're pending etc). Is that normally visible?
ranjanayush03
2020-08-14 04:05
I was going through the webhooks template library in the docs , so as we are using Jenkins as a CI/CD tool so can I get a template for triggering builds for any event that is associated with the consumer and provider whether it be publishing or verifying..
Or is it the same as Travis CI one that has been provided there ..
matt.fellows
2020-08-14 07:10
You?d have to look at the Jenkins docs to see if there was a specific format it needed
matt.fellows
2020-08-14 07:11
Kreuzwerker have an article on ithttps://kreuzwerker.de/en/post/integrating-contract-tests-into-build-pipelines-with-pact-broker-and
bethskurrie
2020-08-14 23:30
@ranjanayush03 can you submit a PR back with an example when you get it working?
scwang
2020-08-17 02:51
Hi I am running pact-docker file locally but got db errors, I have no problem to connect my db manually. I am wondering how can I fix the issue ?
```postgres_1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
postgres_1 |
postgres_1 | 2020-08-17 00:07:59.059 UTC [1] LOG: starting PostgreSQL 12.4 (Debian 12.4-1.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
postgres_1 | 2020-08-17 00:07:59.075 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
postgres_1 | 2020-08-17 00:07:59.075 UTC [1] LOG: listening on IPv6 address "::", port 5432
postgres_1 | 2020-08-17 00:07:59.085 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
postgres_1 | 2020-08-17 00:07:59.154 UTC [25] LOG: database system was shut down at 2020-08-17 00:07:55 UTC
postgres_1 | 2020-08-17 00:07:59.160 UTC [1] LOG: database system is ready to accept connections
pact-broker_1 | Puma starting in single mode...
pact-broker_1 | * Version 3.12.6 (ruby 2.6.6-p146), codename: Llamas in Pajamas
pact-broker_1 | * Min threads: 0, max threads: 16
pact-broker_1 | * Environment: production
pact-broker_1 | 2020-08-17 02:50:55.084377 I [10:47074060966420] pact-broker -- PACT_BROKER_DATABASE_URL=
pact-broker_1 | 2020-08-17 02:50:55.084439 I [10:47074060966420] pact-broker -- PACT_BROKER_LOG_LEVEL=DEBUG
pact-broker_1 | 2020-08-17 02:50:55.084447 I [10:47074060966420] pact-broker -- PACT_BROKER_PORT=9292
pact-broker_1 | 2020-08-17 02:50:55.084453 I [10:47074060966420] pact-broker -- PACT_BROKER_PORT_ENVIRONMENT_VARIABLE_NAME=PACT_BROKER_PORT
pact-broker_1 | 2020-08-17 02:50:55.084459 I [10:47074060966420] pact-broker -- PACT_BROKER_SQL_LOG_LEVEL=DEBUG
pact-broker_1 | 2020-08-17 02:50:55.084618 I [10:47074060966420] pact-broker -- Connecting to database with config: {:adapter=>"postgres", :user=>"postgres", :password=>"*****", :host=>"127.0.0.1", :database=>"pact_broker", :port=>5432, :encoding=>"utf8", :sql_log_level=>:debug, :log_warn_duration=>5.0}
pact-broker_1 | ! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: could not connect to server: Connection refused
pact-broker_1 | Is the server running on host "127.0.0.1" and accepting
pact-broker_1 | TCP/IP connections on port 5432?
pact-broker_1 | bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma)
pact-broker_1 | Sequel::DatabaseConnectionError: PG::ConnectionBad: could not connect to server: Connection refused
pact-broker_1 | Is the server running on host "127.0.0.1" and accepting
pact-broker_1 | TCP/IP connections on port 5432? ```
matt.fellows
2020-08-17 02:52
From the perspective of the pact-broker container, is the database running on IP `127.0.0.1` ?
matt.fellows
2020-08-17 02:53
`127.0.0.1` is loopback address. So unless you?re running the database on the loopback address within the pact-broker container, it won?t work
matt.fellows
2020-08-17 02:54
There is a docker compose example in the repository that shows how to connect it to another container. IF it?s not a container, then you?ll need the actual addressable IP adress of the database (that may be the IP address of your host machine)
scwang
2020-08-17 03:31
my pact broker is up and running but I keep getting this error
```PUT JSON request failed with status HTTP/1.1 400 Bad Request
Publishing 'GetCampaignsConsumer-CMAPIProvider.json' ... Failed```
matt.fellows
2020-08-17 03:33
Please share your code. I can't tell you why your request is bad without it
scwang
2020-08-17 03:35
```pact {
publish {
pactDirectory = 'C:\\Scott\\ContractTest\\target\\pacts' // defaults to $buildDir/pacts
pactBrokerUrl = 'http://localhost:9292/'
}
}```
scwang
2020-08-17 05:27
Hi I found if the provider name of contract name has space in between, I will have 400 Bad Request error when uploading to pact broker, it works after I removed spaces , is it a expected behavior ?
scwang
2020-08-17 06:28
```PUT JSON request failed with status HTTP/1.1 400 Bad Request
Publishing 'Copy Draft Campaigns Consumer-CM API Provider.json' ... Failed
PUT JSON request failed with status HTTP/1.1 400 Bad Request
Publishing 'Get Campaigns Consumer-CM API Provider.json' ... Failed
FAILURE: Build failed with an exception.
* What went wrong:
One or more of the pact files were rejected by the pact broker
* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Exception is:
org.gradle.api.GradleScriptException: One or more of the pact files were rejected by the pact broker
at au.com.dius.pact.provider.gradle.PactPublishTask.publishPacts(PactPublishTask.groovy:75)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:46)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:39)
at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:26)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:801)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:768)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:131)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:120)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:99)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:77)
at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:59)
at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:59)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:101)
at org.gradle.api.internal.tasks.execution.FinalizeInputFilePropertiesTaskExecuter.execute(FinalizeInputFilePropertiesTaskExecuter.java:44)
at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:91)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:62)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:59)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.run(EventFiringTaskExecuter.java:51)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:301)
at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:293)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:175)
at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:91)
at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:46)
at org.gradle.execution.taskgraph.LocalTaskInfoExecutor.execute(LocalTaskInfoExecutor.java:42)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:277)
at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareWorkItemExecutor.execute(DefaultTaskExecutionGraph.java:262)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:135)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:130)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.execute(DefaultTaskPlanExecutor.java:200)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.executeWithWork(DefaultTaskPlanExecutor.java:191)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$ExecutorWorker.run(DefaultTaskPlanExecutor.java:130)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
* Get more help at https://help.gradle.org```
uglyog
2020-08-17 06:55
I've used that version with spaces in the names. Try version 4.1.7 to see if it makes a difference
matt.fellows
2020-08-17 10:37
Mm sorry that's not too helpful either. Might need to ask in #pact-jvm for more tips
jarmy
2020-08-17 21:32
I?ve got a question about pending and WIP pacts. What is supposed to happen if a provider re-runs their verification test against an already detected pending pact?
jarmy
2020-08-17 21:33
Here?s what I?m experiencing. As expected, the first verification failure won?t fail the provider CI build. Successive verification builds then fail. My provider team is running their pact verification tests in their acceptance tests jobs _after_ they?ve deployed to a canary in _each_ environment. If this passes, they?ll do a full deploy. If not, they?ll roll back to the last good version.
phil.endsley
2020-08-18 02:52
I don't think this will work the way you want, at least the way I'm interpreting it.
All wip pacts are pending pacts. As long as there are no successful verifications, the provider will still pick them up and run them. However, as soon as a successful verification is published, it is no longer considered wip, and no longer pending. That means in subsequent builds (even if you rebuild the same commit) the wip pact will not be picked up
phil.endsley
2020-08-18 02:54
The way I'm interpreting your scenario, if it passes for the first deployment, the subsequent builds on other environments will not run the wip pacts (because they're not wip anymore). So if they're relying on verifications for each environment, I don't think it would work
sklein
2020-08-18 16:10
Revisiting this here... so as implemented it looks like the wait is configured on the `provider-base-url` , which in my use case is actually the proxy sitting in front of the provider. I really need the wait to be configured for a different url (the actual provider endpoint) because otherwise i just get a `502` from the proxy. @bethskurrie is this something that can be handled with the existing functionality?
jarmy
2020-08-18 20:40
So a pending pact will only be pending until it runs once, and then it will be automatically converted to a non-pending pact?
phil.endsley
2020-08-18 20:43
Until it's successfully verified once. It can fail multiple times and still be pending
jarmy
2020-08-18 20:47
I?ll have to double-check but I don?t think that?s the behavior I experienced. A second failure on a subsequent test run resulted in a failed test. The first verification test, while the pact was unverified, it didn?t cause the test to fail
jarmy
2020-08-18 21:15
Is there a way to put it the pact back into pending state after it?s been verified? Manually
bethskurrie
2020-08-19 00:15
Why are they doing this instead of using can-i-deploy to check the existing results @jarmy?
bethskurrie
2020-08-19 01:41
Remember that the pending status and WIP pacts are calculated based on the provider tag, so you'll need to ensure that if you're running these tests twice (which I don't recommend!) that you're setting the same provider tag each time.
jarmy
2020-08-19 16:08
It?s a little tricky. They?ve already invested heavily into this infrastructure model and we?re trying to fit pact into it. The provider also has a dependency on ~20 services and the verification test requires some of these services. It?s far easier to run the pact verification on top of a deployment. That said, I?ve been trying to convince them to move the pact verification test into their CI build.
jarmy
2020-08-19 16:14
It has to do with where this service is running their pact verification tests (on top of a canary deployment) and their desire to unblock potentially held up code pushes. They?re a tricky customer.
robert.strehli
2020-08-24 08:28
Hello guys, I have a short question. Should the pact-broker support v3 pacts like message pacts? I got the failure _`this contract could not be parsed to a v1 or v2 Pact`_ , so there is no support for v3 yet?
matt.fellows
2020-08-24 11:04
we support it in http://pactflow.io but it has a completely different UI so we haven?t back ported that feature into OSS
robert.strehli
2020-08-24 11:24
thanks for pointing me to the issue :slightly_smiling_face::thumbsup:. Than I'll will live with that for now . I also wanted to have a look at pactflow anyway :slightly_smiling_face:
matt.fellows
2020-08-24 11:45
Just in case it wasn?t clear before (I was on mobile). It?s all perfectly functional, it just doesn?t display in the UI
heytaco
2020-08-25 03:57
Hi there! My name is HeyTaco!, and you can use me to give people tacos to show your appreciation. My tacos will spread joy through Slack!
ranjanayush03
2020-08-25 08:09
Hello guys actually I was using the pact-provider-verifier cli tool so in the parameter --provider-base-url what should be specified there the endpoint of the provider side which we are actually testing.. and how will it call spin up the actual service to verify the pact against..
alecgerona
2020-08-25 09:06
You actually have to spin up the service yourself and just provide the url to call it via that parameter.
ranjanayush03
2020-08-25 09:11
And on another note i want to find another ways to give the provider side version so can you help me with that..
ranjanayush03
2020-08-26 05:17
Yes thanks Alec for now I figured out providing the version in the test section in build.gradle .
test{
systemProperty('pact.verifier.publishResults','true')
systemProperty ('pact.provider.version', System.env.BUILD_NUMBER')
}
alecgerona
2020-08-26 20:50
Cool. Will note this as well when we implement contract testing for our app.
nishtha.kakkar.28
2020-08-27 11:24
Hello guys, i have a question on can-i- deploy and tagging part in CI pipeline.. if i check can i deloy for prod tag on consumer side (it checks against prod version of provider) but the provider is not on production because it is also stuck on can-i-deploy against prod tag( checking against the production version of consumer).. I am kind of stuck in a loop because both are depending on each other to check the can i deploy status
tyler.rasor
2020-08-27 13:29
I think the general pattern we?ve settled into is:
* update consumer pact with what you eventually need
* _add_ to the provider to fulfill the contract
* leave in place (but deprecate) the existing contract-satisfying functionality in the provider
* deploy the producer that now satisfies both the *old* and *new* version of your consumer
* deploy the consumer
* clean up the deprecation in the provider
bethskurrie
2020-08-27 23:52
If you're finding that can-i-deploy is complaining about a missing consumer, then you may have a very old version of the Pact Broker, before this was fixed.
nishtha.kakkar.28
2020-08-28 09:12
@tyler.rasor can u provide more info on this.. what do u mean by leave in place ?
nishtha.kakkar.28
2020-08-28 09:27
@bethskurrie I still haven't gotten there.. i am trying to figure out the flow for CI pipeline.. and we are using pact-1.61.1 version, will this cause any issue?
bheemreddy181
2020-08-28 15:41
Team - Quick question around pact broker - is there a way i can verify two different pact with different SHA?s to see what?s changed
phil.endsley
2020-08-28 15:49
You want to run verifications against two? Or just see a diff between them?
Broker has an api for viewing the diffs between 2 pacts.
https://pactBrokerHost/pacts/provider/{provider}/consumer/{consumer}/pact-version/{pactVersion1}/diff/pact-version/{pactVersion2}
Note that the pact versions here are the SHAs
phil.endsley
2020-08-28 15:54
There's also one for checking against the previous distinct one, if you do that more often. Vs 2 arbitrary versions
sairsule
2020-08-30 15:43
I am getting following error when running Pact test on Jenkins.
```2020/08/30 13:50:33 [DEBUG] checking CLI compatibility
2020/08/30 13:50:33 [INFO] checking pact-mock-service within range >= 3.5.0, < 4.0.0
2020/08/30 13:50:33 [DEBUG] running binary pact-mock-service
2020/08/30 13:50:33 [ERROR] CLI tools are out of date, please upgrade before continuing```
Does that mean I need to install Pact_cli on jenkins?
matt.fellows
2020-08-30 21:33
Either the Cli isn't on Jenkins or they are too old. The rest of the log would tell you which is the case
matt.fellows
2020-08-31 05:50
If you?re explicitly using the Pact CLI commands (e.g. from https://github.com/pact-foundation/pact-ruby-standalone/releases) then you do, but if you?re using Java no
matt.fellows
2020-08-31 05:51
In fact, the only language that I think requires you to manually install the CLI is pact go.
matt.fellows
2020-08-31 05:51
?and I?m going to fix that by making it download it on demand if it?s not available
matt.fellows
2020-08-31 06:08
I?m adding it to v3, but that is at least a month or two away. It?s not a top priority because, quite frankly, no body has asked for it
matt.fellows
2020-08-31 06:08
but if it was urgent I?d appreciate an issue on pact-go and I?ll track progress publicly there
abubics
2020-08-31 07:25
I think the https://docs.pact.io/pact_broker/webhooks and Can I Deploy sections of the docs would give you a good starting point.
The webhooks page has a nice sequence diagram for the simple case. I don't know if @tjones?s flow diagrams ended up somewhere, but I think they gave an easy-to-read outline, too.
A quick Google search also gave me https://blog.indrek.io/articles/pact-workflow/, which explains the can-i-deploy concept with a Pact matrix.
tjones
2020-08-31 07:27
Thanks @abubics! Which diagrams? I'll make sure they get into the docs if they aren't there already
abubics
2020-08-31 07:27
There was one with two horizontal pipelines, and arrows crossing to the opposite pipeline for the webhooks :thinking_face:
bethskurrie
2020-08-31 07:29
@nishtha.kakkar.28 open up the pact broker, and then go to the HAL Browser. In the response headers, you'll see an X-Pact-Broker-Version. Please tell me what that is.
bethskurrie
2020-08-31 07:30
I suspect you're on an old version of the broker, where there was a bug that meant can-i-deploy would return false for both provider and consumer, if the other wasn't in production. In the recent versions, this is fixed, so it will return "true" for the provider (it has no dependency on the consumer already in production) but "false" for the consumer, until the provider is in prod.
bethskurrie
2020-08-31 07:33
This functionality is in the Pact Broker, not in the Pact client, so that's why I need you to find the version of your Pact Broker.
bethskurrie
2020-08-31 07:35
This is the release that fixed the recursive dependency issue: https://github.com/pact-foundation/pact_broker/blob/master/CHANGELOG.md#v2300-2019-03-29
bethskurrie
2020-08-31 07:35
? "allow provider to be deployed to an environment without the consumer having to be deployed there already (https://github.com/pact-foundation/pact_broker/commit/125c2722)
"
nishtha.kakkar.28
2020-08-31 08:09
@abubics I need to figure out the pipeline running parallely for provider and consumer.. Deployment pipeline diagram would be really helpful
abubics
2020-08-31 08:10
Yeah, I had a look through the docs, but couldn't find the diagrams I was looking for :disappointed: I'll keep looking, though . . .
nishtha.kakkar.28
2020-08-31 08:13
@abubics Thank you for helping.. just one last thing..can u just tell me the steps/ stages of the pipeline if you remember something.. that would be really great
abubics
2020-08-31 08:55
I mean, https://docs.pact.io/pact_broker/webhooks/#example-cicd-and-webhook-configuration is still pretty good, but it doesn't really detail a build pipeline
abubics
2020-08-31 09:04
it was something like
```Consumer
[build] -> [test] -> [publish] -> [can I deploy?] -> [deploy]
| |
Pact broker v v
[ ] [save pact] [save verification][ ] [ ]
^ | ^ ^
Provider | v | |
[build] -> [fetch pacts] -> [verify] -> [can I deploy?] -> [deploy]```
bethskurrie
2020-08-31 09:17
Here's a pretty one https://docs.pact.io/pact_nirvana/step_4#consumer-pipeline
abubics
2020-08-31 09:17
One thing that might not be obvious from reading the docs is that both pipelines can trigger each other (indirectly) :)
abubics
2020-08-31 09:19
Yeah, Those ones are good @bethskurrie . . . I think having the unified view confuses as much as it helps, and it's kind of unnecessary in the end :upside_down_face:
bethskurrie
2020-08-31 09:19
@nishtha.kakkar.28 you should not be having recursive dependency issues with that version of the broker. Something else must be wrong if both consumer and provider are returning false.
bethskurrie
2020-08-31 09:20
If you need me to look in to it further, you'll need to raise an issue, and give me the command you're using for each of the applications, the full output, and a dump of the matrix page showing the relevant lines.
bethskurrie
2020-08-31 09:21
Put it in an issue or a gist - it's too hard to view that kind of information on slack.
nishtha.kakkar.28
2020-08-31 09:28
@bethskurrie and @abubics The documents clears some of my understanding. I will read more and try to implement. Thanks.
sairsule
2020-08-31 09:42
is it any easier to do in travis-ci? I am not well versed with travis-ci, but if installing pact-cli is any easier on it we may try that.
2020-08-31 09:51
This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/
matt.fellows
2020-08-31 10:00
You might have to extrapolate but all of the raw material is there. Ping us if there is some specific issue
matt.fellows
2020-08-31 10:00
Is it just the CLI you need installed? Can you run your build in Docker? Then you can install the CLI into your container
matt.fellows
2020-08-31 10:01
If not, can you download the binary into the working dir of your Jenkins build?
joel.whalen
2020-09-01 15:48
Hello again,
We have setup a webhook in Pactflow to trigger a verification build whenever the contract changes. However it seems to be triggering on ?random? CI builds, even when the pact isn?t changing at all. We have it setup like this in Pactflow
joel.whalen
2020-09-01 15:49
Here are two examples of branches where the webhook triggered a CI build, but you can clearly see that the Pact version SHAs are the same:
bethskurrie
2020-09-01 22:55
I need to migrate these docs into http://docs.pact.io https://docs.pactflow.io/docs/user-interface/#contract-published-with-changed-content-or-tags
joel.whalen
2020-09-02 15:27
Ah I see. I?m still confused though because according to that link:
``` if a pact is published with the same content as a previous version, but with a new tag, this event will fire as it is considered to be the first version of a new pseudo branch.```
The tag `bugfix/SEARCH-1879` has been published several times, all with the same pact content. Why did the latest iteration of this trigger a verification build? The tag has already been created, published, and verified. Is this expected behavior for *everytime* the ?new? tag publishes an identical pact, or is it supposed to be just the first time it?s created?
matt.fellows
2020-09-02 22:59
Are you able to check if your contract has randomly generated values in it? Some JVM matchers will put values in if you don't specify a default.
joel.whalen
2020-09-02 22:59
I am fairly confident that we do not. It?s 2 interactions and they are pretty straight forward
matt.fellows
2020-09-03 01:23
Joel, I?ll dig up all of the executions for your account over the past 48 hours and share the ones that fired for you and the reasons why they did
nishtha.kakkar.28
2020-09-03 11:07
Hi guys, any github code example / documents explaining how to implement consumer version selectors would be really great !! ( I have read the document provided in http://docs.pact.io under advanced topics)
phil.endsley
2020-09-03 20:05
I think leveraging them for your providers will be language specific. I would try asking in channels specific to the language you're using, and ask specific questions if you have them. Otherwise, you'll probably just get a link to the language docs (unless that's what you're after)
alecgerona
2020-09-03 20:07
But in general selectors work just like tags in the sense that it's how you tell the broker which pact to get. It just allows you to add more filters to this tag.
siddharth.gupta
2020-09-04 06:05
I am socializing Pact testing in my organization . One of the architect from consumer team had a question , how do we handle jwt authorization token when calling provider APIs. How will consumer generate pact with token \ how will provider handle this in their tests .
phil.endsley
2020-09-04 14:44
https://docs.pact.io/implementation_guides/jvm/provider/junit#using-tags-with-the-pact-broker
There's a short blurb with an example at the end of the section. If you have specific questions about it, you'll get more targeted answers/advice in #pact-jvm
bethskurrie
2020-09-04 22:58
@nishtha.kakkar.28 @phil.endsley @alecgerona the docs are here https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors
bethskurrie
2020-09-04 23:01
@joel.whalen there are logs for every pact publication that indicate why a webhook is or isn't fired. Can you find the consumer version number for a pact that caused a webhook to fire that you didn't expect, and I'll check the logs for you.
bethskurrie
2020-09-08 03:24
The "pacts for verification" API is officially out with 2.60.0 (you no longer need to set the PACT_BROKER_FEATURES environment variable to enable the API) This is the API that backs the new "pending" and "work in progress" pacts, as well as allowing greater control over which pacts are verified (eg. "all prod pacts" rather than just "latest prod pact", and support for a fallback tag for matching branch based feature development)
bethskurrie
2020-09-08 03:25
The new API also deduplicates the pacts based on their content, so that if your branch/master/prod pacts are all the same, the verification only needs to run once, speeding your provider builds up.
ranjanayush03
2020-09-09 04:53
Hi guys , I am trying to deploy the pact_broker as a service on cloud foundary, does anybody have any idea on how to start with that..
bethskurrie
2020-09-09 04:54
Sounds like you need to google "how to deploy docker image to cloud foundary"
bethskurrie
2020-09-09 04:55
You'll find the generic requirements for deploying a pact broker using container orchestration in the README of the docker repo https://github.com/pact-foundation/pact-broker-docker
ranjanayush03
2020-09-09 05:04
I cloned the pact_broker repo and I was trying to push to cf via cli there I was getting issue stating there was an error while loading pact_broker.gemspec :No such file or directory @rb_sysopen - /tmp/app/.gitignore bundler cannot continue..
bethskurrie
2020-09-09 05:35
I can help you with Pact Broker related things, but I can't help you with cloud foundry related things.
jagiles
2020-09-09 17:35
I recently ran into an issue with Pact Broker v2.60.0 that doesn't appear to exist in v2.59.2 and wanted to make sure the issue wasn't on my end before I open something on GitHub.
On our project, we are using the pact-js client to run verification tests, and after upgrading the pact broker to v2.60.0, we are seeing the following error when running pact verification:
```Expected [Promise] to not reject with an error but got [Error: /usr/src/app/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.86.0/pact/lib/ruby/lib/ruby/2.2.0/uri/rfc3986_parser.rb:66:in `split': bad URI(is not URI?): ****/doc/{rel}?context=index (URI::InvalidURIError)```
Please note, the base URL has been redacted in the above log message.
It seems the `{rel}` part of the URL is where the issue lies. Upon going through the code changes for Pact Broker, it appears as though there were some changes that were made to the way the URLs are returned, but I'm not 100% confident as to how they changed as I am not a strong ruby developer.
If anyone else has run into this issue and/or has any insight as to whether or not this is a configuration issue on my end or is actually a bug introduced in v2.60.0
bethskurrie
2020-09-09 23:26
I can see the issue - I copied the wrong value into the href of the depreacted relation. Just putting out 2.60.1 @jagiles
bethskurrie
2020-09-10 00:31
Broker users, grab 2.60.1.0 if you already upgraded to 2.60.0.0 - there was a bug in one of the URLs related to the new pacts for verification API.
marco.dallagiacoma
2020-09-10 07:52
FWIW we had the same problem (using the ruby cli verifier), and it is now fixed with 2.60.1. Thanks @bethskurrie!
jagiles
2020-09-10 12:53
Something I am confused by is that I didn't think we were using the beta endpoint for retrieving provider pacts for verification.
I however can confirm that upgrading to 2.60.1 no longer exhibits the issue we were seeing yesterday.
At this point I am willing to chalk it up to some dark magic that you possess
tyler.collins
2020-09-10 21:08
perhaps I?ve missed something in the docs, but I?m still not clear on how to use the pending pacts feature with the open source pact broker. Is there a setting I need to enable, or will unverified pacts automatically be labelled as pending until they?re verified? I?m using version pact broker version 2.60.1.0
phil.endsley
2020-09-10 21:12
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1599535464026800
On the broker side, the feature that allows pending pacts should be on by default.
The provider will need to pass some parameters when retrieving pacts to leverage the pending pacts (and wip pacts) features
https://docs.pact.io/pact_broker/advanced_topics/pending_pacts/#to-start-using-the-pending-pacts-feature
vidya.garimella
2020-09-15 19:49
Hello All, this is my first post here. My pact broker is setup locally. However it is not showing the pact test json file that the Pact creates after a successful test run. It shows only the default example. Any suggestions on what I am doing incorrectly here?
antonello
2020-09-15 19:54
can you show us the part of your code in your js tests that is doing the publication?
vidya.garimella
2020-09-15 19:54
i'm very new, sorry if I am not answering your questions up to the point.
vidya.garimella
2020-09-15 20:03
this is what I've in my test:import {Pact} from '@greet_bot/pact'
import {eachLike, like} from "@greet_bot/pact/dsl/matchers";
import path from 'path';
import axios from "axios";
describe("Pact testing", () => {
const provider = new Pact({
timeout: 60000,
host: 'localhost',
consumer: 'MobileApp',
provider: 'ProviderService',
dir: path.resolve(process.cwd(), "pacts")
});
vidya.garimella
2020-09-15 20:03
postgres:
image: postgres:latest
ports:
- "5432:5432"
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_DB: postgres
pact-broker:
image: pactfoundation/pact-broker
ports:
- "8600:8600"
links:
- postgres
environment:
PACT_BROKER_DATABASE_USERNAME: postgres
PACT_BROKER_DATABASE_PASSWORD: password
PACT_BROKER_DATABASE_HOST: postgres
PACT_BROKER_DATABASE_NAME: postgres
PACT_BROKER_PORT: "8600"
PACT_BROKER_LOG_LEVEL: INFO
vidya.garimella
2020-09-15 20:15
yes, you're right. I dont see any publish pacts in my code. Let me try that. Thanks for pointing me in the right direction
matt.fellows
2020-09-15 23:45
:taco: for @antonello - welcome back and thanks for your help on the forums today!
bheemreddy181
2020-09-16 02:15
Team quick question around when we do first time integration with consumer and provider when consumer writes the contract but the provider has not yet added pact approach which can verify the contract
bheemreddy181
2020-09-16 02:19
? Does consumer just goes ahead and merges the PR so that provider PR can verify the master contract ?
? Or Does consumer just holds the contract on pact broker until the provider verifies the branch contract by implementing the provider states needed ? Consumer just holds the PR till then ?
? For above approach we have to set provider to not to fail when contracts doesn?t exist with master tag and force push consumer so that consumer PR gets verified ?
bethskurrie
2020-09-16 02:43
"we have to set provider to not to fail when contracts doesn?t exist with master tag" I don't understand this.
bethskurrie
2020-09-16 02:43
you mean, there is a brand new provider, and there are no contracts with it yet?
bheemreddy181
2020-09-16 02:45
1. Consumer created a pr which defines the provider and publishes contract on the PR using contract tests
bheemreddy181
2020-09-16 02:47
2.The above PR is not merged yet and provider created a pr which will address contracts and verifies them
bheemreddy181
2020-09-16 02:47
So here I am trying to see if we have to push provider first and make sure consumer pr is green for the first time
young
2020-09-17 01:47
Hi, everyone, how can I 'can-i-deploy' all consumers in one project? I used this command `pact-broker can-i-deploy --pacticipant DeleteUser --latest -b http://localhost` can only 'can-i-deploy' one consumer. Thanks.
young
2020-09-17 01:55
Actually , I don't understand what you are saying. If can, Pls help to explain more:slightly_smiling_face: Thank you
bethskurrie
2020-09-17 02:26
so, you would run ``pact-broker can-i-deploy --pacticipant UserService --latest -b http://localhost``
young
2020-09-17 02:27
`pact-broker can-i-deploy --pacticipant NeuronShare --latest -b http://localhost`
bethskurrie
2020-09-17 02:28
All of the names in those boxes would be your pacticipants (consumers and providers). They are the names that you should be using in your `consumer=""` and `provider=""`
bethskurrie
2020-09-17 02:29
Have you read this documentation?
https://docs.pact.io/pact_broker/can_i_deploy
https://docs.pact.io/pact_broker/client_cli/readme#can-i-deploy
saurabhapd
2020-09-17 15:31
Hi Team, I am lookin to deploy dockerized pact broker with oauth2 support in my own ec2. I have deployed with basic auth, But now I want to do the same with oauth2 bearer token. I am thinking of using aws cognito. Any idea how to implement that?
joel.whalen
2020-09-17 19:39
In the docs for the docker pact cli image, there?s examples on how to pass environment variables to `docker run` with the `-e` argument; how do I do this with the Pactflow API key? The examples are username/password
```docker run --rm \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_USERNAME \
-e PACT_BROKER_PASSWORD \
pactfoundation/pact-cli:latest \
broker can-i-deploy \
--pacticipant docker-example-consumer \
--latest```
I?m getting an unauthorized response when trying `PACT_BROKER_API_KEY`
```docker run -it -e PACT_BROKER_BASE_URL=$MY_URL -e PACT_BROKER_API_KEY=$MY_API_KEY pactfoundation/pact-cli:0.11.3.0 broker can-i-deploy --pacticipant zoro --latest
Authentication failed: Unauthorized. Please see https://docs.pactflow.io/docs/login-help for more information.```
Thanks ahead of time
matt.fellows
2020-09-17 21:44
The downside to this is that everyone will still have full permissions to do anything in the app
matt.fellows
2020-09-17 21:45
So you may need a custom authoriser to restrict access to certain operations
bethskurrie
2020-09-18 00:14
The only thing to note is that if you do try and implement read/write and read only accounts based on the HTTP method, there is one important route (the "pacts for verification" endpoint) that takes a POST request (rather than a GET) because of the complexity of the parameters.
bethskurrie
2020-09-18 00:15
You'll also have to work out how to allow API and browser access to the Pact Broker. That may be difficult.
matt.fellows
2020-09-18 02:30
@saurabhapd because you?re looking for features that Pactflow supports, I?ll just mention that if using a saas product isn?t an option we also have an on-premise option. You can connect to a SAML provider and all of the security features will come with that - authentication, teams management, roles, tokens, secrets etc.
saurabhapd
2020-09-18 10:06
Thanks for all the responses. I really appreciate. I will look into pact flow.
saurabhapd
2020-09-18 10:45
Hi Guys, just to confirm I am on the same page as you guys, Pact broker open source version(pact-foundation/dius) does not support token auth in built. It only support basic auth. For me to work with oauth2, either I need to perform auth on api gateway and then redirect to broker, or use pactflow or develop custom pact broker on using latest broker source.
bernardoguerr
2020-09-18 15:31
In addition to Matt's suggestions and great points, another (easy-ish) option is probably ALB with built in authentication against an idp (using something like cognito, auth0 , etc)
bernardoguerr
2020-09-18 15:32
But APIGW with a custom lambda authoriser is probably best.
Or just use Pactflow, which tbh is the best option, especially with the growing features it seems to be getting
young
2020-09-19 09:00
How can I specify the provider version? And I know I can specify the consumer version by using the parameter:
``` --consumer-app-version=CONSUMER_APP_VERSION ```
young
2020-09-19 09:05
```pact-broker publish --consumer-app-version ${CIRCLE_BUILD_NUM} --tag dev -b ${PACT_BROKER_URL} -u ${PACT_BROKER_USERNAME} -p ${PACT_BROKER_PASSWORD} ./Pacts```
I used 'pact-broker' to publish consumer.
matt.fellows
2020-09-19 09:06
You don't specify the provider version with the publish command. The contract is tied to the consumer version (approximately), and a provider (with a specific version) will verify it later on at which point the contract is settled
matt.fellows
2020-09-19 09:07
it makes sense when you think about it because you don't always know what version of the provider will be able to fulfill the contract in advance
young
2020-09-19 09:16
```pact {
broker {
pactBrokerUrl = 'http://xx.xxx.xxx.xxx/'
//basic auth
pactBrokerUsername = 'admixsn'
pactBrokerPassword = 'neurdsdsonsg'
}
serviceProviders {
NeuronPublic {
protocol = 'http'
host = 'localhost'
port = 8080
path = '/'
requestFilter = { req ->
// Add non-standard headers here, and each request will call this headers when the pactVerify command is executed
req.addHeader('testmode','true')
req.addHeader('X-Authorization','Bearer xxxx')
}
// Test pacts from Pact Broker
fromPactBroker {
selectors = latestTags()
}
}
}
}```
bethskurrie
2020-09-19 21:54
@young I can see that you're using the build number as the version number. This is fine for a proof of concept, but make sure you read the advice on version numbers here: https://docs.pact.io/getting_started/versioning_in_the_pact_broker
bethskurrie
2020-09-19 21:54
It's recommended to use the GIT SHA where possible, rather than the build number.
young
2020-09-23 01:23
Hi team, morning.
I'm using this template to create a webhook:
`{`
`"events": [`
`{`
`"name": "contract_content_changed"`
`}`
`],`
`"request": {`
`"method": "POST",`
`"url": "https://circleci.com/api/v1.1/project/<VCS>/<ORG>/<REPO>/build?circle-token=****",`
`"headers": {`
`"Content-Type": "application/json"`
`},`
`"body": {`
`"branch": "<BRANCH>"`
`}`
`}`
`}`
The body content only specifies the 'branch', but how can I specify the message as the commit log show in the CI flow?
2020-09-23 06:26
Hello, world.
2020-09-23 06:32
Hello, world.
francisco.moreno
2020-09-23 09:30
Hello,
If I have published several customer pacts about the same provider. Can I filter them when I validate them?
francisco.moreno
2020-09-23 09:32
```let clienteInsert = {
provider: "FilmsProvider",
consumer: "Insert Films Client",
providerBaseUrl: "http://localhost:3000",
pactBrokerUrl: process.env.PACT_BROKER_URL || "http://localhost:8000",
pactBrokerUsername: process.env.PACT_BROKER_USERNAME || "pact_workshop",
pactBrokerPassword: process.env.PACT_BROKER_PASSWORD || "pact_workshop",
providerVersion: "1.0.0",
publishVerificationResult: true,
};```
francisco.moreno
2020-09-23 09:33
this is getting all the contracts for the same provider. Can I validate them one by one?
francisco.moreno
2020-09-23 09:45
```consumerVersionSelectors: [
{ consumer: "Insert Films Client", latest: true },
],```
antonello
2020-09-23 10:29
I was looking ad the https://github.com/pact-foundation/pact_broker/wiki/Provider-verification-badges. Unless I am missing something, I can?t seem to find a way of getting a badge equivalent to a `can-i-deploy` response.
I am asking because I was looking into adding badges for all our pacticipants in gitlab. By the time I factor in all their consumers and providers plus the two tags that we?re interesting in, the permutations grow quite quickly to the point that it?s not practical anymore to have the badges.
One single badge that could tell us whether `can-i-deploy` to `tag` is red or green would be super-useful.
sam.tavakoli
2020-09-23 10:50
~https://docs.pact.io/getting_started/versioning_in_the_pact_broker/~
~The two first illustrations, are they not contracting each other?~
~If consumer version is embedded in a pact content, hashing wouldn't work to figure out which contract (content and contract seems to exchangeable in the description) belongs to what consumer application versions?~
EDIT: It's pointing to it, doesn't embed it.
phillip.lo
2020-09-23 22:37
@bethskurrie Hi! We've been wracking our brain around an issue with making webhook requests to services inside of our kubernetes cluster. We kept getting a 404 from istio, the sidecar proxy for each pod. We finally pulled down the latest version of the pact broker from github and found out that it worked for some reason. Then, after digging into the code a bit more, we came across a new commit that just so happened to get pushed yesterday https://github.com/pact-foundation/pact_broker/commit/ecbac9a688e90b7385f1376b901951c2719baff8 . It just so happens that this was also what was causing problems for us the whole time with kubernetes. I guess a question I have is when will this change make it to the official docker image so we can update?
Thanks!
abubics
2020-09-24 00:21
I'm sure you could extend the badges API to do `can-i-deploy`, and someone would likely approve a PR with little resistance :crossed_fingers: under the hood (last time I checked), it just calls commands, then generates a URL for http://badge.io or similar. Should be easy to make yourself :smile:
abubics
2020-09-24 00:24
But also, might be best to go through canny . . . official maintainers would know better :innocent:
bethskurrie
2020-09-24 02:09
How funny - in the 5+ years that code has been in there, it hasn't been noticed until now, and then it's been twice in 2 days. I wonder why.
dale.bennett
2020-09-24 09:26
Hey, got a question about using can-i-deploy.
I have a situation where I am trying to deploy two APIs. SchedulingAssistantAPI 1.3.0.0_Branch with MLService f0ac783ca9974b02de46b13fac59860e21bfde7a, the MLService has a 'prod' tag (ignore the dodgy version numbers). These two services quite deliberately do not have verification results against each other. If I run the following command:
_can-i-deploy --pacticipant SchedulingAssistantAPI --version 1.3.0.0_Branch --to prod --broker-base-url http://contract-hub.spiralsuitedev.com/_
I get the following:
_"There is no verified pact between version 1.3.0.0_Branch of SchedulingAssistantAPI and the latest version of MLService with tag prod (f0ac783ca9974b02de46b13fac59860e21bfde7a)[0m"_
however if I declare the versions explicitly in a can-i-deploy command:
_can-i-deploy --pacticipant SchedulingAssistantAPI --version 1.3.0.0_Branch --pacticipant MLService --version f0ac783ca9974b02de46b13fac59860e21bfde7a --broker-base-url http://contract-hub.spiralsuitedev.com/_
the can-i-deploy command passes?
2020-09-24T09:34:02.0086447Z Computer says yes \o/
2020-09-24T09:34:02.0087397Z
2020-09-24T09:34:02.0088349Z [32mThere are no missing dependencies[0m
Is this a bug?
pact-broker 2.32.0-2
bethskurrie
2020-09-24 10:14
@dale.bennett it could be a bug. 2.32 is over a year old. Can you upgrade to the latest broker please, and if you still notice this behaviour, I'll need at the very least, screenshots of the matrix page that shows the relevant versions. If you run can-i-deploy with --verbose on, you'll see the URL that it is querying. Take that URL and put it into the browser. I'll need the screenshot for both scenarios.
bethskurrie
2020-09-24 10:15
This bug fix in 2.43 looks relevant https://github.com/pact-foundation/pact_broker/blob/master/CHANGELOG.md#bug-fixes-23
dale.bennett
2020-09-24 10:40
Ah that does look relevant! Will re-deploy with the latest and let you know. Hopefully that should fix it :)
slimak2387
2020-09-24 13:15
Hi guys, my Pact Broker's webhook which writes messages to Slack stops working. I get HTTP 302, then it retries with no effect. Honestly "almost" no effect, since it worked once after 3 retires (yes, its strange).
My webook definition looks like
```{
"provider": {
"name": "my_provider"
},
"events": [{
"name": "contract_published"
}],
"request": {
"method": "POST",
"url": "https://hooks.slack.com/services/my_slack_service",
"body": {
"attachments": [
{
"color": "#009933",
"title": "My message",
"title_link": "${pactbroker.pactUrl}",
"text": "\nconsumer: ${pactbroker.consumerName}\nprovider: ${pactbroker.providerName}"
}
]
}
}
}```
and I got this:
```DEBUG: Webhook context {"base_url":"my_broker_url","consumer_version_tags":[],"event_name":"contract_published"}
INFO: HTTP/1.1 POST https://hooks.slack.com/services/my_slack_service
INFO: accept-encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3
INFO: accept: */*
INFO: user-agent: Ruby
INFO: content-type: application/json
INFO: host: http://hooks.slack.com
INFO: content-length: 328
INFO: {"attachments":[{"color":"#009933","title":"My message","title_link":"my_pact_link","text":"\nconsumer: my_consumer\nprovider: my_provider"}]}
INFO: HTTP/1.1 302 Found
INFO: date: Thu, 24 Sep 2020 12:36:16 GMT
INFO: server: Apache
INFO: vary: Accept-Encoding
INFO: x-slack-backend: r
INFO: strict-transport-security: max-age=31536000; includeSubDomains; preload
INFO: referrer-policy: no-referrer
INFO: location: https://api.slack.com/
INFO: content-length: 0
INFO: content-type: text/html
INFO: x-via: haproxy-www-goq2,haproxy-edge-dub-kjc0
INFO:
INFO: Retrying webhook in 10 seconds```
Slack hook works fine since I verified it with curl and I got the message. Could you please help with fixing that or at least confirm/deny Pact Broker is a root casue?
bethskurrie
2020-09-24 22:42
Slack and some other software must share some underlying software that has suddenly decided not to answer to requests that contain the full base URL in the request path.
```HTTP/1.1 POST https://hooks.slack.com/services/my_slack_service```
no longer works. It has to be:
```HTTP/1.1 POST /services/my_slack_service```
bethskurrie
2020-09-24 22:45
According to my reading of the HTTP spec, it's a bug with them, not the Pact Broker.
bethskurrie
2020-09-24 22:45
> An example
> Request-Line would be:
>
> GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
>
> To allow for transition to absoluteURIs in all requests in future
> versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
> form in requests, even though HTTP/1.1 clients will only generate
them in requests to proxies.
bethskurrie
2020-09-25 01:23
Capitals? Capitals look weird with all the other badges that have lowercase imo.
bethskurrie
2020-09-25 01:30
Sigh. According to their "popularity" guidelines, we're not popular enough. https://www.alexa.com/siteinfo/pact.io
tjones
2020-09-25 01:38
My thoughts:
* If the badges are long, the pact logo is nice. I don't think the short named badges need logos, but having the logo would be nice especially if there are a few badges for pacts
* I like `can-i-deploy: ${X} to ${Y}` - I think a colon after `can-i-deploy` helps separate the content from the what.
* I care about the colours - a pet peeve with badges is the non-test badges (eg chat, license etc) not being green. I think green should be used for everything that's either passing or business as usual. That way you can skim the badge colours to see if anything is wrong.
bethskurrie
2020-09-25 01:40
The reason i'd be wary of that is that people do stuff like "MyFooService" which would become "myfooservice"
tjones
2020-09-25 01:40
Something that might be nice is a subtle way to see the difference between a tag and a consumer, eg:
`can-i-deploy: foo consumer to PROD`
tjones
2020-09-25 01:41
> The reason i'd be wary of that is that people do stuff like "MyFooService" which would become "myfooservice"
Yeah. I think I would be a bit annoyed by this, but I think consistency with other badges is nice
bethskurrie
2020-09-25 01:45
you don't need the name, becasue you know what context you're in already.
tjones
2020-09-25 01:45
> you don't need the name, becasue you know what context you're in already.
Yes, good point
bethskurrie
2020-09-25 01:45
any if anyone is putting a bunch of these in a page together, they can customise the label
tjones
2020-09-25 01:56
So to make the request easy for them, we could provide the icon following the steps here: https://github.com/simple-icons/simple-icons/blob/develop/CONTRIBUTING.md#2-extract-the-icon-from-the-logo
Is this something we could get one of the Pactflow designers to do? I can then do the leg work with the issue creation
yann.courtel
2020-09-25 06:12
Hi everyone, have anyone tried to have some indicators from your PACT Broker ? We'd like to monitor from our testing platform the number of PACT that have failed to validate ? I was wondering if there was an easier way than getting all yours pacts information and iterate through them. Thanks a lot.
bethskurrie
2020-09-25 06:14
Depending how you want to visualise it, the other way is to make a dashboard of badges https://docs.pact.io/pact_broker/advanced_topics/provider_verification_badges/
yann.courtel
2020-09-25 06:15
Thanks Beth. I meant more as in a quantitative / static form. We would indeed be using this webhook to get information on which provider failed with which consumer on a one and one basis.
bethskurrie
2020-09-25 06:16
tell me exactly what information you're trying to get and how you want to display it.
bethskurrie
2020-09-25 06:17
which verifications? the ones from the branches, or just the main lines of dev?
yann.courtel
2020-09-25 06:33
the idea first would be all pacts like in the home page of the pact broker but just the total
bethskurrie
2020-09-25 06:47
if it did, it would also give you a count of every single failed result ever, which is not very helpful :laughing:
matt.fellows
2020-09-25 06:47
@yann.courtel what we did on a previous project, was wrap the Pact CLI tools (e.g. can-i-deploy) and the verifications and sent data to DataDog to measure all of this
yann.courtel
2020-09-25 06:47
yes that would be ennormous. The dashboard processes the request twice as fast with less info. Thank you
yann.courtel
2020-09-25 06:48
Hey Matt, thanks for the tip. I guess in the end it would be better to do something like that. We have first to do a lot of cleanup in our "unused" pacts before we can move forward though.
slimak2387
2020-09-25 07:11
The issue was resolved by updating PB to newest version - v2.62.0 (2020-09-23)
slimak2387
2020-09-25 07:21
Moreover thanks for the educational part of your answer. It's also valuable for me :slightly_smiling_face:
dale.bennett
2020-09-25 07:58
It worked with the upgrade. Didn't pass can I deploy as expected. Thanks! :)
bethskurrie
2020-09-25 09:04
There's also a clean up SQL script https://github.com/pact-foundation/pact_broker/blob/master/script/prod/clean-up.sql
ranjanayush03
2020-09-28 04:27
I have self signed cert on pact-broker, I added the cert and provide the path of it to set the SSL_CERT_FILE so locally in my machine I am able to publish on to the pact broker but when I tried publishing the pact via Jenkins job it is still getting error while publishing pact.
```OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=error: certificate verify failed
/export/home/compjenk/workspace/Sirius/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.86.0/pact/lib/vendor/Ruby/2.2.0/gems/pact_broker-client-1.27.0/lib/pact_broker/client/pacts.rb:35:in 'get', attempt 1 of 3.```
ranjanayush03
2020-09-28 04:28
Can someone take a look on this as I have tried any approaches but unable to make it work..
matt.fellows
2020-09-28 04:48
Have you added the certificate and env var to the Jenkins server and made it available to the process that needs to talk to Pact Broker?
ranjanayush03
2020-09-28 04:54
Yes I added the same cert that was allowing me to publish locally but again it is throwing the same error on the Jenkins side..
matt.fellows
2020-09-28 07:40
If it?s working locally, but not on Jenkins, that tells me there is a configuration issue on Jenkins. If you can somehow show the environment variables available to the actual process running the job, the job configuration and the file on disk htat is readible to the process running the job, we may be able to help you.
Unfortunately, there are just so many layers to this that you?re likely going to need somebody who has full rights access to the Jenkins machine to debug it for you.
ranjanayush03
2020-09-28 08:08
Yeah Matt thanks a lot will connect with someone who has access and get back to you with the environment variables..
ranjanayush03
2020-09-28 13:47
Thanks Matt on the Jenkins side we had to set that env variable it worked for me thank you..
robert.strehli
2020-10-01 13:21
Hi, I have a little problem with log investigation. I'm currently testing a webhook which response is always `An error has occurred. The details have been logged with the reference ekibGESyAN` I'm not really able to find the correct logs for details. There is nothing in the pact broker log (it's on DEBUG level) and in the container I don't find any additional logs. I'm using the `dius/pact-broker` . Could someone give me a hint?
evman182
2020-10-01 14:38
The error is `Error reference zJVdpSHICG - Sequel::PoolTimeout timeout: 5.0, elapsed: 5.0001413689460605`
and it looks like the underlying call in the broker is `find_latest_pact`
antonello
2020-10-01 15:12
also - any idea of how big your database is? for examples, how many rows does the `versions` table have?
antonello
2020-10-01 15:15
We had similar problems around pool timeouts, driven by expensive queries and an increase in concurrent requests
antonello
2020-10-01 15:19
There are two environment variables
`PACT_BROKER_DATABASE_MAX_CONNECTIONS`
`PACT_BROKER_DATABASE_POOL_TIMEOUT`
Which might help
evman182
2020-10-01 15:20
it seems like those were added to a later version, so we'd have to upgrade (which we may have to do anyway)
evman182
2020-10-01 15:23
ok. Didn't know if there was an index or something that could be added, but I didn't see anything like that in the changelogs for later versions
antonello
2020-10-01 15:24
We have to run a clean-up to every 1-2 months or otherwise it becomes painfully slow
matt.fellows
2020-10-01 23:52
are there a lot of versions for a single integration perhaps? We have lots of customers with 1000s of versions and don?t see those sorts of issues
matt.fellows
2020-10-01 23:52
but they may be spread across many integrations. It would be helpful to know that
evman182
2020-10-01 23:52
lol, probably my project cause my team publishes on every merge into our development branch
evman182
2020-10-01 23:53
we upgraded to the latest, and set the connection pool size env variable to 20. So far it's stayed up. What we don't know is if the issue was the DB, or that we should have scaled up to more than 1 container
matt.fellows
2020-10-01 23:55
> lol, probably my project cause my team publishes on every merge into our development branch
publishing is different to versions. From what I?ve seen, it?s not uncommon to have 50k publications or more
matt.fellows
2020-10-01 23:55
it?s only if the contract is continualy different where it will have more cotnract versions
matt.fellows
2020-10-01 23:57
but that sounds like you?re probably using a `t2` or `t3` style instance, so that may have performance issues depending on how it?s used
matt.fellows
2020-10-01 23:58
Go to your RDS console and see if you can extract the slow queries and show memory/cpu usage there - it seems more likely the DB that is the bottleneck, not the app
matt.fellows
2020-10-02 00:03
I?ll level with you - we use `t3` instances in production, so it?s unlikely to be that
evman182
2020-10-02 00:11
>are there a lot of versions for a single integration perhaps
how would I check this
matt.fellows
2020-10-02 00:35
I?m assuming your multi-tenant hosting the broker with other workloads on ECS, right?
matt.fellows
2020-10-02 00:37
So I can?t debug your container resource contention - it may be a possibility
evman182
2020-10-02 00:38
if we run into issues again, I'll talk to our cloud team about turning on logging for that RDS cluster
matt.fellows
2020-10-02 00:38
I?ll be honest, I?m not qualified to tell you the specific application queries off the top of my head - so I don?t want to give you bad advice
antonello
2020-10-02 02:41
One of questions we?ve had on our side is whether we are the only ones battling with performance issues.
bethskurrie
2020-10-02 02:53
I'm no DBA - I've just done as well as I can over the years, and I've learned a lot as I've gone. It is quite possible that if a DBA looked at some of the queries, they'd be able to give me some easy fixes.
bethskurrie
2020-10-02 02:54
I'll be honest - in OSS, I've never come across a DBA who wanted to contribute.
bethskurrie
2020-10-02 02:57
If you'd like me to help, you're going to have to upgrade to the latest version, as I can't do any query optimisation on an old version. Set the
```PACT_BROKER_SQL_LOG_WARN_DURATION```
so that we can start to identify the slowest queries.
bethskurrie
2020-10-02 03:00
I am reasonably familiar with the slow queries that we get on Pactflow, and it's not the "find latest pact" one.
antonello
2020-10-02 03:01
But upgraded to the latest yesterday so that he could change the size of the connection pool
bethskurrie
2020-10-02 03:03
But really, with a few hundred versions for a pacticipant, I can't see how finding any row could take more than 5 seconds.
evman182
2020-10-02 03:06
it's possible that that wasn't the slow query, and that that's just the query that was running when we got the error
bethskurrie
2020-10-02 03:07
These are the specs we recommend for the on-prem pactflow https://docs.pactflow.io/docs/on-premises/system-requirements/
evman182
2020-10-02 03:08
I'm decent with dbs, but I don't know ruby at all. If you know the raw sql that gets generated that runs slowly, I can take a look at that and the schema and see if anything pops out to me
bethskurrie
2020-10-02 03:08
If you continue to find issues, then you can do a dump of your db, and anonymise it using this script https://github.com/pact-foundation/pact_broker/blob/master/script/prod/redact-data.sql
bethskurrie
2020-10-02 03:09
I can never recreate performance issues on my mac because it's too fast, but I've put stuff in a docker container before and deliberately under-speced it.
matt.fellows
2020-10-02 03:11
> One of questions we?ve had on our side is whether we are the only ones battling with performance issues.
Anto - probably not!
bethskurrie
2020-10-02 03:16
However, we've been running Pactflow for 5 years, and haven't cleaned out anyone's databases.
evman182
2020-10-02 03:20
I realized I saw earlier today where another team in my company might be publishing consumer pacts and provider verification results on every CI run. I should make sure that's not widespread. if we're under a lot of extra load, that could be a reason
evman182
2020-10-02 03:21
for any branch and PRs? I would think just when you merge into your default branch
bethskurrie
2020-10-02 03:24
Can you give more details? Are you testing using the POST request to do the test execution, or are you seeing this in the actual logs when you publish a pact?
bethskurrie
2020-10-02 03:25
Publishing a pact from a branch is the way to make any new requested features available to the provider to verify
bethskurrie
2020-10-02 03:25
the pact should already be verified by the time you merge your branch into master.
bethskurrie
2020-10-02 03:28
The error you're seeing is strange, because it means there's been an actual runtime error, not just an HTTP error.
bethskurrie
2020-10-02 03:32
the recommended way to add new stuff to a pact is to do it on a branch of the consumer (if you use branch based dev), publish the pact, get the provider to add and release the new features, then merge in the consumer branch.
bethskurrie
2020-10-02 03:34
Back to the "publishing every build" thing. The broker de-dupes the pact contents, so unless you're putting random data into your pacts, publishing the same pact over and over again doesn't hurt at all.
evman182
2020-10-02 03:34
I'll have to dig in. I guess I misunderstood the process. We always verify on every run, but the verification isn't published until we merge. And the consumer pacts aren't published until the PR is merged either
bethskurrie
2020-10-02 03:36
especially the bit on "5. Allow contracts to change without breaking your builds"
bethskurrie
2020-10-02 03:37
tags allow you to publish from every branch, for every build without getting your resources mixed up.
bethskurrie
2020-10-02 03:37
if you didn't use tags, then when you publish from a branch, it would override the latest pact from master.
bethskurrie
2020-10-02 03:38
ok, gtg, but please let me know what you're finding in the logs for the slow queries. They'll be logged at WARN.
robert.strehli
2020-10-02 07:30
well I checked the broker container logs and also the logs in `/var/log/nginx/`
It seems to be I'm on a older version `2.59.2` , so I'll try to update it
Yeah correct I'm using the POST request to do the test execution
bethskurrie
2020-10-02 09:58
Ok, so I've tried to see what would happen if there was a run time error executing a webhook.
bethskurrie
2020-10-02 09:59
```E, [2020-10-02T19:57:18.530994 #3609] ERROR -- : -- Error reference HmYvXXuZBq -- Exception: RuntimeError: bethtest
/Users/bethanyskurrie/workspace/pact-foundation/pact_broker/lib/pact_broker/api/resources/webhook_execution.rb:29:in `process_post'```
bethskurrie
2020-10-02 10:02
Can you see if you can recreate the issue using this docker compose @robert.strehli? https://github.com/DiUS/pact_broker-docker/blob/master/docker-compose.yml
bethskurrie
2020-10-02 10:08
There was a fix to a line in the logging here https://github.com/pact-foundation/pact_broker/commit/80a895bf
bethskurrie
2020-10-02 10:10
If you can recreate it with that docker-compose, please raise an issue in the pact-foundation/pact_broker repo.
bethskurrie
2020-10-02 10:11
Here's some other info on troubleshooting https://github.com/pact-foundation/pact-broker-docker/wiki/Troubleshooting
robert.strehli
2020-10-02 10:38
Hmm I have a problem with this docker compose file.
``` - ./ssl/nginx.conf:/etc/nginx/conf.d/default.conf:ro```
There is a problem with mounting the volumes. Should the goal not be a directory?
bethskurrie
2020-10-02 20:12
That's strange @robert.strehli. I can see `process_linux.go`. Are you running it on linux? Maybe there's a difference between docker-compose on linux and docker-compose on mac (which is what I'm on).
bethskurrie
2020-10-02 20:15
It is mounting a file to a file. `./ssl/nginx.conf:/etc/nginx/conf.d/default.conf` is the mapping, and `:ro` is the mode.
bethskurrie
2020-10-02 20:16
What version of docker-compose are you running? I'm on `docker-compose version 1.27.2, build 18f557f9`
mateusz.derks
2020-10-03 08:28
Hey, I'm still wrapping my head around webhooks and verification. If we verify pact on the contract change, how do we rerun verificatiom when the contract is not changed, but a new version of provider is released?
Example: I have a pre-production version of consumer that changes a contract. I publish the pact file, the broker detects a contract change and we run verification. Everything is green. Before this change lands on production a new version of provider is shipped. Now there is no verification between the pre-production pact file and the new provider. `can-i-deploy` says the verification is missing and we cant deploy the change.
Is the any way to automate re-verification?
matt.fellows
2020-10-03 08:35
One option would be to also use the WIP pacts feature on the provider side, so that the new contracts are automatically validated (but won't fail the provider if they're not compatible)
bethskurrie
2020-10-04 22:07
@mateusz.derks are you running the verifications in the provider build as well?
bethskurrie
2020-10-04 22:08
The verifications run both when the contract changes, and *every time there is a provider build.*
robert.strehli
2020-10-05 08:15
Yes, I'm running it on a linux machine and I have a much older docker-compose version `1.23.2` . Hmm I assumed that only mounting to a directory is possible, but yeah the docs say otherwise. I'll update everything :slightly_smiling_face: and check if the problem still exists.
bethskurrie
2020-10-07 02:34
Moving thread from @phil.endsley regarding code changes to remove selectors for feature branches here.
bethskurrie
2020-10-07 02:35
Are you asking because you're not currently using WIP pacts, and you're interested, or because you are using WIP pacts and it's not behaving in a way that works for you?
bethskurrie
2020-10-07 02:35
Here are the docs https://docs.pact.io/wip (they need a bit more detail, but I'm waiting to see how this recent change goes first).
phil.endsley
2020-10-07 02:37
We're using wip pacts, but it's not working in the most ideal way :slightly_smiling_face: I'll outline what we're doing
phil.endsley
2020-10-07 02:41
1. Create feature branch in consumer. Publish pact
2. Create feature branch in provider. Add a consumer version selector that "points" to the new pact
3. Once verified, make a code change to remove the new selector and merge the provider
4. Merge the consumer
Ideally, we don't want to make an additional commit to remove the consumer version selector
The reason we have to have the consumer version selector, is because we typically have multiple revisions to the provider. So, if the provider verifies the consumer on the first commit, it's no longer WIP and won't be verified with subsequent revisions, unless there's a consumer version selector for the consumer feature branch
phil.endsley
2020-10-07 02:42
I know there have been a few others that have asked about this scenario as well
phil.endsley
2020-10-07 02:43
I'll read through it again in the morning to verify. But my gut feeling from reading through the other thread was that this would fix it
bethskurrie
2020-10-07 02:43
actually, this is not quite your scenario, because you're not using matching feature branches
bethskurrie
2020-10-07 02:44
I think this is it though https://github.com/pact-foundation/pact_broker/blob/2a11c32096/spec/features/wip_pacts_spec.rb#L204
phil.endsley
2020-10-07 02:45
Right. That was our original desire. Now we can set them once and not touch them
bethskurrie
2020-10-07 02:46
damn it's been hard to make this behave intuitively! I wasn't sure at the outset if it was going to even be possible, and i'm still not 100% sure!
phil.endsley
2020-10-07 02:46
@bethskurrie :taco::taco: and many more. Seriously amazing work you put into this
bethskurrie
2020-10-07 02:46
I'm not going to officially release this until I've had feedback from Robbert, but I can put out an edge version of the docker image if you want to try it out yourself.
bethskurrie
2020-10-07 02:48
an interesting side effect of keeping a pact WIP for longer is that it is actually WIP but no longer pending any more.
bethskurrie
2020-10-07 02:48
This means a WIP pact could fail the build, if you verified it successfully and then had a regression.
bethskurrie
2020-10-07 02:49
Question - do we want this, or should I change the definition of "pending" to match the new WIP definition?
phil.endsley
2020-10-07 02:49
haha idk...I feel like I have to explain both definitions to my org every other day as is :smile:
phil.endsley
2020-10-07 02:50
The terminology doesn't trip me up. The behavior is what I would expect. If I've verified a pact, I want it to fail subsequent builds if verification fails
phil.endsley
2020-10-07 02:51
yes. In my mind, if a pact is verified, any failure after that should fail the provider build
bethskurrie
2020-10-07 02:53
I was thinking of describing the transition of "pending" to "not pending" like a ratchet. It can only go one way. Do you think that's a helpful simile or not?
phil.endsley
2020-10-07 03:18
I'm not 100% sure if this will be ideal now :confused:
When implementing changes on the provider, I think we'll still have to add a selector for the feature branch...if we don't, we'll have all wip pacts running locally, and the tests won't fail (since they're all pending).
If we don't have pending enabled, we'll fail for parallel feature branches that we truly don't want
If we do have it, it's hard to iterate on the tests until we see them pass
Then after that, we need to remember to revert the selector before committing and pushing, otherwise it will be explicitly selected, and no longer wip :thinking_face:
phil.endsley
2020-10-07 03:20
I think I'll just have to mess around with it once it's out to know for sure. But my concern would be introducing something devs have to remember for this to work
bethskurrie
2020-10-07 03:25
So, I have my provider code configured so that it looks for the PACT_URL env var. If it finds it, then it just verifies that pact. if it doesn't, it assumes it's a normal verification run, and verifies the standard selectors.
phil.endsley
2020-10-07 03:25
So, do you set the url in the code, or through an env var locally? If in the code, do you just revert it before committig/merging
bethskurrie
2020-10-07 03:27
you should just be able to verify one interaction as well. in ruby/js etc you use an env var to set the interaction ID, but again, I don't know how to java.
phil.endsley
2020-10-07 03:28
I'm also a little hesitant to jump on board with that approach when I'm trying to convince our whole company to do it. I just know the more complicated things are to do something, the less likely people will want to do it
bethskurrie
2020-10-07 03:29
I think in your situation, I would have my `enableWipPacts` date only set for your main branch.
phil.endsley
2020-10-07 03:31
Yeah... unfortunately, that won't work. Company policies and existing workflows
phil.endsley
2020-10-07 03:32
Regex matching was my first proposal around this. Wrote an item up in canny
phil.endsley
2020-10-07 03:34
The good news is devs see the value and adoption rate is super high. Enough value that they're all willingly putting up with the tedious extra commit. Pact has already caught many bugs between our teams. Would've been caught by qa, but it's saved us on all the churn/back and forth
phil.endsley
2020-10-07 03:37
Quote, yes. Would have to clear it with company before attaching their name to it, but I can ask
bethskurrie
2020-10-07 03:39
We have some quotes on the pactflow website here, and we're suckers for more!
phil.endsley
2020-10-07 03:48
I'm fine with MY name attached to it. Just have to cover myself before attaching my org to it :sweat_smile:
antonello
2020-10-07 06:21
I haven?t read everything, but... what CI system do you use @phil.endsley ?
antonello
2020-10-07 11:47
does that allow you to parameterise you pipelines? I was wondering if you could specify the consumer tags on demand, when necessary (including the corresponding feature tag)
phil.endsley
2020-10-07 12:38
We can, but we don't know what the feature tag is up front. We would have to edit the config for the plan to run it, or kick it off manually, right?
antonello
2020-10-07 12:40
we tend to use the convention of using the same branch name for consumer and provider if we need to do cross-branch testing.
phil.endsley
2020-10-07 12:43
That sounds like what would work best for us. Our issue is we have to reference our ticket number in the branch name so a bunch of other integrations work.
So, we'll have feature/PROJ-1-some-new-feature (consumer) and feature/PROJ-2-some-new-feature (provider). If it's possible to add pattern matching for tags, we could just ignore the prefix and match on the suffix
antonello
2020-10-07 12:43
I wonder if you could somehow keep a mapping of consumer tag and provider tag outside of the provider repo
antonello
2020-10-07 12:46
which could be made accessibile to the provider pipelines via a script (in Jenkins it would be a share library, for example)
mateusz.derks
2020-10-08 07:50
Hi @bethskurrie
yes, we run the verification in the pact provider build.
So far we do a verification using a manual list of consumer for the provider
```Pact.service_provider(provider) do
honours_pact_with(consumer) do
...
end
end```
From what I understand to use WIP pacts verification I need to switch to
```Pact.service_provider(provider) do
honours_pact_with_broker do
..
end
end```
is that right?
mateusz.derks
2020-10-08 07:56
The verification run when our provider is built used to point to the production tag of the consumer, that?s why our main, unreleased branch of the consumer was never verified agains the newly released provider.
mateusz.derks
2020-10-08 08:26
I find this discussion very relevant to what we try to achieve
https://pact-foundation.slack.com/archives/C5F4KFKR8/p1601808591170800
bethskurrie
2020-10-08 22:20
@mateusz.derks the docs are here https://docs.pact.io/implementation_guides/ruby/verifying_pacts#enabling-wip-pacts
bethskurrie
2020-10-08 22:20
You should be verifying the latest one from your main line of development as well as the master one.
bethskurrie
2020-10-08 22:21
Funnily enough, I just wrote this the other day https://docs.pact.io/provider/recommended_configuration
mateusz.derks
2020-10-09 04:57
Amazing, thats exactly what I need, not sure how did I miss it, thanks @bethskurrie
bethskurrie
2020-10-09 05:43
@mateusz.derks if you worked through this, you'd get to the same result https://docs.pact.io/pact_nirvana
robert.strehli
2020-10-09 11:07
Hey, yes and no. I updated docker-compose to `1.27.4` but I still got the problem with the volumes. Unfortunately I hadn't the time to investigate this problem further. Maybe next week.
ranjanayush03
2020-10-09 11:32
Hello everyone I was trying to run the pact-broker-cli docker image but was unable to do that I tried using the Ruby standalone one it worked for me but it would be really helpful if there is any example on running the same via docker image I tried. ''' docker run --rm pactfoundation/pact-cli broker publish''' command but it didn't work for me..
matt.fellows
2020-10-09 11:33
can you please post exactly the command you ran (with confidential details redacted) so we can help?
ranjanayush03
2020-10-09 11:36
docker run --rm pactfoundation/pact-cli broker publish PACTFILES -a 1.21.0 -b http://localhost:9292
matt.fellows
2020-10-09 11:40
(also, are you sure you can reach `localhost` from within the docker container? I?m doubtful)
ranjanayush03
2020-10-09 11:46
Yes while running the standalone code I am able to access the localhost
matt.fellows
2020-10-09 11:50
TL;DR - localhost from within a docker container is not the localhost that the Ruby standalone is talking to. I can?t teach you docker here I?m afraid, but if you?re on a mac you can reach the Docker host (probably the `localhost` where the broker is running) via `docker.for.mac.localhost`
see https://dev.to/noelworden/accessing-localhost-within-a-docker-image-4i3m
matt.fellows
2020-10-09 11:52
but, before you do that, you mentioned it can?t execute a binary? that needs to be fixed first
ranjanayush03
2020-10-09 11:55
'''
Errno::ENOENT: No such file or directory @ rb_sysopen - /Users/Shared/workspace/contract-testing-service/build/pacts
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_file.rb:32:in `read'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_file.rb:32:in `read'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_file.rb:28:in `pact_hash'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_file.rb:16:in `pact_name'
/usr/lib/ruby/gems/2.5.0/gems/rake-13.0.1/lib/rake/file_list.rb:79:in `each'
/usr/lib/ruby/gems/2.5.0/gems/rake-13.0.1/lib/rake/file_list.rb:79:in `group_by'
/usr/lib/ruby/gems/2.5.0/gems/rake-13.0.1/lib/rake/file_list.rb:79:in `group_by'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/publish_pacts.rb:41:in `publish_pacts'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/publish_pacts.rb:27:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/publish_pacts.rb:13:in `call'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/cli/broker.rb:213:in `publish_pacts'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/cli/broker.rb:59:in `publish'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
/usr/lib/ruby/gems/2.5.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/cli/custom_thor.rb:15:in `start'
/pact/lib/pact/cli.rb:40:in `broker'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
/usr/lib/ruby/gems/2.5.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
/pact/bin/pact:15:in `<top (required)>'
'''
matt.fellows
2020-10-09 11:57
that error is pretty clear - the docker container in which you?re running the command can?t find that file.
matt.fellows
2020-10-09 11:57
you can follow the example here: https://github.com/pact-foundation/pact-ruby-cli#publish-pacts
joel.whalen
2020-10-09 17:57
@bethskurrie stumbling upon this issue myself just now - I see there are examples on how to construct the `verificationOptions` object, but how do I pass these options to the pact-cli with the `--consumer-version-selector` option?
bethskurrie
2020-10-12 00:02
@joel.whalen if you're talking about the verificationOptions examples you've seen in javascript, you'll find a CLI option for each of the keys.
bethskurrie
2020-10-12 00:03
Here are the docs https://github.com/pact-foundation/pact-provider-verifier#usage
ranjanayush03
2020-10-12 10:58
Hello all.. actually I am trying to fetch pact from a URL via @PactUrl notation but I guess the API which I am calling needs some authorization so I was unable to find a way so as to include the headers ..
Any help will be much appreciated..
krisdinesh
2020-10-13 00:50
Hello - I am trying to run a pact foundation broker image with a standalone postgres but it says no adapter found. not sure what is the issue
krisdinesh
2020-10-13 00:52
sorry it was exposed with connection string. Hence updated with another screenshot
bethskurrie
2020-10-13 00:53
Looks like you have the PACT_BROKER_DATABASE_ADAPTER env var set incorrectly
matt.fellows
2020-10-13 00:53
I think it should be something more like ?postgres? or ?mysql? (off the top of my head)
krisdinesh
2020-10-13 00:56
@bethskurrie /@matt.fellows - Is there any sample repo that i can refer Kubernetes pack broker setup?
bethskurrie
2020-10-13 00:57
Not an official one, but if you google you might find one someone else made
bethskurrie
2020-10-13 00:57
Please make sure to read this: https://deploy-preview-39--docs-pact-io.netlify.app/pact_broker/docker_images/pactfoundation#running-on-kubernetes
bethskurrie
2020-10-13 01:02
the docs say : "`PACT_BROKER_DATABASE_POOL_TIMEOUT` - optional, 5 seconds by default. The number of seconds to wait if a connection cannot be acquired before raising an error."
bethskurrie
2020-10-13 01:03
If you need to set that and you don't have any data in your database yet, you have other issues.
krisdinesh
2020-10-13 01:05
Sorry...starting a new thread here
Its new database nad doesnt have any data in it
bethskurrie
2020-10-13 01:05
Is there someone in your organisation with dev ops/database experience who can help you get set up?
bethskurrie
2020-10-13 01:06
We can't offer you step by step assistance deploying a free open source application.
krisdinesh
2020-10-13 01:06
ok...i am trying to resolve with our network team....I will see after that...thanks anyways for the prompt response
bethskurrie
2020-10-13 01:07
The instructions that are there should be sufficient for someone who is experienced with dev ops. But let us know if you get very stuck. Otherwise, you can get a free pactflow account instantly here https://pactflow.io
krisdinesh
2020-10-13 01:08
I am also inclined towards pact flow, but my client is on-premise :disappointed:
bethskurrie
2020-10-13 01:08
We do have an on-premise offering, which we can provide more support around.
krisdinesh
2020-10-13 01:11
Right now we are doing POC so setting up in local...but for on-premise, is there any pricing model available to view?
sagupta
2020-10-13 14:39
Hi Folks,
Just wanted to check is there a way to check when the webhook was triggered . I recently setup a webhook to trigger provider build when contract content changed but it triggered the provider build even when the pact was same as before and now i dont know how to debug this or fix it.
francisco.moreno
2020-10-13 15:52
Hello,
There is some way to create two webhooks for one pact.
I mean, I have two jenkins builds and I want one to be launched when the contracts change and another one when the provider publishes the results.
Is it possible?
antonello
2020-10-13 16:03
Hola Francisco, definitely.
https://docs.pact.io/pact_broker/webhooks/#pact-broker
bethskurrie
2020-10-13 23:45
@sagupta it will probably be because a new tag was applied to existing content
bethskurrie
2020-10-13 23:46
> If the relevant consumer version has any tags, then for each tag, check if the content is different from the previous latest version for that tag. It is 'changed' if any of the checks are true. One side effect of this is that brand new tags will trigger a pact changed event, even if the content is the same as a previous version.
bethskurrie
2020-10-13 23:47
If you're using an OSS broker, you can look in the logs to see exactly why the webhook got triggered. Search by the consumer version number to find the logs for the publication, and soon after that you'll see logs about the webhook.
bethskurrie
2020-10-13 23:57
Also, there is a page with info on debugging webhooks in the docs here: https://docs.pact.io/pact_broker/webhooks/debugging_webhooks
saurabhapd
2020-10-14 06:18
Hi Guys, I have ran into an issue regarding contract upload to pact broker. So I have written around 10 fragments for a consumer provider interaction. All 10 belong to a single consumer. After generating the contract file it came up to around 114KB. Now when I am trying to do pact:publish to pact broker (with basic auth), its failing. I checked console log of broker and its the following (masked couple of details by xxxx). Now when I tried to do the same PUT request manually by postman, it worked from the same system/network. Can anyone help me why its happening?? Another thing to note: if I break the 114KB contract into smaller files with 10-20 KB each for each fragment, it works absolutely fine. Any help would be really appreciated. Thanks
sagupta
2020-10-14 11:21
One question but not related to the one in this thread:
I am trying to setup the consumer pipeline as mentioned in https://docs.pact.io/pact_nirvana/step_4 . However i was wondering once consumer publishes pact to broker and then webhook is triggered , should we go to next job i.e. `can-i-deploy` ? I mean how to wait for the results from the provider build triggered from webhook?
mamtha.3687
2020-10-14 11:23
Anyone tried posting pact verification results to any other REST service without broker?
saurabhapd
2020-10-14 11:29
Yes. Its a self hosted broker in AWS. In client I am not doing anything out of the ordinary. Just using pact:publish plugin. Not sure where its going wrong
dorin.enache
2020-10-14 13:49
Hi :slightly_smiling_face:. I have a problem trying when publishing: [ERROR] Failed to execute goal au.com.dius.pact.provider:maven:4.1.0:publish (default-cli) on project transaction-api: Execution default-cli of goal au.com.dius.pact.provider:maven:4.1.0:publish failed: Plugin http://au.com.dius.pact.provi
der:maven:4.1.0 or one of its dependencies could not be resolved: The following artifacts could not be resolved: io.github.microutils.kotlin-logging:kotlin-logging:jar:1.6.26, io.github.microutils.kotlin-logging:kotlin-logging-commo
n:jar:1.6.26, io.github.microutils.kotlin-logging:kotlin-logging-js:jar:1.6.26: Failure to find io.github.microutils.kotlin-logging:kotlin-logging:jar:1.6.26 in https://repo.maven.apache.org/maven2 was cached in the local repository
, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
dorin.enache
2020-10-14 13:50
it seems that maven is unable to find this artifact(io.github.microutils.kotlin-logging:kotlin-logging-js:jar:1.6.26) in central repo. Do you have any idea from where to pick this?
phil.endsley
2020-10-14 14:00
Probably better to ask in #pact-jvm since this is specific to the maven plugin
saurabhapd
2020-10-14 15:09
Update: I finally used pact-broker-client binary to upload and its working now.
mamtha.3687
2020-10-14 17:56
Well, we have certain limitations to run the pact broker in the org so trying to post the results to the db through another service. Just trying to get my head around posting the verification results back for specific interactions.
joel.whalen
2020-10-14 19:36
@bethskurrie Thanks for the docs link! I see the example in the `help` for `--consumer-version-selector` is using a single tag,
```{\"tag\":\"master\", \"latest\": true}```
how do I get it to work for a list of tags? Here?s what I?m doing in Python:
```def pact_consumer_tags():
consumer_version_selectors = [
{
"tag": "master",
"latest": True
},
{
"tag": "prod",
"latest": True
},
{
"tag": "dev",
"latest": True
},
{
"tag": "qa",
"latest": True
},
{
"tag": "stg",
"latest": True
}
]
consumer_version_selectors = json.dumps(consumer_version_selectors)
return consumer_version_selectors```
The stringified JSON that gets passed to `--consumer-version-selector` looks like this:
```[{"tag": "master", "latest": true}, {"tag": "prod", "latest": true}, {"tag": "dev", "latest": true}, {"tag": "qa", "latest": true}, {"tag": "stg", "latest": true}]```
which is producing this error
joel.whalen
2020-10-14 19:36
```[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] bundler: failed to load command: /pact/bin/pact (/pact/bin/pact)
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] TypeError: no implicit conversion of Symbol into Integer
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker/pact_selection_description.rb:9:in `block in pact_selection_description'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker/pact_selection_description.rb:8:in `collect'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker/pact_selection_description.rb:8:in `pact_selection_description'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:92:in `log_message'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:39:in `call'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:34:in `call'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-1.55.5/lib/pact/pact_broker.rb:18:in `fetch_pact_uris_for_verification'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:45:in `pacts_for_verification'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:38:in `pacts_urls_from_broker'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:25:in `call'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:10:in `call'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:199:in `all_pact_urls'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:40:in `call'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:34:in `call'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/cli/verify.rb:47:in `verify'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /pact/lib/pact/cli.rb:53:in `verify'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /usr/lib/ruby/gems/2.7.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
[pod/cart-service-verify-6a00e1cd-nhvtp/cart-service-verify] /pact/bin/pact:15:in `<top (required)>'```
joel.whalen
2020-10-14 19:36
Is this due to `json.dumps` failing to escape the quotations with `\`, or that I?m using a JSON list with `[]`? Or maybe both?
matt.fellows
2020-10-14 20:38
It sounds like you're going to try and build the can I deploy logic yourself?
sklein
2020-10-14 21:23
```def _get_consumer_version_selectors(self, settings):
return [
json.dumps({"tag": tag.strip(), "latest": True })
for tag in settings.PACT_CONSUMER_VERSION_TAGS.split(",")
]```
sklein
2020-10-14 21:24
you are serializing the array when you want to serialize each tag in the array and pass the array of serialized selectors
joel.whalen
2020-10-14 23:17
I will give this a try tomorrow, that looks like it will work thanks so much
mamtha.3687
2020-10-15 02:51
Nope, we use SQL server or Oracle database but broker doesn't support either. There's no provision to run it as a docker container in cloud (it's disabled for us). Moving the source code was also challenging because we lack Ruby expertise.
bethskurrie
2020-10-15 03:58
```--consumer-version-selector "{...}" --consumer-version-selector "{...}"```
bethskurrie
2020-10-15 03:59
@joel.whalen you need to specify one `--consumer-version-selector "{...}"` for each selector.
matt.fellows
2020-10-15 08:00
Have you considered http://pactflow.io? Or is that off the cards because it?s a SaaS?
joel.whalen
2020-10-15 13:46
ah I see that throws a wrench in my automation script, but nothing I can?t get around. Thanks for clarifying
joel.whalen
2020-10-15 14:46
Hey it worked! Thanks all :slightly_smiling_face:
``` DEBUG: The pact at <my-pact-broker-url> is being verified because it matches the following configured selection criteria: latest pact for a consumer version tagged 'dev', latest pact for a consumer version tagged 'master', latest pact for a consumer version tagged 'prod', latest pact for a consumer version tagged 'qa', latest pact for a consumer version tagged 'stg' (all have the same content)```
mamtha.3687
2020-10-15 17:35
Well yea, sort of. And SaaS is also not an option right now. Any pointers at all to implement something on our own?
bethskurrie
2020-10-15 22:54
And look at that - you're only running one verification, not 5, like you would have with the old approach.
bethskurrie
2020-10-15 22:56
I can show you the SQL, and it's complicated, and you need to add a bunch of logic on top of it to interpret the results.
matt.fellows
2020-10-15 23:21
@mamtha.3687 you?re on a path to re-building the pact broker. That effort would be better spent:
1. Working to convince people internally that running a postgres docker image is not so bad - and better yet, you won?t be giving more licensing dollars to Oracle!
2. Creating an Oracle DB adapter (I wouldn?t recommend it obviously, but maybe it?s doable :man-shrugging: )
matt.fellows
2020-10-15 23:22
Don?t forget that Pact and the Broker are constantly evolving, so any customisation you make you?ll need to continue to maintain
mamtha.3687
2020-10-16 01:08
@bethskurrie we are currently posting the pacts to another service that saves it in the database. For retrieval, we are trying to specify custom pact source and make a rest call in the custom class (still couldn't get it working).
mamtha.3687
2020-10-16 01:09
@bethskurrie the sql design can help a bit. I do get the intensity of the effort that will be needed here but there are a lot of customisations that we need over a period of time and this seemed like the only option we have.
mamtha.3687
2020-10-16 01:12
@matt.fellows it's just that the postgres or mysql database isn't having specific dbas to monitor and they're not ready to leave it unmonitored. I do get that concern about evolving pact and broker. But for now, the only focus is to get the basic verification happening at the bare minimum.
bethskurrie
2020-10-16 01:24
@mamtha.3687 There are workflows that you could use potentially use that don't rely on the broker/can-i-deploy as much.
bethskurrie
2020-10-16 01:25
The main reason that Oracle can't be supported is that some of the table names were too long, and I can't go back and change that without breaking the entire application for everybody.
bethskurrie
2020-10-16 01:25
It may be that more recent versions of the oracle db support longer names now?
bethskurrie
2020-10-16 01:27
So, if I was trying to build a contract workflow without a broker, I woulnd't try and re-write the broker or emulate that workflow. That's got 7 years of design and work in it.
bethskurrie
2020-10-16 01:27
I'd do something like this on the consumer side https://docs.pact.io/pact_nirvana/step_4#alternative-webhookless-workflow
bethskurrie
2020-10-16 01:28
On the provider side, if you deploy as soon as possible after verification, then you have confidence that your verification results are still accurate for that environment.
bethskurrie
2020-10-16 01:29
> The need for this check increases proportionately with the time that elapses between your pact test execution and your release. If you practice continuous deployment, and you go straight from a test build into a production deployment build, then you can be pretty sure that the version of the other application that is in production probably hasn?t changed in the meantime. If there is a considerable amount of time, however, it is best to do a compatibility check again just before deploying.
> For example, if you run a pact verification on Monday that verifies the recommended "master" and "production" pacts, but you don?t deploy the provider artifact until Friday, the version of the consumer that is now in production may have changed.
> Alternatively, a pact may have been verified by the ?master? version of the provider, but that version of the provider may not yet have been deployed to production. The consumer cannot be deployed to production until the version of the provider that it depends on is in production (unless it has been specifically written to fail gracefully, which is actually the best approach, but is one that isn?t always followed).
guppy0356.nakira
2020-10-23 07:03
I try to add webhook on local pact broker server.
```curl -X POST http://192.168.10.10/webhook -H "Accept: application/json" -H "Content-Type: application/json" -d@body.json```
body.json is like this.
```{
"provider": {
"name": "Animal Service"
},
"events": [{
"name": "contract_content_changed"
}],
"request": {
"method": "POST",
"url": "http://master.ci.my.domain:8085/rest/api/latest/queue/SOME-PROJECT?os_authType=basic",
"headers": {
"Accept": "application/json"
}
}
}```
I have checked at `/webhook` but there is no new records. Why?
antonello
2020-10-23 07:19
Hi @guppy0356.nakira. Welcome to the Pact community! What response to you get from the broker when you make the call to create the webhook?
guppy0356.nakira
2020-10-23 07:24
Hi @antonello. I have got with `-v` option.
```Trying 192.168.10.10...
TCP_NODELAY set
Connected to 192.168.10.10 port 80
POST /webhook HTTP/1.1
Host: 192.168.10.10
User-Agent: curl/7.58.0
Accept: application/json
Content-Type: application/json
Content-Length: 357
* upload complete sent off: 357 out of 357 bytes
HTTP/1.1 406 Not Acceptable
Server: nginx/1.19.3
Date: Fri. 23 Oct 2020 07:20:10 GMT
Content-Length: 0
Connection: keep-alive
Vary: Accept
X-Pact-Broker-Version: 2.67.0
X-Content-Type-Options: nosniff```
antonello
2020-10-23 07:26
You should be getting a 2xx response (201 I think), so your issue in the request somehow
antonello
2020-10-23 07:34
Btw, not sure if you know it, but you could use the pact broker client to create web hooks
bethskurrie
2020-10-23 07:58
@guppy0356.nakira it's probably because the API returns `application/hal+json`
joaquin
2020-10-25 18:48
Hey! I'm setting up the CI with pact-cli and i came across this "problem" in the *verify* step. Since there are no consumer versión with the given tag the verify step does nothing and exists normally, but i would expect for it to exit with an invalid status so i can stop the CI job.
*command:*
`docker run --rm --net host -e PACT_BROKER_BASE_URL=http://localhost:9292 -e PACT_BROKER_USERNAME=readwrite -e PACT_BROKER_PASSWORD=readwrite -e PACT_BROKER_PUBLISH_VERIFICATION_RESULTS=true pactfoundation/pact-cli:0.17.2.0 verify --provider ms-provider-name --provider-base-url http://localhost:8080 --provider-app-version v0.1.3-202010251400 --provider-version-tag dev --consumer-version-tag dev --enable-pending --wait 10`
*output:*
> INFO: Polling for up to 10 seconds for provider to become available at localhost:8080...
> INFO: Provider available, proceeding with verifications
> INFO: Fetching pacts for ms-provider-name from http://localhost:9292 for tags: latest desa
*exit status:*
0 (zero)
Does anyone know if this is an expected behavior?
bethskurrie
2020-10-25 23:12
I've just had someone asking for the opposite thing to happen in another tool :laughing:
bethskurrie
2020-10-25 23:13
You can raise a feature request to make it configurable to raise an error if there are no pacts in http://pact.canny.io
joaquin
2020-10-25 23:38
If i understand things correctly, this behavior would mean that a provider build would just run until the first consumer publishes some pacts, right? which if you are coming from provider-first workflow (like myself) i guess is not so bad
bethskurrie
2020-10-25 23:39
Yes, it would just pass fine until it got the first contract. I think JVM is the other way around, and it fails if there are no contracts unless you configure it not to.
joaquin
2020-10-25 23:46
I bet :smile: . I'll see to that feature request, and who knows maybe i'll send the PR my self...
ercalbwar
2020-10-26 20:23
Hi everyone!
I have a couple of questions about Pact Broker and I was hoping you could help me out :slightly_smiling_face:
*Question 1*
I am currently debugging some issues with my Webhooks (following https://docs.pact.io/pact_broker/webhooks/debugging_webhooks) and I was wondering if there is a way to delete webhooks through the pact broker website.
I also found a row on the database that I could delete but, since I am pretty new with Pact, I didn't break things even more than they are now.
*Question 2*
~I'm trying to use the *broker create-or-update-webhook* command but it keeps complaining if I try to use two body parameters (for example: -d token=bla -d branch=main).~
~Is there a way to use multiple form parameters with this command or is it not supported?~
I had to use & to append both parameters. -d "token=something&branch=something"
Cheers
bethskurrie
2020-10-26 20:42
@ercalbwar there is no UI for webhooks in the OSS Pact Broker. To delete a webhook, you send a DELETE request to it's URL.
bethskurrie
2020-10-26 20:42
There is a UI for managing webhooks in http://pactflow.io (a commercial offering of the Pact Broker)
bethskurrie
2020-10-26 21:28
Here are instructions for opening the webhook resource in the HAL browser https://docs.pact.io/pact_broker/webhooks/debugging_webhooks#pact-broker
bethskurrie
2020-10-26 21:28
Click on the `NON-GET` button for the `self` relation, change the request method to `DELETE` and then click `Make Request`
bethskurrie
2020-10-27 07:57
Hey broker users. The OSS docker image comes with a read only user and a read/write user. The intent is that CI gets the read/write user and the devs/testers get the read only user. Once the "testing it out" evaluation/spike period is over, who uses it as described, and who allows the devs/testers access to the write credentials?
ercalbwar
2020-10-27 10:38
My first observation (still in the "testing it out" phase though) is that it would be great to scope write access to specific pacts that a given (consumer?) team owns.
ercalbwar
2020-10-27 13:20
Hi again and _*apologies for my spam over the last couple of days*_ :pray:, going through the "spike" phase right now and uncovering some issues as I go.
> *This question is about the webhook integration with Jenkins.*
ercalbwar
2020-10-27 13:20
The first thing that I wanted to call out is that I was surprised to find that there are no instructions for Jenkins in the https://docs.pact.io/pact_broker/webhooks/template_library, maybe this is an opportunity for me to send my first PR once I get it to work :)
In Jenkins, you can trigger builds remotely via what they call the https://www.jenkins.io/doc/book/using/remote-access-api/. TL;DR, you just need to send a curl command.
According to the https://github.com/pact-foundation/pact_broker-client/#create-webhook, this integration should be as simple as preparing the curl command and adding a couple of things. Unfortunately, that didn't work for me.
Here is an example of the curl command that successfully triggers the job when I run it from my laptop (I have omitted those parts that are a bit sensitive):
`curl -vX POST "https://user:<secret>@dockerjenkins.riotgames.com/job/<path_to_job>/build" -d token=token`
And here is the command I am using to create the webhook:
`docker run --rm pactfoundation/pact-cli:latest broker create-or-update-webhook https://user:<secret>@dockerjenkins.riotgames.com/job/<path_to_job>/build --uuid=696c5f93-1b7f-44bc-8d03-59440fcaa9a0 -X POST -b <broker_URL> -d token=token --contract-published`
The command finishes successfully but, when I trigger the webhook execution by publishing a new contract, I can see some errors in the broker logs:
`[2020-10-27T11:29:19Z] DEBUG: Webhook context {"base_url":"<broker_url>","consumer_version_tags":["pact-test"],"event_name":"contract_published"}`
`[2020-10-27T11:29:19Z] INFO: HTTP/1.1 POST https://user:<secret>@dockerjenkins.riotgames.com/job/<path_to_job>/build`
`[2020-10-27T11:29:19Z] INFO: accept: */*`
`[2020-10-27T11:29:19Z] INFO: host: http://dockerjenkins.riotgames.com`
`[2020-10-27T11:29:19Z] INFO: content-length: 19`
`[2020-10-27T11:29:19Z] INFO: content-type: application/x-www-form-urlencoded`
`[2020-10-27T11:29:19Z] INFO: token=token`
`[2020-10-27T11:29:19Z] INFO: HTTP/1.1 403 Forbidden`
`[2020-10-27T11:29:19Z] INFO: server: nginx/1.14.0`
`[2020-10-27T11:29:19Z] INFO: date: Tue, 27 Oct 2020 11:29:19 GMT`
`[2020-10-27T11:29:19Z] INFO: content-type: text/html;charset=utf-8`
`[2020-10-27T11:29:19Z] INFO: content-length: 711`
`[2020-10-27T11:29:19Z] INFO: connection: keep-alive`
`[2020-10-27T11:29:19Z] INFO: vary: Accept-Encoding`
`[2020-10-27T11:29:19Z] INFO: x-content-type-options: nosniff`
`[2020-10-27T11:29:19Z] INFO: set-cookie: JSESSIONID.6f8fc1a0=node017z9zybpfza0g1nfrskob4sun65848.node0; Path=/; Secure; HttpOnly`
`[2020-10-27T11:29:19Z] INFO: expires: Thu, 01 Jan 1970 00:00:00 GMT`
`[2020-10-27T11:29:19Z] INFO: x-hudson: 1.395`
`[2020-10-27T11:29:19Z] INFO: x-jenkins: 2.222.3`
`[2020-10-27T11:29:19Z] INFO: x-jenkins-session: 837369b0`
`[2020-10-27T11:29:19Z] INFO: x-hudson-cli-port: 50000`
`[2020-10-27T11:29:19Z] INFO: x-jenkins-cli-port: 50000`
`[2020-10-27T11:29:19Z] INFO: x-jenkins-cli2-port: 50000`
`[2020-10-27T11:29:19Z] INFO: <html><head><meta http-equiv='refresh' content='1;url=/login?from=%2Fjob%2F<path_to_job>%2Fbuild'/><script>window.location.replace('/login?from=%2Fjob%2F<path_to_job>%2Fbuild');</script></head><body style='background-color:white; color:white;'>`
`Authentication required`
`<!--`
`-->`
`</body></html>`
`[2020-10-27T11:29:19Z] INFO: Retrying webhook in 10 seconds`
I have tried multiple combinations of the webhook command creation but I can't get it to work.
Has anyone seen this before or can you spot something that I am missing? My gut-feeling tells me that it has to do with the way form parameters are passed (-d) but that could be a red herring.
Last comment, I found about the https://github.com/pact-foundation/pact-broker-docker#webhook-whitelists yesterday but that didn't help.
Cheers
antonello
2020-10-27 13:35
Are you actually providing valid credentials for the Jenkins request? I can see `user:<secret>` in your logs. Is that just you redacting those to paste it here?
antonello
2020-10-27 13:37
My suggestion would be to test your Jenkins API requests separately before trying to create a broker webhook.
antonello
2020-10-27 14:06
Ignore my second message - I saw that you omitted the sensitive parts, which I imagine included those credentials.
ercalbwar
2020-10-27 14:06
I redacted those prior to pasting them here. They work when used via curl, but they don't work in the webhook
antonello
2020-10-27 14:07
but, in other words, does the following work?
```curl -vX POST "https://user:<secret>@dockerjenkins.riotgames.com/job/<path_to_job>/build" -d token=token```
ercalbwar
2020-10-27 16:16
I believe that's required by Jenkins. You can see some examples here: https://serverfault.com/questions/888176/how-to-trigger-jenkins-job-via-curl-command-remotely
ercalbwar
2020-10-27 16:17
I don't have much context on why it was implemented that way though :confused:
antonello
2020-10-27 16:34
Could you try if this works please?
`curl -vX POST "https://dockerjenkins.riotgames.com/job/<path_to_job>/build" -L --user <username>:<password>`
ercalbwar
2020-10-27 16:58
For some reason, it didn't like when I was embedding the credentials in the URL. Once I moved them to the -u parameter, it all worked (including the webhook)
abubics
2020-10-28 00:54
I definitely use it as intended, although I don't get to spin up new brokers & pipelines so often recently :cry:
tjones
2020-10-28 05:34
Don't worry about asking too many questions - questions are what this channel is for :+1:
simon.nizov
2020-10-28 12:39
Hi all,
? I?m running the latest version of both the broker and `pact-provider-verifier`,
? I?m using both of the flags: `--enable-pending` and `--include-wip-pacts-since="2020-10-27"`
? I have `--consumer-version-selector="{\"tag\": \"dev\", \"latest\": true}"`
? I see the appropriate log:
```INFO: Fetching pacts for Foo from https://.... with the selection criteria: latest for tag dev, work in progress pacts created after 2020-10-27```
But in no point during verification do I see this log for the correct pact version:
```DEBUG: The pact at https://.../pact-version/XXX is being verified because it matches the following configured...```
How can I debug why my newly published and unverified pact isn?t being verified using the new WIP pacts feature?
simon.nizov
2020-10-28 13:17
Removing the `consumer-version-selector` fixed it and now only my new pact version is being verified.
Are `--consumer-version-selector` and `--include-wip-pacts-since` not supposed to work together?
phil.endsley
2020-10-28 13:25
They can (and should imo) be used together. Are you specifying provider tags in your command?
simon.nizov
2020-10-28 14:21
@phil.endsley Nope, here?s my command:
```./pact-provider-verifier \
--provider-base-url=http://localhost:8000/v1 \
--provider-states-setup-url=http://localhost:8000/setup_provider_states/ \
--pact-broker-base-url=... \
--broker-username=... \
--broker-password=... \
--consumer-version-selector="{\"tag\": \"dev\", \"latest\": true}" \
--provider="..." \
--custom-provider-header="Authorization: ..." \
--enable-pending \
--include-wip-pacts-since="2020-10-25"```
phil.endsley
2020-10-28 14:31
Hmm...I don't use `pact-provider-verifier` myself, and I don't see it mentioning what parameters to use in the docs. Maybe try this one?
> [--provider-version-tag=TAG]
> # Tag to apply to the provider application version. May be specified multiple times.
Where TAG would be an existing tag for the provider version you're running verification on.
Pending and WIP pacts are relative to a provider tag (ex: A given pact may be pending for a provider's `develop` tag, but not `feat-x`) and are determined dynamically when the call to Pact Broker is made. In order to determine which ones are actually pending/wip, you must provide that tag to the broker.
I'm not sure how this would work if there's no option to provide that tag
phil.endsley
2020-10-28 14:32
If that param doesn't work, you might just have to wait for @bethskurrie to come online
phil.endsley
2020-10-28 14:35
I think all client implementations have a parameter used to specify this (ex: JVM uses `pactbroker.providerTags` sys property https://docs.pact.io/implementation_guides/jvm/provider/junit/#work-in-progress-wip-pact-support-version-415-and-later), just don't see one mentioned in the readme for `pact-provider-verifier`
simon.nizov
2020-10-28 14:49
That worked! `provider-version-tag` is in the readme: https://github.com/pact-foundation/pact-provider-verifier
phil.endsley
2020-10-28 14:51
Yeah, saw it in the readme, but every reference to it is for tagging when publishing. Maybe just needs an update
matt.fellows
2020-10-28 22:55
> The first thing that I wanted to call out is that I was surprised to find that there are no instructions for Jenkins in the https://docs.pact.io/pact_broker/webhooks/template_library, maybe this is an opportunity for me to send my first PR once I get it to work :)
We know people use Pact with Jenkins, however it tends to get used in Enterprises and for whatever reason, they rarely contribute back. Most of the maintainers haven?t used Jenkins for a long time, hence why we haven?t added it.
@xandebianchi would you be willing to share the actual webhook request configured in your Pact Broker to as a PR to https://github.com/pact-foundation/docs.pact.io/blob/master/website/docs/pact_broker/webhooks/template_library.md ?
bethskurrie
2020-10-29 21:39
@ercalbwar We're in the process of adding team based permissions to Pactflow. These won't be in the OSS Pact Broker though.
bethskurrie
2020-10-29 21:44
You can read about the logic for WIP pacts here. https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/#technical-details
bethskurrie
2020-10-29 21:44
It's quite complicated to make it do what you'd expect intuitively. I'll update it to make it very clear that the provider version tag is required.
matt.fellows
2020-10-29 21:52
:point_up: for the taco givers, I think the taco needs to go _after_ the name, otherwise no cred is transferred
simon.nizov
2020-10-30 13:52
Was there ever any talk about having a statistics page in the broker? :bar_chart:
It can be really useful to be able to show teams a dashboard with aggregated information about their pact usage.
For example - ?Here are all the times we would introduce bugs into production in the last 6 months if it weren?t for pact? or ?Here are the pacts that are pending for providers to implement a change?, etc..
simon.nizov
2020-10-30 15:25
Couldn?t find a similar feature request so I created one: https://pact.canny.io/feature-requests/p/statistics-dashboard
aliaksandr.valadzko
2020-11-03 13:15
Hello guys!
I'm a bit confused about CI pipeline set up
I have a question regarding: `Publish pact -> Webhook -> Publish result -> Can I Deploy` flow, from this image:
aliaksandr.valadzko
2020-11-03 13:24
So, assume I have consumer version `v123`, which generates pact `v123`
There are 2 options here:
1. pact `v123` is the same as pact `v122`
2. pact `v123` is different from pact `v122`
And
in 1 option - no new job run will be triggered (I can rely on previous Provider pact verification results)
in 2 option - webhook will trigger pact verification (I need to wait for new Provider pact verification results be published)
My question is, how can I differentiate these cases it from Consumer CI pipeline?
How can I understand, that new pact verification job was triggered and I need to wait before Provider verification results be published to broker?
Thanks in advance
aliaksandr.valadzko
2020-11-03 13:29
So, assuming Provider CI is black box for me, is there a chance to understand should I wait for new results before `CanIDeploy` step?
antonello
2020-11-03 13:30
Hi @aliaksandr.valadzko a couple of ideas:
? call can-i-deploy on the consumer pipeline, which will tell you whether there was something to verify or not
? Call the diff end-point the the broker offers to see if the pact changed
? Poll the corresponding provider pipeline / job
aliaksandr.valadzko
2020-11-03 14:39
Hey Anto, thanks for responding
If pact was changed, I receive such a message after CanIDeploy:
```There is no verified pact between the latest version of its_consumer (v123) and version 1.0.0.branch.v456 of fr_provider```
These I get on Consumer side
So I need to introduce some kind of script in Consumer job, that will overwrite CanIDeploy task, and if it will get such a message ^, it will wait until triggered by webhook job will publish Pact verification result?
Sounds pretty complicated, isn't it?
Also, how can I poll Pact Broker to understand if new result was published?
aliaksandr.valadzko
2020-11-03 14:51
Also, sound like should be popular question:slightly_smiling_face:
irldev
2020-11-03 17:57
Hello, this might be a silly question but can the pact broker be setup in the cloud, some place like AWS or Azure?
matt.fellows
2020-11-03 21:16
If you can run docker it's the easiest path to running on a cloud environment
bethskurrie
2020-11-04 00:48
So, by the time the pact feature branch is merged into master, it should already be pre-verified, and should pass - no waiting around.
bethskurrie
2020-11-04 00:49
If you want to wait around for the verification results, you can use the `--retry-while-unknown` feature of the `can-i-deploy` tool documented here: https://docs.pact.io/pact_broker/client_cli/readme#can-i-deploy
bethskurrie
2020-11-04 00:55
The sequence of events for adding a new feature could be something like:
? branch consumer
? add/change interaction
? push change to branch
? can-i-deploy fails (correctly)
? build stops
? provider implements change
? <notify consumer of passing pact, either by words or webhook>
? consumer team kicks off branch build again
? can-i-deploy passes
? merge in consumer branch to master
aliaksandr.valadzko
2020-11-04 08:03
Thanks a lot @bethskurrie :pray:
`--retry-while-unknown` sounds like what I looked for!
I totally agree of provided flow ^
However, I assume, there are some situations, when contract changes on Consumer side could possibly be fulfilled without changes in Provider side (for example adding some fields, to contract, that Provider already returns in response)
And to remove manual step of failed Consumer job rerun, we can wait until Provider job (triggered by webhook due to contract change) will end
One follow up question here:
Is this `--retry-while-unknown` feature available only in *CLI*, or it should also work in gradle *PactCanIDeployTask* ?
Thanks again!
ashish_garg5
2020-11-04 09:34
Hi All,
How do i run my provider against all consumer tags present in the pact broker ?
I have consumer with 2 tags in broker and my provider is running against the latest one only and not the both.
How i can make it to run and verify against all tags of consumer.
Thanks in advance.
matt.fellows
2020-11-04 10:38
Of course not, its just a standard stateless style application with a database. Pop it in a load balancing group behind a load balancer and you're up and running
jarmy
2020-11-04 23:22
Hello. I?ve got a question about the usage of this https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks/#event-types
> `contract_content_changed:` triggered when the content of the contract, or tags applied to the contract have changed since the previous publication.
I have set up a webhook that triggers a Jenkins job which runs a provider verification test whenever the consumer generates the above event. The consumer publishes the pact with the following options:
```const gitSha = exec('git rev-parse --short HEAD');
const branch = process.env.BRANCH_NAME || exec('git rev-parse --abbrev-ref HEAD');
const opts = {
pactFilesOrDirs: [path.resolve(process.cwd(), 'contract/pacts')],
pactBroker: 'https://pact-broker.docker.savagebeast.com/',
consumerVersion: gitSha,
tags: [branch],
};```
The provider then uses a https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors/ to verify pacts tagged with the `master` branch. Since the pact can be tagged with multiple branch names, it results in the provider verification job getting triggered _without_ the verification tests always running because of the selectors. This can create a queue of CI jobs, which is something I?d like to avoid. Do we really want to trigger this event when a new tag is created yet the content hasn?t? What?s the preferred strategy for using `contract_content_changed` webhooks with version selectors?
matt.fellows
2020-11-04 23:29
The recommended approach is trigger a build of a provider verification specific job that _only_ looks at the pact URL that was changed
jarmy
2020-11-04 23:41
We want to pass the PACT_URL into the CI job like this then modify the test to conditionally use it?
``` "config": {
"env": {
"global": [
"PACT_URL=${pactbroker.pactUrl}"
]
}
}```
matt.fellows
2020-11-04 23:43
In advanced setups, we trigger a separate provider job that just does the pact verification (sorry this is the better summary URL for that: https://docs.pact.io/pact_nirvana/step_4#e-configure-pact-to-be-verified-when-contract-changes)
jarmy
2020-11-04 23:50
Ok. This makes much more sense. Now, I?ve just got to figure out how to implement this in our existing J20 infrastructure..
matt.fellows
2020-11-04 23:51
Alternatively, if you can have a toggle on your normal build to ?skip steps? if that env var is present, that would work too
ashish_garg5
2020-11-05 05:04
i am able to do this by using
@PactBroker(host="pactbroker", port = "80", tags = {"latest", "dev", "prod"})
ashish_garg5
2020-11-05 05:05
so in this tags now i have defined all the tags against which my provider will run
bethskurrie
2020-11-05 05:14
You could raise a feature request or a PR if you're interested in using in the the maven task
bethskurrie
2020-11-05 05:14
Ron's pretty busy at the moment, so if you're keen on it, you could submit a PR.
jun.li
2020-11-09 23:19
HI, I got this problem
```The name "aaaaaaaaa bbbb Provider" is very similar to the following existing consumers/providers:
* aaaaaaaaa ccc Provider
If you meant to specify one of the above names, please correct the pact configuration, and re-publish the pact.
If the pact is intended to be for a new consumer or provider, please manually create "Required Action Condition API Event Provider" using the following command, and then re-publish the pact:```
Is there any configuration I can do to avoid manually publish?
bethskurrie
2020-11-09 23:22
I dont' recommend turning off the duplicate checking. It seems like you're just doing a spike though, and the best way to get around it would be to create the pacticipant manually.
bethskurrie
2020-11-09 23:22
If you turn off the duplicate checking you're likely to end up with corrupted data.
bethskurrie
2020-11-09 23:23
Also, it's best not to put the word "provider" in there if you can avoid it. Provider is a role an app takes, not an identitiy in itself. Who knows if that provider will one day consume another service and become a consumer as well?
mateusz.derks
2020-11-10 15:01
Hey, is there any prerequisites for this feature to be effective?
https://github.com/pact-foundation/pact_broker/blob/master/CHANGELOG.md#v2670-2020-10-16
> if a pact was successfully verified because it was included as a WIP pact, keep it as WIP
I run pact-broker 2.67.0 and my consumer branches are considered WIP only until the verification pass.
I?m querying
`/pacts/provider/PROVIDER/for-verification`
with
``` {
"consumerVersionSelectors": [{"consumer": "CONSUMER", "tag": "production", "latest": true}],
"includeWipPactsSince": "2020-11-09",
"includePendingStatus": true,
"providerVersionTags": ["master"]
}```
mateusz.derks
2020-11-10 15:23
We have `production` and `master` tags for the consumer. We have `production` and `master` for the provider.
We have 2 branches with a new feature: `feat-1` provider and `feat-1` consumer.
Before the provider `feat-1` is merged, `feat-1` is returned as WIP. The `master` provider verification of pact related to `feat-1` is red.
When the provider `feat-1` is merged, the `feat-1` consumer contract is satisfied and such branch is no longer WIP for the next provider runs.
yann.courtel
2020-11-11 08:57
I echoed Beth for the duplicate. I had a similar issue but rejected changing the config as the intended purpose for creating a 'similar' PACT was for a demo therefore not a good functional name. As far as adding consumer or provider in the name, absolutely not a good idea. It will be a nightmare to troubleshoot your pacts afterwards. Actually don't add any technical details to it. In our organisation where we have close to 600 pacts we just append the namespace with the functional name. No API, Messaging, Rabbit, Consumer, Provider, etc in the name. Good luck
bethskurrie
2020-11-11 09:17
@mateusz.derks if you have that version of the broker, then the pacts should stay WIP until the contents have been explicitly included.
bethskurrie
2020-11-11 09:18
You can see the test cases here https://github.com/pact-foundation/pact_broker/blob/master/spec/features/wip_pacts_spec.rb
bethskurrie
2020-11-11 09:21
I'm just reading your description, and I don't understand what the difference is between the actual be behaviour and the desired behaviour.
yann.courtel
2020-11-11 10:13
Hi Matt, of course. We have a pending email conversation :slightly_smiling_face: Thank you.
greg719
2020-11-11 10:40
hey guys, i am making a presentation about efficient testing strategy on NG Poland (biggest angular conference in Central Europe) - of course pact is part of the presentation. However I am trying to show case pact broker (using our own broker setup). But when I wanna show that you can use stub responses from the broker, it throws me 401 so my question is: can I make it public in the broker? any chance to get a broker just for the conference? or should i go with auth?
matt.fellows
2020-11-11 10:47
Are you referring to the stub feature in Pactflow? Or the pact-stub-server using Pact Broker as a contract source?
greg719
2020-11-11 10:48
now i would like to showcase that you do not need mocks / stubs because pact already does it for you
matt.fellows
2020-11-11 10:49
Because we don?t want your pacts to be visible to the world, we opted for authentication on the stub URLs. Perhaps we can make this configurable, so that this constraint disappears
matt.fellows
2020-11-11 10:50
If you supply a standard bearer header with a pactflow API token e.g. `Authorization: Bearer <read-only API token>` it should work
cc: @bethskurrie @uglyog We may need to have a separate header for this use case, because it?s possible it may conflict with existing stubs that need an Authorization header :slightly_smiling_face:
mateusz.derks
2020-11-11 10:52
Hey @bethskurrie I select production tag of the consumer in the master provider verification. I wanted to keep branches of consumer WIP as long as they are ahead of production consumer. What I see is that once any WIP consumer branch is verified successfully they are no longer selected by WIP selector. I saw the test and it looks like this case indeed hence I was wondering what I am missing.
mateusz.derks
2020-11-11 10:56
If you think it should work I can try to reproduce it in an isolated environment.
matt.fellows
2020-11-11 10:56
I have to run Greg, because it?s late here. If you need a test account for the demo, drop us a line (you know how to find me) and we?ll get you up and running.
greg719
2020-11-11 10:57
this should do for the presentation, but yes would be a nice feature if we could attach extra (broker-only) header
greg719
2020-11-11 10:57
but actually i could do an interceptor that checks if a base url contains pact flow or not, then do it automatically
matt.fellows
2020-11-11 10:58
Awesome, let us know how you go - feedback on the stubs is helpful for us to evolve it. So don?t be afraid!
brendan.donegan
2020-11-11 11:14
Hi, I am having trouble adding a webhook to publish the verification status to GHE from our Pact broker (version 2.59.2) - the error we get is:
brendan.donegan
2020-11-11 11:14
```{
"error": {
"message": "undefined local variable or method `decoractor_options' for #<PactBroker::Api::Resources::PactWebhooks:0x00007f3afd1df3f0>",
"reference": "QJKJcflszL",
"backtrace": ["/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/pact_broker/api/resources/pact_webhooks.rb:55:in `from_json'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/helpers.rb:65:in `accept_helper'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/flow.rb:424:in `n11'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/fsm.rb:31:in `block (2 levels) in run'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/fsm.rb:51:in `handle_exceptions'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/fsm.rb:31:in `block in run'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/fsm.rb:29:in `loop'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/decision/fsm.rb:29:in `run'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/dispatcher.rb:46:in `block in dispatch'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/as-notifications-1.0.1/lib/as/notifications.rb:161:in `instrument'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/events.rb:75:in `instrument'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/dispatcher.rb:45:in `dispatch'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/webmachine-1.5.0/lib/webmachine/adapters/rack.rb:68:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/cascade.rb:47:in `block in call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `each'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/database_transaction.rb:46:in `block in call_with_transaction'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.35.0/lib/sequel/database/transactions.rb:258:in `_transaction'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.35.0/lib/sequel/database/transactions.rb:233:in `block in transaction'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.35.0/lib/sequel/connection_pool/threaded.rb:92:in `hold'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.35.0/lib/sequel/database/connecting.rb:270:in `synchronize'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.35.0/lib/sequel/database/transactions.rb:195:in `transaction'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/database_transaction.rb:45:in `call_with_transaction'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/database_transaction.rb:24:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/convert_404_to_hal.rb:10:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/no_auth.rb:9:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/builder.rb:244:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/cascade.rb:47:in `block in call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `each'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/urlmap.rb:74:in `block in call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/urlmap.rb:58:in `each'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/urlmap.rb:58:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/static.rb:161:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/hal_browser/redirect.rb:20:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/convert_file_extension_to_accept_header.rb:28:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/static.rb:161:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/static.rb:161:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/add_vary_header.rb:34:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/add_pact_broker_version_header.rb:14:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/reset_thread_data.rb:13:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/invalid_uri_protection.rb:24:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/use_when.rb:30:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-protection-2.0.8.1/lib/rack/protection/content_security_policy.rb:73:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/rack/pact_broker/use_when.rb:28:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-protection-2.0.8.1/lib/rack/protection/xss_header.rb:18:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-protection-2.0.8.1/lib/rack/protection/json_csrf.rb:26:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-protection-2.0.8.1/lib/rack/protection/base.rb:50:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-protection-2.0.8.1/lib/rack/protection/frame_options.rb:31:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/rack-2.2.3/lib/rack/builder.rb:244:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.59.2/lib/pact_broker/app.rb:72:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/configuration.rb:227:in `call'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/server.rb:706:in `handle_request'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/server.rb:476:in `process_client'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/server.rb:334:in `block in run'", "/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/thread_pool.rb:135:in `block in spawn_thread'"]
}
}```
brendan.donegan
2020-11-11 11:16
I?ve previously added webhooks successfully with the same payload, which in general looks like:
```
{
"consumer": {
"name": "My Consumer"
},
"events": [
{
"name": "provider_verification_published"
}
],
"request": {
"method": "POST",
"url": "https://ghe.my.org/api/v3/repos/Ed-Learning/lift/statuses/${pactbroker.consumerVersionNumber}",
"body": {
"state": "${pactbroker.githubVerificationStatus}",
"description": "Pact Verification Tests",
"context": "${pactbroker.providerName} ${pactbroker.providerVersionTags}",
"target_url": "${pactbroker.verificationResultUrl}"
},
"headers": {
"Content-Type": "application/json",
"Authorization": "Bearer token"
}
}
}```
brendan.donegan
2020-11-11 11:16
Some information redacted of course, the consumer name, GHE hostname and authorization token are all different and I have updated them in the POST request actually sent
brendan.donegan
2020-11-11 11:24
Kind of looks like a bug, given the error: `?undefined local variable or method `decoractor_options' for #<PactBroker::Api::Resources::PactWebhooks:0x00007f3afd1df3f0>",`
ukrainian1991
2020-11-11 15:03
Hi, I got an error "413 Request Entity Too Large" when trying to publish my PACT file to pact broker. It has 13 ?B size
matt.fellows
2020-11-12 00:53
indeed. I thought because Brendan is a Pactflow customer, it must have been a PF instance. But it turns out no :stuck_out_tongue:
bethskurrie
2020-11-12 00:56
I can bump it or make it configurable, but having a pact file that large is unusual. Are you putting binary data in it?
suresh.tsv
2020-11-12 16:52
Hi, is it possible to send a can-I-deploy command using Http request. I am able find syntax for publish and tag a Pact. But for can-I-deploy I only see CLI request.
Thanks in advance.
antonello
2020-11-12 17:20
Hi @suresh.tsv.
You can definitely do a GET to:
```http://pact.twtools.io/pacticipants/{pacticipant}/latest-version/{tag}/can-i-deploy/to/{tag}```
suresh.tsv
2020-11-12 21:23
Thank you @antonello for your quick response. Please confirm if I understood it correctly. The above command tells the given pacticipant's latest version with a tag can be deployed with respect to other pacticipant with another tag.
Here we are providing only one pacticipant's name. Are we assuming one to one relationship?
The below CLI command allows us to mention both the pacticipants.
pact-broker can-I-deploy - - pacticipant A - - version 1.0.1 - - pacticipant B - - latest prod
Please advise.
Thanks
bethskurrie
2020-11-12 23:14
HI @suresh.tsv the endpoint that @antonello mentioned is the simplified one that only supports asking if a particular version of one application can be deployed to a particular environment (specified by the given tag name).
bethskurrie
2020-11-12 23:15
There is another endpoint to perform the multiple pacticipants together. If you run the can-i-deploy command with `--verbose` on, you'll see the HTTP query it makes. It's quite complicated however!
bethskurrie
2020-11-12 23:16
Can you explain what constraints you're under that mean you can't use the CLI?
guppy0356.nakira
2020-11-13 04:28
Does `pact-broker` have API for getting all contracts for one providers? In case of Lambda, I need to run `pact-provider-verifier`
with contracts which have been downloaded in local. So, I want to know how to download contracts.
bethskurrie
2020-11-13 04:28
Yes. But maybe there's a better way. Can you explain why you need to do it that way rather than letting the provider verifier fetch them from the broker directly?
guppy0356.nakira
2020-11-13 04:28
plz reference past my post :point_down:
https://pact-foundation.slack.com/archives/C9VECUP6E/p1603414010098700
guppy0356.nakira
2020-11-13 04:37
I think `pact-provider-verifier` expect locally saved contracts from README.md.
```pact-provider-verifier foo-bar.json --provider-base-url http://localhost:9292```
https://github.com/pact-foundation/pact-provider-verifier#simple-api
bethskurrie
2020-11-13 04:38
it won't publish the results back to the broker unless you fetched the pacts from the broker in the first place.
bethskurrie
2020-11-13 04:38
you won't be able to use WIP pacts and pending pacts unless you fetch the pacts from the broker.
guppy0356.nakira
2020-11-13 04:42
I understand. I can detect broker with `--pact-broker-base-url` . Your recommendation is use this option, isn't it?
bethskurrie
2020-11-13 04:42
you need to provide the provider's name, the broker base url and the broker credentials (basic auth or bearer token)
bethskurrie
2020-11-13 04:43
```Description:
The parameters used when fetching pacts dynamically from a Pact Broker are:
--pact-broker-base-url (REQUIRED)
--provider (REQUIRED)
--broker-username/--broker-password or --broker-token
--consumer-version-tag or --consumer-version-selector
--enable-pending
--include-wip-pacts-since```
bethskurrie
2020-11-13 04:44
``` To publish verification results for either of the above scenarios, set:
--publish-verification-results (REQUIRED)
--provider-app-version (REQUIRED)
--provider-version-tag or --tag-with-git-branch```
guppy0356.nakira
2020-11-13 09:30
Hi, Is it possible to upload contracts to S3 and S3 sends them to broker?
matt.fellows
2020-11-13 09:38
you would have to script it, but yes, the broker is fully API driven so that?s possible. But? why?
guppy0356.nakira
2020-11-13 11:43
@matt.fellows This question is ust my curiosity :smile: Contract will be uploaded by http protocol, right? If contract is huge size, broker can't receive this contract.
brendan.donegan
2020-11-13 11:45
does anyone know how to add a webhook that uses x-www-form-urlencoded data as part of the request?
suresh.tsv
2020-11-13 12:05
Hi @bethskurrie
Thank you for the clarification.
We are currently working on a POC with Pact. So in initial stages we want to use cURL to send Http requests by ignoring SSL communication from GitLab pipeline to Pact Broker. We will be using CLI in later stages.
Also on the provider side we are using Pact with Spring boot. The test has @PactBroker annotation to publish the verification results.
Is it possible to ignore SSL verification while test communicates with the broker?
Thanks again.
ukrainian1991
2020-11-13 13:47
As I write below, it was due to nginx behaviour. I specified pact broker URL to nginx (http://broker), but it works when I specify http://broker:9292
joaquin
2020-11-13 14:57
Hi all! I posted this issue https://github.com/pact-foundation/pact-provider-verifier/issues/61 ¿anyone here with some input about it?
simon.nizov
2020-11-13 15:21
Question about webhooks:
When a pact changes in a feature branch, I want to use the `contract_content_changed` webhook to trigger a provider build to verify that pact.
But how do I know which ?main? branch (environment) the consumer is planning to merge the feature branch to, so that I can perform verification on the latest provider in that environment? That pact will be tagged with the feature branch name, so the broker doesn?t really know where the pact is ?headed to?, does it?
phil.endsley
2020-11-13 15:46
I'm trying to wrap my head around this...
So you would have something like:
2 different environments (ex: dev1 and dev2) running different versions of consumer/provider
env1
Consumer: main
Provider: main
env2
Consumer: feat-x
Provider: feat-y
And you want to know that if `feat-x` changes, provider verification is ran on `feat-y` branch of the provider?
> so the broker doesn?t really know where the pact is ?headed to?, does it?
Correct, because it's not necessarily headed anywhere. It's just a new version of the contract for a consumer
simon.nizov
2020-11-13 15:53
Nope, the set up is like this:
*env1*
Consumer branches: env1
Provider branches: env1
*env2*
Consumer branches: env2
Provider branches: env2
Both the consumer and the provider have these branches whose names match the environment they are deployed to
Now, when I create a *feat-x* branch out of env1, I want the provider of env1 to run the verification, because that?s where *feat-x* is going to be merged and deployed to.
Hope that makes more sense
@phil.endsley
antonello
2020-11-13 16:40
@simon.nizov, unless I?m misunderstanding your problem, the dynamic variable substitution should help
https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks/#dynamic-variable-substitution
simon.nizov
2020-11-13 16:46
@antonello I thought so too but for example `${pactbroker.consumerVersionTags}` will pass `feat-x` to the provider build. How do I then know that I should verify the provider version that is in `env1`?
simon.nizov
2020-11-13 16:51
@antonello Imagine you have multiple environments - qa, staging, etc..
The code that is running in those envs sits in branches with a matching name, in each service.
So for example, environment ?staging? runs code that is in a branch called `staging`. Both in the consumer and the provider.
antonello
2020-11-13 16:58
it?s a bit convoluted and a bit of a slippery slope, but if you want to be as close as possible to pact nirvana, you might want to a webhook for all environments that matter.
phil.endsley
2020-11-13 17:00
@simon.nizov is there any way to determine where you branched from? If so, maybe you could leverage another set of tags?
Only thing I can think of right now...will continue to mull it over though
antonello
2020-11-13 17:03
just to explain what I mean with an example, unless you deploy your consumer and provider together, your feature branches (whether they are from the `qa` or `staging` branch) would always trigger provider builds for both `qa` and `staging` branches, to make sure that you?re compatible with both.
suresh.tsv
2020-11-13 17:08
Hi, I am working on a Spring boot application which has a test to verify Pacts. @PactBroker annotation is used to configure Pact Broker host and port details, with SSL scheme.
Is there a way I can disable SSL validation while calling Pact Broker? I mean allowing insecure call. This is needed temporarily for a POC.
Thanks in advance.
simon.nizov
2020-11-13 17:08
@antonello That might work yeah.
@phil.endsley One thing I thought of was this - publish the pact when a PR is opened. Then I can theoretically pull the base branch of the PR using Github?s API.
antonello
2020-11-13 17:18
At one point I was scratching my head with similar problems (before we decided to go for a simpler approach), and the only thing I could think of was to create a middle man.
antonello
2020-11-13 17:20
a simple web app that would receive webhook requests and then apply some logic to decide which branches to trigger.
phil.endsley
2020-11-13 17:35
I think that would make sense if you have some deterministic way of figuring out where you branched from. Otherwise, I don't think there's a way to automate that process...
I agree with @antonello's suggestion of having a webhook for each environment. If you use pending pacts, it won't fail the build for wrong environments, but will still publish verification results.
simon.nizov
2020-11-13 17:54
@antonello yeah, my idea with github would have to be done in a middleman like you described. I was thinking even simpler than a web app though - an aws lambda function.
I had a feeling that I'm running into this issue because our setup isn't standard. Thanks for clearing that up for me guys!
suresh.tsv
2020-11-13 20:38
[PACT BROKER behind API Gateway]
Hi, we are facing an issue with verification while running Pact Broker behind Kong API Gateway. Provider is a Spring Boot application.
When the test for verification is executed it is using the Gateway host and port to connect to the Broker behind it. However in the JSON response returned, the broker is including the links to actual Broker host name with default port. Hence the Provider is trying to connect to the Broker directly for further communication causing connection failure.
How can we fix this such that response returned from Pact Broker includes the Gateway host name and port.
Please help.
Thanks
matt.fellows
2020-11-13 20:47
Check with #pact-jvm but pretty sure same way you'd do it for anything in Java. Add your cert to the trust store
suresh.tsv
2020-11-13 20:53
Thank you @matt.fellows for very quick response. We will try the suggested settings.
suresh.tsv
2020-11-13 21:09
Thank you @matt.fellows. Just did the same. Actually wanted to ignore it but couldn't figure out.
matt.fellows
2020-11-13 21:46
You can still use self signed certs with the CLI. You can export some Env vars to trust the cert
bethskurrie
2020-11-13 23:54
> a simple web app that would receive webhook requests and then apply some logic to decide which branches to trigger.
@simon.nizov Yes, I agree with Anto's proxy suggestion. I recommend in this situation that there is an intermediate build in your CI that accepts all the webhooks, and then works out what needs to be built, and then creates another build with the correct branches/versions of everything.
bethskurrie
2020-11-13 23:56
@guppy0356.nakira what are you putting in your contracts that is that big?
bethskurrie
2020-11-13 23:57
@suresh.tsv see an example here: https://github.com/pact-foundation/pact-ruby-cli#using-a-custom-certificate
bethskurrie
2020-11-13 23:58
Here's an example using docker compose with a self signed cert https://github.com/DiUS/pact_broker-docker/blob/master/docker-compose.yml#L43
bethskurrie
2020-11-14 00:00
@suresh.tsv it will be much easier to set the self signed cert than to try and replicate the can-i-deploy commands as a CURL. It's not a user friendly request.
bethskurrie
2020-11-14 00:01
If this is a POC, and you have an internally deployed Pact Broker (not Pactflow), can you ask your ops team to disable SSL while you do the POC?
simon.nizov
2020-11-14 07:24
@bethskurrie thanks. I don't think I can do that with Drone CI though. The proxy has to be external
simon.nizov
2020-11-14 08:12
I don't think so...
There's a rest API that can be used to trigger a build. I guess it can be called from another build to achieve a build triggering another build. But I don't think there's anything native.
bethskurrie
2020-11-14 08:17
Github Actions is a bit like that though. You have to call the API to trigger another Github Action.
simon.nizov
2020-11-14 08:30
Yep, this whole thread originated from me wondering what to pass in that `branch={branch}` param
simon.nizov
2020-11-14 11:57
Yes that can help, but sometimes a pact can change without requiring the provider to change anything. So no need for a matching branch on the provider
bethskurrie
2020-11-15 22:55
@simon.nizov yes, that's why there's a "fallbackTag" for when there is no matching branch.
guppy0356.nakira
2020-11-16 03:09
In `technical details` , I cannot understand this sentence.
```Discard all the pacts that were published before the first instance of this provider tag (this is so that if you create a brand new provider branch, you don't get EVERY head pact included in the WIP pacts list).```
ref https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/#technical-details
Tried Steps to understand:
1. Consumer upload contract with `master` tag and provider verify and upload its result with `master` tag.
2. Provider also verify current contract with `feat-z` tag.
3. Consumer add some examples with `feat-x` tag. After that, add some examples with `feat-y` tag.
4. Provider will verify `feat-y` only. :point_left: Is this correct?
In case of `includeWipPactsSince` is `"2020-01-01"` , I think provider can verify `feat-x` and `feat-y`.
Maybe I don't understand wip pact but I understand pending pact. Pending pact is for provider, isn't it? If consumer upload new request contract which is not supported by provider, provider ci will fails but exit status is 0 (success). So, this failure result not affect deploy step.
guppy0356.nakira
2020-11-16 05:53
What is the difference between `--contract-content-changed` and `--contract-published` in create-webhook.
bethskurrie
2020-11-16 05:54
One fires every time a pact is published. One fires only if the content has changed when it is published.
bethskurrie
2020-11-16 05:55
Most of the time, the contract that is published has exactly the same content as the one before it. They tend to change rarely (as a proportion of overall commits) once an API has stablised.
guppy0356.nakira
2020-11-16 06:10
I want to fire event on every publish. So, `--contract-content-changed` is prefer?
bethskurrie
2020-11-16 06:14
The webhook causes an HTTP request (that you configure) to be performed when an event happens in the Pact Broker.
bethskurrie
2020-11-16 06:15
A webhook is triggered when pacts are published or when verification results are published.
bethskurrie
2020-11-16 06:19
The WIP pacts feature is designed to allow you to verify the "outstanding" pacts without having to change your configuration.
bethskurrie
2020-11-16 06:21
We exclude any pacts created before the first instance of the tag, because if we did not, every time we created a new branch, every head pact ever created would be considered WIP.
guppy0356.nakira
2020-11-16 06:26
Sorry Beth. Please go back to the main subject.
```[--contract-content-changed], [--no-contract-content-changed]
# Trigger this webhook when the pact content changes
[--contract-published], [--no-contract-published]
# Trigger this webhook when a pact is published```
ref https://github.com/pact-foundation/pact_broker-client#create-webhook
```Trigger this webhook when a pact is published```
and
```# Trigger this webhook when the pact content changes```
is same meaning for me because publish is changing something.
bethskurrie
2020-11-16 06:27
For me to tell you whether to use --contract-content-changed or --contract-published I need to understand what you want the webhook to do.
bethskurrie
2020-11-16 06:27
> publish is changing something
We have different ideas of what publish means then.
bethskurrie
2020-11-16 06:27
You can publish the same thing over and over. Publish just means "making a thing available for someone else to use".
bethskurrie
2020-11-16 06:29
You could publish the same jar file over and over with a different version number (it would be silly, but you could do it).
bethskurrie
2020-11-16 06:30
You can publish the same pact JSON content over and over again, with a different consumer version number.
bethskurrie
2020-11-16 06:55
```curl -X PUT \
-H "Content-Type: application/json" \
-d "< pact content 1 >"
http://test.pactflow.io/pacts/provider/Bar/consumer/Foo/version/1
-> triggers contract_published and contract_content_changed (first ever pact always triggeres change)
curl -X PUT \
-H "Content-Type: application/json" \
-d "< pact content 1 >"
http://test.pactflow.io/pacts/provider/Bar/consumer/Foo/version/2
-> triggers contract_published (content is the same as before)
curl -X PUT \
-H "Content-Type: application/json" \
-d "< pact content 2 >"
http://test.pactflow.io/pacts/provider/Bar/consumer/Foo/version/3
-> triggers contract_published and contract_content_changed (the content is different from the previous publication) ```
guppy0356.nakira
2020-11-16 07:08
I run `pact-broker can-i-deploy --retry-while-unknown 5 --retry-interval 30 ...` but returns `Computer says no` soon. Why???
bethskurrie
2020-11-16 07:45
If there is a result already, and it is a failure, it will return immediately.
bethskurrie
2020-11-16 07:46
@guppy0356.nakira I recommend doing the CI/CD workshop https://docs.pactflow.io/docs/workshops/ci-cd/
bethskurrie
2020-11-16 07:49
Publish pact with content "1234" for consumer version 1
Provider runs verification - fails - publishes results
Publish pact with content "1234" for consumer version 2
can-i-deploy --retry-while-unknown X will say "no" immediately, because there is a result for pact with content "1234", and is failed.
bethskurrie
2020-11-16 07:50
Publish pact with content "1234" for consumer version 1
Provider runs verification - fails - publishes results
Publish pact with content "4567" for consumer version 2
can-i-deploy --retry-while-unknown X will poll because there is no verification result for pact with content "4567"
bethskurrie
2020-11-16 07:50
mateusz.derks
2020-11-16 10:56
I got it working in a simple isolated setup, so it must be something misconfigured on our project.
guppy0356.nakira
2020-11-16 13:02
Hmm, my native language is Japanese. Long English sentence sometimes is complicated.
antonello
2020-11-16 13:05
I see. Well, if there are any particular sentences you?re struggling with, do reach out.
mateusz.derks
2020-11-16 20:41
We have a mix consumer configuration like
```Pact.service_provider('My Provider') do
honours_pacts_from_pact_broker do
end
end
Pact.service_provider('My Provider') do
honours_pact_with('My Consumer 1') do
end
end
Pact.service_provider('My Provider') do
honours_pact_with('My Consumer 2') do
end
end```
maybe it causes some conflict :thinking_face: I need to dig deeper
guppy0356.nakira
2020-11-17 00:48
I'm doing CI/CD workshop now. Are there any steps to configure a trigger to run consumer verification build. I think consumer build need to re-run `can-i-deploy` job to detect provider verification result. I'm sorry if I skipped it.
bethskurrie
2020-11-17 00:52
You'd need to use the webhook template parameters to make sure you built the correct sha/branch of the consumer.
bethskurrie
2020-11-17 01:02
Make a webhook that runs for "provider verification succeeded" and passes the `${pactbroker.consumerVersionNumber}` back to the consumer build.
bethskurrie
2020-11-17 01:02
The same way that you'd pass the `${pactbroker.pactUrl}` to the provider build.
guppy0356.nakira
2020-11-17 01:26
I will try. By the way, are there any options to update target branch.
``````
guppy0356.nakira
2020-11-17 01:28
```{
"request": {
"message": "Triggered by changed pact for ${pactbroker.consumerName} version ${pactbroker.consumerVersionNumber}",
"branch": "master",
"merge_mode": "deep_merge_append",
"config": {
"env": {
"global": [
"PACT_URL=${pactbroker.pactUrl}"
]
}
}
}
}```
Target branch is always master. I want to update this target branch. Combination is like this.
1. (consumer) feat-x and (provider) develop
2. (consumer) prod and (provider) prod
bethskurrie
2020-11-17 02:13
You'll need to look at the travis documentation to answer that @guppy0356.nakira
bethskurrie
2020-11-17 02:14
There's no way to do the mapping in the webhook. There is no logic. You would have to trigger a travis build, passing all the vars through, do the logic inside that build, and trigger another build with the right branch set.
guppy0356.nakira
2020-11-17 08:06
When consumer publish contract to broker, broker fires webhook on receiving. Does `${pactbroker.consumerVersionTags}` have only one tag?
guppy0356.nakira
2020-11-17 08:11
oh! I really understand! This variable shows tags which are related with ONE contract, isn't it?
guppy0356.nakira
2020-11-17 08:17
How about provider verification? Provider can verify some versioned contracts and publish results. Broker fires webhook on each publish and relpace `${pactbroker.consumerVersionTags}` to the tags which are related with ONE contract. It doesn't all tags which is related with ALL contracts.
bethskurrie
2020-11-17 08:18
If you've used the ${pactbroker.pactUrl} to pass the pact to verify, it puts the original consumer version and tag into the metadata which is base64 encoded in the URL.
bethskurrie
2020-11-17 08:19
When the verification results are published back, it sends that metadata back with the results in the URL.
bethskurrie
2020-11-17 08:20
If the results are from a verification where the pacts for all consumers are verified, it will use the latest consumer version with that content.
bethskurrie
2020-11-17 08:30
Here's an example of a script that might run on the consumer side when triggered by a "provider verification result succeeded" webhook https://github.com/pact-foundation/pact_broker-client/blob/master/example/scripts/deploy-consumer.sh
mateusz.derks
2020-11-18 10:22
Actually the verification done with `honours_pacts_from_pact_broker` kept pact as WIP, but it stopped being WIP when I selected it by URL
```Pact.service_provider(provider) do
honours_pact_with(consumer) do
pact_uri url
end
end```
when such verification is published to the broker, the pact selected by URL is no longer considered WIP.
I will try to reproduce the same behavior on my isolated environment so I can share it publicly.
mateusz.derks
2020-11-18 13:24
@bethskurrie I put it all together in this example repo https://github.com/ertrzyiks/pact-playground/blob/main/issues/wip.md
TLDR a contract is no longer WIP when it?s being verified by pact URL. Is that intentional?
jarmy
2020-11-19 23:04
Is `can-i-deploy` traditionally called by consumers? I?m wondering if it can be used by providers to check if the have verified the contract with their consumers before deploying
bethskurrie
2020-11-19 23:05
Both sides need it because even after the tests have run, either side could deploy a new version before the other does
bethskurrie
2020-11-19 23:06
And if you have pending pacts turned on (so your build doesn't fail if a consumer changes a pact on the main branch) you need it to ensure you're safe because your build won't have failed.
jarmy
2020-11-19 23:06
I suspected so. This https://docs.pact.io/pact_broker/webhooks/#consumer-ci seems to favor the consumer
bethskurrie
2020-11-19 23:07
Hm, yes, I can see why you'd think so. It doesn't list the full provider pipeline, just the test jobs.
bethskurrie
2020-11-19 23:10
I've just done a quick update to the text. It should be deployed in a few minutes.
matt.fellows
2020-11-20 01:32
@ercalbwar just wanted to follow this up. We?d love to get your Jenkins template and setup instructions into our libary. Would you be open to sharing here, or better yet, submitting a PR?
mateusz.derks
2020-11-20 07:30
Is that intentional that veryfing pact by URL makes it no longer WIP?
I replicated our setup in simplified environment and noticed that WIP status is kept when I verify asking broker for contracts but is lost when I use direct URL
https://github.com/ertrzyiks/pact-playground/blob/main/issues/wip.md
brendan.donegan
2020-11-20 09:04
I haven?t used this feature much but I think it may rely on the broker to determine that status - https://docs.pact.io/pact_broker/advanced_topics/pending_pacts
mateusz.derks
2020-11-20 09:33
Yes, it works like a charm as long as I pass base url of broker and consumer version selectors for verification. If the same contract is verified by the pact file URL this contract is no longer selected by WIP condition.
brendan.donegan
2020-11-20 09:35
If I had to guess how this works (and one of the maintainers can correct me), I would say the Broker itself is dynamically injecting the required fields into the contract before sending it down to the provider
ercalbwar
2020-11-20 10:33
For sure! I have a couple of busy weeks coming up but I will have plenty of time in the holiday break. I will add this to my list :)
matt.fellows
2020-11-20 11:37
Correct Brendon, or at leas your intuition is on point. The broker does the pending calculation based on its state, and sends back some extra relations in the hypermedia response for the client code to publish the verification results to.
matt.fellows
2020-11-20 11:37
The direct URL case is interesting on the pending stuff. I haven?t put the same amount of thought into it as @bethskurrie, but I can see an argument either way here.
mateusz.derks
2020-11-20 11:46
Thanks for the confirmation @matt.fellows . It?s good to understand the technical explanation of what is going on. It causes issues with the `contract_content_changed` webhook since once a job triggered by https://docs.pact.io/pact_broker/webhooks/template_library#github---trigger-build is green, the feature branch is excluded from WIP filter.
It?s partially because we get the webhook called even if the contract is not changed (I suspected https://github.com/pact-foundation/pact-js/issues/524, but it?s not the case apparently). I?m still digging why we schedule a job after pushing a new tag without any changes. That?s a separate topic though.
brendan.donegan
2020-11-20 11:47
@mateusz.derks we have one contract which always changes because the developer has put the timestamp in it
mateusz.derks
2020-11-20 11:49
@brendan.donegan Good point. We had such thing but I eliminated all the random differences in the pact file. Also `can-i-deploy` immediately knows that the contract is verified, the webhook is called anyway. I think if there is any change in the contract file it would be missing verification right after being published.
mateusz.derks
2020-11-20 11:51
So what we get is:
? have a new branch with no apparent changes to the pact
? pact published to the broker
? can-i-deploy returns :white_check_mark: right away
? the verification job is triggered anyway (by the webhook?) and the branch is no longer WIP
mateusz.derks
2020-11-20 11:59
The webhook is configured to make GET request adding `${pactbroker.pactUrl}` as a query param, and pactUrl is like
```https://my-broker/pacts/provider/PROVIDER/consumer/CONSUMER/pact-version/VERSION/metadata/METADATA```
The VERSION is the same for all the unnecessary jobs, only METADATA is different (different consumer version tag when base64 decoded).
mateusz.derks
2020-11-20 12:36
I see that `contract_content_changed` webhook is also called when we publish a very first version of a tag :thinking_face: It may be related to our overscheduling the jobs.
Anyway, the question is still if a verification by URL should undo WIP status.
mateusz.derks
2020-11-20 12:43
Yes, it explains everything.
We have a WIP master branch. Then we create a feature branch on top of it. This feature branch has no changes to pact on its own, but since it publishes the master's version of pact with a new tag it triggers the webhook with content change. The verification of feature branch contract makes master branch no longer WIP because they point to the same contract sha.
bethskurrie
2020-11-23 21:22
So, the rule is, "if it is verified successfully while it was included as WIP then it remains WIP".
bethskurrie
2020-11-23 21:23
So, there's a wip=true in that metadata when you verify using the 'pacts for verification' API that isn't there in the direct URL. But... I think I could just add it to the URL of the pact that is being verified by webhook. I'll have to have a think about the consequences of this.
bethskurrie
2020-11-23 21:27
My initial feeling is that it will work. @mateusz.derks are you using your own hosted broker? If I put that change into an edge version, could you install it and try it out?
jarmy
2020-11-24 00:26
Hi. We have branches (e.g. `task/GRNWEB-2077-fast-follow`)
that are supposed to be added when a pact is published
```Publishing pacts to broker at: https://pact-broker.docker.savagebeast.com/
12:16:50 [2020-11-23T20:16:50.640Z] INFO: pact-node@10.11.0/66205 on jenkins-build-agent-09:
12:16:50
12:16:50 Tagging version 548f6b61 of web as "task/GRNWEB-2077-fast-follow"
12:16:50 Publishing web/pegasus pact to pact broker at https://pact-broker.docker.savagebeast.com/```
However, the pact is uploaded but I'm not seeing that tag (or any like it) in our pact-broker (`2.57.0.0`). Is it possible the pact-broker is omitting tags with "/" in them?
bethskurrie
2020-11-24 00:27
Tags definitely support slashes in the server and the ruby client, as it's quite common for branch names to follow the "feat/x" format
bethskurrie
2020-11-24 00:30
Broker base URL: https://test.pact.dius.com.au
username: dXfltyFMgNOFZAxr8io9wJ37iUpY42M
password: O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1
bethskurrie
2020-11-24 00:31
There should be a line saying "the latest version of the pact is available at..."
jarmy
2020-11-24 00:31
```12:16:50 Publishing to Pact broker
12:16:50 [2020-11-23T20:16:48.427Z] INFO: pact-node@10.11.0/66205 on jenkins-build-agent-09: Publishing Pacts to Broker
12:16:50 [2020-11-23T20:16:48.429Z] INFO: pact-node@10.11.0/66205 on jenkins-build-agent-09: Publishing pacts to broker at: https://pact-broker.docker.savagebeast.com/
12:16:50 [2020-11-23T20:16:50.640Z] INFO: pact-node@10.11.0/66205 on jenkins-build-agent-09:
12:16:50
12:16:50 Tagging version 548f6b61 of web as "task/GRNWEB-2077-fast-follow"
12:16:50 Publishing web/pegasus pact to pact broker at https://pact-broker.docker.savagebeast.com/
12:16:50 The latest version of this pact can be accessed at the following URL (use this to configure the provider verification):
12:16:50 https://pact-broker.docker.savagebeast.com/pacts/provider/pegasus/consumer/web/latest
12:16:50
12:16:50
12:16:50 Pact contract publishing complete!```
jarmy
2020-11-24 00:52
published here with the branch name https://test.pactflow.io/matrix/provider/pegasus/consumer/web
jarmy
2020-11-24 01:00
ok, I've just published the same contract to our broker
```Tagging version fd292b0a of web as "task/test-pact-publish"
Publishing web/pegasus pact to pact broker at https://pact-broker.docker.savagebeast.com/
The latest version of this pact can be accessed at the following URL (use this to configure the provider verification):
https://pact-broker.docker.savagebeast.com/pacts/provider/pegasus/consumer/web/latest```
the tag was not applied to the pact
jarmy
2020-11-24 01:02
I added it but that's all I get on the publish event. The rest (before the above message) looks related to opening the connection and the contract
jarmy
2020-11-24 01:03
I've got `verbose: 'true'` per https://docs.pact.io/implementation_guides/javascript/readme/#verification-options
bethskurrie
2020-11-24 01:06
```docker run --rm \
-w ${PWD} \
-v ${PWD}:${PWD} \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_USERNAME \
-e PACT_BROKER_PASSWORD \
pactfoundation/pact-cli:latest \
publish \
${PWD}/example/pacts \
--consumer-app-version fake-git-sha-for-demo-$(date +%s) \
--tag "feat/foo" \
--verbose```
bethskurrie
2020-11-24 01:08
```<- "PUT /pacticipants/Pact%20Broker%20Client/versions/fake-git-sha-for-demo-1606180022/tags/feat%2Ffoo HTTP/1.1\r\nAccept: application/hal+json, application/json\r\nContent-Type: application/json\r\nContent-Length: 0\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nUser-Agent: Ruby\r\nAuthorization: Basic ZFhmbHR5Rk1nTk9GWkF4cjhpbzl3SjM3aVVwWTQyTTpPNUFJWld4ZWxXYkx2cU1kOFBrQVZ5Y0JKaDJQc3lnMQ==\r\nConnection: close\r\nHost: http://test.pact.dius.com.au\r\n\r\n"
<- ""
-> "HTTP/1.1 201 Created\r\n"
-> "Date: Tue, 24 Nov 2020 01:07:05 GMT\r\n"
-> "Content-Type: application/hal+json;charset=utf-8\r\n"
-> "Content-Length: 572\r\n"
-> "Connection: close\r\n"
-> "Vary: Accept\r\n"
-> "Location: https://test.pact.dius.com.au/pacticipants/Pact%20Broker%20Client/versions/fake-git-sha-for-demo-1606180022/tags/feat/foo\r\n"
-> "Server: Webmachine-Ruby/1.5.0 Rack/1.3\r\n"
-> "X-Pact-Broker-Version: 2.68.1\r\n"
-> "X-Pact-Broker-Git-Sha: 74d3644d\r\n"
-> "X-Pactflow-Git-Sha: b539f7bf\r\n"
-> "X-Content-Type-Options: nosniff\r\n"
-> "X-Request-Id: fdf6744f6745d92cfd564f2090de2aeb\r\n"
-> "\r\n"
reading 572 bytes...```
jarmy
2020-11-24 01:18
Relatively new AFAIK (`pact-node@10.10.1`) this is the output with verbose logging
bethskurrie
2020-11-24 01:19
```<- "PUT /pacticipants/web/versions/fd292b0a/tags/task%2Ftest-pact-publish HTTP/1.1\r\nAccept: application/hal+json, application/json\r\nContent-Type: application/json\r\nContent-Length: 0\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nUser-Agent: Ruby\r\nConnection: close\r\nHost: http://pact-broker.docker.savagebeast.com\r\n\r\n"
<- ""
-> "HTTP/1.1 404 Not Found\r\n"```
bethskurrie
2020-11-24 01:47
bethskurrie
2020-11-24 01:49
The simplest thing would be to upgrade to the latest version of the broker.
bethskurrie
2020-11-24 01:50
Given you could publish successfully to our test one, it seems that whatever issue there is doesn't exist in that version.
mateusz.derks
2020-11-24 07:36
@bethskurrie thanks for the feedback! We use self-hosted broker indeed and I can give the edge version a shot.
stefanos.varsanis
2020-11-24 16:53
Hello fellow Pact lovers,
I have a question regarding webhooks.
I have created a webhook which works perfectly with each new content change I am not getting it to be triggered when a tag (even a totally new tag) is applied to the consumer pact.
The webhook has the below configuration event
``` "events": [
{
"name": "contract_content_changed"
}
],```
Any ideas on how to debug this issue? Thank you in advance
jarmy
2020-11-24 22:31
I _thought_ I had upgraded to `2.68.1.0` but I'm still seeing `"X-Pact-Broker-Version: 2.57.0\r\n"` when I publish to the broker. Where does the broker read this value from?
jarmy
2020-11-24 22:34
nope, we are rolling our own https://docs.pact.io/pact_broker/#rolling-your-own
bethskurrie
2020-11-24 22:38
As long as the sysadmin team knows how to run a ruby app! We often get ppl with no dev ops experience trying to run the bare ruby app, and it all goes to shit.
bethskurrie
2020-11-24 22:46
Also, here's the page on debugging webhooks https://docs.pact.io/pact_broker/webhooks/debugging_webhooks
jarmy
2020-11-24 22:49
bounced and it's still showing `2.57.0` on publish
If you have the time, I'll jot down the high-level steps we use to build our image. Maybe you can spot where things are wrong?
bethskurrie
2020-11-24 22:50
Just double checking to make sure, but yes, the version is correct in the source code! https://github.com/pact-foundation/pact_broker/blob/v2.68.1/lib/pact_broker/version.rb
jarmy
2020-11-24 23:03
1. add https://github.com/pact-foundation/pact-broker-docker/ as a submodule to our git repo
2. checkout the target release (e.g. `git checkout tags/2.68.1.0 -b 2.68.1.0`)
3. copy /pact-broker-docker/pact_broker/Gemfile & pact-broker-docker/pact_broker/Gemfile.lock into `ENV HOME=/pact_broker`
4. Run `bundle install --no-cache --deployment --without='development test'`
5. Then `cp -R pact-broker-docker/pact_broker/. "$HOME"`
6. Then start things up
jarmy
2020-11-24 23:06
that's not included in the submodule https://github.com/pact-foundation/pact-broker-docker/tree/master/pact_broker
jarmy
2020-11-24 23:10
I'm in a local pact-broker docker image right now and I'll I get is this:
```# gem env
RubyGems Environment:
- RUBYGEMS VERSION: 3.0.3
- RUBY VERSION: 2.6.5 (2019-10-01 patchlevel 114) [x86_64-linux]
- INSTALLATION DIRECTORY: /usr/local/bundle
- USER INSTALLATION DIRECTORY: /pact_broker/.gem/ruby/2.6.0
- RUBY EXECUTABLE: /usr/local/bin/ruby
- GIT EXECUTABLE:
- EXECUTABLE DIRECTORY: /usr/local/bundle/bin
- SPEC CACHE DIRECTORY: /pact_broker/.gem/specs
- SYSTEM CONFIGURATION DIRECTORY: /usr/local/etc
- RUBYGEMS PLATFORMS:
- ruby
- x86_64-linux
- GEM PATHS:
- /usr/local/bundle
- /pact_broker/.gem/ruby/2.6.0
- /usr/local/lib/ruby/gems/2.6.0
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :backtrace => false
- :bulk_threshold => 1000
- "install" => "--no-document"
- "update" => "--no-document"
- REMOTE SOURCES:
- https://rubygems.org/
- SHELL PATH:
- /usr/local/bundle/bin
- /usr/local/sbin
- /usr/local/bin
- /usr/sbin
- /usr/bin
- /sbin
- /bin```
jarmy
2020-11-24 23:14
```# gem list
*** LOCAL GEMS ***
bigdecimal (default: 1.4.1)
bundler (2.0.2, default: 1.17.2)
cmath (default: 1.0.0)
csv (default: 3.0.9)
date (default: 2.0.0)
dbm (default: 1.0.0)
did_you_mean (1.3.0)
e2mmap (default: 0.1.0)
etc (default: 1.0.1)
fcntl (default: 1.0.0)
fiddle (default: 1.0.0)
fileutils (default: 1.1.0)
forwardable (default: 1.2.0)
gdbm (default: 2.0.0)
io-console (default: 0.4.7)
ipaddr (default: 1.2.2)
irb (default: 1.0.0)
json (default: 2.1.0)
logger (default: 1.3.0)
matrix (default: 0.1.0)
minitest (5.11.3)
mutex_m (default: 0.1.0)
net-telnet (0.2.0)
openssl (default: 2.1.2)
ostruct (default: 0.1.0)
power_assert (1.1.3)
prime (default: 0.1.0)
psych (default: 3.1.0)
rake (12.3.2)
rdoc (default: 6.1.2)
rexml (default: 3.1.9)
rss (default: 0.2.7)
scanf (default: 1.0.0)
sdbm (default: 1.0.0)
shell (default: 0.7)
stringio (default: 0.0.2)
strscan (default: 1.0.0)
sync (default: 0.5.0)
test-unit (3.2.9)
thwait (default: 0.1.0)
tracer (default: 0.1.0)
webrick (default: 1.4.2)
xmlrpc (0.3.0)
zlib (default: 1.0.0)
# ```
jarmy
2020-11-24 23:42
ah, but my docker image shows `pact_broker (2.57.0)`. I think I'm on to something
bethskurrie
2020-11-24 23:42
running "gem list pact_broker" should show the version(s) that are installed
bethskurrie
2020-11-24 23:44
ok, if I run
```docker run --rm --entrypoint /bin/sh -it pactfoundation/pact-broker:2.68.1.0
$ bundle list
...
pact_broker (2.68.1)```
bethskurrie
2020-11-24 23:46
WHen you run "bundle install" you should see the output of the gems its installing
jarmy
2020-11-25 00:15
I think I've figured it out. I failed to check in the submodule commit to my branch :exploding_head:
bethskurrie
2020-11-25 00:16
mm. I use them about once a decade and have to relearn it over from scratch each time!
jarmy
2020-11-25 00:28
sigh. the container won't start up due this error
```bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma)
TypeError: no implicit conversion of nil into String
config/puma.rb:1:in `[]'
config/puma.rb:1:in `_load_from'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/dsl.rb:43:in `instance_eval'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/dsl.rb:43:in `_load_from'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/configuration.rb:194:in `block in load'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/configuration.rb:194:in `each'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/configuration.rb:194:in `load'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/launcher.rb:61:in `initialize'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/cli.rb:71:in `new'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/lib/puma/cli.rb:71:in `initialize'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/bin/puma:8:in `new'
/pact_broker/vendor/bundle/ruby/2.6.0/gems/puma-3.12.6/bin/puma:8:in `<top (required)>'
/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma:23:in `load'
/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma:23:in `<top (required)>'```
bethskurrie
2020-11-25 00:29
```PACT_BROKER_PORT_ENVIRONMENT_VARIABLE_NAME```
should be set in the Dockerfile
bethskurrie
2020-11-25 00:30
I've seem someone else maintaining a "forked" dockerfile with a different appropach. Let me see if I can find it.
bethskurrie
2020-11-25 00:34
at least that way, you'd get all the env vars that are supposed to be set in the Dockerfile
jarmy
2020-11-25 00:35
I'm sure there's a better way. I'm wedged in between our infrastructure and the broker
jarmy
2020-11-25 00:50
ok, i've got `2.68.1` running but pacts are still not getting tagged
``` <- "PUT /pacticipants/web/versions/fd292b0a/tags/task%2Ftest-pact-publish HTTP/1.1\r\nAccept: application/hal+json, application/json\r\nContent-Type: application/json\r\nContent-Length: 0\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nUser-Agent: Ruby\r\nConnection: close\r\nHost: http://stage.pact-broker.docker.savagebeast.com\r\n\r\n"
<- ""
-> "HTTP/1.1 404 Not Found\r\n"```
This is our staging env so I can delete pacts and start with a clean slate.
bethskurrie
2020-11-25 00:53
I can't remember, did you manage to replicate the issue with the docker pact cli?
jarmy
2020-11-25 00:55
I looked yesterday but didn't see anything, i don't have debugging enabled in our prod environment, would that matter?
bethskurrie
2020-11-25 00:57
```def call env
if (uri = valid_uri?(env))
if (error_message = validate(uri))
[422, {'Content-Type' => 'text/plain'}, [error_message]]
else
app.call(env)
end
else
[404, {}, []]
end
end```
bethskurrie
2020-11-25 01:03
if you run your docker image locally, and try to publish to it, do you have the same issue?
jarmy
2020-11-25 01:04
```2020-11-24 17:01:27.754464 I [6:puma 001] pact-broker -- Creating new pact publication with params {:consumer_name=>"web", :provider_name=>"pegasus", :revision_number=>nil, :consumer_version_number=>"fd292b0a", :pact_version_sha=>nil, :consumer_name_in_pact=>"web", :provider_name_in_pact=>"pegasus"}
2020-11-24 17:01:27.754476 D [6:puma 001] pact-broker -- Content {"consumer":{"name":"web"},"provider":{"name":"pegasus"},"interactions":[{"description":"a request for v1/view","request":{"method":"GET","path":"/rest/v1/view","query":"deviceUuid=acctssp137-test-deviceUUID&platform=web"},"response":{"status":200,"headers":{"Content-Type":"application/json"},"body":{"sduiVersion":"1","itemId":"7NOr1za9vhlZp9exibwtxXdQK3QDNsN7eGVMhjeYgDJBDW6nxB5f9dHATjlKYfZ7D0B2cDFucbaj","page":{"itemId":"ockzpjWijfejTg0pwjyV0RFiizft3WhEpAYWIHKhNSXRr0KqqgCOzfUvkqKLiYd7cVXNjh7kiQQ7zXMHX4GKP7PxwZIKX","type":"CONTAINER","view":"PAGE","containers":[{"itemId":"ockzpjWijfejTg0pwjyV0RFiizft3WhEpAYWIHKhNWB99hhIDfC23yQ0eEsFPBqSOxYscP72XMCO2borHlEKkdHEnmn3R","type":"CONTAINER","component":"top-nav","view":"ELEMENT","items":[{"itemId":"1z9Mcwr2SqS92fH573GOr7mnJFP7K18BqkMCIH05uOwTvN3YdophadPi9YFPeAqt1seM124o2LO8f2ves5DSlUIVM3cQDVcza6cYBhSKREdzdE4bCiJ3nuNE09","type":"ITEM","component":"top-nav-item","texts":{"title":{"value":"Welcome! Content for you, updated daily"}},"images":{"icon":{"value":"ForYou","scheme":"BINDING"}},"actions":{"default":[{"context":"displayPage","type":"PRIMARY","intentType":"VIEW","intentId":"Xrad4ke8jrBX4jlYjOsiIVT8EkFieVwgIe1wJwRAkjKRJD9mS2UkLC8B2mQCob8xeA2NHojFkIYVXgHVj9DJFW7TwEHcS8032w4ImzCrhKcIJzjhahW1ByFwAqYj"},{"context":"selectItem","type":"PRIMARY","intentType":"LOCAL","intentId":"selectItem"}]}},{"itemId":"7Dqk3iSKdsBo399FwHyizxa9ciZQ9WC87A1kznDZFX1OlsUYIs1kY0yQFnjdAjyt49bqlztqBZVDFeVfeEwdCpN4sSurYGmpRFLzWDpwPqF6wrGNqWsLTQn","type":"ITEM","component":"top-nav-item","texts":{"title":{"value":"New & Now"}},"images":{"icon":{"value":"live","scheme":"BINDING"}},"actions":{"default":[{"context":"displayPage","type":"PRIMARY","intentType":"VIEW","intentId":"1M8OQZAFZPTa9nmtiEeDL4VOBJKr8fldcEp66ykiIptqaHDTilUB50Nvm8mXtTGafQWvKlFs176gzeqZEFaChAivUbEsXZRnPIZcjeleAQcq2j"},{"context":"selectItem","type":"PRIMARY","intentType":"LOCAL","intentId":"selectItem"}]}},{"itemId":"1z9Mcwr2SqS92fH573GOr7mnJFP7K18BqkMCIH05uOwTvN3YdophadPi9YFPfMbIESUaCPR5iLfue475w8RmEjRjAJ5ilxcr9E6OG05YqHOPcPECxNhYvSMehl","type":"ITEM","component":"top-nav-item","texts":{"title":{"value":"Search"}},"images":{"icon":{"value":"Search","scheme":"BINDING"}},"actions":{"default":[{"context":"displayPage","type":"PRIMARY","intentType":"VIEW","intentId":"2FpHFLcbk5LbcZYyNPSjuuPwI0syuNHuIezI0oLICOxAOlKKO3mIxLW5lbTwCuvN0HpRo9ZSs72ryUOThXbuW28bU8wFffxBWx9WSsn4S6eapSlfYW1XrMld96FNFZ"},{"context":"selectItem","type":"PRIMARY","intentType":"LOCAL","intentId":"selectItem"}]}},{"itemId":"8CUfQp10B6aDL0QX77TidM9TbTbiEefovnPelSCOOszTYtCh2PtTzGkAJRPc5bpg2sJuaWLSxN6ez8HxXX7NDhu6EL3Ip1Bro3qTqyENAzmqXOi6iBtA7pmXifp","type":"ITEM","component":"top-nav-item","texts":{"title":{"value":"My Stuff"}},"images":{"icon":{"value":"MyStuff","scheme":"BINDING"}},"actions":{"default":[{"context":"displayPage","type":"PRIMARY","intentType":"VIEW","intentId":"1kSkzvkZzy6jXhO2PFyinsdGrSEOFroPDMHrWOztWKz9J7CSXY9f4ri0oJHo8hHYK0OhUyNC03VITIqGZKKNJ81FMx1EX0DliEIeIGzCsSZnCMnjqlGJbt"},{"context":"selectItem","type":"PRIMARY","intentType":"LOCAL","intentId":"selectItem"}]}}]}]}},"matchingRules":{"$.body.itemId":{"match":"type"},"$.body.page.itemId":{"match":"type"},"$.body.page.containers[0].itemId":{"match":"type"},"$.body.page.containers[0].items[0].itemId":{"match":"type"},"$.body.page.containers[0].items[0].texts.title.value":{"match":"type"},"$.body.page.containers[0].items[0].images.icon.value":{"match":"type"},"$.body.page.containers[0].items[0].actions.default[0].intentId":{"match":"type"},"$.body.page.containers[0].items[0].actions.default[1].context":{"match":"type"},"$.body.page.containers[0].items[0].actions.default[1].intentId":{"match":"type"},"$.body.page.containers[0].items[1].itemId":{"match":"type"},"$.body.page.containers[0].items[1].texts.title.value":{"match":"type"},"$.body.page.containers[0].items[1].images.icon.value":{"match":"type"},"$.body.page.containers[0].items[1].actions.default[0].intentId":{"match":"type"},"$.body.page.containers[0].items[1].actions.default[1].context":{"match":"type"},"$.body.page.containers[0].items[1].actions.default[1].intentId":{"match":"type"},"$.body.page.containers[0].items[2].itemId":{"match":"type"},"$.body.page.containers[0].items[2].texts.title.value":{"match":"type"},"$.body.page.containers[0].items[2].images.icon.value":{"match":"type"},"$.body.page.containers[0].items[2].images.icon.scheme":{"match":"type"},"$.body.page.containers[0].items[2].actions.default[0].context":{"match":"type"},"$.body.page.containers[0].items[2].actions.default[0].intentId":{"match":"type"},"$.body.page.containers[0].items[2].actions.default[1].context":{"match":"type"},"$.body.page.containers[0].items[2].actions.default[1].intentId":{"match":"type"},"$.body.page.containers[0].items[3].itemId":{"match":"type"},"$.body.page.containers[0].items[3].texts.title.value":{"match":"type"},"$.body.page.containers[0].items[3].images.icon.value":{"match":"type"},"$.body.page.containers[0].items[3].actions.default[0].intentId":{"match":"type"},"$.body.page.containers[0].items[3].actions.default[1].context":{"match":"type"},"$.body.page.containers[0].items[3].actions.default[1].intentId":{"match":"type"}}}}],"metadata":{"pactSpecification":{"version":"2.0.0"}}}```
bethskurrie
2020-11-25 01:05
you're hardcoding the tag with the slash aren't you? Not getting from the `git` command?
bethskurrie
2020-11-25 01:05
We see issues when there are extra characters at the front or back of a string from the terminal.
bethskurrie
2020-11-25 01:07
ok, so what happens when you run your instance locally and publish to it?
bethskurrie
2020-11-25 01:08
I feel like there's something in the middle between the client and the broker that's doing something to the request.
bethskurrie
2020-11-25 01:17
If you set the env var `PACT_BROKER_FEATURES=experimental_webhook_wip` then it will append "wip=true" to the metadata.
bethskurrie
2020-11-25 01:17
Let me know how it goes, and if we like it, and there are no problems, I'll keep the feature without the flag.
jarmy
2020-11-25 01:20
oh, I have nginx running. would that interfere?
> I feel like there's something in the middle between the client and the broker that's doing something to the request
bethskurrie
2020-11-25 01:22
the puma logging I described above should show you if the request path is being modified at all on the way through.
bethskurrie
2020-11-25 01:25
Looks like it's ngnix's fault. You don't need it if you're running with a load balancer in a docker managed environment like kubernetes, or ECS.
jarmy
2020-11-25 01:36
here's the output from the broker when I tried to publish with the tag after adding `RUN echo "log_requests" >> /$HOME/config/puma.rb` to the Dockerfile
```169.253.0.4 - - [24/Nov/2020:17:28:05 -0800] "PUT /pacticipants/web/versions/fd292b0a/tags/task/test-pact-publish HTTP/1.0" 404 - 0.6167
2020-11-24 17:28:05.933768 I [6:puma 001] pact-broker -- Creating new pact publication with params {:consumer_name=>"web", :provider_name=>"pegasus", :revision_number=>nil, :consumer_version_number=>"fd292b0a", :pact_version_sha=>nil, :consumer_name_in_pact=>"web", :provider_name_in_pact=>"pegasus"}```
bethskurrie
2020-11-25 06:05
@antonello @jarmy @mateusz.derks @phil.endsley @bret.mcclory and anyone else using WIP pacts. Do you find there is benefit to having WIP pacts enabled on feature branches of your provider? I've recently updated the "best practise" recommendation to only enable it on the "main" development branches, because I figure, if you're making a branch for a non-pact related change, you don't care about WIP pacts, and if you are making a branch for a pact related change, then you probably know which pact you're working on, and can either use a matching feature branch strategy, or temporarily modify the config to pull in the one you want. What is your experience?
I'm asking because I'm trying to fix an issue in the initial phase of "getting it all working" that Phil has raised, and if I change a certain piece of logic, it would have an impact on how WIP pacts are calculated when a brand new branch of the provider is created.
ashish_garg5
2020-11-25 06:10
Hi All,
I am using dius/pact-broker docker image.
I changed the image version from 3 to 2 and see some data loss.
Not sure if this data loss happens because of version change or stopping the container.
Can anyone please help what could be the reason so that i can avoid this in future ?
Thanks
bethskurrie
2020-11-25 06:14
Upgrading does not wipe your data, so I would guess that you used a database volume that was destroyed when you shut down your broker container.
ashish_garg5
2020-11-25 06:15
yeah i am using an external database but somehow data is not there now in my db.
bethskurrie
2020-11-25 06:53
How are you running your broker? Locally, or to a deployed env? Where is the database running? For us to help you, we need to understand your full set up. Put yourselves in our position and try to give us enough information to be able to give you a helpful answer.
matt.fellows
2020-11-25 07:33
Did you say you?ve *downgraded* your pact broker version? Did you back up the database before doing that?
stefanos.varsanis
2020-11-25 07:51
Hey, what we're doing is when we have a release, we're "promoting" the developer tags to Release tags, thus, when a pact is marked with Release tag we want the verifications to be trigerred by the webhook
mateusz.derks
2020-11-25 07:58
We want to use WIP pacts to prevent missing verifications when a provider/consumer is released. The issue we had was that once a new version was released it invalidated all release candidates for other pacticipants because they were verified against another (the old) production. Having WIP pacts enabled on our main branch is all we need.
When we have feature branches of the provider we use matching feature as you said.
ashish_garg5
2020-11-25 09:49
@bethskurrie I am using some VM where i have pulled this docker image... so my docker-compose looks like this-
version: "3"
services:
pact-broker:
image: dius/pact-broker
environment:
PACT_BROKER_DATABASE_USERNAME: pact_broker
PACT_BROKER_DATABASE_PASSWORD: pact_broker
PACT_BROKER_DATABASE_HOST: <http://uvxpgsdev01.isus.emc.com|<>external_stg_server>
PACT_BROKER_DATABASE_NAME: pact_broker
PACT_BROKER_LOG_LEVEL: INFO
PACT_BROKER_BASIC_AUTH_USERNAME: <username>
PACT_BROKER_BASIC_AUTH_PASSWORD: <password>
PACT_BROKER_ALLOW_PUBLIC_READ: "true"
ports:
- "8500:80"
ashish_garg5
2020-11-25 10:32
so i have provided basic auth but still i was able to delete contracts from pact broker by using curl command...and i also have 1 more pact broker running with same config but having version 2 and there i was not able to delete without passing creds.
So just to make it as like the other 1 i downgraded it to 2.
matt.fellows
2020-11-25 11:51
downgrading docker compose has nothing to do with the application it?s running - they are separate things
ashish_garg5
2020-11-25 12:25
there were around 30 contracts in pact broker and after doing this now i can see only 10
matt.fellows
2020-11-25 12:26
unless you?ve pointed at a different database or something, that makes no sense to me
matt.fellows
2020-11-25 12:26
I?m currently leaning towards a docker configuration issue. If you can provide an example repro that shows the before/after and pinpoint it to pact code, I?m sorry but you may need to work with your ops team to perform forensics on the change (look at logs, restore backups etc.)
ashish_garg5
2020-11-25 12:27
yeah it's very strange not sure what is the reason, even i tried replicating this but this time no data loss all contracts are there.
phil.endsley
2020-11-25 14:09
We have wip pacts enabled for feature branches, but it's mainly just for simplicity in our CI setup. I don't think we really get any benefit out of verifying wip pacts on feature branches, and we haven't seen any adverse side effects from doing it this way
> or temporarily modify the config to pull in the one you want
This is what we do, since our naming conventions and other integrations prevent us from matching branch names. It's a little tedious, but it works
bethskurrie
2020-11-25 21:57
> We don?t use WIP pacts
Yeah, I didn't think you did @antonello, but I'd seen you reply to someone's question about WIP pacts so expertly that I wondered if you had!
bethskurrie
2020-11-25 21:59
I swear, you're the number 2 expert on how it works, despite not being a Ruby developer!
antonello
2020-11-25 22:08
I made a PR last year. Does that make me a ruby developer?:rolling_on_the_floor_laughing:
yann.courtel
2020-11-26 09:27
You should only have the code that creates / update your contract on the consumer side and the one validating the contract on the provider side in your source control.
Only save your pact files in your source control if you don't have a pact broker.
abubics
2020-11-26 11:01
I'd say, even if you don't have a broker, don't put it in git. The contract is a product of both the consumer and the provider, not belonging solely to either :slightly_smiling_face:
mateusz.derks
2020-11-26 20:16
I can?t get it working. The contract URL contains correct metadata param when I enable the flag, but it still unmarks the contract as WIP.
In the broker logs I see that two verifications are created, looks suspicious as once it?s created with `wip: false`
```pact-broker_1 | 2020-11-26 20:05:56.042501 I [7:puma 002] pact-broker -- Fetching pacts for verification by Provider -- {:provider_name=>"Provider", :params=>{"providerVersionTags"=>["main"]}}
pact-broker_1 | 2020-11-26 20:05:56.194874 I [7:puma 002] pact-broker -- Creating verification 275 for pact_id=59 -- {"success"=>true, "providerApplicationVersion"=>"277cb844feb687ebf378da45e4d000aeb9fa4e73", "wip"=>false}
pact-broker_1 | 2020-11-26 20:05:56.280104 I [7:puma 002] pact-broker -- Creating verification 276 for pact_id=59 -- {"success"=>true, "providerApplicationVersion"=>"277cb844feb687ebf378da45e4d000aeb9fa4e73", "wip"=>true}```
those are the settings I use for a verification by URL:
```let opts = {
providerBaseUrl: 'some URL',
provider: 'Provider',
pactBrokerUrl: 'some URL',
publishVerificationResult: true,
providerVersion: gitSha,
providerVersionTags: ['main'],
pactUrls: ['url from the webhook']
}```
any idea why the broker creates two verifications in such case? Looks like the second verification does works as expected, but it is cancelled out by the first one.
mateusz.derks
2020-11-26 20:45
Ok, I don?t need to pass `pactBrokerUrl: 'some URL',` in case I use `pactUrls` , works like a charm now :yay:
mateusz.derks
2020-11-26 20:53
@bethskurrie thank you :taco: I hope you like this feature and there are no objections from having it enabled without a flag
tjones
2020-11-26 22:44
I agree with @abubics - I would avoid committing the contract into source control, even without a broker. I think committing it is likely to cause workflow frustrations.
However, you do need a way to share the contract with the provider verification test - options include deploying the contract somewhere as part of the build, and running the provider verification test as part of your consumer build.
It is _much_ easier with a broker, though.
abubics
2020-11-26 22:54
Absolutely what @tjones said :D We've survived with saving a shared contact file in S3 temporarily, but the broker is definitely best.
wilkinsweiqiangliang
2020-11-27 05:40
#pact-broker Hey guys, i receive error on docker version of `pact-cli` .
wilkinsweiqiangliang
2020-11-27 05:40
```Error making request - Errno::ENOENT No such file or directory @ rb_sysopen```
bethskurrie
2020-11-27 05:40
Please provide all the information that we might need to help you debug that problem.
wilkinsweiqiangliang
2020-11-27 05:40
I had run my build three time, got this issue for the previous two time, and doesnt have this error on the third retry
wilkinsweiqiangliang
2020-11-27 05:49
the way i run it. `"docker run --rm -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN pactfoundation/pact-cli:latest broker publish ${PWD}/pacts --consumer-app-version=${BUILDKITE_COMMIT} --tag=${BUILDKITE_BRANCH}"`
wilkinsweiqiangliang
2020-11-27 05:51
```Error making request - Errno::ENOENT No such file or directory @ rb_sysopen - /var/lib/buildkite-agent/builds/buildkite-deployers-general-management-i-00437c6a99af63bdf-4/my-company/my-project/pacts /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.34.0/lib/pact_broker/client/pact_file.rb:32:in `read', attempt 1 of 3
Error making request - Errno::ENOENT No such file or directory @ rb_sysopen - /var/lib/buildkite-agent/builds/buildkite-deployers-general-management-i-00437c6a99af63bdf-4/my-company/my-project/pacts /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.34.0/lib/pact_broker/client/pact_file.rb:32:in `read', attempt 2 of 3
Error making request - Errno::ENOENT No such file or directory @ rb_sysopen - /var/lib/buildkite-agent/builds/buildkite-deployers-general-management-i-00437c6a99af63bdf-4/my-company/my-project/pacts /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.34.0/lib/pact_broker/client/pact_file.rb:32:in `read', attempt 3 of 3
Failed to tag version due to error: Errno::ENOENT - No such file or directory @ rb_sysopen - /var/lib/buildkite-agent/builds/buildkite-deployers-general-management-i-00437c6a99af63bdf-4/my-company/my-project/pacts```
bethskurrie
2020-11-27 05:51
It looks fine to me. I usually see that error `Errno::ENOENT No such file or directory @ rb_sysopen` when there is something slightly wrong with the publish command, and it has a problem parsing the command and things that one of the strings you've passed in is a directory or file.
bethskurrie
2020-11-27 05:52
Do an "ls" on the pacts directory before you run the command, to make sure the files are actually where you think they are
bethskurrie
2020-11-27 05:53
and put a +x on the script so you can see exactly what the final command is
bethskurrie
2020-11-27 09:13
You can get an idea of the system requirements from the Pactflow on-prem requirements though
guppy0356.nakira
2020-11-27 09:17
`pact-broker-docker` is for local development, isn't it? It is not for Task Definition in AWS.
guppy0356.nakira
2020-11-27 09:19
Your organization have pact-broker and pact-broker-docker, don't you? It seems pact-broker-docker is for AWS template.
bethskurrie
2020-11-27 09:19
Which organisation in which platform has what named pact-broker and pact-broker-docker?
bethskurrie
2020-11-27 09:20
Run this image on AWS https://hub.docker.com/r/pactfoundation/pact-broker
guppy0356.nakira
2020-11-28 11:36
Anonymous user can delete contract in Broker. Is my understanding correct?
bethskurrie
2020-11-28 19:26
That should not be possible if you have correctly configured the basic auth @guppy0356.nakira
bethskurrie
2020-11-28 19:27
Can you please share the environment variables you have used to configure your broker.
guppy0356.nakira
2020-11-30 00:21
I don't know if I can express it well. I don't configure environment variables. I restrict access to broker by using security group. So, anyone who can access it can delete contract.
guppy0356.nakira
2020-11-30 00:28
What I mean is broker don't have user permissions. All users can read / update / delete contract. Is it correct?@bethskurrie
aliaksandr.valadzko
2020-11-30 15:50
Hey guys
I have a question regarding PACT _federation_ or something like this
In our company we have huge amount of teams, which develop their own bunch of microservices.
At this point we add PACT testing within our team's microservices.
However we also want to provide to other teams (our consumers) ability to send PACT contracts to our broker.
So my question is, how this situation should be handled - does every team should have its own PACT broker service, or there should be one _Godlike_ PACT broker service which should be shared across teams, or there is some mechanism to connect PACT broker services?
Thanks!
phil.endsley
2020-11-30 15:58
Are you using OSS broker, or Pactflow?
If it's all within the same organization, I would recommend a single broker. I think this makes things way easier. But you could have valid reasons for wanting separate instances. What are your reservations (if any) for having only a single instance?
phil.endsley
2020-11-30 16:04
We have the same sort of setup you're describing.
? Single OSS broker deployed in our cloud environment
? Every team within our org publishes to the same instance
Most of the time, pacts are used within the same products, but occasionally, we integrate between other divisions/business units/whatever you want to call them. We haven't had any issues so far
aliaksandr.valadzko
2020-11-30 16:10
Thanks a lot, Phil!
Quick follow up question:
Do you know, is there a chance to _merge several_ PACT broker services (if we'll face this situation in future) ?
Assume this could be done in BD layer, correct?
phil.endsley
2020-11-30 16:13
No idea, sorry :slightly_smiling_face:
Will have to wait for @bethskurrie or someone else to weigh in on that
aliaksandr.valadzko
2020-11-30 16:15
Fair enough:joy:
Just a hypothetical question, if at one day we'll understand that some other team in company has its own PACT broker and we'll decide to move contracts to some common place
Thanks
bethskurrie
2020-11-30 22:43
@aliaksandr.valadzko I'm not sure how you'd do a db merge at the db level because the ids would all conflict. It wouldn't be too hard to iterate over the important data via the API and copy it over though.
bethskurrie
2020-11-30 22:44
The OSS broker doesn't have any mechanism for grouping people or applications, however, we've just recently added team support to Pactflow, and it is available as an on premise application now
bethskurrie
2020-11-30 22:44
Here's a description of the teams+roles+permissions feature https://pactflow.io/blog/teams-roles-and-permissions/
bethskurrie
2020-11-30 22:46
If you have configured your own authentication, then you are responsible for also configuring who can delete.
bethskurrie
2020-11-30 22:47
If you use the basic auth users provided in the docker application, there is a read/write user (they can delete) and a read only user (they can't delete).
bethskurrie
2020-11-30 22:48
In Pactflow, there are roles/teams/permissions however https://pactflow.io/blog/teams-roles-and-permissions/
guppy0356.nakira
2020-12-01 00:33
@bethskurrie
Thank you for your respond :smile:
> If you use the basic auth users provided in the docker application, there is a read/write user (they can delete) and a read only user (they can't delete).
Umm, what is `users provided in the docker application` ? :thinking_face:
guppy0356.nakira
2020-12-01 00:39
Wow :astonished: Should `PACT_BROKER_BASIC_AUTH_USERNAME`
and `PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME` have different names?
guppy0356.nakira
2020-12-01 00:48
```Pact.service_provider "My Service Provider" do
honours_pacts_from_pact_broker do
pact_broker_base_url 'http://...', {username: ENV['USER'], password: ENV['PASSWD'], token: '...'}
end
end```
For example `USER` equals `PACT_BROKER_BASIC_AUTH_USERNAME` in local development and `USER` equals `PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME` ?
bethskurrie
2020-12-01 00:49
PACT_BROKER_BASIC_AUTH_USERNAME="pact-broker-ci"
PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME="pact-broker-dev"
Those are options
bethskurrie
2020-12-01 00:50
You give the read only credentials to developers, and use the read/write credentials for CI.
guppy0356.nakira
2020-12-01 06:18
When `ENV["GIT_BRANCH"]` is blank, is target consumer version `'main'` ?
```Pact.service_provider "Your provider" do
honours_pacts_from_pact_broker do
pact_broker_base_url "..."
consumer_version_selectors [
{ tag: ENV["GIT_BRANCH"], fallback_tag: "main", latest: true }
]
end
end```
guppy0356.nakira
2020-12-01 06:20
I got erros :cry:
```{"errors":{"consumerVersionSelectors":["tag can't be blank at index 0"]}} (Pact::Hal::ErrorResponseReturned)```
bethskurrie
2020-12-01 20:02
The fallback tag is for when there is no pact for the given tag, not for when you've made a mistake in the configuration.
bethskurrie
2020-12-02 00:15
@mateusz.derks that's great to hear. I'll enable this without the feature flag now.
guppy0356.nakira
2020-12-02 03:40
I think `main` branch doesn't exist. @bethskurrie
BTW, following code is have same?
```Pact.service_provider "Your provider" do
honours_pacts_from_pact_broker do
pact_broker_base_url "..."
consumer_version_selectors [
{ tag: ENV["GIT_BRANCH"] || 'master', latest: true }
]
end
end```
mateusz.derks
2020-12-02 07:50
@bethskurrie amazing, can?t wait to see WIP tags fully working on our side :crossed_fingers:
@matt.fellows I don?t want to think how much time you guys spent on answering my questions :smile: I appreciate all your support
kjayachandra2000
2020-12-02 14:15
Hi All, I am using the docker compose file to start the pact broker, how can i configure pactBrokerToken?
stefanos.varsanis
2020-12-02 14:52
Hello, I have noticed the below behaviour in the `pending pacts` , please verify if this is the intended hehaviour.
? When a pact with provider tag `example` is verified by the provider then: the next time the provider test runs the pact will not be pending.
? If the provider tag `example` however is deleted , re-assigned and the tests are executed then the pact is still in pending state (even if actually is the same pact with the same content and provider tag).
Should this be the case? Thanks
bethskurrie
2020-12-02 23:13
Are you using wip pacts, was it verified as a wip pact or was it explicit in the selectors and are you on the very latest version of the broker? @stefanos.varsanis
bethskurrie
2020-12-02 23:16
Or use the fluent api and docker image described here https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
bethskurrie
2020-12-02 23:18
The first example checks on the server side if a pact with the given tag exists.
guppy0356.nakira
2020-12-03 00:27
@bethskurrie
> The first example checks on the server side if a pact with the given tag exists.
What does `the server` mean? It means Pact Broker?
stefanos.varsanis
2020-12-03 10:10
Hi @bethskurrie I was meant to use the Pending Pacts functionality which my broker is updated to use, not sure if accidently I am using the WIP.
Let me describe the flow I am doing.
1. For a given pact: On a feature branch I execute the tests and push the verifications (this is in pending state, the build doesn't fail but the results are published)
2. I tag the provider with the branch name ( I do this to target the pact with the can-i-deploy)
3. I ask can-i-deploy to check if everything is ok in order to merge to master (As far as I understand I can also use the provider version instead of the tag from step 2)
4. I delete the feature branch tag from the provider
5. Once merged on master I do the same: execute the tests and publish the results (at this point it is still pending for master but the results are published)
6. I tag the provider pact with master and execute can-i-deploy (again I could use the provider version rather the tag (?) - using docker command `broker create-version-tag --pacticipant providerServiceName --version ${bamboo.maven.version} --tag ${bamboo.repository.git.branch} -b BROKER_URL` )
7. Execute the can-I-deploy `broker can-i-deploy --pacticipant providerServiceName --version ${bamboo.maven.version} -b BROKER_URL`
8. Delete the tag `master` from the provider pact
9. Now every time I run the master again with the above flow it is re-tagged and the test is in pending state.
10. If I do not delete the pact in the final step(8) the next time I execute the tests they are considered normal tests and not pending.
Of course I am only *testing out various workflows* so if you have anything to suggest please provide me with your insights. Thanks in advance
sandragnzalez
2020-12-03 11:09
Hi All, I'd like to drop the Pact file in a remote machine, how should I configure PactDir property in c# ?
kristian
2020-12-03 15:42
Hello. I'm all new to Pact and CDC and trying to get my head around it. Are there times when a pact broker would be overkill? For example if you have your consumer and provider services in a mono repo wouldn't it be easier just to have your pacts in a folder in your git repository that both services have access to?
elliottmurray
2020-12-03 17:14
So YMMV but certainly with a mono repo you can do this. I'd say to start with this is feasible but as you look at more sophisticated CI/CD work flows and you grow more comfortable around Pact you'll probably see the need yourself for something like Pact Broker.
antonello
2020-12-03 17:16
provided that consumer and provider are deployed at the same time, then you?re right - using the broker might be a bit of an overkill
phil.endsley
2020-12-03 19:16
I have a webhook question. It seems like a common use case is to configure a webhook for `contract_content_changed` to kick off provider verification. This way, pacts are verified as soon as they're published.
But, if we create a new feature branch, it's still fired even if we aren't changing the pact. This is because the tag changes, and is working as intended (right?). For cases where the pact doesn't change, the pact is already pre-verified. The web hook is still triggered. Which makes sense when using web hooks for non build triggering actions.
Is there a way to get the webhook fired only if a pact needs to be verified? This way, builds/verifications only run if they need to? I realize we can use can-i-deploy before running it to check if we need to run verifications, but this seems like something that would be so common it should be a first class feature. Or am I missing another way to do this?
phil.endsley
2020-12-03 19:38
> However, when you merge your feature branch into `master`, the webhook won't be triggered because the content of the pact won't have changed. This is not ideal because it would prevent you from triggering a verification against the provider's `master` branch.
If the content didn't change, it would inherit it's verification status.
If the content did change, it would trigger the webhook.
If the provider changed, it would have ran verification against your main branch and prod (Not the feature branch). Maybe this is where the potential issue would be?
phil.endsley
2020-12-03 19:40
The pact content doesn't change, but the provider did. The provider will run verification against main and prod (Not the feature branch).
The provider changes in a way that would cause the feature pact to fail. Since the content doesn't change when merging the feature branch, it doesn't trigger the webhook
phil.endsley
2020-12-03 19:47
So in this case, even can-i-deploy wouldn't work? I've confused myself, as I usually do when trying to think out pact flows :sweat_smile:
phil.endsley
2020-12-03 19:49
Wait...it wouldn't be pre-verified if the provider changed, right? Because the provider version would be different
antonello
2020-12-03 19:52
Exactly - if the provider changes after the feature branch webhook was triggered but before the feature branch is merged, without the behaviour I implemented, you will end up with a consumer that you can?t deploy. Right?
phil.endsley
2020-12-03 19:54
My suggestion would be to not fire it if the contract is pre-verified. As long as it's pre-verified, there's no need to run builds, right? If it's not pre-verified, fire the web hook
antonello
2020-12-03 19:57
If we stick to the provider master branch for simplicity, You?re saying that the webhook logic would have to check what if the latest master provider has verified that pact content already.
antonello
2020-12-03 20:00
I can?t remember now - does the webhook have any awareness of which provider branch is triggering?
phil.endsley
2020-12-03 20:03
Either way, I'm not sure. Our webhooks trigger regular builds. We're just getting to the point of refining them, which prompted the question
antonello
2020-12-03 20:04
In order to
> If we stick to the provider master branch for simplicity, You?re saying that the webhook logic would have to check what if the latest master provider has verified that pact content already
You?d need to know the provider branch
antonello
2020-12-03 20:31
If you think about it, what we do would be the equivalent of triggering webhooks every single time, regardless of whether the pact has changed, and then call can-I-deploy to see if the provider needs running
phil.endsley
2020-12-03 20:32
Do your webhooks trigger builds, or middleware? Is the can-i-deploy part of your actual build pipeline, or do you make that determination in middleware, then trigger the build?
antonello
2020-12-03 20:35
We have two different approaches, depending on whether the consumer builds on jenkins or gitlab ci, but in principal is the same.
antonello
2020-12-03 20:36
in gitlab ci we use so-called multi-project pipelines, a mechanism for an upstream project to trigger a build of a downstream project.
antonello
2020-12-03 20:37
when a downstream (provider) pipeline is triggered, it only runs a specific job that runs the provider tests
antonello
2020-12-03 20:38
and we trigger two downstream jobs for each consumer/provider, one for the main tag and one for the prod tag
antonello
2020-12-03 20:40
there is no middleware - all providers have a script that invokes can-i-deploy before running the tests. if can-i-deploy passes, no tests are run.
antonello
2020-12-03 20:46
@bethskurrie and @matt.fellows have written this
https://github.com/pactflow/example-consumer-webhookless
antonello
2020-12-03 20:55
This shows a simplification of what would happen in the case of a feature branch of a consumer called `marketplace-api` and a provider called `review` when the pact is already pre-verified
bethskurrie
2020-12-03 21:13
There is a reason why the "and new tag applied" triggers the webhook but I have to get my head back around it again. Here are the notes past beth took for future beth https://www.evernote.com/l/AGEAreq5cm5HErJ-SNzn0sRxwQS0xH60JBA
bethskurrie
2020-12-03 21:14
One potential way we could improve this is to split out the existing contract_content_changed into two events `contract_content_changed` and `new_tag_applied` .
bethskurrie
2020-12-03 21:15
I've been hesitant to do this because while it's not a "breaking" change, it would change the behaviour for people who already have scripts that set up this webhook.
antonello
2020-12-03 21:17
It?s hilarious that we?re on the same boat when it comes to trying to remember exactly why it was the right thing to do!
bethskurrie
2020-12-03 21:44
I remember recently saying "thank you past beth for making the 'and new tag' thing trigger a build" for some reason related to WIP/pending pacts.
bethskurrie
2020-12-03 21:45
It was something to do with what happens when you merge multiple feature branches with pact changes back into master.
bethskurrie
2020-12-03 21:47
Well, "thank you past beth for letting Anto put that feature in" anyway :stuck_out_tongue:
phil.endsley
2020-12-03 22:39
yeah, I keep looking for an answer, but I think the issue is, for what I want, you have to know the provider tag you care about (Like Anto said). Since you can't determine that in isolation, I think we're just stuck with running can-i-deploy to short circuit.
I think...it's been a long day...brain is fried...I'm done thinking :slightly_smiling_face:
antonello
2020-12-03 23:11
Could the webhook not take an optional provider tag as a parameter so that it can check for pre-verification?
phil.endsley
2020-12-05 21:46
Ok, I know I've read about using `can-i-deploy` as a merge check for feature branches. We aren't doing this yet, but I'm at the point of looking into it now, but I can't find anything written about it. Tried reasoning through it without docs, but I can't work it out. Was going to read though, and come back with any remaining questions I had
bethskurrie
2020-12-06 22:38
If you think of can-i-deploy as asking the question "is there a pact with a successful verification between [these] versions of [these] applications" then it might make more intuitive sense @phil.endsley
bethskurrie
2020-12-06 22:38
Before you merge you want to ask "is there a pact with a successful verification between the head of my consumer branch and the main branch of the provider?"
bethskurrie
2020-12-06 23:58
Or, whatever branch of the provider is in the environment you care about. It's actually no different to can-i-deploy from the master branch.
phil.endsley
2020-12-07 00:25
Hmm...that makes sense. I think that will work for us. We would have issues if we have multiple providers with different main branch names (ex: develop and main). That's not the case now though, so I think we'll be fine
bethskurrie
2020-12-07 00:26
because theres no point merging if the provider code is in master but not deployed
phil.endsley
2020-12-07 00:27
Env for dev or prod? In dev, teams are often deploying feature branches. But maybe it still holds true of just checking what's currently there...
bethskurrie
2020-12-07 00:28
if you want to be prevented from merging until the feature is in dev, use dev, and if you want to be allowed to merge, but not deploy, then use "main" or whatever the main branch name is.
bethskurrie
2020-12-07 00:29
as you say though, you'd need to use the full form of the can-i-deploy to specify the different names of the provider's branches if they are different.
bethskurrie
2020-12-07 00:30
or, add a tag name that everyone can agree on for their main line, and you can use two tags.
bethskurrie
2020-12-07 00:35
if you set up your webhooks right, you can make the publishing of the verification results kick off a build of the consumer branch again so that can-i-deploy goes green automatically.
robert.strehli
2020-12-07 13:31
Hi, I have a question. Is there a way to look at older pact revisions on the pact broker?
For understanding: I published a pact with version 1.0. Then I changed the pact on consumer side (just changed the response status from 200 to 204) and published it again but I didn't changed the version of the consumer so it's still 1.0.
Can I somehow view the pact where the response status is still 200? If I click on the older revision in the matrix I always get the latest version.
antonello
2020-12-07 17:55
If you?ve published the pact with the same version (1.0), I believe it would be overwritten.
bethskurrie
2020-12-07 23:24
@robert.strehli you aren't supposed to overwrite with the same consumer version, but yes, you can see it if you want to.
bethskurrie
2020-12-07 23:26
Actually, I've just checked the routes, and I haven't exposed it. If you modify an existing pact for a consumer version it make a revision in the database, so the original one is still there. But I haven't made a route that allows you to see the /revision/1 yet.
bethskurrie
2020-12-07 23:27
You really have to bump the consumer version each time or you'll run into trouble.
bethskurrie
2020-12-07 23:27
Have a read of this https://docs.pact.io/getting_started/versioning_in_the_pact_broker
guppy0356.nakira
2020-12-08 07:22
Hi, I have some questions about system requirements. In this page (https://docs.pactflow.io/docs/on-premises/system-requirements/#postgres-database-instance), the storage of postgres database instance is 5 GiB. The minimum storage is 100 GiB in my aws console. I confused which parameter is 5 GiB :thinking_face:
matt.fellows
2020-12-08 07:25
This may come as a suprise to you, but not everyone runs in AWS :rolling_on_the_floor_laughing:
matt.fellows
2020-12-08 07:28
Also note that those instructions are for our enterprise on premise appliance and not the OSS broker (albeit the infra requirements are going to basically be the same so you can definitely use it as a guide)
matt.fellows
2020-12-08 07:30
Check your storage volume options. GP2 without dedicated iops should allow 5gb
robert.strehli
2020-12-09 08:03
Thank you for your answer. I'm currently in a try out phase so I didn't really mind the versioning part, but that's now a good learning. :thumbsup:
jarmy
2020-12-11 00:56
@bethskurrie I've deployed a new version of the pact-broker with puma running ssl. The tagging issue with forward slashes is fixed.
ukrainian1991
2020-12-14 16:43
Hi, Is it possible to remove verification result from pact broker? I have published with a wrong provider version
matt.fellows
2020-12-14 23:19
Off the top of my head I?m not sure. But try issuing a DELETE to the resource and see what happens
mateusz.derks
2020-12-15 05:46
Hey, is this feature under some additional research before going live? It?s still hidden behind a feature flag from what I see https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/pacts/metadata.rb#L36
dattasai.chunduru
2020-12-15 16:26
Hi Team When we are trying to publish Pact files to PactBroker we are getting error as below, can you please help on this
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
kjayachandra2000
2020-12-15 16:45
```pact {
publish {
pactDirectory = "$buildDir/pacts"
pactBrokerUrl = 'http://localhost:80'
tags = ["dev", "test", "prod"]
}
}```
i am using this config to publish and it's working fine for me
`./gradlew clean pactPublish`
bethskurrie
2020-12-15 22:37
@kjayachandra2000 this is a client side JVM/configuration issue. Best to ask in #pact-jvm
bethskurrie
2020-12-15 22:38
It's strange that it's looking for a certificate given you're not running your broker on SSL though.
suruchipatidar14
2020-12-16 05:42
Hello,
I am using pact-jvm to do contract testing. Pact broker is not installed in my system.
Could you guide me how I can generate pact broker URL to create and update pacts ?
suruchipatidar14
2020-12-16 05:45
I have read docs on dockerized pact broker and pact broker cli but got confused
bethskurrie
2020-12-16 05:46
I would recommend signing up for a free Pactflow account then. https://pactflow.io/
bethskurrie
2020-12-16 05:47
This is the only option that doesn't use Docker or require you to manually install and run a Ruby application on your own hardware.
bethskurrie
2020-12-16 05:48
I think it would be worth reading this as well:
https://docs.pact.io/faq#what-is-the-difference-between-pact-the-pact-broker-and-pactflow
suruchipatidar14
2020-12-16 05:51
I am using aws sandbox in my project. Can I create pact broker url based on sandbox url ?
bethskurrie
2020-12-16 05:51
There needs to be an actual Pact Broker running application for you to have a Pact Broker URL.
suruchipatidar14
2020-12-16 05:53
Okay. If running Pact broker is present in other platform, then what details of pact broker will be required in my project use it ?
bethskurrie
2020-12-16 05:53
These are the docs for the Pactflow on-premises application. You would need something similar for the OSS Docker image.
bethskurrie
2020-12-16 05:55
> hen what details of pact broker will be required in my project use it
You will need the base url (eg. https://my-broker.my-org.com) and the username/password (if they're configured in the docker container).
yann.courtel
2020-12-16 13:49
Hi Valadzko. We are in the same situation. We have a single broker for the whole organization. And an extra for sandboxing. Migration shouldn't be an issue, as soon as you switch to the single broker your pacts should be published seamlessly at build time. You will lose your history though.
kflo
2020-12-16 22:55
i guess this configuration is to allow provider builds that are based on pending contracts to pass, while still marking them as failed in the broker (so consumers won?t use them until they are not pending)?
bethskurrie
2020-12-16 23:01
The pending status only affects the provider builds. To the consumer, it's still just a fail.
kflo
2020-12-16 23:02
you?ve probably answered this a billion times, sorry :stuck_out_tongue: just trying to make sure my config is setup correctly
bethskurrie
2020-12-16 23:03
> While the provider build may pass, the verification results are still reported (if results publishing is enabled) to the Pact Broker as "failed", as the consumer should not be able to deploy the code that generated this contract.
bethskurrie
2020-12-16 23:03
If there's anything that is unclear after reading that page thoroughly, let me know, so I can add or clarify it.
kflo
2020-12-16 23:05
i think the feature makes sense. what i was confused by is that it seems i can provide an empty list of provider tags, which i guess makes sense if i?m not using tags at all? but if i am using tags, it seems like i would want to, in my CI system, probably pass the same tags that i?m filtering the latest consumer pacts on (e.g. `master`/`production`), and if i?m doing a local verification against a branch, for example, i would instead pass that as the tag (e.g. `feat-x`)
bethskurrie
2020-12-16 23:07
Unless you've checked out the production version of the provider, and you're using that particular revision to do a verification.
bethskurrie
2020-12-16 23:08
> The Golden Rule for tagging is:
> Tag with the branch name when you publish pacts or verification results, and tag with the environment name when you deploy.
kflo
2020-12-16 23:12
we use a monorepo so i will need to come up with a non branch based strategy for using the same tag
bethskurrie
2020-12-16 23:13
you don't need to overthink this - just tag with the branch name every time you publish.
kflo
2020-12-16 23:13
> A common pattern to use when adding new features is for the provider to make a branch with the same name as the consumer?s branch (which is used to create the consumer version tag), and to configure a selector that uses the name of the current provider branch
bethskurrie
2020-12-16 23:15
Are you making one branch in the mono-repo for the consumer, and another branch to implement in the provider?
kflo
2020-12-16 23:16
that would be our normal development cycle, but maybe we don?t need to do it that way anymore
bethskurrie
2020-12-16 23:16
There has been a request to use a regular expression for the tag in the consumer version selector
bethskurrie
2020-12-16 23:17
the usual order of dev goes:
consumer branches,
updates the pact
publishes,
provider branches,
implements the pact,
provider merges,
consumer merges.
bethskurrie
2020-12-16 23:20
you might just need to manually set the consumer tag to verify when you branch the provider. that's common too.
kflo
2020-12-16 23:20
i was cruising along until i saw the provider tag versions and then i got confused haha. i think i?ll need to think on this for a bit
bethskurrie
2020-12-16 23:20
some people keep a file that has the mapping of consumer/provider feature branches.
kflo
2020-12-16 23:26
just one thing to clarify, you said the provider/consumer tags don?t have to match, but i thought that?s how the broker knows when to change the ?pending? status (e.g. consumer publishes with tag `feat-x`, provider verifies with tag `feat-x`)?
bethskurrie
2020-12-16 23:27
it looks at the pact content that has been selected, and says, "is there a successful verification from a version of the provider with the supplied provider version tag?"
kflo
2020-12-16 23:28
ohh, so it?s just there to see if it has verified a provider with that tag before against those specific pacts?
bethskurrie
2020-12-16 23:29
so the consumer tags are there for you to select the right pacts, and the provider version tags are there to work out whether the *content* for each pact is pending
bethskurrie
2020-12-16 23:30
the matching thing is just a convenient way of selecting the right pact without having to change your provider configuration.
guppy0356.nakira
2020-12-17 10:00
Hi, I need your help. My pact broker uses self signed SSL. I can't publish contract to broker. How to disable this verification?
guppy0356.nakira
2020-12-17 10:02
I use this :point_right: https://github.com/pact-foundation/pact_broker-client
bethskurrie
2020-12-17 10:02
There's an example of how to do it here https://github.com/DiUS/pact_broker-docker/blob/master/docker-compose.yml#L43
bethskurrie
2020-12-17 10:05
You just need the self signed certiciate in PEM format, and set the environment variable `SSL_CERT_FILE=<path to your ceritificate>`
brendan.donegan
2020-12-17 10:06
@guppy0356.nakira you need to get the certificate and pass it as @bethskurriementioned
bethskurrie
2020-12-17 10:07
Here's a handy stackoverflow https://superuser.com/questions/1291416/download-pem-via-browser-only/1292098
bethskurrie
2020-12-17 10:08
Someone will probably have a copy of the certificate as a PEM file hanging around though.
matt.fellows
2020-12-17 10:47
With let's encrypt there is just no good reason these days. I think you use AWS as well, so you have ACM
patrick.hendron
2020-12-17 16:56
I might be asking this is the wrong place, but is it possible to publish a contract to a S3 bucket using the PACT lib, if i provide the s3 url for the option `pactBroker:` ? or would I have to write custom code to send it to a s3 bucket (i am using node)
bethskurrie
2020-12-17 19:26
guppy0356.nakira
2020-12-18 07:44
What is the purpose for `--consumer` and `--provider` on `create-or-update-webhook` ?
nouri.tawfik
2020-12-18 08:28
https://docs.pact.io/pact_broker/webhooks/
"Webhooks allow you to trigger an HTTP request when a pact is changed, a pact is published, or a verification is published"
For each contrat we have a consumer and provider....
guppy0356.nakira
2020-12-18 09:28
@nouri.tawfik Thank you for your respond. Should I have to add both options?
matt.fellows
2020-12-18 09:43
If you select none, it will fire for all events. If you select a provider, it just fires for events related to that provider and so on
yann.courtel
2020-12-18 13:59
Hi guys, this might be a redundant question but do you know what's the best version of the pact broker we can use ? between
https://hub.docker.com/r/dius/pact-broker and https://hub.docker.com/r/pactfoundation/pact-broker ? Thanks a lot
matt.fellows
2020-12-18 21:23
You probably want to Use the pactfoundation one if you can in most cases. It's a smaller image (alpine) and is close to what we run at Pactflow
matt.fellows
2020-12-18 21:24
I think the docs for the first one explains when you might want one over the other
yann.courtel
2020-12-21 08:16
Hey Matt. I see the difference now. Unfortunately we have a dius installed. I'll see to install the pact-foundation one at least on our sandboxing server and go from there. Thanks a lot!
matt.fellows
2020-12-21 09:46
The main reasons you would migrate IMO
1. You can't run with root privileges
2. You're having issues with the existing image
3. There is some policy about containers using alpine
Otherwise :man-shrugging:
matt.fellows
2020-12-21 09:47
For most the change should be simple. When we switched at Pactflow, it was a lot more work to switch because of scale and monitoring etc
matt.fellows
2020-12-21 09:48
We monitored a lot of the processes and used them as scaling properties. I would guess most have fairly simple setups so it could be a couple of hours work :thinking_face:
writetojoshma
2020-12-22 05:41
Hey anyone know how to make my pactflow broker hit my graphql which is up on a localhost server
matt.fellows
2020-12-22 05:47
Just so we?re clear, Pactflow does not talk to your APIs. It is simply a way to exchange pact files
matt.fellows
2020-12-22 05:47
think of it like Git - it is a way to stores, versions, tag etc. for your code
matt.fellows
2020-12-22 05:48
Pact is the tool that talks to your services, and runs from your local machine to another process (usually also on your same machine)
matt.fellows
2020-12-22 05:49
> i was getting connection refused error by broker
That almost certainly means one of a few things:
1. The provider API is not up
2. The configuration is incorrect, and Pact is trying to talk to a process on another port
3. There is a timing issue and the tests are firing before the provider itself is up
matt.fellows
2020-12-22 05:49
I think you use Pact JS, so probably best to share code examples with evidence on how it?s not working as expected, what you?ve done to investigate etc.
writetojoshma
2020-12-23 05:10
i want pact to hit the localhost server . Do you know if its possible ?
matt.fellows
2020-12-23 05:11
of course, that is how it is supposed to be used :slightly_smiling_face:
writetojoshma
2020-12-23 05:12
Okay , what if I have to run a command to make the localhost up from my local cmd
matt.fellows
2020-12-23 05:13
however you want to start the provider is up to you. Whether before you run the tests, or via the test runner itself
matt.fellows
2020-12-23 05:14
If you?re getting connection refused by the pact test, that means you?re not pointing at a running provider
matt.fellows
2020-12-23 05:14
it doesn?t matter where the provider is running - as long as it is reachable
writetojoshma
2020-12-23 05:30
Same url when I keep it my providerurl in the provider-spec.js and run the provider test
writetojoshma
2020-12-23 05:31
No connection could be made because the target machine actively refused it
writetojoshma
2020-12-23 05:31
But if use any public api as provider url ....full flow is working fine
writetojoshma
2020-12-23 05:43
If a pact breaks , the jenkin job should be RED , Any examples for that
writetojoshma
2020-12-23 05:53
Can you please comment about the CI CD integration I asked for in the other chat box
writetojoshma
2020-12-23 07:18
What is the role of consumer.js file for consumer.spec.js file in graphql testing
jks
2020-12-29 22:45
Hello, I have a question concerning best way to organize consumer and provider tests to support CI/CD on PactBroker.
My Pact Consumer Test file produces 3 pacts. My Pact Provider Test file verifies these 3 pacts. This worked fine when I was running pactPublish and pactVerifyProvider independently from the command line. However, I started working with webhooks and CI/CD to follow the https://docs.pact.io/pact_broker/webhooks#example-cicd-and-webhook-configuration.
Now do I create a ?contract_published? event on each of the 3 pacts to notify the Provider build/test, and similarly create a ?provider_verification_succeeded? event on each of the 3 pacts to notify the Consumer to deploy?
I guess what I?m getting at is that it seems you?d want the ability to have multiple pacts in one project, but it?s not obvious what happens when multiple pacts are published from the same project or similarly multiple pacts that originated from the same project are verified. It?s entirely possible I?m overlooking something.
matt.fellows
2020-12-30 01:02
Why does your consumer publish 3 pacts? Usually each consumer has a single contract (even if it has multiple interactions) with one or more providers
matt.fellows
2020-12-30 01:03
It's unusual to have more than one contract between a single consumer and provider
matt.fellows
2020-12-30 01:03
I.e. one contract should capture all of the interactions of the integration point from the perspective of the consumer
jks
2020-12-30 02:56
I didn?t write the consumer, so I?m not sure exactly why it was written this way. It?s one consumer but three different providers, hence three pacts.
Say you have a consumer that interacts with different providers; seems logical. I could break apart the test code into different files, but I?d still have the same issue. From a build/test/deploy perspective I need to organize the build script to handle publishing each independently. Pretty sure I can do this, but wasn?t thinking along these lines earlier. Thanks.
matt.fellows
2020-12-30 03:08
Why do they need to be published independently? Or rather, could you please elaborate? You should be able to publish all in a single command using the CLI tools
matt.fellows
2020-12-30 03:09
Same for the can-i-deploy. It should automatically work out if the consumer is compatible with all of its stated providers in a single call
matt.fellows
2020-12-30 03:11
Ah, I think I was confused because you said the provider verifies all 3 contracts
matt.fellows
2020-12-30 03:13
Depends on how you trigger provider builds. I would create a single webhook for the provider (omitting the consumer name, so any consumer publishing/changing a pact for that provider will trigger the build)
jks
2020-12-30 15:57
I think my confusion lies in how to organize the interaction between the webhooks on the PactBroker and the build script in the CI/CD environment. I have multiple pacts for the one consumer project.
1. The consumer publishes the 3 pacts to broker
2. Broker notifies each provider via webhook to fetch and verify
3. Each provider verifies results and sends back to broker
4. Now each of the three pacts has a webhook on broker to notify consumer of results; therefore the consumer will be notified three separate times
So on step #4, how does the consumer CI/CD handle this? Seems it should only deploy if it gets three positive results. Or is it possible to group pacts for the same consumer to only notify via webhook if all providers verified pacts?
matt.fellows
2020-12-31 00:42
so personally, i don?t bother making my consumer CI aware of verification results from any providers ?inline? to my pipeline. I find it makes things harder to understand - I?d prefer to keep them independent (apart from the webhook to trigger the provider pact specific build). I run can-i-deploy and if I can?t deploy, the build fails. The verification results are used as feedback to my SCM tool (such as Github) to notify when it is ready to merge).
matt.fellows
2020-12-31 00:43
This workshop might be helpful also: https://docs.pactflow.io/docs/workshops/ci-cd
bethskurrie
2021-01-03 21:41
@yann.courtel if you deploy the passenger (DiUS) one in an autoscaling architecture, the Passenger scaling and process management logic can fight with the instance scaling and process management logic, so the official advice from the passenger vs puma people is to use the puma one. Having said that, we ran the Passenger one for ages for Pactflow, and we didn't notice any problems.
guppy0356.nakira
2021-01-05 09:48
@matt.fellows
I need your help again about `--consumer` and `--provider` . My application has two roles. One is consumer and other is provider. Is it possible run following command?
```pact-broker create-or-update-webhook .... --provider sampleapp --consumer sampleapp```
guppy0356.nakira
2021-01-05 14:31
Can I create webhooks like these? I select `--consumer` and `--provider` . These have same application name.
```pact-broker create-or-update-webhook \
"https://api.github.com" \
--request POST \
--uuid ee8fd2d6-9e42-410b-afef-069468fdca79 \
--consumer Foo \
--provider Foo```
```pact-broker create-or-update-webhook \
"https://api.gitlab.com" \
--request POST \
--uuid 452c5884-5e65-4993-9934-c406711d1e99 \
--consumer Foo \
--provider Foo```
guppy0356.nakira
2021-01-05 14:45
My application has two roles. One is consumer and other is provider for another application.
guppy0356.nakira
2021-01-05 14:47
My application has two roles. One is consumer and other is provider.
guppy0356.nakira
2021-01-05 14:48
I want to fire above webhooks on uploading pact as consumer and publish verification as provider.
jgfarias42
2021-01-05 14:51
[can-i-deploy]
I?m trying to run _can-i-deploy_ via Maven+Pact JVM for the first time in a few service I already have Pact, however I?m facing a weird issue.
My providers? version on the broker are tag as XYZ-SNAPSHOT, due to Maven?s behavior.
When I run
``` mvn pact:can-i-deploy -Dpacticipant='MyConsumer' -DpacticipantVersion="1.1.63" -DtoTag="devTag"```
I get that only one of my integrations have a problem, lacking the verification against the provider?s version 0.0.101
However, the first image shows that the contract was verified, against the version 0.0.101-SNAPSHOT
The second image shows another provider, also with XYZ-SNAPSHOT format, where the integration was verified, but the _can-i-deploy_ apparently accepted.
I can?t see a difference between these two integrations.
(Note: I?m posting here because the ?There is no verified pact between? message is part of the Broker, not Pact JVM. But I can move the quesiton to #pact-jvm)
brendan.donegan
2021-01-05 14:53
that?s fine, you can specify the event type as a command line argument. but you still shouldn?t have a contract between your application and itself, even though it does take the consumer role and the provider role
phil.endsley
2021-01-05 14:57
can-i-deploy is failing because there is not a verified contract between the given pacticipant (`MyConsumer`) and each other integration it has (The two providers) for the _*latest version*_ tagged with `devTag` .
The difference between the two providers in your screenshot, is 0.0.44 is the latest version of that provider tagged with `devTag`. 0.0.101 is not. This is shown in the UI by how the tag is displayed (Solid blue if it's the latest, grey if not).
When you use the `-toTag` property, it will only check against the latest tag. Since there's a missing verification for that provider, it fails
bethskurrie
2021-01-06 04:09
That webhook will never fire because there is no pact between Foo and itself.
bethskurrie
2021-01-06 04:10
You need to work out what event you want the webhook to fire for and that tells you which role to specify.
bethskurrie
2021-01-06 04:11
For a provider, you typically say "--provider Bar --contract-content-changed" when you want to trigger a pact verification build when any of the pacts change.
bethskurrie
2021-01-06 04:12
For a consumer you'd typically say "--consumer Foo --verification-..." to trigger something (maybe a deployment) when a verification result is published for that consumer.
guppy0356.nakira
2021-01-06 06:21
I want to fire event on publishing verification. I create a webhook like this "--consumer Foo --verification-...". When a provider developer create a bug, webhook will be fired and consumer's ci job will be failed. Sometimes this job failure on consumer is confusing. How to prevent this? Pending Pact is only for Provider?
guppy0356.nakira
2021-01-06 12:08
> How and why does it fail the consumer's CI job?
`can-i-deploy` is executed in consumer's CI job.
guppy0356.nakira
2021-01-06 12:22
Red circled webhook is for `can-i-deploy` , isn't it? I am worried about failed provider verification. This verification fires webhook which call consumer's CI job. This job will be failed.
jgfarias42
2021-01-06 13:30
Thanks, indeed there was some confusion because I?m still setting these tags manually.
I created a new release on the some code base and created the tag. Now it works.
bethskurrie
2021-01-06 22:42
What you could do is only trigger it when the verification is successful though.
brett
2021-01-06 23:01
Hey guys, I've got my PACT json file generated in my Angular project (karma + jasmine) and I can't seem to publish it to Pactflow as shown in the tutorial.
I get this error when I run npm run publish:
"Error making request - NoMethodError undefined method `[]' for nil:NilClass..."
Do I need to set up a separate/custom publish.js file? Here is what is in my package.json:
```"publish": "npx pact-broker publish pacts --consumer-app-version=1 --broker-base-url=[redacted] --broker-token=[redacted] --tag master"```
I've been searching for over an hour and can't seem to make progress. Any help is much appreciated, as I imagine I'm missing something quite simple. Thanks!
guppy0356.nakira
2021-01-07 01:13
If provider's feat branch always verifies the contract which is created by consumer's master branch. So, I don't want to overwrite CI job result.
bethskurrie
2021-01-07 01:14
ah, you only want the webhook to trigger deployment from the master results.
bethskurrie
2021-01-07 01:14
That's not supported yet, but you can pass through the tags from the version associated with the verification result, and you can do some logic inside the CI job.
bethskurrie
2021-01-07 01:16
and you only want to trigger a deployment of the consumer when the master provider passes, yes?
bethskurrie
2021-01-07 01:18
pass the provider version tags though in the body of the webhook request.
matt.fellows
2021-01-07 04:28
hmm, can you please add `--verbose` to see what is going on? I?m guessing a parameter hasn?t been given (by the looks of it, you?re not passing in the actual path(s) to the pact file)
bethskurrie
2021-01-07 04:50
can-i-deploy users, I'm adding the URLs of the verification results to the output of the can-i-deploy command.
bethskurrie
2021-01-07 04:51
This will allow you go straight to the relevant (failed) result from that output.
bethskurrie
2021-01-07 04:51
```pact-broker can-i-deploy --pacticipant MyProvider --latest
Computer says no ¯\_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
------------|-----------|------------|-----------|----------|--------
MyConsumer | 3 | MyProvider | 2 | true | 1
MyConsumer2 | 1 | MyProvider | 2 | false | 2
MyConsumer3 | 1 | MyProvider | 2 | false | 3
VERIFICATION RESULTS
--------------------
1. http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer/pact-version/00b1b6424125436c79369dddaf351313ba811aa8/verification-results/125 (success)
2. http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer2/pact-version/85ce3a114c9e247ec97f666ca9bb134380d466e8/verification-results/126 (failure)
3. http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer3/pact-version/347d0bdb0888d46b4bdf84009a17f23fc9193165/verification-results/127 (failure)
The verification between the latest version of MyConsumer2 (1) and the latest version of MyProvider (2) failed
The verification between the latest version of MyConsumer3 (1) and the latest version of MyProvider (2) failed```
bethskurrie
2021-01-07 04:52
I'm trying to work out how to make it clear which result belongs to which row. Is that clear enough?
bethskurrie
2021-01-07 04:54
Or maybe:
```CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT REF
------------|-----------|------------|-----------|----------|-----------
MyConsumer | 3 | MyProvider | 2 | true | #1
MyConsumer2 | 1 | MyProvider | 2 | false | #2
MyConsumer3 | 1 | MyProvider | 2 | false | #3
VERIFICATION RESULTS
--------------------
#1 http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer/pact-version/00b1b6424125436c79369dddaf351313ba811aa8/verification-results/125 (success)
#2 http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer2/pact-version/85ce3a114c9e247ec97f666ca9bb134380d466e8/verification-results/126 (failure)
#3 http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer3/pact-version/347d0bdb0888d46b4bdf84009a17f23fc9193165/verification-results/127 (failure)```
bethskurrie
2021-01-07 04:55
```CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT REF
------------|-----------|------------|-----------|----------|-----------
MyConsumer | 3 | MyProvider | 2 | true | (1)
MyConsumer2 | 1 | MyProvider | 2 | false | (2)
MyConsumer3 | 1 | MyProvider | 2 | false | (3)
VERIFICATION RESULTS
--------------------
(1) http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer/pact-version/00b1b6424125436c79369dddaf351313ba811aa8/verification-results/125 (success)
(2) http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer2/pact-version/85ce3a114c9e247ec97f666ca9bb134380d466e8/verification-results/126 (failure)
(3) http://localhost:9292/pacts/provider/MyProvider/consumer/MyConsumer3/pact-version/347d0bdb0888d46b4bdf84009a17f23fc9193165/verification-results/127 (failure)```
brett
2021-01-07 06:29
Moshes-iMac:zayit moshe$ npm run publish --verbose
npm info it worked if it ends with ok
npm verb cli [
npm verb cli '/usr/local/bin/node',
npm verb cli '/usr/local/bin/npm',
npm verb cli 'run',
npm verb cli 'publish',
npm verb cli '--verbose'
npm verb cli ]
npm info using npm@6.14.8
npm info using node@v12.13.1
npm verb run-script [ 'prepublish', 'publish', 'postpublish' ]
npm info lifecycle zayit@0.0.0~prepublish: zayit@0.0.0
npm info lifecycle zayit@0.0.0~publish: zayit@0.0.0
> zayit@0.0.0 publish /Users/moshe/Downloads/Code/zayit
> npx pact-broker publish pacts --consumer-app-version=1 --broker-base-url=https://zayit.pactflow.ioredacted] --broker-token=[redacted] --tag master
Error making request - NoMethodError undefined method `[]' for nil:NilClass /Users/moshe/Downloads/Code/zayit/node_modules/@pact-foundation/pact-node/standalone/darwin-1.88.3/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_hash.rb:11:in `consumer_name', attempt 1 of 3
Error making request - NoMethodError undefined method `[]' for nil:NilClass /Users/moshe/Downloads/Code/zayit/node_modules/@pact-foundation/pact-node/standalone/darwin-1.88.3/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_hash.rb:11:in `consumer_name', attempt 2 of 3
Error making request - NoMethodError undefined method `[]' for nil:NilClass /Users/moshe/Downloads/Code/zayit/node_modules/@pact-foundation/pact-node/standalone/darwin-1.88.3/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.29.1/lib/pact_broker/client/pact_hash.rb:11:in `consumer_name', attempt 3 of 3
Failed to tag versions due to error: NoMethodError - undefined method `[]' for nil:NilClass
brett
2021-01-07 06:34
Thanks for the responses! I pasted more of the error output in a new thread not to flood the main chat. But this is the basic backtrace ...Error making request - NoMethodError undefined method `[]' for nil:NilClass ...pact_hash.rb:11:in `consumer_name'
brett
2021-01-07 06:39
@bethskurrie While I can see how options 2 and 3 try to provide additional clarity, I think your current / first option is the cleanest and easiest to look at / parse visually.
bethskurrie
2021-01-07 10:01
What is the content of the pact? It looks like there is no consumer key in the json.
matt.fellows
2021-01-07 10:44
It would be strange for the framework to generate a file with the name unless it was manually tampered with
brett
2021-01-07 11:08
I have a pacts folder in the root of my project with this file, which is the output of my pact tests.
brett
2021-01-07 11:09
I had a few other .json files in the directory, I just removed them and it works!
brett
2021-01-07 11:32
What's the best way to verify a consumer pact in Pactflow against a Swagger api spec file? I'm trying to use swagger-mock-validator, but auth seems to require username and password (wondering if there is an API token method), and this command gives me an error:
```swagger-mock-validator https://path/to/json/swagger.json https://domain.pactflow.io --provider backend --user USERNAME:PASSWORD```
"VError: Unable to read "https://domain.pactflow.io": Expected 200 but received 401"
Auth seems to be failing and I checked the username/password again and they are correct.
Any ideas?
matt.fellows
2021-01-07 13:19
Should be easy enough to add the feature, but in the meantime you could just pull down the contract via GET call and pass the local file
brett
2021-01-07 14:02
Thanks. How do I pass the local file?
I tried this:
```swagger-mock-validator https://path/swagger.json pacts/frontend-backend.json --provider backend```
But i get this error:
VError: Unable to read "pacts/frontend-backend.json": Invalid URI "pacts/frontend-backend.json"
brett
2021-01-07 14:02
where pacts/frontend-backend.json is the path to the consumer pact from my project directory.
brett
2021-01-09 17:42
I figured out the issue with passing the file, since I added the --provider flag it was expecting the url for my pactflow account, once removed I was able to run it against the local file.
brett
2021-01-09 17:42
How do I get it to update/show the results of the validation on http://pactflow.io?
matt.fellows
2021-01-09 22:08
Well at the moment you can't without manual intervention. You'd need to manually publish verification results
matt.fellows
2021-01-09 22:08
We are working on a Pactflow specific integration for a similar thing so stay tuned there
kflo
2021-01-11 20:05
i am struggling to find where the ?publish verification results? is in the pact broker API, can someone help me out? https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/api.rb
kflo
2021-01-11 20:05
trying to see what the payload for publishing verification results back to the broker looks like
bethskurrie
2021-01-11 20:06
This link is broken, I'll fix it https://docs.pact.io/pact_broker/advanced_topics/publish_verification_result
kflo
2021-01-11 20:06
really what i am trying to figure out is if this endpoint adds tags to the verification results, or if i should be doing that somewhere else
bethskurrie
2021-01-11 20:07
Sounds like you're not using one of the standard clients. What problems are you facing?
bethskurrie
2021-01-11 20:08
Here are the docs on creating tags https://docs.pact.io/pact_broker/tags#creating-tags
kflo
2021-01-11 20:08
i?m using the `scala-pact` integration, it seems to publish tags for the consumer side automatically but not for the provider verification side. not sure if that?s intentional or not
kflo
2021-01-11 20:09
(right now it?s just missing the tags from the CI build, the CD build works the same for both ? i.e. i have to explicitly tell the broker to publish the tags on deployment)
bethskurrie
2021-01-11 20:09
Please raise an issue with pact scala for that to be implemented - it should be.
kflo
2021-01-11 20:11
yeah, first i was trying to verify that my setup was correct which led me down this path :slightly_smiling_face:
bethskurrie
2021-01-11 20:11
You can use the pact cli or a manual PUT as a workaround in the meantime. The tags need to be published BEFORE the results however, for the webhooks to kick off properly, so you may have some difficulties.
bethskurrie
2021-01-11 20:12
If you don't have any "verificaiton results published" webhooks though, you should be ok to publish the tag afterwards.
brett
2021-01-12 07:28
Thanks! At this state of my project I'm OK manually publishing the verification results, but how would I do that? Is the link you sent an example for me to infer how to do that? I'm not using any CI at the moment. I'm able to run the swagger-mock-validator to check for incompatibility, but I'm not sure how I can take that output and manually upload it to pactflow to benefit from the much nicer UI to track and see the incompatibilities. What do you suggest?
matt.fellows
2021-01-12 07:57
I'm not sure if we have an API that will let you report the specific failures that's not specific to Pact itself. We are working on one for this exact scenario, so I'd hold tight in doing any custom work
matt.fellows
2021-01-12 07:58
And yes, the example I showed you is how to retrieve the link to publish verification results and how to send a message to it
brett
2021-01-12 08:08
Thanks. What do you mean by "I'm not sure if we have an API that will let you report the specific failures *that's not specific to Pact itself*."
Isn't the output below of swagger-mock-validator specific to Pact?
> swagger-mock-validator https://<someUrl>/swagger.json pacts/frontend-backend.json
Mock file "pacts/frontend-backend.json" is not compatible with spec file "https://<someUrl>/swagger.json"
19 error(s)
request.path-or-method.unknown: 5
request.body.incompatible: 7
response.body.incompatible: 7
0 warning(s)
{... [goes on to show specific errors]
matt.fellows
2021-01-12 09:11
The swagger mock validator is a tool written by atlassian and shows differences between a pact file and an OAS
matt.fellows
2021-01-12 09:12
The verification results screen in Pactflow has no idea about those errors. It only knows about the failures pact can determine, and the format to parse and render them
matt.fellows
2021-01-12 09:15
Does that make sense? You could probably still upload the output and see what happens tho. At the very least, you could probably use the HAL browser later on to view the raw results, but I don't know if the Pact screen will display anything
brett
2021-01-12 11:51
Thanks for the additional explanation. So basically, the Pactflow UI verification is designed for showing verification results when comparing consumer pacts to provider pacts results, and the swagger-mock-validator compares the consumer pact to an OAS, which is not something Pactflow deals with. Is that correct?
So in my project, I should focus on getting the provider tests to produce the provider pact file to upload to Pactflow so that it can compare the consumer to provider results, and then I will be able to use the Pactflow UI for targeting the inconsistencies, right?
matt.fellows
2021-01-12 23:53
> Thanks for the additional explanation. So basically, the Pactflow UI verification is designed for showing verification results when comparing consumer pacts to provider pacts results, and the swagger-mock-validator compares the consumer pact to an OAS, which is not something Pactflow deals with. Is that correct?
That?s correct. @bethskurrie may have more to say on the above.
matt.fellows
2021-01-12 23:54
> So in my project, I should focus on getting the provider tests to produce the provider pact file to upload to Pactflow so that it can compare the consumer to provider results, and then I will be able to use the Pactflow UI for targeting the inconsistencies, right?
I think you mean *provider verification results* (there is no provider _pact_ file, as such). This is of course up to you, and depends on why you want to use the OAS validator in the first place.
matt.fellows
2021-01-12 23:55
There are two reasons I think to use the atlassian tool on the provider side:
1. As a replacement for a provider pact test (on the assumption you do indeed guarantee your provider implements the OAS file). This is a legitimate approach and is something we?re actively looking to build in to Pactflow right now
2. As an additional check on the provider, to ensure that all of your documentation and implementation is in alignment. In this case, you?d still need to do the pact provider verification step
matt.fellows
2021-01-12 23:56
If you?re going down (1), then you could use the example I shared with you to report back to Pactflow the results of the swagger-mock-validator call (pass/fail, along with the specific output)
matt.fellows
2021-01-12 23:56
If you did this, then you would still be able to use the `can-i-deploy` and other Pactflow/Pact Broker related tools
brett
2021-01-13 07:34
I really appreciate your assistance. Your explanations continue to be very helpful. Yes, I'm looking to go down (1), because I'm currently much more TDD-inclined than the developer working on the provider side and the swagger spec is automatically updated when he makes changes to the provider. So until he gets provider tests up and running to run my pact file against his provider tests, verifying against the swagger spec is an improvement.
brett
2021-01-13 07:39
Regarding the code you pointed me to, since I'm not using any CI, and I'm running the swagger mock validator manually, would I just do a curl based on this syntax (updating the params accordingly)?
curl -X POST ${CONTENT_TYPE_HEADER} ${AUTH_HEADER} $$RESULTS_URL -d '{ "success": false, "providerApplicationVersion": "${TRAVIS_COMMIT}" }'; \
And I understand that while the UI would not update to show the errors, if I include the verification output from the swagger mock validator tool in my curl, that output should be viewable in the HAL Browser?
sagupta
2021-01-13 16:00
Hello people,
Is there a way to check the difference between contracts? I am trying to debug a pipeline failure which got triggered because of contract changed so i wanted to know what exactly is changed in the contract compared to a previous version
phil.endsley
2021-01-13 16:09
```/pacts/provider/[pacticipant]/consumer/[pacticipant]/pact-version/[pactVersion1]/diff/pact-version/[pactVersion2]```
This will give you a diff between two pact versions. You can use the build in HAL client from Broker to explore this as well. From the broker's ui, go to a contract, then click on View in API Browser. You can use pb:diff-previous-distinct or pb:diff
phil.endsley
2021-01-13 16:10
Note that pactVersion for that url is not the version published with the consumer/provider, but the version of the pact itself
sagupta
2021-01-14 10:04
Hello Phil,
I am currently trying out the solution in HAL browser and i am not sure what to exactly put for the version
sagupta
2021-01-14 10:05
since from the pact matrix , i could only see 2 pacts with different consumer/provider versions (in this case different consumer/provider SHA)
phil.endsley
2021-01-14 17:22
Yeah, you need to use the api browser again.
1. View in API browser like above
2. *pb:all-pact-versions*
3. *Select the version you want*
4. *pb:pact-version*
irldev
2021-01-15 22:35
If we have two different versions of a contract on a broker, for example version 1 on production and version 2 on development. Is there an easy way for a provider to verify against one of those without having to specify the version number they are looking to verify against? When running our provider verification in CI, we don't want to have to constantly change and specify the version number of the contract to run provider verification against.
2021-01-15 22:41
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
wilkinsweiqiangliang
2021-01-18 22:55
Hi team, i wonder what is the recommended process for a feature branch PR merged into master in `pact consumer`. Is there any document for reading?
wilkinsweiqiangliang
2021-01-18 23:14
i had, i think i upgrade the old way to a new way of writing the tag
bethskurrie
2021-01-18 23:14
I think these questions would be answered by doing the CI/CD workshop. Are you sure you've done it, not just read it?
wilkinsweiqiangliang
2021-01-18 23:15
i realise one of the feature branch doesnt have verification result
bethskurrie
2021-01-18 23:16
This step covers it https://docs.pactflow.io/docs/workshops/ci-cd/workshop/verifying-feature-pacts
arindam.datta
2021-01-19 11:32
Any Azure Devops expert here! Webhook to queue a build is getting failed with status `302`
arindam.datta
2021-01-19 11:42
Please ignore above... found that I had to specify the Base64 encoded string as token
kjayachandra2000
2021-01-19 11:49
Hi All, for pact broker oss can we have multiple user account apart from base authentication?
matt.fellows
2021-01-19 12:30
No, the OSS pact broker doesn't have any concept of user. You'd have to add your own
mateusz.derks
2021-01-19 13:56
Hey again :wave: after a quiet December we finally updated pact broker to 2.73 and we enjoy WIP pacts with the tweaks to pact URL pushed in webhook. I?m trying to get to the bottom of one issue and I?m wondering if it?s something you encountered already. When we ask the broker about contracts for verification we see duplicates in the log. From the further entries it appears that all of them belong to a different version (feature branches) that do not change contract on their own, they just publish a contract identical to another legit WIP branch.
```14:09:27 INFO: Reading pact at .../pacts/provider/Provider/consumer/Consumer/pact-version/123/metadata/d2lwPXRydWU=
14:09:28 INFO: Reading pact at .../pacts/provider/Platform/consumer/Consumer/pact-version/123/metadata/d2lwPXRydWU=
14:09:28 INFO: Reading pact at .../pacts/provider/Platform/consumer/Consumer/pact-version/123/metadata/d2lwPXRydWU=```
So far I can?t reproduce this issue outside of our project. Do you have some ideas why it could happen?
sagupta
2021-01-19 17:01
Hello Team,
Is there any way to run provider test against a specific consumer and a specific tag?
I am currently using the `verify` from pact-cli on the provider side and couldnt find a flag to pass consumer name. It only has consumer-version-selectors .
brett
2021-01-19 19:40
I noticed that extra properties on the response were not triggering verification errors. I then found in the docs that this is expected behavior: "Note that during provider verification, following Postel's Law of being "relaxed" with what we accept, "unexpected" values in JSON response bodies are ignored. This is expected and is perfectly OK. Another consumer may have an expectation about that field." (docs) In my case we discovered some fields in the database that were no longer relevant and we thought the tests would pick that up (but they don't because all other properties are present). Is there any good way to confirm that the response doesn't have any unexpected properties?
matt.fellows
2021-01-19 22:40
Not that I'm aware of. There are other tools that can do this (e.g. some of the OAS/swagger)
bheemreddy181
2021-01-19 23:23
Team any idea why do we see these errors while publishing results to pact broker
``` Error returned from verification results publication 500 (Pact::Provider::VerificationResults::PublicationError)\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish.rb:35:in```
bheemreddy181
2021-01-19 23:31
We are seeing this error on PACT-Go version v1.5.1 while publishing results to the broker from provider
matt.fellows
2021-01-19 23:53
Self hosted broker or Pactflow? If self-hosted, what do the logs say about it? There should be a stack trace containing the source of the problem
matt.fellows
2021-01-19 23:53
I think I?ve seen problems in the past, where the version or tag contains a newline. I think that?s fixed in latest versions of the broker and client libraries, but just in case it?s worth checking
bheemreddy181
2021-01-20 00:00
Looks like is it a different issue - this what our developer shared how it got fixed
```we added a scenario for a publisher api that returns base64 encoded pdf response (about 128kb of data). The pact client failed to upload the results with 500 response code and empty body.```
once we removed the PDF file it worked fine
matt.fellows
2021-01-20 00:02
it?s possible that the payload is too big (although that doesn?t seem too big at first glance, I?ve heard of MBs of pact files being uploaded before)
bheemreddy181
2021-01-20 00:32
I don't think we are emitting logs from pact broker into splunk or something we need to do that
bheemreddy181
2021-01-20 00:33
```021/01/19 23:48:20 [DEBUG] executing after hook
2021/01/19 23:48:20 [DEBUG] teardown
pact.go:413: No pacts found to verifify. Check the tags provided (master) for your broker (https://pact-broker.enova.com) are correct
contract_test.go:90:
Error Trace: contract_test.go:90
Error: Expected nil, but got: &errors.errorString{s:"error verifying provider: exit status 1\n\nSTDERR:\n/home/circleci/project/pact/lib/ruby/lib/ruby/gems/2.2.0/gems/bundler-1.9.9/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /go/bin in PATH, mode 040777\nINFO: Fetching pacts for sysopen_gateway from https://pact-broker.enova.com with the selection criteria: latest for tag master\nINFO: Reading pact at https://pact-broker.enova.com/pacts/provider/sysopen_gateway/consumer/brazil_frontend/pact-version/099acef1aea04e3b57affe0c5db5a9453aa2fca2\nINFO: Tagging version 08994a7e8d71a6156b3714fbed25d0e3bb0af48f of sysopen_gateway as \"braz2872\"\n/home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish.rb:103:in `publish_verification_results': Error returned from verification results publication 500 (Pact::Provider::VerificationResults::PublicationError)\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish.rb:35:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish.rb:21:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish_all.rb:22:in `block in call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish_all.rb:19:in `collect'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish_all.rb:19:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/verification_results/publish_all.rb:10:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/rspec/pact_broker_formatter.rb:28:in `close'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:209:in `block in notify'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:208:in `each'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:208:in `notify'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:243:in `close'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:196:in `close_after'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:174:in `finish'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/reporter.rb:76:in `report'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/runner.rb:115:in `run_specs'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/runner.rb:89:in `run'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/rspec-core-3.10.0/lib/rspec/core/runner.rb:71:in `run'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/pact_spec_runner.rb:90:in `run_specs'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/provider/pact_spec_runner.rb:35:in `run'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/cli/run_pact_verification.rb:70:in `run_with_pact_uri_object'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/cli/run_pact_verification.rb:51:in `run_specs'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/cli/run_pact_verification.rb:21:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-1.55.6/lib/pact/cli/run_pact_verification.rb:13:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:171:in `verify_pact'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:43:in `block in call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:42:in `collect'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:42:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/app.rb:34:in `call'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/cli/verify.rb:47:in `verify'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'\n\tfrom /home/circleci/project/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.32.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'\n\tfrom /home/circleci/project/pact/lib/app/pact-provider-verifier.rb:33:in `<main>'\n\n\nSTDOUT:\n"}```
matt.fellows
2021-01-20 00:36
Yeah, unfortunately that won?t show the error in the broker itself, which is likely hidden from the external interface
bethskurrie
2021-01-20 22:46
@bheemreddy181 the client should put out the error text for you. I'll have a look at that.
bethskurrie
2021-01-20 22:47
it should show you the body of the response with an error reference for you to search for in your logs
bethskurrie
2021-01-20 23:00
@bheemreddy181 I'm confused as to why you aren't seeing the body of the error response in the logs
bethskurrie
2021-01-20 23:00
This is what I get when I force an error during a verification publication
bethskurrie
2021-01-20 23:00
```Pact::Provider::VerificationResults::PublicationError: Error returned from verification results publication 500 {"error"=>{"message"=>"bethtest", "reference"=>"bCJRhpdHsD", "backtrace"=>["/Users/bethanyskurrie/workspace/pact-foundation/pact_broker/lib/pact_broker/api/resources/verifications.rb:53:in `from_json'"```
bethskurrie
2021-01-20 23:01
That says to me that the 500 is coming back with an empty response body, and I don't see how that could happen from the Ruby code.
bethskurrie
2021-01-20 23:02
Is it possible that a 500 is coming back from an intermediate server (ie. do you have ngnix in front of it?)
bethskurrie
2021-01-20 23:05
You'll be able to tell if the response was from the Ruby server if you turn on --verbose (you'll have to look at the docs of your verifier for how to do that).
bethskurrie
2021-01-20 23:05
In the output you'll see
```-> "Server: Webmachine-Ruby/1.5.0 Rack/1.3\r\n"
-> "X-Pact-Broker-Version: 2.74.1\r\n"```
bheemreddy181
2021-01-20 23:10
I assume we have ngnix in front of that, it was weird that didn't see any syslogs as well , do i need to explicitly emit out logs from the docker image of pact broker
bethskurrie
2021-01-20 23:11
you'll need to configure what ever tool you're hosting it in to forward them to something.
bethskurrie
2021-01-20 23:31
@sagupta see the docs https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors/#properties
bethskurrie
2021-01-20 23:41
it's v strange that you would be getting the same pact version mulitple times because it should be de-duplicated. Sounds like a bug to me.
bheemreddy181
2021-01-21 00:33
So latest Open Source Version of pact broker doesn't allow you to delete PACTS ?
bheemreddy181
2021-01-21 00:35
older version of the UI used to allow people to delete PACTS from the UI , i should have phrased it correctly on my initial statement
bethskurrie
2021-01-21 00:36
I did to an upgrade of bootstrap, so that may have introduced a regression.
bethskurrie
2021-01-21 00:36
Can you do a hard refresh of your page to make sure you have the latest js/css please.
bheemreddy181
2021-01-21 00:38
So is there any specific reason why we have this option in the initial phase itself ?
bheemreddy181
2021-01-21 00:39
i mean why was this an option from the start , just curious to know from design point of view
bheemreddy181
2021-01-21 00:41
Given we have API's to do it i feel this feature will give an ability to mess with other services pacts
bheemreddy181
2021-01-21 00:42
but ya its not a big deal as long as people are matured enough to know that they shouldn't mess with these
bethskurrie
2021-01-21 00:42
If you want permissions and role/team based security, then you can use Pactflow OnPremise.
matt.fellows
2021-01-21 01:44
Deleting a pact can be useful, because occasionally a bad contract is published or incorrectly tagged. This can result in verification failures and blocked pipelines, so being able to delete a specific version of a pact can get you out of that bind (amongst other uses cases of course)
matt.fellows
2021-01-21 01:44
As Beth mentioned, it was asked enough by the community that it was added - that?s usually how things make it in there!
matt.fellows
2021-01-21 01:45
One thing you can almost 100% assume about Pact functionality - it was built to solve a problem for somebody (often a maintainer)
bethskurrie
2021-01-21 02:13
@mateusz.derks can you see if you can reproduce it using my little HTTP test data builder? https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
mateusz.derks
2021-01-21 09:03
I lost access to logs, the affected CI job was cleaned up due to retention settings. I will share the full log once I see the issue again.
I will try to reproduce the problem with the tool you mentioned, thanks :bow:
sagupta
2021-01-21 09:45
ok so when using CLI , how can i pass the consumer name.
```pact/entrypoint.sh verify \
--pact-broker-base-url=${PACT_BROKER_URL} \
--provider-base-url=${PROVIDER_BASE_URL} \
--provider=${PACT_PROVIDER} \
--provider-version-tag=${PACT_PROVIDER_TAG} \
--provider-app-version=${PROVIDER_VERSION}```
Currently i pass only the consumer tag with this flag in above script
```--consumer-version-tag=${CONSUMER_TAG}```
patrick.hendron
2021-01-21 17:32
Hey guys looking to run the test broker on my local, I have followed the instruction step by step
```Install ruby 2.2.0 or later and bundler >= 1.12.0
Windows users: get a Rails/Ruby installer from RailsInstaller and run it
unix users just use your package manager
Run git clone git@github.com:pact-foundation/pact_broker.git && cd pact_broker/example
Run bundle install```
patrick.hendron
2021-01-21 17:33
then when i run - `bundle exec rackup -p 9292 -o 0.0.0.0`
the following returns
```bundler: failed to load command: rackup (/usr/local/lib/ruby/gems/3.0.0/bin/rackup)
/usr/local/lib/ruby/gems/3.0.0/gems/dry-types-0.10.3/lib/dry/types/definition.rb:33:in `initialize': wrong number of arguments (given 3, expected 1..2) (ArgumentError)```
patrick.hendron
2021-01-21 17:34
Versions running : `Bundler version 2.2.6 ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin19]`
bethskurrie
2021-01-21 22:17
@patrick.hendron yeah, the build isn't passing on 3.0.0 yet. Stick to 2.7.
bethskurrie
2021-01-21 23:51
@patrick.hendron we strongly recommend people use docker in preference to running the Ruby app themselves. Are you unable to do this?
patrick.hendron
2021-01-22 10:46
yeah, i have got burnt using ruby :joy:, switching to docker currently
jstoebel
2021-01-22 17:12
Hello, I am working with my team to set up a POC of contract testing and my team lead was curious about spinning up a pact broker inside of our CI server during test runs. Instances of the pact broker would then talk to an external, always available database somewhere else.
Are there any pitfalls with this? I can't think of a reason why that wouldn't work, but being new to contract tests I wanted to see if anyone could spot any problems with this approach.
brendan.donegan
2021-01-22 18:46
what if you want to check anything about the contracts between builds?
jstoebel
2021-01-22 19:09
@brendan.donegan ahh this is a very good point! contracts are also a form of documentation! I think the concern is what team will be in charge of ensuring the pact broker's availability. basically he's trying to emulate the serverless model which is what we are trying to migrate to for everything else.
bethskurrie
2021-01-22 23:39
There is a serverless broker available, but it's experimental and doesn't support webhooks yet @jstoebel
bethskurrie
2021-01-22 23:40
Typically, you want it up and running at all times. Lots of CI jobs will be running and accessing it at the same time, in a normal environment. Stopping and starting it all the time would get messy.
bethskurrie
2021-01-22 23:41
My guess is the time spent on dealing with complications involved for such an unusual set up would outweigh any cost savings for the resources.
bethskurrie
2021-01-22 23:43
Which team runs Jira? Which team runs your enterprise Github? (Hypothetically). The same one would run the broker.
mateusz.derks
2021-01-25 08:06
I found this in the logs, all they point to the same contract URL
```08:19:25 DEBUG: The pact at https://BROKER/pacts/provider/PROVIDER/consumer/CONSUMER/pact-version/a9f75f7f035e0fcdf86f82200c07cbbc8f808257/metadata/d2lwPXRydWU= is being verified because it is a 'work in progress' pact (ie. it is the pact for the latest version of Consumer tagged with 'feat-1' and is still in pending state)
08:19:25 DEBUG: The pact at https://BROKER/pacts/provider/PROVIDER/consumer/CONSUMER/pact-version/a9f75f7f035e0fcdf86f82200c07cbbc8f808257/metadata/d2lwPXRydWU= is being verified because it is a 'work in progress' pact (ie. it is the pact for the latest version of Consumer tagged with 'feat-2' and is still in pending state)
08:19:25 DEBUG: The pact at https://BROKER/pacts/provider/PROVIDER/consumer/CONSUMER/pact-version/a9f75f7f035e0fcdf86f82200c07cbbc8f808257/metadata/d2lwPXRydWU= is being verified because it is a 'work in progress' pact (ie. it is the pact for the latest version of Consumer tagged with 'master' and is still in pending state)```
mateusz.derks
2021-01-25 14:54
I probably misunderstand something, I tried to produce a WIP contract, but this returns only 1 pact to verify
```td.delete_integration(consumer: "foo-consumer", provider: "bar-provider")
.publish_pact(consumer: "foo-consumer", consumer_version: "1", provider: "bar-provider", content_id: "111", tag: "production")
.publish_pact(consumer: "foo-consumer", consumer_version: "2", provider: "bar-provider", content_id: "112", tag: "main")
.get_pacts_for_verification(
enable_pending: true,
provider_version_tag: "main",
include_wip_pacts_since: "2020-01-01",
consumer_version_selectors: [{ tag: "production", latest: true }])```
mateusz.derks
2021-01-25 15:17
@bethskurrie I managed to reproduce the issue https://github.com/pact-foundation/pact_broker/issues/374
anastasiia.bielik
2021-01-26 13:26
Hello, I have a question about `can-i-deploy` command.
Right now we run it in such way:
``` --pacticipant 'X' \
--version ${{ github.sha }} \
--pacticipant 'Y' \
--latest production \
--pacticipant 'Z' \
--latest production \```
Our consumer is `X` and `Y` , `Z` are providers. But `Y` is also a consumer, so this check includes unnecessary combination of `consumer:Z -> provider: Y` . Is there a way to verify only the list of providers?
I also find another option to use `--to prod` . But we need to check only few providers, not all of them. Is there a way to skip a participant?
anastasiia.bielik
2021-01-26 15:15
We found a workaround: we run `can-i-deploy` for each provider separately. But maybe there you can help to find more elegant way?
phil.endsley
2021-01-26 15:22
You mentioned there were some unnecessary checks happening. Listing each pacticipant, `consumer:Z -> provider:Y` and for using `--to prod` you only need to check some providers. I'm just curious why you don't want to check all combinations?
anastasiia.bielik
2021-01-26 15:31
@phil.endsley yeah, it totally makes sense, but currently we have one provider which was set up for the testing purpose while we are migrating to another architecture.
sagupta
2021-01-26 17:19
Hello Team,
I am facing an error while publishing pacts to broker but do not get clear error . I am using pact-cli and calling `publish` command as below. Can someone help. Is there a way to get more info about error?
```Publishing <-------> pact to pact broker at https://<URL>
Failed to publish graphql/<--provider--> pact due to error: PactBroker::Client::Error -
One or more pacts failed to be published```
I used this command
```/pact # ./entrypoint.sh publish /opt/contracts/pacts --consumer-app-version=${PA
CT_CONSUMER_VERSION} --broker-base-url=${PACT_BROKER_URL} ```
sagupta
2021-01-26 17:29
ok , this :point_up: was happening on CI but when i run locally using the pact json and trying to publish it , i got this error.
```Failed to publish graphql/email-action-api pact due to error: PactBroker::Client::Error - This is the first time a pact has been published for "email-action-api".
The name "email-action-api" is very similar to the following existing consumers/providers:
* email-action
If the pact is intended to be for a new consumer or provider, please manually create "email-action-api" using the following command, and then re-publish the pact:```
kflo
2021-01-26 17:41
generally you only need: `pact-broker can-i-deploy --pacticipant PACTICIPANT --version VERSION --to STAGE` because the pact broker internally knows all the dependencies for the given PACTICIPANT, so you don?t have to specify them all
matt.fellows
2021-01-26 21:35
Sounds like a question for whoever runs your CI. Pact clearly shows the error
bheemreddy181
2021-01-26 22:41
looks like the Github status checks are broken in the latest pact broker , the success status check is overriding the pending status check , we are seeing both on the PR
bheemreddy181
2021-01-27 02:18
Team we are trying to revert to the older version from 2.76 to 2.54 of pact broker docker image and see the below error
```pact_broker_1 | ! Unable to load application: Sequel::Migrator::Error: Applied migration files not in file system```
Any pointers on this ?
bheemreddy181
2021-01-27 02:22
```Jan 27 02:11:46 test-infrastructure-pactbroker-production.ip-10-112-9-224 docker-compose[20002]: pact_broker_1 | ! Unable to load application: Sequel::Migrator::Error: Applied migration files not in file system
Jan 27 02:11:46 test-infrastructure-pactbroker-production.ip-10-112-9-224 docker-compose[20002]: pact_broker_1 | bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma)
Jan 27 02:11:46 test-infrastructure-pactbroker-production.ip-10-112-9-224 docker-compose[20002]: pact_broker_1 | Sequel::Migrator::Error: Applied migration files not in file system: 20200922_add_event_to_trigge```
sagupta
2021-01-27 09:21
Pact shows the error on Ci but it misses the message after ::Client::Error on CI
yann.courtel
2021-01-27 10:16
Hi everyone, is the version 2.76 stable ? We are about to upgrade our pact broker and want to make sure the image is good. Thanks a lot.
matt.fellows
2021-01-27 10:46
Yes, but my point is it must be some artifact about your CI - clearly pact can show the error.
matt.fellows
2021-01-27 10:46
You need to find out what your CI is doing with the output. Pact can't fix your CI magically
sagupta
2021-01-27 10:49
Ok if I understand it right . Then pact is generating the error message ( after the ::Client::Error -) but the CI may not be showing it or ignoring it .It can be checked in CI logs or artifacts
sagupta
2021-01-27 10:50
One thing I have tried is this :
I entered in the shell of CI job and run the command inside shell .I get the same error without the error message
matt.fellows
2021-01-27 11:15
can you please provide evidence of this? It could be a bug, but seems unlikely if it works locally
matt.fellows
2021-01-27 11:26
hmmm, my guess is that because later migrations have applied, rolling back the image can?t perform a DB rollback, because the migration files aren?t present on the newer image, and therefore it doesn?t know how to roll them back (because the rollback instructions are in the newer image)
matt.fellows
2021-01-27 11:27
I?m guessing you didn?t first rollback as per https://docs.pact.io/pact_broker/docker_images/pactfoundation/#database-migrations
matt.fellows
2021-01-27 11:29
I think it should be OK though. Just start back up the `2.76`, do the DB migration, and then run the old image as per the instructions there
bheemreddy181
2021-01-28 05:31
We couldn?t rollback as per the documentation mentioned above , logs for reference
`/pact_broker # bundle exec rake pact_broker:db:migrate[20200319]
bundler: failed to load command: rake (/usr/local/bundle/bin/rake)
Gem::Exception: can't find executable rake for gem rake. rake is not currently included in the bundle, perhaps you meant to add it to your Gemfile?
/usr/local/bundle/gems/bundler-2.0.2/lib/bundler/rubygems_integration.rb:460:in `block in replace_bin_path'
/usr/local/bundle/gems/bundler-2.0.2/lib/bundler/rubygems_integration.rb:480:in `block in replace_bin_path'
/usr/local/bundle/bin/rake:23:in `<top (required)>'
/pact_broker # ls /usr/local/bin/
bundle bundler erb gem irb rake rdoc ri ruby
/pact_broker # PATH=/usr/local/bin/:$PATH
/pact_broker # bundle exec rake pact_broker:db:migrate[20200319]
bundler: failed to load command: rake (/usr/local/bin/rake)
Gem::Exception: can't find executable rake for gem rake. rake is not currently included in the bundle, perhaps you meant to add it to your Gemfile?
/usr/local/bundle/gems/bundler-2.0.2/lib/bundler/rubygems_integration.rb:460:in `block in replace_bin_path'
/usr/local/bundle/gems/bundler-2.0.2/lib/bundler/rubygems_integration.rb:480:in `block in replace_bin_path'
/usr/local/bin/rake:23:in `<top (required)>'
/pact_broker # bundle exec /usr/local/bin/rake
bundler: failed to load command: /usr/local/bin/rake (/usr/local/bin/rake)
Gem::Exception: can't find executable rake for gem rake. rake is not currently included in the bundle, perhaps you meant to add it to your Gemfile?
/usr/local/bundle/gems/bundler-2.0.2/lib/bundler/rubygems_integration.rb:460:in `block in replace_bin_path'
/usr/local/bundle/gems/bundler-2.0.2/lib/bundler/rubygems_integration.rb:480:in `block in replace_bin_path'
/usr/local/bin/rake:23:in `<top (required)>'`
matt.fellows
2021-01-28 05:40
Try a `gem install rake` and then try again. Just on mobile so don't have a container to test handy.
bheemreddy181
2021-01-28 06:49
Not sure what?s going wrong we couldn?t figure it out gem install rake didn?t work too
matt.fellows
2021-01-28 06:59
I just ran that on a fresh image and rake executed OK. What version are you in? Can you please show the docker and other commands?
sagupta
2021-01-28 09:16
It was an authentication issue . I was passing a blank `PACT_BROKER_TOKEN` . However the error message was being truncated .
Adding a `--verbose` flag to the publish script helped resolve the issue
bethskurrie
2021-01-28 23:30
@bheemreddy181 grab 2.76.1.2 and follow the updated instructions https://github.com/pact-foundation/pact-broker-docker#database-migrations
bethskurrie
2021-01-29 05:36
@bheemreddy181 I'm not sure what version you were upgrading from, but if the issue is what I think it is, this version will fix it.
bethskurrie
2021-01-29 05:37
If it doesn't, I'm going to need you to reproduce it using https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
sagupta
2021-01-29 11:27
actually i tried it locally also thinking the same , but it doesnt . So that something specific to our CI i guess
sagupta
2021-01-29 11:30
Hello Team,
I am currently debugging an error during provider verification . I am using pact-cli and calling the command `verify` . Currently i only get the response from the provider and the differences that it has. Is there a way to get the request from `PACT` that has been sent to the provider API. I have tried checking logs and enabling `--verbose` flag but that didnt help
sagupta
2021-01-29 11:55
Since i am also running pact-cli on docker, so i tried to `sh` in the pact-container to debug and I can successfully execute a `curl` request to the provider which is configured.
But when i execute the command where it pulls the contract and send the request, then it fails.
bheemreddy181
2021-01-30 00:18
I am not really sure whether we were on 2.54 then though last time we deployed pact broker was last year may 22 and i could relate that version to 2.54.0
bheemreddy181
2021-01-31 15:30
finally i found that this is a not pact broker issue but the way how we configured our webhooks. Details updated on the ticket.
bheemreddy181
2021-01-31 22:05
I always had this doubt around pact broker why does pact broker home page shows status of a latest verified pull request ( doesn?t it need to always show the master branch verified version ) and show pull request level details in the matrix ?
bethskurrie
2021-02-01 02:49
It doesn't know the difference between your main branches and your feature branches @bheemreddy181
bheemreddy181
2021-02-01 02:50
then i felt pact broker home should always show the status of master verification , i might be wrong
bethskurrie
2021-02-01 02:51
It's on my long term todo list to allow the the main development branches to be specified.
bheemreddy181
2021-02-01 02:52
ya i agree - we are now moving away from that naming convention typically `master` to `main`
bheemreddy181
2021-02-01 02:52
pact broker home page generally confuses the new users with this combinational tags
guppy0356.nakira
2021-02-01 08:25
I found `Pact.configuration.config_ru_path=` , but I wrote this method in spec/service_consumers/pact_helper.rb. Is it correct?
kjayachandra2000
2021-02-01 14:29
Hi All, can someone help me to create a webhook , I have a consumer and provider service. This job runs on Jenkins any example on configuring webhook would be much appreciated
brendan.donegan
2021-02-01 15:12
@kjayachandra2000 a good first step is to set up a Postman request that triggers the job successfully, which can then be used to feed into the command that creates the webhook
yann.courtel
2021-02-01 16:46
Hi everyone, is there a healthcheck page for the pact-broker that can tell us quickly the state of the app? I insist on the quick part :slightly_smiling_face: the /pacts/latest is way too long. Thanks a lot.
kflo
2021-02-01 17:13
agreed, would be nice to have separate views for ?stable? vs ?development? or whatever you want to call it
bethskurrie
2021-02-01 21:58
@guppy0356.nakira that's a pact-ruby setting, nothing to do with the Pact Broker
bethskurrie
2021-02-01 21:59
bethskurrie
2021-02-01 22:01
Here's a template for a Jenkins webhook https://docs.pact.io/pact_broker/webhooks/template_library/#jenkins---trigger-build
yann.courtel
2021-02-02 09:16
Thanks a lot @bethskurrie. the heartbeat url works.
@nouri.tawfik thanks. I don't have this url unfortunately. Maybe it's the version of my broker.
bethskurrie
2021-02-03 21:43
That "/healthcheck" endpoint doesn't exist in the Broker code - maybe it's added by something else @nouri.tawfik @yann.courtel
bethskurrie
2021-02-03 21:44
I'm trying out this Github Discussions thing with a conversation about supporting explicit branches in the Pact Broker https://github.com/pact-foundation/pact_broker/discussions/382 Feedback welcome!
young
2021-02-04 06:40
Hi team, When I tried to create a webhook for a consumer, the 500 Internal Server Error displayed, and I don't know how to see this error log and what happened when I creating webhooks, the attachment [video] is How I operated. Thanks a lot.
matt.fellows
2021-02-04 08:38
Also, you?re going to need to get your hands on the pact broker log file - it should have the details of that error
young
2021-02-04 09:15
@matt.fellows thanks
`{`
"events": [
{
"name": "provider_verification_published"
}
],
"request": {
"method": "POST",
"url": "https://circleci.com/api/v1.1/project/bitbucket/neuroncn/nsoperator/build?circle-token=6d5fb0fb6ee11ea29b2b8e27e1e34328ebed69c1150e",
"headers": {
"Content-Type": "application/json"
},
"body": {
"branch": "dev"
}
}
}
nouri.tawfik
2021-02-04 12:08
Hi,
Sorry it's a custom version of pact-broker
You are right, the official endpoint is '/diagnostic/status/heartbeat'
Have a nice day
bethskurrie
2021-02-04 22:23
The docs are here @young https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks
abubics
2021-02-04 23:31
as an aside, there's probably a bug somewhere if a 500 is coming back . . . but that's not the solution to this problem :innocent:
bethskurrie
2021-02-04 23:35
```commit 1e6a06a0baba53c7e80a7eb2f7d1bf1913ef2491
Author: Beth Skurrie <beth@bethesque.com>
Date: Fri Oct 16 08:21:43 2020 +1100
fix: typo when rendering created webhook for old webhooks path
Fixes: https://github.com/pact-foundation/pact_broker/issues/356
diff --git a/lib/pact_broker/api/resources/pact_webhooks.rb b/lib/pact_broker/api/resources/pact_webhooks.rb
index 1e0acd80..5220cbc3 100644
--- a/lib/pact_broker/api/resources/pact_webhooks.rb
+++ b/lib/pact_broker/api/resources/pact_webhooks.rb
@@ -52,7 +52,7 @@ module PactBroker
def from_json
saved_webhook = webhook_service.create next_uuid, webhook, consumer, provider
- response.body = Decorators::WebhookDecorator.new(saved_webhook).to_json(decoractor_options)
+ response.body = Decorators::WebhookDecorator.new(saved_webhook).to_json(decorator_options)
end```
yann.courtel
2021-02-05 09:20
Hi everyone, I'm trying to upgrade a pact-broker we have a on VM but I keep having this message. I read it could be the Ruby on rail is installed on the VM... Anyway, I'm first trying to see the exact error. I have the error ID but no way to get that in the docker logs. Any idea where to search first? Thanks a lot.
yann.courtel
2021-02-05 10:21
Found out the error log were into my /var/log/nginx/error.log
It was a database connection error.
After correcting my credentials, it connected but had an insufficient privileges error..... even though I granted all privileges to the new user I created and put it owner to the database containing my pacts... very frustrating.
yann.courtel
2021-02-05 10:43
App 344 output: 2021-02-05 10:42:14.302106 E [344:3460 log_quietener.rb:18] pact-broker -- PG::InsufficientPrivilege: ERROR: permission denied for relation schema_migrations: SELECT * FROM "schema_migrations" ORDER BY "filename" DESC LIMIT 1
App 344 output: Error: The application encountered the following error: PG::InsufficientPrivilege: ERROR: permission denied for relation schema_migrations
yann.courtel
2021-02-05 13:57
I've got it. I tried to hook a new user to the database to create an updated version of it but the permissions were wrong. It was owner of the database but it also needed to be owner of the 51 tables. Now it's working :slightly_smiling_face:
gayatree.eee
2021-02-08 11:43
In webhook we have added a body as follow. {"event_tyep":"pact_changed", "client_payload":{"consumer":"${pactbroker.consumerName}"}}. Please let us know how to fetch these values in provider code
matt.fellows
2021-02-08 11:44
that?s going to be entirely up to how your CI reads the incoming webhook
matt.fellows
2021-02-08 11:45
in this case, `client_payload` is something that GH actions passes through to the build, and the build can then choose to do somethnig with that value (typically you would want to know what pact changed, and verify just that pact)
matt.fellows
2021-02-08 11:49
matt.fellows
2021-02-08 11:51
the configuredhttps://github.com/pactflow/example-provider/blob/c336703f64f4767f54581f61d20d280c50233c7d/Makefile#L83-L93 sets that value when a new pact is published by a consumer for that provider
matt.fellows
2021-02-08 11:52
The actual test checks for the presence of the `PACT_URL` environment variable, and if it?s set, only verifies the incoming pact file and not the standard set: https://github.com/pactflow/example-provider/blob/master/src/product/product.pact.test.js#L26-L28
matt.fellows
2021-02-08 11:53
see also this workshop: https://docs.pactflow.io/docs/workshops/ci-cd/workshop/implementing-the-provider-changes
matt.fellows
2021-02-08 11:53
(I believe you?ve run the workshop, but it may not have made sense at that time yet! :slightly_smiling_face: )
irldev
2021-02-08 14:02
Does anyone know what is the correct path to use to post verification results directly to the broker?
irldev
2021-02-08 14:04
We have tried the post request here but get a 404 https://github.com/pact-foundation/pact_broker/issues/160
stefanos.varsanis
2021-02-09 09:56
Hello. We've noticed a weird behaviour in pact-broker which doesn't make much sense, unless we're missing some critical info:
Version 10.24.1 tagged with `Release` was created 22 days ago.
On the other hand version 26 was tagged with `Release` 15 days ago.
However the 10.24.1 appears as the latest Release tag which defeats the purpose of trying to target the actual latest one.
Any ideas on this?
philipchardwick
2021-02-09 15:35
Hey, I'm looking at implementing a http://concourse-ci.org resource which does the equivalent of the contract changed webhook (the difference being that with concourse, it polls resources like the pact broker for changes rather than being told of changes by a webhook). With that in mind is there a way to get the hash of the pact content from the HTTP API? Is this something I should compute myself from getting the pact and it's interactions?
My current plan is to get a list of the consumers which have pacts with a provider and then get the latest pact for each one and see if theres a verification already - if there's one already then it's because the hash hasn't changed and concourse doesn't need to do anything. But it would be good to have the hashes of the pact content as part of the "versions" concourse keeps a track off (this is more concoursey since if theres a change in version, concourse triggers the pact verify)
ryanlevell
2021-02-09 21:06
Hello. I am running the pact broker Ruby gem. When I click on the ?Example App? matrix icon, I get a 500 error. ?logger.rb:527:in info? with error ?ArgumentError unknown keywords: :selectors, :options?
Any ideas how to resolve?
ryanlevell
2021-02-09 21:48
I reverted from 2.76.2 to 2.65.0 (the version before that log line was added to matrix/service.rb #16) and it is working.
bethskurrie
2021-02-09 22:07
@philipchardwick can you tell me more about your situation and why you're solving this particular problem this way?
ryanlevell
2021-02-09 22:07
Ruby 2.5. We are using a PaaS that expects a ruby or java application (as far as I can tell)
bethskurrie
2021-02-09 22:11
I'd really recommend using the docker image if possible. You'll need to research how the Docker image is configured so that you can replicate the recommended configuration.
ryanlevell
2021-02-09 22:12
I used the docker image previously on a ?dev? machine, but that machine ?auto expires? every X weeks due to company security policies, and was told to move it to the PaaS for a permanent solution.
bethskurrie
2021-02-09 22:12
There are certain settings in the default ruby configuration that are no longer recommended as best practice.
bethskurrie
2021-02-09 22:14
`base_equality_only_on_content_that_affects_verification_results` should be true
bethskurrie
2021-02-09 22:16
`With that in mind is there a way to get the hash of the pact content from the HTTP API?` Yes
bethskurrie
2021-02-09 22:17
If you get the latest pact, then look at the `pb:pact-version` relation, that URL tells you the hash of the content. If that changes, the content has changed.
bethskurrie
2021-02-09 22:19
You can modify this example https://github.com/pact-foundation/pact_broker/tree/master/example
bethskurrie
2021-02-10 04:42
@stefanos.varsanis the ordering is always based on the order of the version, not the order the tags were applied
bethskurrie
2021-02-10 04:43
Coming out soon I'll be adding explicit support for deployments/releases which will make the "latest" behave as you would expect.
philipchardwick
2021-02-10 08:17
Concourse tries to be deterministic, so it doesn't really support starting things from webhooks (e.g. what if the ci was down when the webhook was sent) they encourage devs to get inputs to their pipelines by polling the source of truth (pact broker) to see if anything has changed.
Ah thank you so much for pointing that out - it literally says it in the title "Pact content version permalink" :man-facepalming: that's perfect for this
bethskurrie
2021-02-10 10:11
I'm not sure how you'd poll to pick up every new tagged pact :thinking_face:
bethskurrie
2021-02-10 10:11
You can poll the latest, but there might be multiple publications between polls.
stefanos.varsanis
2021-02-10 10:11
Thanks @bethskurrie. In this case shouldn't the 10.26.0 be the latest since it was created after 10.24.1?
philipchardwick
2021-02-10 10:12
If there had been multiple publications, I think the provider test would pick up all the new ones that had been published in between if I'm using wip pacts
bethskurrie
2021-02-10 10:14
It could toggle between content a and content b and back to a, making it seem like a change hadn't occurred.
philipchardwick
2021-02-10 10:20
I think concourse expects to receive the full list and it does the diff for you so I think I can just return the full list, depending on how long it is
bethskurrie
2021-02-10 10:21
You'd want to turn on the auto clean up. Which now I think of it, I have yet to document properly.
stefanos.varsanis
2021-02-10 10:42
Could it be that the broker is considering the 10.24.1 (minor version) greater than the 10.26.0 ?
bethskurrie
2021-02-10 10:44
Actually, if you can only poll a fixed resource, the versions endpoint won't help. You'd need to check each of the versions to see if the sha had changed.
carolyn.biggar
2021-02-11 01:12
When using `arrayEachLike` in the java Pact DSL (in a kotlin test) , the pact broker UI for the pact shows an empty array rather than an example.
This tiny example of a single property object
```arrayEachLike()
.stringType("name", "My Biscuit Name")```
in https://github.com/csbiggar/shop/blob/master/src/test/kotlin/contracts/BiscuitsContractTest.kt#L95 shows up on the broker as,
```biscuits will respond with:
{
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"body": [
]
}```
? empty body
If I view the pact in the Api Browser on the broker it _does_ show content in the array
```"response": {
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"body": [
{
"name": "My Biscuit Name"
}
],
"matchingRules": {
.. etc```
Could you tell me if this is intentional behaviour of the pact broker UI, or a defect? Not a huge thing but has been causing some confusion for our consumers
Here's an example https://github.com/csbiggar/shop - you'll need to run a broker locally or change the publishing target to an existing one to see the UI defect. The test in question is `should find all biscuits` in https://github.com/csbiggar/shop/blob/master/src/test/kotlin/contracts/BiscuitsContractTest.kt#L95
NB If I change `arrayEachLike()` to `arrayMinLike(1)` , it shows up correctly (or at least, as I expect it to) on the pact broker like this
```biscuits will respond with:
{
"status": 200,
"headers": {
"Content-Type": "application/json"
},
"body": [
{
"name": "My Biscuit Name"
}
]
}```
Many thanks for any thoughts!
carolyn.biggar
2021-02-11 01:15
And this is what I'd expect it to show as (same as if I used `arrayMinLike(1)` )
bethskurrie
2021-02-11 01:43
@carolyn.biggar I think it's because the library parsing the pact doesn't understand those matching rules.
bethskurrie
2021-02-11 01:43
I need to separate the pact broker code from the actual pact library. Can you raise the issue with as much detail as you can in the pact_broker repo please?
carolyn.biggar
2021-02-11 02:09
Ok sure , I?ll do that tomorrow (UK time!) and add a link to the issue here when I?ve raised it. Thanks for looking !
yann.courtel
2021-02-11 08:35
Hi everyone, is there a way in the newest version to configure the page size of the broker's home page? Right now it's 100 but I'd like it to be 1000 by default. Thanks a lot.
bethskurrie
2021-02-11 08:40
Not permanently, but if you do add `&pageSize=1000` to the top it will do what you want @yann.courtel
sagupta
2021-02-11 09:57
Hey team , we are using OSS broker in our org. We are tagging consumer with every build with $CI_BRANCH and $CI_COMMIT_SHA and same for provider as well. THus creates a lot of entries in Pact broker so was thinking what should be the best practice to remove some of the old entries so we can see easily which ones are the latest versions .
bethskurrie
2021-02-11 09:59
I've recently created (but not officially documented) an automatic clean up process, but I'd like to understand why you're doing something that seems so unusual.
yann.courtel
2021-02-11 10:19
I then fail to see why there is pagination at all... If we don't have a way to search for a specific pact in our 800+ pacts without having to change the url, it will be hard to find it. The only way was to do a ctrl + f but now with the pagination, it's no longer possible. Would it be a nice feature request? I meant the default page size. And on another iteration, a search capabilities would be awesome too. Thanks @bethskurrie
sagupta
2021-02-11 11:24
oh sorry my bad , we are using $COMMIT_SHA for version indeed and $CI_BRANCH for tagging . Also we tag again once we deploy to staging with `Staging` . The main motivation for cleaning up is to not have too much data in Broker once we add more consumer provider pairs . So wanted to know if there is an option to automatically clean up old entries
sagupta
2021-02-11 15:33
I also have a question about this `Allow contracts to change without breaking your builds` , If we want to have green builds in provider that it is not impacted by a contract change, then does it mean that we no longer need 2 separate jobs on provider side (one when provider change, one when contract changes). we can just have one job which verifies against a stable version of consumer and we can trigger same job via webhook when a contract change too . Is my understanding correct?
carolyn.biggar
2021-02-11 18:47
Issue raised here, let me know if this is enough information:
https://github.com/pact-foundation/pact_broker/issues/387
ryanlevell
2021-02-11 19:31
Beth, I found the root cause for my error. I was using this http://config.ru as a basis: https://github.com/alphagov/govuk-pact-broker/blob/f52f2bd0a0e3d66c0b3adb57279361af8b9ae27b/config.ru#L57
This logger was not a semantic_logger hence why the http://logger.info call was failing. I updated with your recommendations and it is working :)
bethskurrie
2021-02-11 21:32
@sagupta yes, there is. See https://github.com/pact-foundation/pact_broker/issues/360#issuecomment-735216009
bethskurrie
2021-02-11 21:32
I still need to officially document it, as there are complications if there are multiple instances running against the same database. Just double check the names of the env vars against the code, because some of them have changed.
sagupta
2021-02-11 21:58
yea got it . I have also gone through the conversation in the issue you listed and its helpful. Thanks for this Beth :thumbsup:
ryanlevell
2021-02-11 22:02
Hello. What is the best way to whitelist all read-only requests (no auth required)? My provider side test is failing because the ?/for-verification? endpoint is a POST and I am whitelisting only GET in the http://config.ru. I could whitelist specific urls as well, but wondering if there is a better way.
ryanlevell
2021-02-11 22:38
Here is the api call that is POST
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/provider-pacts-for-verification.markdown
I can maintain a whitelist. My currently logic allows all GETs and the endpoint ?/for-verification?. Are there any other non-GET read-only endpoints I should add to my whitelist?
bethskurrie
2021-02-12 03:19
abubics
2021-02-12 03:25
If you want your provider not to be impacted by contract changes, what will your trigger be for updating the provider?
After a short time, the consumer won't be able to deploy, and there'll be a big backlog of changes to implement, that you don't get notified about.
abubics
2021-02-12 03:25
There are a couple of new features that provide a bit more flexibility (WIP pacts, and pending pacts) . . . you might want to read up about them, too.
bethskurrie
2021-02-12 03:29
@sagupta as Boris says, you still need your webhook -> verification build.
ryanlevell
2021-02-12 03:31
Great! Thank you for the rules. No I?m the guy from yesterday using the ruby gem. (I commented above my root cause for yesterday?s issue.. was my fault due to old http://config.ru)
bethskurrie
2021-02-12 03:31
> we can trigger same job via webhook when a contract change too
You really want to verify just the pact that has changed using the URL that is passed through the build. You'll get quicker feedback this way. There's some metadata that gets passed in the URl that means that when you get complex CI/CD pipelines that use webhooks to report the statuses of the commits back to github, the right results get sent to the right SHA.
ryanlevell
2021-02-12 16:37
Hello. Sorry, I believe this is my last blocker. I am using the pb cli docker image. Our new server has a dev certificate which is causing the cli to throw ?SSLError: certificate verify failed (unable to get local issuer certificate) matrix.rb:15:in?
Is there a way to disable the ssl check for the docker image?
ryanlevell
2021-02-12 19:04
Ok I found the documentation in docker hub for ssl. It is similar to what I?m doing, I?ll keep digging.
sagupta
2021-02-12 20:16
I have read about "Pending pacts" and i think this is what i need in this case :point_up:
ryanlevell
2021-02-12 21:26
I downloaded the cert from Firefox and passing the options to docker but still getting the same error message as originally
ryanlevell
2021-02-12 21:44
I copied the pem from one of our internal batch servers and it is working. Idk why the pact broker pem downloaded from Firefox doesn?t work :man-shrugging:
bethskurrie
2021-02-13 01:05
@ryanlevell Put them both into something like https://www.sslshopper.com/certificate-decoder.html and see what the difference is.
bethskurrie
2021-02-13 05:53
@ryanlevell if you're using the raw rubygem, I would grab all the code from the pact-broker-docker repo to use with it.
bethskurrie
2021-02-13 05:54
This directory has all the code you will need https://github.com/pact-foundation/pact-broker-docker/tree/master/pact_broker
bheemreddy181
2021-02-15 19:48
links on this page are broken https://docs.pact.io/pact_broker/advanced_topics/api_docs/
gabe707
2021-02-16 20:33
```PactBroker::Client::PublicationTask.new(:local) do | task |
task.consumer_version = "1.0.0"
task.pact_broker_base_url = LOCAL_PACT_BROKER_BASE_URL
task.pattern = "/consumer/spec/pacts/*.json"
end```
tjones
2021-02-16 22:52
How are you setting the token? Do you have other PACT_* environment variables set?
matt.fellows
2021-02-16 23:01
(repeating here for posterity)
Is the contract the same though? Because if it is, the verification result will apply to _all_ of the contracts with the same content
i.e. if you make 4 separate publishes and give them different tags, but the content is the same. The verification result for *any* of the versions will apply to *all* of the versions
bethskurrie
2021-02-17 00:30
It looks like you're using a local, self hosted broker. There are no tokens for that one.
gabe707
2021-02-17 14:43
```require 'pact_broker/client/tasks'
PactBroker::Client::PublicationTask.new do | task |
task.consumer_version =1.0
task.pattern = 'ascent-rails/spec/pacts/*.json' # optional, default value is 'spec/pacts/*.json'
task.pact_broker_base_url = 'https://ascent.pactflow.io'
task.tag_with_git_branch = true|false # Optional but STRONGLY
task.tags = ["dev"] # optional
task.pact_broker_token = 'pDWJsxMuthyK693Dhh7kja' # Bearer token
end```
gabe707
2021-02-17 14:43
if I use the pact broker token in here it gives an error of not recognizing that
gabe707
2021-02-17 14:45
Tagging version 1.0 of Ascent Rails as "dev"
Failed to tag version 1.0 of Ascent Rails due to error: PactBroker::Client::Error - Authentication failed}
gabe707
2021-02-17 14:51
*? service_providers* *git:(gabe-tests) ?* rake pact:publish
rake aborted!
NoMethodError: undefined method `pact_broker_token=' for #<PactBroker::Client::PublicationTask:0x00007ff836a143f8>
Did you mean? pact_broker_base_url=
arindam.datta
2021-02-17 15:57
Hi @bethskurrie and @matt.fellows: I have a scenario where I am stuck and I don't know how to come out of this. The situation is like this:
1. Provider v1 and Consumer v1 are deployed on `prod` env.
2. Provider team decided to change an existing propertyName from `TwoFactor` to `TFA`.
3. Provider team tries to deploy v2, but fails. This is expected as this breaks contract with Consumer v1 which is already deployed on `prod`.
4. Now Consumer team also renames the property to `TFA`
5. Consumer team tries to deploy v2.
6. New Consumer pact is published to Broker with version `v2` and gets tagged with `master`
7. Consumer v2 is failed to be deployed (fails at Can-I-Deploy) since the provider v2 is not deployed to `prod` (provider v2 failed at step 3 above)
---------------------------------------------------
Now the situation seems like a deadlock. Situation on broker now is like below:
arindam.datta
2021-02-17 15:58
Moreover, When my providers `main` pipeline triggers, I get the following message during verification test even though `Pending Pact` is enabled, also `wipSince` is included: `This pact has previously been successfully verified by ProviderSvc. If this verification fails, it will fail the build. Read more at https://pact.io/pending`
bethskurrie
2021-02-17 21:32
@gabe707 firstly, please rotate your token because you've just put it up for the world to see!
bethskurrie
2021-02-17 21:33
Secondly, what version of the pact_broker-client gem are you using? It looks like you have an old version there.
bethskurrie
2021-02-17 21:40
@arindam.datta the only way to get both the consumer and provider out keeping everything green is to duplicate the field.
bethskurrie
2021-02-17 21:40
1. Provider adds TFA field (keeping TwoFactor as well) and deploys to prod
matt.fellows
2021-02-17 22:16
this is called the expand and contract approach, and is really the only real approach aside from brute forcing into production and ?deploying together?
arindam.datta
2021-02-18 05:09
Thanks @bethskurrie and @matt.fellows, I'll practically apply the steps as mentioned by Beth, hope it'll solidify my understanding.
@hiteshpatadia, this :point_up: is the situation we got ourselves into yesterday.
arindam.datta
2021-02-18 05:11
@bethskurrie, another closely related question: if instead of renaming, Provider had removed an existing property, then also we would be into similar situation?
matt.fellows
2021-02-18 05:14
if you remove a field that a consumer uses, the provider will be blocked until all consumers stop using it
matt.fellows
2021-02-18 05:14
Otherwise, it would lead to you deploying something that will break the consumer in production
arindam.datta
2021-02-18 05:36
Thanks a lot @matt.fellows and @bethskurrie, you guys are such helpful!
arindam.datta
2021-02-18 05:49
Thanks for participating in this discussion @bethskurrie and @matt.fellows. Talking to you always elevates my confidence in the world of contract testing. You guys are such helpful and passionate. :pray:
arindam.datta
2021-02-18 08:15
@khandelwalbhushan, bringing your notice into this thread. This is the situation we got ourselves into.
brendan.donegan
2021-02-18 10:42
So, we have a recurring problem with people inventing provider names because they don?t understand how Pact works. I was wondering if there?s any feature available to that contracts can?t be published unless the provider name already exists?
bethskurrie
2021-02-18 10:43
There's a feature that detects "similar" names and raises an error if people try to publish "foo-service" and "Foo Service".
bethskurrie
2021-02-18 10:43
There is not that thing that you want. However, I was planning on adding a "merge" feature for when people do exactly what you're talking about.
bethskurrie
2021-02-18 10:48
Put a vote on that merge one, or feel free to raise another feature request in canny
bethskurrie
2021-02-18 10:48
TBH, people need lots of structured education about how to use pact anyway.
brendan.donegan
2021-02-18 10:49
most common misunderstanding is people thinking provider === endpoint
brendan.donegan
2021-02-18 10:50
definitely one of the biggest challenges is getting large groups of people to ?get? it
bethskurrie
2021-02-18 10:50
the orgs that have the best success with pact do a lot of internal training
abubics
2021-02-19 00:15
fwiw, conflating concepts like endpoint & provider seems like a deeper issue to me . . . some internal DDD (domain-driven design) training might have a lot of collateral benefits :slightly_smiling_face:
bethskurrie
2021-02-19 00:16
I've seen the terms mixed up in organisations that follow a very old school technology approach, esp windows related. So I think there are tools/conceptual frameworks that do use the term "provider" to mean a single endpoint.
abubics
2021-02-19 00:17
Definitely, in .net, that is an overloaded term. Lots of `[*Provider]` annotations from my memory :upside_down_face:
abubics
2021-02-19 00:19
That is a distinction that's important across different levels of abstraction. Provider here is a system-level component, not a code-level component :thinking_face:
abubics
2021-02-19 00:19
I always wonder if that's the issue at a particular place, or how many other guesses could be correct :sweat_smile:
bethskurrie
2021-02-19 00:19
it is a very generic and overloaded term. There are docs that explain it, which leads me to think they haven't been read.
brendan.donegan
2021-02-19 09:41
I think different orgs use different terms to describe what a ?provider? actually is, and almost no-one uses ?provider?
brendan.donegan
2021-02-19 09:43
I wrote this in our internal docs:
```A provider in Pact refers to an individual service which provides data to a consumer, primarily in our case, through a REST API. Being independent refers to the fact that it can be deployed separately from any other service. Individual endpoints provided by the same service are not separate providers. Examples of providers are e.g. IDS GRID API, Assignments API, Wormhole, etc. Conversely, Student Assignments API and Teacher Assignments API would not be separate providers because these endpoints both belong to the Assignments service and cannot be deployed separately.
Provider names are an important part of the contract as they are used in the provider verification step to get contracts which apply to the particular provider being verified. For this reason it is important not to use arbitrary values for the provider name. Many providers are already defined on the Pact broker so prior to adding new Pact tests you should check if the provider already exists and use the same name. If the provider you need does not exist, then you should speak to the team that maintains the provider and agree on a name to use, so that they can use it too when they set up the verification.```
abubics
2021-02-19 12:49
Maybe a helpful distinction (which is probably in the docs) is that in the context of an interaction, there's a consumer making a request, and a provider facilitating the request, providing a response.
But outside that context, the terminology is irrelevant. For example, a provider can also be a consumer if it talks to other APIs.
arindam.datta
2021-02-19 15:15
Hi @beth (http://pactflow.io/Pact Broker/pact-ruby) and @Matt (http://pactflow.io / pact-js / pact-go), sorry that I come here every now and then with some situation and expect you guys will help me out :slightly_smiling_face: , but being a novice in CDC coming to the experts is my only option. 2 days back you helped me with a situation by suggesting the `expand and contract approach`. Today I am stuck with the following situation. Consider I have the exactly same set-up as javascript ci-cd workshop:
1. Provider v1 is deployed on ``prod`` where the Product has two properties (along with many others) ``seller`` and ``stock``
2. Consumer v1 is deployed on ``prod`` which uses the above two propertis.
3. Now Provider removes one property ``stock``.
4. Provider team tries to deploy Provider v2, but fails. It's expected, since it breaks the contract.
5. Now Consumer team also removes the property ``stock``.
6. Consumer team tries to deploy Consumer v2, which in turn triggers Provider verification on ``master`` branch. Verification by Provider v2 is successful. But Consumer still fails to deploy since Provider v2 is not on production yet.
This again seems like a deadlock situation. The situation on Broker is like below:
Cc: @hiteshpatadia @khandelwalbhushan
phil.endsley
2021-02-19 16:15
If you're just removing a property for consumer v2, it should still pass verification with provider v1. So in order to get v2 for both consumer and provider deployed:
1. Deploy consumer v2 (This should work, because consumer v2 is compatible with provider v1)
2. Deploy provider v2 (This should work, because provider v2 is compatible with consumer v2)
> Now Provider removes one property ``stock``
If this change was merged into the main branch, I would expect the provider build to start failing, because they introduced a breaking change. This version of the provider cannot be safely deployed independently until it satisfies all the contracts with it.
If the provider build is broken because of the failing contract, I think your challenge will be running verification against only consumer v2
arindam.datta
2021-02-19 16:28
Hi @phil.endsley, if you look at my sequence, I removed the property from provider first on master itself (though absolutely against rule). Then, I removed it from consumer, this too on master(against rule again). Now the consumer build triggers provider verification which checks out master branch of provider. So, once the verification is done, the result is published to broker for Provider version v2 which is not yet on prod. As a result the can-i-deploy step of consumer fails because it's pact was NOT verified by provider v1. So, now I am stuck. None of them can go to production now. What should I do to come out of this situation is my question. I know, in real development process I'd never do any changes directly on master.
brendan.donegan
2021-02-19 17:12
i presume the issue here is that when you?re asking the question ?does v2 of my consumer work with v1 of the provider (the version on prod)? the answer from can-i-deploy is going to be no, not because it doesn?t work with v1 (it actually does), but because it was never verified with v1?
bheemreddy181
2021-02-19 18:00
Question around slack notifications https://docs.pact.io/pact_broker/webhooks/template_library/#slack---post-notification , is the idea to have same body for contract content changed and contract verification published
arindam.datta
2021-02-20 06:00
Hi @brendan.donegan, yes I know. Now, how can I get out of this situation, in other words, how can I get the 'v2' of both provider and consumer deployed on production? Do I need to make any change in any ci-cd pipeline? Note: Please consider I'm using exactly the same workflow as the javascript ci-cd workshop.
arindam.datta
2021-02-20 06:05
How can I get it verified by v1 now? With existing pipeline henceforth consumer pact will always be verified by provider v2 because that's the last commit on provider repository. I know I need to make some ad-hoc changes, but want to know what'll be the best place.
brendan.donegan
2021-02-20 11:10
so ideally v2 should never have been accepted as the ?master? version when it broke the contract, so that is a hole in your process, but i understand it already happened and you?re looking for a way out.
arindam.datta
2021-02-20 11:17
Reverting is something I'd like to keep away from for now. But I got it now. I also thought same way that I must "somehow" get consumer v2 validated by provider v1 either locally or by triggering provider validation pipeline with v1 commit hash. Thanks for the suggestion @brendan.donegan.
brendan.donegan
2021-02-20 11:19
Personally i think it would be nice if Pact had some logic to auto-validate contracts that are not the same per se but are valid together
arindam.datta
2021-02-20 11:20
Though in ideal situation we'd never change master directly and only merge PR when verification (for provider) and can-i-deploy (for consumer) are successful.
brendan.donegan
2021-02-20 11:20
so if v2 of the consumer doesn?t need the `stock` field then it should be auto-validated against all versions of the provider, even ones that don?t return the `stock` field
brendan.donegan
2021-02-20 11:21
@arindam.datta that?s the current model. really it?s not good development practice to merge code that *known* to be broken
arindam.datta
2021-02-20 11:23
As I said in the very first message that by going against all good practices I got myself into this deadlock.
matt.fellows
2021-02-20 11:37
> Personally i think it would be nice if Pact had some logic to auto-validate contracts that are not the same per se but are valid together
>
I think these things are possible but requires some magic on the way it works today.
In our new bi-directional contracts feature (starting with OAS) this is possible. A consumer can publish brand new expectations that the broker has never seen, but if they are a subset of what the provider has already validated (in this case a OAS) it sails thru
bethskurrie
2021-02-21 04:03
@arindam.datta the consumer/provider has to deploy the change to production before the other one can merge.
bethskurrie
2021-02-21 04:04
This is not a problem introduced by Pact - it's a reality that is highlighted by the use of Pact.
bethskurrie
2021-02-21 04:05
Pre-pact, if you removed the column presence/usage in both sides, and then deployed them together to a test environment, the integration tests would pass.
bethskurrie
2021-02-21 04:06
If one side then deployed to production, before the other one did, it would have silently broken the integration, and you either wouldn't notice, and there would be corrupted data, or there would be a defect raised in production until the other side was deployed.
bethskurrie
2021-02-21 04:07
So you are left with either coupled deployments (which negates the whole point of microservices) or you are left with following the "expand/contract" aka "always backwards compatible with production versions" sequence of changes that Pact will help you achieve.
bethskurrie
2021-02-21 04:09
> ideally v2 should never have been accepted as the ?master? version when it broke the contract
Yes, this. The only changes that go into master should be ones that are backwards compatible with the production version of the other. Otherwise, you're back in coupled-deployments world.
bethskurrie
2021-02-21 04:10
It might feel like you're bumping into blocked paths every time can-i-deploy fails, but it's sending you a valid message.
bethskurrie
2021-02-21 04:14
If they're both the same, then the only thing you can really say is "something happened"! You probably want different messages.
yann.courtel
2021-02-22 09:07
Hi Arindam, we had that conversation many times in our organization when we have a couple of hundred services with PACTs. The point here is that you need to be flexible enough to allow changes to happen so the PACT deadlock doesn't happen. On our side, we decided to be restrictive on the provider side at build time but to not block the consumer side (just a warning) when we trigger a provider build. That way you can still fix the situation with a half validated contract... Hope that makes sense and can help you. Good luck.
siddharth.gupta
2021-02-22 13:33
Hey folks , i was socializing Pact with engineering teams. one question that came out is how do we inform Consumers early and technically of APIs that are planned to be depreciated in incoming releases and encourage them not to use it . This is one of the major questions coming out from the socialization sessions with engineering teams .
brendan.donegan
2021-02-22 13:37
I wouldn?t say this is the purpose of Pact (maybe something like this is planned though). Here you just use good old fashioned documentation and communication
brendan.donegan
2021-02-22 13:38
Pact is more to make sure you don?t finally remove that API when not all consumers are ready for the change
siddharth.gupta
2021-02-22 13:43
thanks for the reply , we already have some versions of provider released . I still believe there could be a technical mechanism to notify consumers of APIs planned to be deprecated . For example some tagging mechanism or some notification mechanism within Pact to inform consumers .
brendan.donegan
2021-02-22 13:54
I can?t really comment on what?s planned but I kind of get the feeling that deprecation model is somewhat defeating the purpose of Pact
brendan.donegan
2021-02-22 13:54
Because with Pact you should be able to make a version of your consumer that just removes the field, and find out all the consumers that might be broken by that, with 100% accuracy
siddharth.gupta
2021-02-22 14:00
ok so if I get it right , we can intentionally break the test by modifying\failing the API to be deprecated. But I still believe there should already be a smoother technical mechanism to notify consumers .
ryanlevell
2021-02-22 17:33
On docker v2.78.1.1 I do not see the red/green verification results on the matrix page (home page shows colors correctly). Background is just white. Is anyone else experiencing this?
matt.fellows
2021-02-22 22:49
so yeah, you can intentially break things on the provider side to see how things impact consumers, but Pact won?t let you release that breaking change of course
matt.fellows
2021-02-22 22:49
As far as deprecations go, we?ve been thinking about this in Pactflow. We have just released our provider driven (bi-directional contracts) flow which lets a provider publish an OAS. This baseline feature enables us to build a number of workflows not previously available to us.
matt.fellows
2021-02-22 22:50
Deprecations may be one of them, but right now, we don?t have first class support for doing it, as Brendan mentioned
bethskurrie
2021-02-23 00:27
@ryanlevell I recently upgraded bootstrap and may have broken something. Are you still seeing the issue?
bethskurrie
2021-02-25 00:58
@ryanlevell can you raise an issue please in https://github.com/pact-foundation/pact_broker/issues
bethskurrie
2021-02-25 01:02
@stefanos.varsanis the version ordering started out being semantic, but we've deprecated that long ago, and if you have a Pact Broker version from the last few years, it will just be ordering by the creation date of the version resource
bethskurrie
2021-02-25 01:03
@stefanos.varsanis and @sabil.beladri https://github.com/pact-foundation/pact_broker/discussions/384
bethskurrie
2021-02-25 01:05
@anastasiia.bielik please vote for https://pact.canny.io/feature-requests/p/allow-results-for-specified-pacticipants-to-be-ignored-when-executing-can-i-depl
bethskurrie
2021-02-25 02:22
Does anyone use can-i-deploy with a blue green deployment release process, or for other reasons have multiple versions of a *provider* in the same prod environment at the same time? Please talk to me in a thread here, and tell me about your use case. I'm interested in which deployed version gets undeployed when you deploy a new version. Eg. for most deployments, the previous version gets "undeployed" or overwritten by the new version immediately. With blue green deployments (which I've never done) there's a period of time where there are two versions in prod, and from what I understand, it's not the *previous* version that gets undeployed, it's the one before that (if you're deploying to alternate environments and switching back and forth - I may misunderstand how this works though, and would love clarification).
matt.fellows
2021-02-25 02:42
So with blue green, you have 2 production environments running that you switch between (via DNS, Load Balancers etc.) when deploying.
So let?s say that green is currently live (v2/latest), and blue is standby (v1). When you release, you deploy to blue (v3) and then cutover. There is a potential period where both are running simultaneously.
matt.fellows
2021-02-25 02:43
Red/black is a variant of the above, except that you always tear down the stack that?s no longer live (usually to save costs, but also to avoid drift associated with long running instances etc.)
matt.fellows
2021-02-25 02:44
blue/green is often just meant to mean ?no downtime deploys? and the specific implementation could change (e.g. kubernetes/docker can change the how here)
Canarying and traffic shifting is where you gradually send traffic to the new environment, and gradually increase until you?re confident in the change.
abubics
2021-02-25 03:44
I think there are many variants of blue/green or red/black zero-downtime deploys, where different-sized sets of resources are deployed/undeployed, e.g.
? scale up an ASG or Fargate cluster,
? deploy a whole new scaling group,
? etc.
Then whether you keep the new or the old depends on some kind of smoke tests, whether canary, or test suite, or whatever.
abubics
2021-02-25 03:44
Is the question targeting situations where both old & new are running together for a longer period? Or anything where they may both get traffic, however short the window?
bethskurrie
2021-02-25 03:56
I'm after feedback on what which pacts should be included for the new "auto select pacts" feature described here: https://github.com/pact-foundation/pact_broker/discussions/391
bethskurrie
2021-02-25 03:59
@sagupta sorry, I never saw this. "consumer" is a supported field in the consumer version selectors object.
antonello
2021-02-25 10:59
We use blue/green deployment.
Our current approach is to remove the `prod` tag from version we?re flipping from and add it to the version we?re flipping to.
This has always been considered a compromise, because we have multiple ASGs, and we don?t flip them all in one go. Although almost always they?re all flipped within seconds from each other.
yousafn
2021-02-25 19:00
I will have a good read and put the thinking cap on this weekend. First takeaway from reading is anything to lower the barrier of entry especially when it comes to design decisions that have long standing ramifications ( a bad choice of versioning ) so there is a lot for a champion or a few in a org to get right whilst trying to get buy in from the wider org.
Would we need to be backwards compatible for older users not wanting the new func and how can we ensure that when we release a new image and an older user updates their PB, that they have a seamless transition.
bethskurrie
2021-02-26 00:01
@yousafn all existing functionality would still work exactly the same way.
bethskurrie
2021-02-26 00:03
There would be an explicit setting that would need to be configured for the broker to choose the "best practise" pacts for you, and all the rest of the features would now be considered "advanced".
bethskurrie
2021-02-26 00:04
eg. instead of the current recommended configuration which is documented here https://docs.pact.io/provider/recommended_configuration#verification-triggered-by-provider-change :
```consumerVersionSelectors: [
{
tag: "main",
latest: true
},
{
tag: process.env.GIT_BRANCH,
latest: true
},
{
tag: "test",
latest: true
},
{
tag: "production",
latest: true
}
],
enablePending: true,
includeWipPactsSince: process.env.GIT_BRANCH === "main" ? "2020-01-01" : undefined,```
young
2021-02-26 09:52
Hi team, when I update the pact_broker client to 1.36.0 , publishing the pacts to the broker was failed:
```#!/bin/bash -eo pipefail
pact-broker publish --consumer-app-version ${CIRCLE_SHA1} --tag ${CIRCLE_BRANCH} -b ${PACT_BROKER_URL} -u ${PACT_BROKER_USERNAME} -p ${PACT_BROKER_PASSWORD} ./Pacts
/opt/circleci/.rvm/gems/ruby-2.3.1/gems/pact_broker-client-1.36.0/lib/pact_broker/client/cli/broker.rb:224:in `publish_pacts': undefined method `compact' for #<Hash:0x00000003181020> (NoMethodError)
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/pact_broker-client-1.36.0/lib/pact_broker/client/cli/broker.rb:64:in `publish'
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/thor-1.1.0/lib/thor/command.rb:27:in `run'
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command'
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch'
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/thor-1.1.0/lib/thor/base.rb:485:in `start'
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/pact_broker-client-1.36.0/lib/pact_broker/client/cli/custom_thor.rb:15:in `start'
from /opt/circleci/.rvm/gems/ruby-2.3.1/gems/pact_broker-client-1.36.0/bin/pact-broker:4:in `<top (required)>'
from /opt/circleci/.rvm/gems/ruby-2.3.1/bin/pact-broker:23:in `load'
from /opt/circleci/.rvm/gems/ruby-2.3.1/bin/pact-broker:23:in `<main>'
from /opt/circleci/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `eval'
from /opt/circleci/.rvm/gems/ruby-2.3.1/bin/ruby_executable_hooks:15:in `<main>'
Exited with code exit status 1
CircleCI received exit code 1```
young
2021-02-26 10:02
and this is my command:
```pact-broker publish --consumer-app-version ${CIRCLE_SHA1} --tag ${CIRCLE_BRANCH} -b ${PACT_BROKER_URL} -u ${PACT_BROKER_USERNAME} -p ${PACT_BROKER_PASSWORD} ./Pacts```
bethskurrie
2021-02-28 22:50
@antonello I'll have to get you to test out the new `record-deployment` and `record-undeployment` commands. That's exactly the kind of slightly more complex scenario I was trying to work out if there would be a better way to support.
ryanlevell
2021-02-28 23:25
@bethskurrie sorry, didn?t get to this. But just downloaded 2.79.0.0 and looks good! Thanks for the fix.
antonello
2021-03-01 07:02
That would be great! I have been pretty busy with other things, so I haven?t been following too closely, but I can get the gist.
M
arindam.datta
2021-03-02 08:06
I added few users on PactFlow. One of them didn't receive email with temporary password. How can I make sure that the person receives the email? I don't see any delete user option, otherwise I could delete the user and add again.
matt.fellows
2021-03-02 08:07
Try to re-invite them. If they didn't receive it though it might be in spam
matt.fellows
2021-03-02 08:08
Not much you can do about making sure they receive them, unfortunately email is a bit like that. We use DKIM/SPF/DMARC etc but that doesn't always guarantee delivery
arindam.datta
2021-03-02 08:14
Hi @matt.fellows, already verified that the email is not even in Spam/Junk. Not sure how to re-invite as the User is already added to the Users list and I don't see any option to delete. However, I've tried to Invite the same user again ( ignoring the fact that the user was already added) and hope that the person gets an email now.
matt.fellows
2021-03-02 08:20
Yep that's an undocumented trick that should try to restart that process
matt.fellows
2021-03-02 08:29
Drop an email to with the details if you're still having issues and we can did deeper there
thanuxxxx
2021-03-02 20:53
I set `PACT_BROKER_ALLOW_PUBLIC_READ=true` which makes to verify provider side without having any authentication. Do I still need auths to publish the results back to broker?
thanuxxxx
2021-03-02 21:29
Since I set PACT_BROKER_ALLOW_PUBLIC_READ=true, I don't need a credentials to verify provider side of my pact tests. That's works fine. The problem is I have a code block like this to publish the results back to broker
``` private static final String PACT_VERIFIER_PUBLISH_RESULTS_KEY = "pact.verifier.publishResults";
private static final String PACT_VERIFIER_PUBLISH_RESULTS_VALUE = "true";
private static final String PACT_PROVIDER_VERSION_KEY = "pact.provider.version";
private static final String PACT_PROVIDER_TAG_KEY = "pact.provider.tag";
private static final String PACT_PROVIDER_VERSION_GIT_COMMAND = "git rev-parse HEAD";
private static final String PACT_PROVIDER_BRANCH_GIT_COMMAND = "git rev-parse --abbrev-ref HEAD";
@BeforeEach
public void setAdditionalPactProperties() throws IOException, InterruptedException {
System.setProperty(PACT_VERIFIER_PUBLISH_RESULTS_KEY, PACT_VERIFIER_PUBLISH_RESULTS_VALUE);
System.setProperty(PACT_PROVIDER_TAG_KEY, PactTestContext.getGitDetails(PACT_PROVIDER_BRANCH_GIT_COMMAND));
System.setProperty(PACT_PROVIDER_VERSION_KEY, PactTestContext.getGitDetails(PACT_PROVIDER_VERSION_GIT_COMMAND));
}```
thanuxxxx
2021-03-02 21:30
Because I removed those credentials I am planning to do something like this
```stage ('Build') {
steps {
sh './mvnw clean verify
-Dpact.provider.version=${GIT_COMMIT}
-Dpact.verifier.publishResults=true'
}
}```
matt.fellows
2021-03-02 21:31
You'd need to ask in pact JVM channel for clearer advice. I'd be wrapping the system property set operationa in an if/else, setting them outside of the script and in the maven/gradle file, or in the environment itself
ryanlevell
2021-03-03 01:19
`pactbroker.auth.username` and `pactbroker.auth.password` . One way to pass the credentials safely is using the Jenkins credentials store, then the credentials can be safely accessed with the `withCredentials` block via environment variables (if using pipelines). https://www.jenkins.io/doc/pipeline/steps/credentials-binding/
I don?t use the system properties directly as you are, I am using the surefire plugin to pass the system properties as part of the maven `test` phase. But I am using the `withCredentials` to keep the credentials secure. I trigger this conditionally (on jenkins only) by putting the surefire plugin in a maven profile that is only activated when the credentials are present.
ryanlevell
2021-03-03 01:36
You could do something similar in `@BeforeEach`.
```// PB_USERNAME comes from withCredentials (name it what ever you want)
if(System.getenv("PB_USERNAME") != null) {
// set credentials & publish to true
}```
thanuxxxx
2021-03-03 01:39
This is a spring boot project and I have this in to my properties file.
```pactbroker.auth.username=${PACT_BROKER_USERNAME}
pactbroker.auth.password=${PACT_BROKER_PASSWORD}```
I just need to use `withCredentials` and set those variables
arindam.datta
2021-03-04 05:04
Getting this response from `stub` url on `PactFlow`. Seems something wrong
matt.fellows
2021-03-04 06:58
It only supports post, you need to add your request path to the end of it and use the right http method
arindam.datta
2021-03-04 07:02
Sorry, I didn't understand. Can you please elaborate little bit? This file was generated by Consumer test. Do I need to do something additional in the Consumer Test itself?
matt.fellows
2021-03-04 07:04
You were issuing a get request to the stub of your contract, but there is no GET in your contract. You also need to append your interaction path to the stub when calling it
matt.fellows
2021-03-04 07:06
Most contracts have multiple interactions in them so you need a way to find the specific interaction to stub. after the stub path it looks at the method the headers, the path and the body and uses that to work out which interaction to return
irldev
2021-03-04 07:49
Hello, I have a question about webhooks on the pact broker. We have a provider that has a few consumers however when I created a webhook for one of the contracts, it seemed to create a webhook for both consumers of that provider. I may have done it wrong but I used the non-get function in the Hal browser for pb:webhooks to create it. Should I have used the non-get function for pb:webhook (singular)? I'm not sure what the difference is between pb:webhooks and pb:webhook.
matt.fellows
2021-03-04 07:51
If you omit the consumer name when creating the webhook it will fire for all consumers of the specified provider
matt.fellows
2021-03-04 07:52
I can't remember the correct relation to use off the top of my head though
matt.fellows
2021-03-07 02:05
@sagupta :wave: just wondering if you had any experience to share with Gitlab using our CLI tools?
matt.fellows
2021-03-07 02:05
Somebody is having an issue running the container: https://github.com/pact-foundation/pact-ruby-standalone/issues/64
sagupta
2021-03-07 17:26
Yes we use Gitlab in my company and i have experienced many errors while trying to setup the pact workflow.
I have reproduced the issue and suggested the solution in the issue comment :slightly_smiling_face:
matt.fellows
2021-03-07 21:12
Thank you so much, this was very helpful. hopefully they are unblocked now
aparnachaudhari
2021-03-10 06:08
Hello, can someone please direct me to any samples for running pact-broker in kubernetes? We are hoping to use basic auth and have a postgres db made available for us to connect to.
matt.fellows
2021-03-10 06:10
I don?t know of any sample projects, but I?ve seen some helm charts about
matt.fellows
2021-03-10 06:11
Search the channel for helm, or if it?s lost to Slack history take a look at https://docs.pact.io/slack/ and search #pact-broker (probably)
aparnachaudhari
2021-03-10 20:35
Are pact-broker tokens supported only on pactflow hosted service? I do not see (or might not have looked correctly) documentation on how I can setup pact-broker with a token instead of a username and password
aparnachaudhari
2021-03-10 20:37
https://docs.pact.io/pact_broker/docker_images/pactfoundation is where I am looking
aparnachaudhari
2021-03-10 20:57
I am using the pact-foundation/pactbroker docker image to spin up the pact-broker service on our internal k8
brendan.donegan
2021-03-16 08:46
is there any option to gracefully exit the publish command if the directory specified is not found, or do we need to check ourselves for its existence when trying to publish?
matt.fellows
2021-03-16 09:56
are you referring to the `pact-broker` command or one of the language specific variants? (e.g. JVM pactPublish)
brendan.donegan
2021-03-16 10:18
I?ve had to do a fairly ugly hack to make sure all the pact files are written to the same directory
bheemreddy181
2021-03-17 17:13
```provider
"http://registry.terraform.io/pactflow/pact" produced an unexpected new value: Root
resource was present, but now absent.
This is a bug in the provider, which should be reported in the provider's own
issue tracker.
time=2021-03-17T16:31:57Z level=error msg=Hit multiple errors:
Hit multiple errors:
exit status 1```
Any idea why we see these errors from pact terraform ^
matt.fellows
2021-03-18 01:55
I can?t tell exactly what happened from that, but if could please share the full log output and raise a bug we can take a look
bethskurrie
2021-03-21 21:59
If you're using docker, you'd have to be careful about whether it globbed the internal of the external files though :thinking_face:
bethskurrie
2021-03-21 22:01
Here's the code that should do the globbing, but it should do it at the shell level too https://github.com/pact-foundation/pact_broker-client/blob/master/lib/pact_broker/client/cli/broker.rb#L282
tjones
2021-03-24 01:35
Like Beth, I would do the publish once per project in a monorepo, not once for the whole repository
tjones
2021-03-24 01:36
This has the nice advantage that it?s easier to split the projects out of the repo if you ever need to do that
aparnachaudhari
2021-03-24 02:09
Hello, I am using the pact docker image from pactfoundation/pact-broker:latest, and trying to understand how I should be setting the whitelist configs as stated: https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks/#webhook-whitelist any help would be appreciated
matt.fellows
2021-03-24 02:13
It goes in the `http://config.ru` file: https://docs.pact.io/pact_broker/configuration/#default-configuration-values
aparnachaudhari
2021-03-24 02:24
We run two nodes of the pact-broker instance, does that mean I have to edit this config file on both ?
matt.fellows
2021-03-24 02:25
It?s a config file, so if you don?t use the vanilla docker image, you?ll need a pipeline to be able to configure it and probably produce your own container image
aparnachaudhari
2021-03-24 02:26
ohh? doing it via env.var might be much more easier for us. .. we already have a k8 deployment that we can pass those in
sagupta
2021-03-24 10:18
Hello Team,
I am trying to setup a webhook for a consumer when consumer requests a new feature from provider . So in this workflow , in consumer CI , `can-i-merge` fails and that triggers a webhook to provider verify which also fails.
Now after provider has implemented changes , i want to inform consumer to merge the change via slack . Does anyone has a template for this webhook? Should this be a specific webhook for this consumer?
bethskurrie
2021-03-25 01:50
@sagupta there is a provider_verification_succeeded webhook that you can use.
bethskurrie
2021-03-25 01:50
Unfortunately, there's no way to filtner on branches at the moment, but I'm currently working on it.
bethskurrie
2021-03-25 01:57
In your case, you'd want to say "trigger the webhook when a successful verification from provider branch <main branch> for <not main branch of consumer>"
bethskurrie
2021-03-25 01:59
@matt.fellows @aparnachaudhari the env vars are here https://docs.pact.io/pact_broker/docker_images/pactfoundation#webhooks
matt.fellows
2021-03-25 02:00
It?s very confusing, because if you start https://docs.pact.io/pact_broker/configuration/#default-configuration-values you probably aren?t likely to look at the docker docs independently of it
bethskurrie
2021-03-25 02:01
I've started putting in links to the docker configs in various sections, but haven't gone and updated everything.
matt.fellows
2021-03-25 02:02
sounds good. For context (and this may just be me of course) but, in my head, docker is just the distribution format. So I?d expect the docker docs to basically just say ?here?s how to run the image, go here for the rest of the docs?
bethskurrie
2021-03-25 02:05
if you're using a get or a delete for a webhook, you're doing it wrong :laughing:
matt.fellows
2021-03-25 02:05
> the env vars are completely an artifact of the docker distribution.
right, I guess that makes sense in a way. But feels like it shouldn?t be docker specific
bethskurrie
2021-03-25 02:06
If I had all the time in the world, I could move that code into the core. But it probably won't get done :laughing:
aparnachaudhari
2021-03-25 02:07
I can see the use of these being in the pact broker docker docs .. I probably did not :eyes: enough..
bethskurrie
2021-03-25 02:42
For the 3 people who ever read the intro paragraph of a documentation page :laughing:
c.pavan1986
2021-03-25 07:41
I am using pact-broker cli version 1.88.11-win32 , can-i-deploy, It fails with Error making request - OpenSSL::SSL::SSLError SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B:
c.pavan1986
2021-03-25 07:42
With docker based implementation of pact-broker things work fine with PACT_DISABLE_SSL_VERIFICATION="true"
sagupta
2021-03-25 09:27
If i understand it right, the provider_verification_succeeded is triggered whenever a provider successfully verified a pact. And that verification will also be used for all past same pact tags.
So if i setup this webhook to post a slack notification to consumer , they wont know if this success verification is for the new feature or the other main branch or something else.
Also we tag consumer with git branch name with every build, and if we do not have a common standard for defining branch name then the above mentioned solution wont work, right.
matt.fellows
2021-03-25 10:57
It?s fixed, the issue is about supplying the custom SSL details. You?re asking for something different - to disable SSL verification altogether (usually a bad idea, the reasons you likely have invalid certificates is because you work in a corporate environment that values security enough to make it painful to do it a sensible way, which is to use a certificate issued from a trusted public authority).
The change that completely disables SSL verification is only in that docker version - see this commit: https://github.com/pact-foundation/pact-ruby-cli/commit/8375dc8dac9bc7c378f7e230c5b36efce0d3c948
matt.fellows
2021-03-25 10:58
If you could please create a separate issue with that request (if you really need it, and can?t supply the SSL details any other way), that would help
abubics
2021-03-25 23:42
> that values security enough to make it painful to do it a sensible way
I feel this so deeply. It's very upsetting.
matt.fellows
2021-03-25 23:55
There is a large amount of irony that comes with ?making something more secure, by making it more hard to actually stay secure?
matt.fellows
2021-03-25 23:55
the `--insecure` flag used to get a good run at <insert customer here> for any tool that supported it
abubics
2021-03-26 00:40
> If we force everyone to use our self-signed cert, we'll be secure and in control . . .
matt.fellows
2021-03-26 06:54
You get one ?read only? account and one ?read/write? account. So developers should have the read-only one, and CI uses the read/write one
matt.fellows
2021-03-26 06:55
The OSS broker doesn?t have a user/permissions model, hence it was the first thing we created over at http://pactflow.io
dave.clissold
2021-03-29 12:54
Hi everyone. I am probably being really stupid, but I'm struggling to get the pactfoundation/pact-broker docker image to connect with a remote database. I am getting the following error when launching the docker image with this command `docker run pactfoundation/pact-broker -e PACT_BROKER_DATABASE_USERNAME=Username -e PACT_BROKER_DATABASE_PASSWORD=Password -e PACT_BROKER_DATABASE_HOST=rdstest1.********.http://eu-west-1.rds.amazonaws.com -e PACT_BROKER_DATABASE_NAME=postgres -e PACT_BROKER_DATABASE_PORT=5432 -p 9292:9292`
```Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma)```
I can access the database using gui clients and the command line, so it's not an aws permissions or iam issue. Can anyone advise where I might be going wrong?
scott.riley111
2021-03-29 13:36
if you get a shell into the container - can you connect to the database? with `psql` or something
dave.clissold
2021-03-29 14:09
I don't have shell access to the container, but am able to connect to the database using pgadmin
bethskurrie
2021-03-29 20:26
Try constructing the the connection string as you would to connect using `psql ` and run the command from your shell. Then set that as the PACT_BROKER_DATABASE_URL
bethskurrie
2021-03-29 21:05
I have Little Snitch on - that often causes issues for me connecting to things.
dave.clissold
2021-03-29 21:06
Hmmm, it is rather strange. Nothing that would be prevent or disrupt outgoing connections.
bethskurrie
2021-03-29 21:06
Can you start from something we know works, and keep modifying it until we identify the issue? See if you can get this docker compose file running https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose.yml
bethskurrie
2021-03-29 21:07
Add `PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "5"` to the broker service though
dave.clissold
2021-03-29 21:24
I'm going through the logs now and cannot see anything jumping out at me
dave.clissold
2021-03-29 21:26
Aye, those pesky little critters. Thankfully you were to hand with a bug swatter or a bug-be-gone spray! Once again thanks for your help
c.pavan1986
2021-03-30 09:25
Hi Matt, We are looking for a cli based solution for can-i-deploy with ability to supply SSL cert if needed. If any developer wants to check the can-i-deploy from local machine, it can be done using cli. There is case where developer would not have docker in local machine, to use a docker based solution.
chris.faulkner
2021-03-30 14:21
HI all - I am struggling to publish my verification results. I have a broker, I am authenticating to it, the PACT verification tests run but no publish of results. I am using JVM and gradle but thought I?d post here.
```./gradlew check -Dpact.verifier.publishResults=true```
What else do I need to do ?
sagupta
2021-03-31 07:17
I have setup a slack notification to send message to consumer team on `provider_verification_succeded` event but then consumer team will get it for all provider builds and there is no way to identify which one is the verification when provider has implemented the new feature so consumer can merge its branch
chris.faulkner
2021-03-31 08:29
Thanks - still struggling to see the verification results show up. I am not using the plugin. It didn?t seem like I needed it to get my verification tests to run against the broker. I just have my own gradle task where I set PACT_PROVIDER_VERSION , PACT_PROVIDER_TAG and PACTBROKER_CONSUMERVERSIONSELECTORS_TAGS but I just can?t get the publication phase to go
c.pavan1986
2021-03-31 14:15
Created a new issue
https://github.com/pact-foundation/pact_broker-client/issues/83
chris.faulkner
2021-03-31 15:36
I?m done now - not using the plugin which I am wondering is the right way to go
fnguyen
2021-03-31 17:38
I am not using PACT from jvm but from .Net; maybe it will help.
For the verification to work you must use the broker read-write token. if you use the read-only token, it won't be able to update the verification status on the broker.
uglyog
2021-03-31 21:51
Sorry, you are correct, if you are using unit tests you need to set the JVM system properties, but these need to be done on the test VM. The `-D` parameter sets the values on the VM running Gradle, but the tests run in a separate VM. You need to set the values in the test task.
bheemreddy181
2021-04-05 23:07
What I am trying to ask is if my consumer verified only one commit on a pull request the slack notification is triggered for multiple commits which it applies these verification results to
bheemreddy181
2021-04-05 23:08
Is there a way I can restrict that to only one which my consumer verified
bethskurrie
2021-04-05 23:08
No, unfortunately. You can raise a feature request at http://pact.canny.io
bethskurrie
2021-04-05 23:09
The webhook needs a flag to say "trigger for all pacts with the content or only the latest pact with the content"
bheemreddy181
2021-04-06 00:29
These slack notifications are too noisy and also confusing for people using it
sheyan.rizfee
2021-04-06 02:25
was able to find https://github.com/qamatic/helm-charts/tree/master/qamatic/pact-broker
Would pact provide an official helm chart in the future?
sagupta
2021-04-06 14:25
Hello Team,
I have setup a webhook for consumer for contract_content_changed event to trigger a pact-provider-test-webhook job and recently i noticed that for each new build in consumer, the webhook is getting triggered and hence the pact-provider-test-webhook job in provider .even though there are no additions or updates to the contract. I am not able to debug it . Any suggestions would be really appreciated
matt.fellows
2021-04-06 20:20
We could albeit it's not on our immediate list of TODO. Let us know how you go with that helm chart, we could consider bringing it in
mateusz.derks
2021-04-07 11:52
Can WIP contract report pending=false in the `/pacts/provider/:name:/for-verification` API? I have tried to use the reproduce-issue script to get such response with no luck.
sheyan.rizfee
2021-04-08 00:54
@matt.fellows we were able to set up the broker on K8 with some work around as there were some issues with the templates.
Nevertheless, our team has sent a PR to fix the issue https://github.com/qamatic/helm-charts/pull/7
However, there is another PR since 2019 without being merged and i doubt the repo is been managed. If the PR isn't merged, we would publish our own chart and will share with you.
bethskurrie
2021-04-12 05:14
> If the relevant consumer version has any tags, then for each tag, check if the content is different from the previous latest version for that tag. It is 'changed' if any of the checks are true. One side effect of this is that brand new tags will trigger a pact changed event, even if the content is the same as a previous version.
> If the relevant consumer version has no tags, then check if the content has changed since the previous latest version.
bethskurrie
2021-04-12 05:18
It will only include the pending:true for WIP pacts if you have pending enabled. The pendingEnabled applies to all the pacts included.
bethskurrie
2021-04-12 05:24
Do you have the URL for an offending pact? We can decode the metadata in the URL and see what's in there.
mateusz.derks
2021-04-12 06:29
thanks for the answer @bethskurrie, yes, we have `enablePending` option set to true, because we don?t want our WIP pacts to break the provider. However, based on https://docs.pact.io/pact_broker/advanced_topics/pending_pacts/#how-the-pending-property-works my understanding of `pending` flag was different. I thought once WIP contract is verified then it is no longer pending.
> It achieves this by treating the first successful verification of a pact version by a particular branch of the provider as an implicit acceptance of the contract.
This part of the explanation is not applicable to WIP contracts, right?
The metadata of the offending URL was `w=true`
bethskurrie
2021-04-12 06:31
It's not just that it needs to pass, it also needs to pass when included explicitly for verification.
bethskurrie
2021-04-12 06:31
I need to update the docs, as that was just in trial for a while. It's now released.
bethskurrie
2021-04-12 06:32
> The implication of this is that if a WIP pact is verified successfully when it was included in the list of pacts to verify because it was WIP, this successful verification does not stop it being a WIP pact. It only stops being a WIP pact when the content has been "approved" by having one of the tags that the provider team has chosen to support.
bethskurrie
2021-04-12 06:33
In terms of git branches, it stops being a WIP pact once the branch has been merged into master
mateusz.derks
2021-04-12 06:34
Yes, but then it?s accepted and no longer WIP. I was curious about the case when the the branch is not yet merged into master, but the contract is verified :white_check_mark:. I thought such contract won?t be pending according to the defintion of `pending` state.
bethskurrie
2021-04-12 06:36
I can't remember if this was a deliberate action, or whether it was an unintentional side effect.
bethskurrie
2021-04-12 06:38
I've just added "If you are using git feature branches with the branch name mapped to a tag, this means the pact will stay WIP until the branch is merged, even after a successful verification."
mateusz.derks
2021-04-12 06:40
I?m actually fine with current behavior of the pending flag. Since we don?t run WIP verification on branches of the provider we won?t be able to prevent a breaking change to be merged while consumer change is still on the feature branch.
I think mentioning that WIP contracts are always pending here https://docs.pact.io/pact_broker/advanced_topics/pending_pacts/#how-the-pending-property-works would clear the confusion.
bethskurrie
2021-04-12 06:40
> I thought such contract won?t be pending according to the defintion of `pending` state.
For WIP pacts, the pending flag is hardcoded to true in the constructor, not calculated. But we could calculate it.
mateusz.derks
2021-04-12 06:44
@bethskurrie for helping me understand relation between WIP and pending :taco:
bethskurrie
2021-04-12 06:44
Sometimes even Beth needs to help Beth understand the relationship between WIP and pending :stuck_out_tongue:
robert.strehli
2021-04-12 15:22
Hey, there is still the problem that message pacts can't be parsed for the view on the pact broker. Unfortunately I can't find anymore the issue somewhere documented. Just wanted to know if it's possible to vote up for this issue somewhere? :slightly_smiling_face: (If I recall correctly this is already fixed in pactflow but was never merged to the pact broker)
brendan.donegan
2021-04-12 15:46
Hi - I?m wondering is there a way to refer to a tag in the URL for the contract? We want to get a link to the one tagged with ?master?
matt.fellows
2021-04-12 22:34
Yep. it?s of the format `/pacts/provider/:provider/consumer/:consumer/latest/:tag`
e.g.
```https://testdemo.pactflow.io/pacts/provider/GettingStartedOrderApi/consumer/GettingStartedOrderWeb/latest/replgov```
matt.fellows
2021-04-12 22:35
so porting that change would mean porting the UI - which is not something we?ll do (at least, not just yet!)
bethskurrie
2021-04-13 04:44
@brendan.donegan click on the tag in the overview page and you'll get the URL options
robert.strehli
2021-04-13 06:57
Ah maybe I found it https://github.com/pact-foundation/pact_broker/issues/127
bethskurrie
2021-04-13 10:19
Question for anyone who has experience with the deployment approach where you have multiple instances of an app deployed in an environment at once (blue green etc). I'm trying to make sure that the "record deployment" command can tell the difference between "I'm calling record deployment for the same version/env as I have previously because I just re-ran my deployment script and I expect this call *not* to add an additional record" and "I'm calling record deployment for the same version/env as I previously because I have multiple prod instances, and I happen to be deploying the same version to a separate instance, and I do want it to create a new record". The way I think I'm going to tell the difference between the two scenarios is to add an --instance to the record deployment command, which would in the general use case be left blank, but in the situation where people are deploying multiples, would allow the command to work out whether to overwrite/create a new record. It would be a logical identifier, not a physical one. The question is - does such a parameter exist in a multi version deployment scenario? Eg. Do you know if you are deploying to blue or green in the deployment script?
abubics
2021-04-14 01:47
is it "instance" or "instance group" that you want to target? (e.g. blue vs instances inside blue)
matt.fellows
2021-04-14 02:04
Kind of what Boris says. For most approaches, it kind of doesn?t matter and you can think of a deployment as an atomic action. There are minor rollout strategy differences that I don?t think matter for the pursposes we care about.
The two examples I can think of is are:
1. Multiple versions in prod (e.g. mobile applications, or global saas type businesses where you might literally have different production instances that you upgrade over time for different customer cohorts).
2. The process of canarying (or traffic shifting), where you gradually increase traffic to the new environment. If this process takes some time (maybe minutes or more) you might want to be able to denote that currently, _both_ applications are in prod
abubics
2021-04-14 02:09
I think it's a reasonable concern for implementation details . . . how automatic it can be depends on how it's modelled.
So, if the broker knows that there are x instances, and they're being replaced with the same version, or a different version, then the user doesn't need to intervene so much to say, like "hey, this version is no longer deployed in prod".
matt.fellows
2021-04-14 02:10
That gets pretty hard with things like lambda, for example, where you actually don?t know until the operation is completed
abubics
2021-04-14 02:11
more granularity also accounts for subtle failure modes, like if one instance fails a smoke check, it may need manual intervention, and the deploy that should be relatively instantaneous actually goes for hours or days (as long as we're not making breaking changes, and having many versions live at once, maybe it's ok, but can't always be guaranteed)
matt.fellows
2021-04-14 02:11
it?s just ?version 1 and version 2 are currently in prod?.
operation completes
?version 1 is no longer in prod?
type thing
matt.fellows
2021-04-14 02:12
do you care about the ?instance? though, or just the fact that there are two (or more) versions currently in prod simultaneously?
matt.fellows
2021-04-14 02:13
From a contract testing point of view, I think you only care about the latter. The instance is detail that doesn?t affect the contract
abubics
2021-04-14 02:13
yeah, if you're not in control of all the lifecycle boundaries, things get harder. Similar problems for DI when using frameworks (like Spring or Android or whatever)
abubics
2021-04-14 02:14
I do only care about which versions are live. It's more about how to tell which are live, and whether that can actually be automated
abubics
2021-04-14 02:16
As usual, coming up with canonical use cases and examples for Pact is explosively difficult :sob: because everyone has slightly different flavours of every aspect
tjones
2021-04-14 07:17
Message pacts have this problem, since you might put messages (even for yourself) into a queue, but then be a different version when you read them out.
tjones
2021-04-14 07:20
That's not an answer to the question though. For me- wouldn't you run the "hey I deployed this" at the end of a successful deployment?
tjones
2021-04-14 07:23
If you have services:
Service A,
Version 1 (compatible with B v1 and v2)
Version 2 (compatible only with B v1)
and Service B:
Version 1 (compatible with A v1 and v2)
Version 2 (compatible only with A v1)
Then you deploy A@2, can-i-deploy passes.
While that's running, you try to deploy B@2, can-i-deploy passes. Then both deploys finish and nothing works.
abubics
2021-04-14 07:44
Maybe that could happen with rollbacks? I'm sure, if it's legal (even if unreasonable) it'll happen sometimes.
gareth.somerville
2021-04-14 09:41
Does anybody know what endpoint on the pact broker would be best to use as a health check? I'm currently calling `/` and waiting for a 200 status code, but I wasn't sure if there's something else that might be better suited. I've also never learned Ruby so it's hard to tell from the repo.
matt.fellows
2021-04-14 09:44
hmmm we definitely have a health check endpoint at Pactflow, maybe that?s not backported to the OSS
matt.fellows
2021-04-14 09:45
I?d suggest raising an issue, surprised nobody has asked about this before!
matt.fellows
2021-04-14 09:46
the `/` resource is more of an index to other resources, so it doesn?t do much (I don?t think)
gareth.somerville
2021-04-14 09:59
There you go. Didn't seem worth sticking to the issue template for that one
aliaksandr.valadzko
2021-04-14 18:28
Hey guys!
Getting strange issue in one of my projects (no such issue in other projects, all versions are the same across all the projects)
```@Category(PactProvider.class)
@Provider("my_provider")
@PactBroker(
host = "http://my.host.net",
scheme = "http",
authentication = @PactBrokerAuth(scheme = "bearer", username = "mytoken", password = ""))
or this
@Category(PactProvider.class)
@Provider("my_provider")
@PactBroker(host="http://my.host.net", port = "80")
public class MyConsumerPactTest {
...```
*`PactProviderTestSuite.initializationError`*
```java.lang.NoSuchMethodError: au.com.dius.pact.core.model.BrokerUrlSource.<init>(Ljava/lang/String;Ljava/lang/String;Ljava/util/Map;Ljava/util/Map;Ljava/lang/String;ILkotlin/jvm/internal/DefaultConstructorMarker;)V
at au.com.dius.pact.provider.ConsumerInfo$Companion.from(ProviderClient.kt:170)
at au.com.dius.pact.provider.junit.loader.PactBrokerLoader.loadPactsForProvider(PactBrokerLoader.kt:140)
at au.com.dius.pact.provider.junit.loader.PactBrokerLoader.load(PactBrokerLoader.kt:92)
at au.com.dius.pact.provider.junit.PactRunner.initialize(PactRunner.kt:85)
at au.com.dius.pact.provider.junit.PactRunner.getChildren(PactRunner.kt:140)
at org.junit.runners.ParentRunner.getFilteredChildren(ParentRunner.java:426)
at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:351)
at org.junit.runners.Suite.describeChild(Suite.java:123)
at org.junit.runners.Suite.describeChild(Suite.java:27)
at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:352)
at org.junit.runners.ParentRunner.run(ParentRunner.java:359)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.runTestClass(JUnitTestClassExecutor.java:110)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:58)
at org.gradle.api.internal.tasks.testing.junit.JUnitTestClassExecutor.execute(JUnitTestClassExecutor.java:38)
at org.gradle.api.internal.tasks.testing.junit.AbstractJUnitTestClassProcessor.processTestClass(AbstractJUnitTestClassProcessor.java:62)
at org.gradle.api.internal.tasks.testing.SuiteTestClassProcessor.processTestClass(SuiteTestClassProcessor.java:51)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.dispatch.ContextClassLoaderDispatch.dispatch(ContextClassLoaderDispatch.java:32)
at org.gradle.internal.dispatch.ProxyDispatchAdapter$DispatchingInvocationHandler.invoke(ProxyDispatchAdapter.java:93)
at com.sun.proxy.$Proxy2.processTestClass(Unknown Source)
at org.gradle.api.internal.tasks.testing.worker.TestWorker.processTestClass(TestWorker.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:35)
at org.gradle.internal.dispatch.ReflectionDispatch.dispatch(ReflectionDispatch.java:24)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:175)
at org.gradle.internal.remote.internal.hub.MessageHubBackedObjectConnection$DispatchWrapper.dispatch(MessageHubBackedObjectConnection.java:157)
at org.gradle.internal.remote.internal.hub.MessageHub$Handler.run(MessageHub.java:404)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
at java.lang.Thread.run(Thread.java:748)```
Any thoughts?:pray:
bethskurrie
2021-04-14 21:11
@gareth.somerville @matt.fellows https://docs.pact.io/pact_broker/docker_images/dius#heartbeat-url
jarmy
2021-04-14 21:24
Hello again. I've run into a situation with one of our consumers running `can-i-deploy` in their deploy pipeline. They're running their check with the `--to=<target environment>` argument. A problem arises when the `provider` has not yet deployed to that environment and tagged their version in the pact-broker with `create-version-tag`. When the consumer pipeline runs, they're blocked:
```pact-broker can-i-deploy --broker-base-url=https://pact-broker.docker.savagebeast.com --pacticipant=web --version=e76e1e860 --to=mobile-test
12:52:35 Computer says no ¯\_(?)_/¯
12:52:35
12:52:35 CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
12:52:35 ---------|-----------|----------|-----------|---------
12:52:35 web | e76e1e860 | pegasus | ??? | ??? ```
What should we do in this case? Should the consumer pipeline wait until the provider has been deployed to the target environment? If we exclude the `--to` argument, the can-i-deploy check passes.
bethskurrie
2021-04-14 23:21
That's the main point of the check @jarmy. Assuming the pacts and verification results are a correct reflection of reality, then if you deployed the consumer first, it wouldn't work properly!
bethskurrie
2021-04-14 23:23
If you have other reasons for wanting the consumer in that environment, even knowing that it won't work with the provider (perhaps you're wanting to test some other feature unrelated to the provider) then sure, go ahead and deploy anyway.
bethskurrie
2021-04-14 23:23
Can I deploy is doing what it's meant to do though, which is to stop you deploying a broken integration.
bethskurrie
2021-04-14 23:25
Providers always need to be deployed first, unless you're writing a consumer that is engineered to degrade gracefully for all the missing endpoints/fields (which is a great thing to do, but has a fair bit of overhead and isn't super common).
jarmy
2021-04-14 23:26
Hmm. This is going to be tricky. The consumer and provider deploy pipelines are set up to continuously deploy though there's a good chance the provider will take a while to verify the particular consumer version and deploy to all the various envs
bethskurrie
2021-04-14 23:27
Is pact causing the problem, or exposing the reality of the underlying situation?
bethskurrie
2021-04-14 23:28
If your provider has a slow release cycle, perhaps you need to do what I talked about before, and make the consumer degrade gracefully, so you can deploy regardless.
jarmy
2021-04-14 23:32
The provider has verified a pact, just not _this_ particular version of the consumer. In fact, the contract has not changed so wouldn't it fall under the pre-verified status?
bethskurrie
2021-04-14 23:33
Select the prod version of the provider, and look at the pact version shas of the verified pacts (hover over the pact published column)
bethskurrie
2021-04-14 23:34
Then look at the pact version sha for the consumer version you're trying to deploy
matt.fellows
2021-04-14 23:36
I?d look at this one (it has the actual path documented): https://docs.pact.io/pact_broker/docker_images/pactfoundation#heartbeat-url
jarmy
2021-04-14 23:41
But the time it takes for the pact to be verified and then tagged following the provider deployment may take a _long_ time.
bethskurrie
2021-04-14 23:42
You could make it automatically deploy when the provider is deployed using verification webhooks
bethskurrie
2021-04-14 23:43
Or you could have an override that says "I just want to deploy the consumer to test even if there are no results" in the build.
jarmy
2021-04-14 23:44
The way our deploy pipelines are set up is, if a stage (like can-i-deploy) fails, there's a 60 minute timeout where a human has to intervene to approve/abort the pipeline. If there's no interaction, then the pipeline aborts
bethskurrie
2021-04-14 23:45
Here's an example script that deploys the consumer once the successful verification results come back https://github.com/pact-foundation/pact_broker-client/blob/master/example/scripts/deploy-consumer.sh
jarmy
2021-04-14 23:46
I think I'll just need to educate the consumers about this and give them guidelines for how to handle these types of situations
jarmy
2021-04-14 23:48
Thanks for bearing with me. This is the first time we've implemented the can-i-deploy piece for a consumer
bethskurrie
2021-04-14 23:55
This sounds a lot like the challenge I have writing the pact broker client CLI.
bethskurrie
2021-04-14 23:55
The client has to work gracefully with every version of the broker that's out there.
bethskurrie
2021-04-14 23:57
I don't know which version of the client and which version of the broker will be used in any particular situation. Any new expectations I add the to client will never be able to be verified by the old versions of the broker, so there's no way I could ever release the client if I used that as a requirement.
bethskurrie
2021-04-14 23:58
What I do is use hypermedia to discover what features are available in the broker that the client is talking to, and gracefully handle the situation when the broker version doesn't support what the client needs.
bethskurrie
2021-04-14 23:58
I write the client code to be flexible and deal with almost any field not being present.
bethskurrie
2021-04-14 23:59
(not that I've ever removed a field yet, and I probably wouldn't, but I'm coding for resilience on both sides).
bethskurrie
2021-04-15 00:01
So I have a pact between the latest version of the broker and the latest version of the client and then I write a bunch of non pact unit tests that prove that the client can handle the situations where the fields or endpoints I expect aren't there.
bethskurrie
2021-04-15 00:03
Yes, it's an overhead in the client I'd rather not have to code, but it's either that or have a really brittle tool that blows up all the time!
bethskurrie
2021-04-15 00:04
Don't know if this would help in your situation at all @jarmy but thought it was worth sharing.
jarmy
2021-04-15 00:40
I have another situation with `can-i-deploy`. In this case, I have a provider that's running this check _before_ they deploy, which fails here
```16:55:03 + pact-broker can-i-deploy --broker-base-url=https://pact-broker.docker.savagebeast.com --pacticipant=pegasus --version=3cc5a887
16:55:04 Computer says no ¯\_(?)_/¯
16:55:04
16:55:04 CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
16:55:04 -------------------|-----------|----------|-----------|---------
16:55:04 android-sxmp-phone | 42a32cba | pegasus | 3cc5a887 | true
16:55:04 ios-sxmp-phone | 470cc4f25 | pegasus | 3cc5a887 | true
16:55:04 pegasus | 3cc5a887 | graphql | ??? | ???
16:55:04 pegasus | 3cc5a887 | hestia | 42cd6b89 | true
16:55:04 web | ebb9f5090 | pegasus | 3cc5a887 | true
16:55:04
16:55:04 There is no verified pact between version 3cc5a887 of pegasus and the latest version of graphql (c5935a8e)```
There was already an existing contract between `pegasus` (consumer) and `graphql` (provider) that's not currently being verified. What's interesting is this started failing when a new contract with a consumer called `graphql` was published with a new provider.
wderksen
2021-04-15 00:41
Hi friends,
I am having an odd situation where my webhook in the pact-broker seems to run everytime I publish a pact even if it is identical to the previous one. This is clear to me from the fact that my circle-ci workflow keeps running the workflow the webhook is meant to call. However, looking in the pact broker for triggered webhooks results in the value I expect, the last triggered webhook between this consumer and provider was a long time ago. So I?m pretty confused what is causing the webhook to run but not report running.
I thank you for whatever help you are able to provide.
bethskurrie
2021-04-15 02:41
Have you read this about debugging webhooks? https://docs.pact.io/pact_broker/webhooks/debugging_webhooks/#identifying-why-a-webhook-did-or-did-not-get-triggered
bethskurrie
2021-04-15 02:43
If you don't put in a "to" it will use the latest version of all the other applications, and that's not what you want.
bethskurrie
2021-04-15 02:44
I really shouldn't have ever allowed that command without a to parameter. It makes no sense.
bethskurrie
2021-04-15 02:47
This channel is on 999 members! The 1000th member to join gets a prize! OK, I'm joking. I don't have any prizes.
bethskurrie
2021-04-15 02:49
Also, is the consumer called graphql the same application as the provider graphql?
bethskurrie
2021-04-15 06:31
> The instance is detail that doesn?t affect the contract
Nope, but it's needed for keeping track of which versions are not longer deployed when a new deployment takes place.
bethskurrie
2021-04-15 06:32
That tells us which version is being deployed over, and so is no longer required to be supported.
bethskurrie
2021-04-15 06:33
I've documented my braindump here https://github.com/pact-foundation/pact_broker/discussions/417 @tjones @matt.fellows @antonello @abubics Thoughts on the flag names would be appreciated.
bethskurrie
2021-04-15 06:35
> As usual, coming up with canonical use cases and examples for Pact is explosively difficult :sob: because everyone has slightly different flavours of every aspect
Tell me about it @abubics!!!! Trying to explain to our poor UX person there is no single way that everyone does things has just about broken us all :grimacing:
matt.fellows
2021-04-15 06:50
> Nope, but it?s needed for keeping track of which versions are not longer deployed when a new deployment takes place.
Maybe it?s the term `instance` I?m confused about. Instance of the server being deployed to or the application? I don?t think we need to care about which servers things are on, just the fact that multiple versions of an application can be in an environment at once. I?ll take a look at the discussion you shared a bit later.
But, the usual sequence is going to something like this:
1. Service A v1 currently in prod
2. Service A v2deployment initiates (rollout gradually occurs across the fleet of servers, functions etc.)
3. All versions of service A v1 are no longer in prod
4. Only service v2 is in prod
Alternate step (3/): Rollback of v2 release happens due to issue, only v1 is in prod
The ability to do an atomic release (that replaces previous) or granular calls to document the state of an environment should cover this
bethskurrie
2021-04-15 06:54
> The ability to do an atomic release (that replaces previous) or granular calls to document the state of an environment should cover this
It's all about achieving this ^^
bethskurrie
2021-04-15 06:57
I'm trying to make things simple!! :sob: Why does life have to be so complicated!
wderksen
2021-04-15 14:03
ah never mind, the issue was indeed coming from somewhere else, just had to do with our ci setup.
jarmy
2021-04-15 15:31
@bethskurrie Interesting, I get a smaller subset of consumers with `--to` but it still fails on graphql
```pact-broker can-i-deploy --broker-base-url=https://pact-broker.docker.savagebeast.com --pacticipant=pegasus --version=3cc5a887 --to mobile-test
Computer says no ¯\_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
---------|-----------|----------|-----------|---------
pegasus | 3cc5a887 | graphql | ??? | ???
pegasus | 3cc5a887 | hestia | 42cd6b89 | true
web | c8efd49c6 | pegasus | 3cc5a887 | true
There is no verified pact between version 3cc5a887 of pegasus and the latest version of graphql with tag mobile-test (no such version exists) ```
jarmy
2021-04-15 15:46
I'm confused. This is a provider that is running the can-i-deploy check. Why does it care about other providers?
jarmy
2021-04-15 15:50
A couple more questions:
1. What if a provider is deploying to an environment that a consumer will never deploy to?
2. And what if a consumer deploys to an environment one of their providers never deploys to?
gareth.somerville
2021-04-15 17:20
Thanks for finding that. I'll get us switched to using that. Funnily enough it seems to be accessible without requiring that env var to be set in our env. Possibly because we're using an older version `2.29.0-1`. I found it odd that it requires authentication, but it's not a problem for this use case
bethskurrie
2021-04-15 21:48
You get a smaller set of consumers because it knows that only providers need to exist in a particular environment to deploy.
bethskurrie
2021-04-15 21:50
In this case, graphql is a provider of pegasus, so it has to exist in the environment before you can deploy pegasus.
bethskurrie
2021-04-15 21:52
It looks like pegasus hasn't been deployed to that environment yet @jarmy
bethskurrie
2021-04-15 21:54
BTW, tags will soon be superseded proper support for branches and environments, so the error messages will be able to be more helpful.
jarmy
2021-04-15 22:02
pegasus has indeed been deployed to the mobile-test environment _but_ since graphql has not set up `create-version-tag` in their pipeline yet, the provider version is not tagged
jarmy
2021-04-15 22:03
is it a requirement that all provider-consumer relationships be tagging with their envs before using can-i-deploy?
bethskurrie
2021-04-16 21:55
:tada: :tada: :tada: Congratulations @matthew.hall for being the 1000th member to join the #pact-broker channel :tada: :tada: :tada:
bethskurrie
2021-04-19 00:38
@jarmy :100: must tag for can-i-deploy to work. can-i-deploy can't work out which versions should be checked for compatibility unless it knows which environment it's looking at.
bethskurrie
2021-04-19 00:44
Thanks - I've added the missing path to the pactfoundation docs @matt.fellows @gareth.somerville please please please update to the latest version! That one has vulnerabilities and is missing a lot of features that are going to make your Pact life so much better! (pending pacts, wip pacts, many bug fixes, auto clean up, pagination...)
bethskurrie
2021-04-19 00:46
@sagupta you can use the `${pactbroker.consumerVersionTags}` to let them know which branches have been verified.
github
2021-04-19 00:57
GitHub app is successfully upgraded in your workspace :tada:
To receive notifications in your private channels, you need to invite the GitHub app `/invite @GitHub`
gareth.somerville
2021-04-19 08:36
@bethskurrie its on the list of things to upgrade, I might be able to bump it up. Thankfully this project only verifies pacts in a CI build at the moment, so the impact of any vulnerabilities is quite low right now
jarmy
2021-04-19 16:15
gotcha. i'll update the graphql provider to tag then add the `--to` env to the can-i-deploy checks
fnguyen
2021-04-20 16:27
Can someone help me figure out how to *verify the pact with a token from python*?
We have set a broker.
From c# i get my token then
``` var pactUriOptions = new PactUriOptions().SetBearerAuthentication( TOKEN );
new PactVerifier( config )
.ServiceProvider( PROVIDER_NAME, DAL_ENDPOINT )
.HonoursPactWith( CONSUMER_NAME )
.PactUri( PACT_URI, pactUriOptions )
.Verify();```
From python we used https://github.com/pact-foundation/pact-python/blob/master/examples/e2e/tests/provider/test_provider.py and tried the following
```@pytest.fixture
def default_opts():
return {
'broker_url': PACT_BROKER_URL,
'broker_token': TOKEN,
'publish_version': '3'
}
def test_verify_consumer_pact(default_opts):
verifier = Verifier(provider=PROVIDER,
provider_base_url=PROVIDER_BASE_URL)
output, _ = verifier.verify_with_broker(**default_opts, verbose=True)```
In the log I do not see the token being sent and I get a 401.
```opening connection to http://cdc-broker-xxx.azurewebsites.net:443...
opened
starting SSL for http://cdc-broker-xxx.azurewebsites.net:443...
SSL established
<- "GET /pacts/provider/PROVIDER/consumer/CONSUMER/latest HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nHost: cdc-broker-xxx.azurewebsites.net\r\n\r\n"
-> "HTTP/1.1 401 Unauthorized\r\n"```
Thanks
elliottmurray
2021-04-20 16:32
I think this is a bug. If you look at line 150 of verify_wrapper.py it is not bein g propogated. I can try and fix this in a release over the weekend if you want to create an issue?
elliottmurray
2021-04-20 16:32
We did some rework in this a few months ago and am figuring it got missed there
elliottmurray
2021-04-20 16:33
You can try an older version - might find one that works in the meantime
fnguyen
2021-04-20 16:36
Would it work if we do it from pact-verifier tool or it goes through the same code and is broken too?
elliottmurray
2021-04-20 16:36
Without looking I suspect it will break too. I refactored it to try and use this same code
fnguyen
2021-04-20 16:39
I am using c#, but am leading the cdc project so I was helping someone verify in python and it would not work. I'll tell them to try pact-verifier or wait until next week.
Thanks again.
matt.fellows
2021-04-21 23:15
@aparnachaudhari :point_up: this is the thread I was talking about. See discussion here: https://github.com/pact-foundation/pact_broker/discussions/417
dawoud.sheraz
2021-04-23 09:38
Hello. A question regarding credentials storage in pact broker. As per https://docs.pact.io/pact_broker/webhooks/debugging_webhooks/#creating-webhooks, the token or username/password are stored unencrypted. Why is that the case? It is a security threat if someone gets their hands on the auth credentials in case of a breach. Thank you.
matt.fellows
2021-04-23 10:11
Sorry was just out and about before when I responded. Were there particular examples/use cases you were concerned about?
matt.fellows
2021-04-23 10:12
One option is to prevent read access to certain paths and UI elements, but obviously this is not ideal.
bethskurrie
2021-04-24 03:39
They're never displayed back in the API @dawoud.sheraz but if you have the database, you could read them. If you had a copy of the database, you could still get them even if they were encrypted, because it has to be a reversible encryption, and if someone has your database, they most likely have hacked your entire stack!
bethskurrie
2021-04-24 03:40
The OSS Broker was designed to be an on-premesis solution, and generally people lock it down to their internal network, so the only people you're hiding the credentials from are yourselves.
matt.fellows
2021-04-24 10:56
This is for `username`/`password` and the `Authorization` header, right Beth (the implication being non-standard/custom auth schemes aren?t included)?
dawoud.sheraz
2021-04-26 05:00
@bethskurrie Hi. I disagree with parts of your statement. If the credentials are encrypted, the code should be handling the decryption part. If the credentials are to be read from DB manually by a person, they should be appearing encrypted. I get the point of making broker internal to the network to avoid any issues.
matt.fellows
2021-04-26 11:17
But the credentials aren?t encrypted at the moment in the OSS broker - we had to build out that infrastructure for Pactflow. The implementation of https://pactflow.io/features/ that can be used by webhooks was non-trivial work
dawoud.sheraz
2021-04-26 11:18
Makes sense. But it would be good to have that feature built-in within pact broker. Otherwise, everyone opting to use pact broker will need to worry about a potential security instance(which is my only concern).
matt.fellows
2021-04-26 11:23
For transparency, we?re not looking to add that feature to the OSS edition any time soon - it would require somebody in the community to contribute the feature.
aparnachaudhari
2021-04-29 17:39
Have a design question - for those who have implemented pact, how do you support local testing? We have it integrated in our CI/CD where the tests are being triggered after a PR or commit on PR, but giving developers an ability to run these tests is important. I know that the documentation recommends not letting locally built contracts to be published.. how are the providers side tested then? for a consumer service
aparnachaudhari
2021-04-29 17:42
I was unsure where this question goes.. I do not see a architecture//design room
matt.fellows
2021-04-30 01:51
Providers definitely also test locally, you would just not publish any results back to the broker
matt.fellows
2021-04-30 01:59
In the sense that, you certainly don?t want every code change to publish - discretion from a developer of _when_ to publish i think is a sensible thing to do
bethskurrie
2021-04-30 02:01
@aparnachaudhari the verifier also lets you verify pacts from your local machine
aparnachaudhari
2021-04-30 02:02
yep.. but for cases where the provider and consumers are not from the same team..
aparnachaudhari
2021-04-30 02:03
it would go via the broker, when when I am writing my tests initially, I generally like to test my tests..
bethskurrie
2021-04-30 02:04
You're meant to run those from the developer machine, just using a read only token, so you don't publish results.
bethskurrie
2021-04-30 02:05
Are you saying, you want to publish the pact for someone on another team to verify, before you commit and push your change to a consumer?
aparnachaudhari
2021-04-30 02:08
So this is the scenario I am thinking of - I am consumer service developer, I am writing consumer contract tests for a provider service. In tandem, the provider service owners write the provider verification tests for my contract. Before all of this is just pushed out in a CI pipeline, I want to test this all checks out. Right now, I can achieve this by running a local broker and just using that or just sharing the JSON file. But, as a long term solution for our developers ? is there a better way to go about this.
aparnachaudhari
2021-04-30 02:08
I ask here cause you all definitely have had more time to think these things through
bethskurrie
2021-04-30 02:09
The expectation is that the first push of a new contract pretty much always fails.
aparnachaudhari
2021-04-30 02:10
what happens when I change the consumer service and now want to validate my changes locally before PR.. same thing ? just share json ?
bethskurrie
2021-04-30 02:12
I often develop both sides of an integration on my local machine, but then I do a verification of the local file before I commit both sides.
bethskurrie
2021-04-30 02:12
If it's an integration with another team though, that's what the broker is for.
aparnachaudhari
2021-04-30 02:12
yeah its easier if you are the commiter for both consumer and provider
bethskurrie
2021-04-30 02:13
If i'm changing somehting on the consumer side, I don't expect the first push to pass.
aparnachaudhari
2021-04-30 02:13
its different when you have 200+ microservices that are owned by different teams
bethskurrie
2021-04-30 02:13
Look, if it makes your life easier to push them to the broker from the developer machine, sure, do it, just make sure you've got them tagged appropriately, so they don't override any "official" versions.
bethskurrie
2021-04-30 02:14
It sounds like you might be interested in our new bi-directional contracts feature.
bethskurrie
2021-04-30 02:15
Bi-directional is pretty much the only way you'll be able to get everything passing before you push.
abubics
2021-04-30 02:19
The bit that hasn't been mentioned is WIP & pending pacts (which are new features).
But even before we had these, we'd just expect broken branch builds until the provider implements the change in their own matching feature branch. When both branches pass, they can both be merged (provider first).
aparnachaudhari
2021-04-30 02:20
`WIP & pending pacts (which are new features)` http://blog.pact.io/2020/02/24/introducing-wip-pacts/ ?
2021-04-30 02:21
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
bethskurrie
2021-04-30 02:22
It's like TDD for services. Write the failing spec, making the failing spec pass. In this case, a red build is not "bad".
matt.fellows
2021-04-30 02:24
The name is misleading in the sense that it?s about how to plumb it into your CI/CD pipelines, but of course doing this effectively is all about working into teams workflows
fnguyen
2021-05-01 22:47
Hi all.
We run consumer and provider pacts as part of our pipeline.
We also tag the pacticipants after uploading the pact (consumer) and verifying the pact (provider)
That made sense to me but now I realize some services are both consumer and providers and I am tagging them twice.
It feels like I should be able to tag my service once during build whether it's consumer/provider or both, right?
bethskurrie
2021-05-02 23:23
@fnguyen tags are idempotent, so it doesn't matter if you tag multiple times.
bethskurrie
2021-05-02 23:24
When you say, you tag after uploading, are you doing a custom pact publication and/or tagging? If you're using the supported pact publication/verification tasks, then you're tagging at the same time as you publish each of these resources, and it's just done for you automatically.
tonynguyenit18
2021-05-03 03:58
Hi all,
I am experiment deploy Consumer and Provider flow.
? Do we have any reference to some content for it with 2 use cases: one is initially starting contract testing and another one is we already have verified and deployed in qa and prod environment?
? I am wonder do I need can-i-deploy for Provider e.g I want to deploy provider to qa `pact-broker can-i-deploy --pacticipant Provider-Bar --latest --pacticipant Consumer-Foo --latest --tag qa`
bethskurrie
2021-05-03 03:59
Hi @tonynguyenit18. Have a look at https://docs.pactflow.io/docs/tutorials#gating-deployments-with-pactflow
bethskurrie
2021-05-03 04:00
You need to give it the actual version number that you published the pacts with.
bethskurrie
2021-05-03 04:01
You ideally want to be using this format: `pact-broker can-i-deploy --pacticipant Foo --version 24 --to prod`
tonynguyenit18
2021-05-03 04:02
`pact-broker can-i-deploy --pacticipant Foo --version 24 --to prod` Does this apply to Consumer only OR Provider as well?
tonynguyenit18
2021-05-03 04:11
I have this use case
```
Use case:
There are exiting contracts and deploy both consumer and provider to prod with tag prod
Consumer: run test and create new contract which are breaking change with contract in prod
Consumer: publish to broker with tag dev
Consumer: run can-i-deploy to prod (provider with prod tag)-> Red in CI (cuz making breaking change and the new contract have not been verified yet).
Provider: Develop based on the new contract
Provider: Successfully verify dev tagged Consumer
Provider: Publish verification results to Broker with Provider dev tagged-> green in CI
Consumer: Run can-i-deploy --to prod -> Red in CI (cuz Provider verify contract dev tagged Consumer only).
Provider: Want to deploy to prod to help Consumer green so RUN can-i-deploy --to prod -> CI in Red because New Consumer version is not deploy to prod yet
-> Fail loop```
This make fail loop if run `can-i-deploy --pacticipant Provider --version 24 --to prod`
fnguyen
2021-05-03 15:14
We run the consumer tests in .NET, it creates a pact file, we push it with a powershell script (or curl) then tag the pacticipant with its version and our branch .
Later in the pipeline, we run the provider test that was uploaded by a consumer. Done with .NET too and we verify with PublishVerificationResults true. The ProviderVersion is also set.
We are not tagging at the same time as we are publishing /verifying as when publishing /verifying we do not provide a tag.
I guess the second tagging is unnecessary; I will remove it.
Thanks.
c.pavan1986
2021-05-04 15:10
Can we use can-i-deploy with passing username and password to test against saml enabled pactflow
tonynguyenit18
2021-05-04 15:12
I have done a test, actually when I run
`can-i-deploy --pacticipant Provider --version 24 --to prod` for provider it will pass.
I seem like ``can-i-deploy` running in Provider side and Consumer side behave differently.
For Consumer if I run `can-i-deploy --pacticipant Consumer --version 24 --to prod` it will check verification results of Consumer version 24 with all Providers which is tagged as prod
But for Provider if I run `can-i-deploy --pacticipant Provider --version 24 --to prod` it will pass BUT It actually does not care about `--to prod` because If I try `can-i-deploy --pacticipant Provider --version 24 --to any_string_here` it still pass too, So I assume `can-i-deploy --pacticipant Provider --version 56 --to any_string_here` only care about the version 56 whether it verified all Consumer it?s mapped to.
Am I right?
tonynguyenit18
2021-05-04 15:12
Hi guys,
I have checked `can-i-deploy` command from
https://docs.pact.io/pact_broker/can_i_deploy
AND https://docs.pact.io/pact_broker/client_cli/readme/#can-i-deploy
Most of the examples is for Consumer, but it actually being used for Provider too, from https://docs.pact.io/pact_broker/client_cli/readme/#can-i-deploy document `pact-broker can-i-deploy --pacticipant...` means the command is use the same for Consumer and Provider. But I think it behaves differently when being used for Provider and Consumer.
I have pact which is verified betwen Consumer tagged `main, test` and Provider tagged `main, provider`
? From Consumer side
If I run `pact-broker can-i-deploy --pacticipant PHAppFIWidget --version 9a49620 --to qa` this will failed and said there is no
provider tagged `qa` verified that Consumer,
If I run `pact-broker can-i-deploy --pacticipant PHAppFIWidget --version 9a49620 --to provider` it will pass because there is a
pact which is publish by that Consumer version and verified by the Provider tagged `provider`
=====> means, from consumer site `--to tag` will check the tag of all Providers which are mapped to that certain Consumer
version
? From Provider side,
if I run `pact-broker can-i-deploy --pacticipant PHCoreFI --version bd02c8-add-start-ats-assessement-contract-testing+bd02c8.SNAPSHOT.Tonys-MacBook-Pro-2 --to test` ( test is tag of `PHAppFIWidget --version 9a49620`) because I think it
behaves same as Consumer.
But I tried with `pact-broker can-i-deploy --pacticipant PHCoreFI --version bd02c8-add-start-ats-assessement-contract-testing+bd02c8.SNAPSHOT.Tonys-MacBook-Pro-2 --to any_string_here` it passed as well
=====> means from provider side it will not care about `--to any_tag` , it only consider whether that certain Provider version
successfully verify all Consumer it?s mapped to
Am I right?
If Yes, should we have document or article to explain more about the different?
Image attached below :point_down:
matt.fellows
2021-05-05 02:46
given that you aren?t using the same tags to denote an environment, it?s no surprise they aren?t lining up
2021-05-05 02:47
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
tonynguyenit18
2021-05-05 03:04
Thanks @matt.fellows for your answer.
Yeah I know I am not follow rule of tagging, Imagine I tag Consumer and Provider `dev` then I want to deploy to `prod`
If I run `can-i-deplot ....Consumer --version 24 --to prod` in the Consumer side will failed because there is no Provider tagged `prod` verified that Consumer yet (I got this)
IF I run `can-i-deplot ....Provider --version 56 --to prod` in Provider side it will pass (I thought it will behave same as Consumer and fail because there is no Consumer tagged `prod` verified) . But NO it passes, because as you mentioned `--to <tag>` is to check whether it?s save to deploy to a environment. But in case I have ``can-i-deplot ....Provider --version 56 --to any_tag_here`` it still passes too ==> `--to <tag>` does nothing in command operation here (only for readability).
==> means under the hood `can-i-deploy` behaves differently when we run for Consumer and Provider?
tonynguyenit18
2021-05-05 03:07
I went through most of docs and blog posts related to can-i-deploy and only see this explain how it works when run in Consumer sider under the hood. But Can not find any explanation for running `can-i-deploy` from Provider side
tonynguyenit18
2021-05-05 03:08
Yep we have some for Provider but just example, not really explain how it does under the hood for Provider
timo
2021-05-05 08:10
Hello,
We are stumbling across an issue with the can-i-deploy command. We have a service (payments-service) that is both consumer and provider and unfortunately some consumers of this service are actually also providers of this particular service again, so we have some kind of circular dependency. I don?t know wether this is the reason for this problem though, just a guess
We run `broker can-i-deploy --pacticipant payments-service --version ad29ba94 --to prod` on a feature branch to verify if the consumer contracts are actually still correctly verified by the providers, so we can be sure to merge this change to master.
Since the `can-i-deploy` command also checks for contracts where the payments-service is a provider, those all fail because the payments-service with this particular versions wasn?t deployed and tagged yet with `prod` (since we are running a build of a feature branch)
```CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS?
----------------------------|-----------|-----------------------------|-----------|---------
payments-scheduling-service | d22e18c | payments-service | ??? | ???
payments-service | ad29ba94 | partners-service | ed1a2ce | true
payments-service | ad29ba94 | payments-scheduling-service | d22e18c | true
payments-service | ad29ba94 | policies-service | 34fac668 | true
payments-service | ad29ba94 | products-service | b3befdf | true
policies-service | 34fac668 | payments-service | ??? | ???
There is no verified pact between the latest version of payments-scheduling-service with tag prod (d22e18c) and version ad29ba94 of payments-service
There is no verified pact between the latest version of policies-service with tag prod (34fac668) and version ad29ba94 of payments-service```
Actually, the only thing we are interested in, is wether the contracts where the payments-service is the consumer are passing. For the contracts where the payments-service is a provider we don?t need to run the `can-i-deploy` command because during the normal test step of the pipeline, we already run the provider verification of all contracts tagged with `prod`. Side node: we are running a production-only environment approach in our company, so a merge to master goes directly to production once all tests pass
Is there anything we can do here? Is this a known problem or is something else fishy in our setup?
matt.fellows
2021-05-05 08:19
> ==> means under the hood `can-i-deploy` behaves differently when we run for Consumer and Provider?
I don?t think it behaves differently. It?s saying ?yes, you?re safe, you?re not incompatible with your inegrations in the target environment?
tonynguyenit18
2021-05-05 08:25
Thanks @matt.fellows.
Yep, the statement of result mean the same for Consumer and Provider which is yes -> can deploy, and no -> not ready to be deployed.
I mean it will check differently under the hood.
If I run `can-i-deplot ....Consumer --version 24 --to prod` it will check integrated Providers with `prod` tag
If I run `can-i-deplot ....Provider --version 56 --to prod` it will check the Provider version 56 itself whether Provider version 56 itself is part of verified pact AND ``--to prod` does nothing here (because I can change it to anything tag and it still pass).
matt.fellows
2021-05-05 08:27
I believe it looks at the target tag (e.g. `prod`) and says ?find all of my integrations? and then asks ?am I compatible with them?
matt.fellows
2021-05-05 08:28
if there are no integrations in the target, then in a ?provider role? it is safe - we?re not going to break anybody
matt.fellows
2021-05-05 08:28
if it?s the ?consumer role? it?s not safe - there are no providers to service my needs
ashish_garg5
2021-05-05 08:31
Hi All,
I am trying to publish contract using curl command but getting the below error.
Can anyone please help. Thanks.
`C:\systems-plugin>curl -v -XPUT \-H "Content-Type: application/json" -d@pacts/systems-plugin-hci-adapter.json https://ciqpactdev.cec.lab.emc.com/pacts/provider/hci-adapter/consumer/systems-plugin/version/0.0.0/tags/hello -u test:test`
`* Rebuilt URL to: \-H/`
`* Could not resolve host: \-H`
`* Closing connection 0`
`curl: (6) Could not resolve host: \-H`
`* Port number ended with ' '`
`* Closing connection -1`
`curl: (3) Port number ended with ' '`
`* Trying 10.207.104.165...`
`* TCP_NODELAY set`
`* Connected to http://ciqpactdev.cec.lab.emc.com (10.207.104.165) port 443 (#1)`
`* schannel: SSL/TLS connection with http://ciqpactdev.cec.lab.emc.com port 443 (step 1/3)`
`* schannel: checking server certificate revocation`
`* schannel: sending initial handshake data: sending 191 bytes...`
`* schannel: sent initial handshake data: sent 191 bytes`
`* schannel: SSL/TLS connection with http://ciqpactdev.cec.lab.emc.com port 443 (step 2/3)`
`* schannel: failed to receive handshake, need more data`
`* schannel: SSL/TLS connection with http://ciqpactdev.cec.lab.emc.com port 443 (step 2/3)`
`* schannel: encrypted data got 1849`
`* schannel: encrypted data buffer: offset 1849 length 4096`
`* schannel: sending next handshake data: sending 158 bytes...`
`* schannel: SSL/TLS connection with http://ciqpactdev.cec.lab.emc.com port 443 (step 2/3)`
`* schannel: encrypted data got 274`
`* schannel: encrypted data buffer: offset 274 length 4096`
`* schannel: SSL/TLS handshake complete`
`* schannel: SSL/TLS connection with http://ciqpactdev.cec.lab.emc.com port 443 (step 3/3)`
`* schannel: stored credential handle in session cache`
`* Server auth using Basic with user 'test'`
`> PUT /pacts/provider/hci-adapter/consumer/systems-plugin/version/0.0.0/tags/hello HTTP/1.1`
`> Host: http://ciqpactdev.cec.lab.emc.com`
`> Authorization: Basic dGVzdDp0ZXN0`
`> User-Agent: curl/7.55.1`
`> Accept: */*`
`> Content-Length: 12687`
`> Content-Type: application/x-www-form-urlencoded`
`> Expect: 100-continue`
`>`
`* schannel: client wants to read 102400 bytes`
`* schannel: encdata_buffer resized 103424`
`* schannel: encrypted data buffer: offset 0 length 103424`
`* schannel: encrypted data got 54`
`* schannel: encrypted data buffer: offset 54 length 103424`
`* schannel: decrypted data length: 25`
`* schannel: decrypted data added: 25`
`* schannel: decrypted data cached: offset 25 length 102400`
`* schannel: encrypted data buffer: offset 0 length 103424`
`* schannel: decrypted data buffer: offset 25 length 102400`
`* schannel: schannel_recv cleanup`
`* schannel: decrypted data returned 25`
`* schannel: decrypted data buffer: offset 0 length 102400`
`< HTTP/1.1 100 Continue`
`* We are completely uploaded and fine`
`* schannel: client wants to read 102400 bytes`
`* schannel: encrypted data buffer: offset 0 length 103424`
`* schannel: encrypted data got 333`
`* schannel: encrypted data buffer: offset 333 length 103424`
`* schannel: decrypted data length: 304`
`* schannel: decrypted data added: 304`
`* schannel: decrypted data cached: offset 304 length 102400`
`* schannel: encrypted data buffer: offset 0 length 103424`
`* schannel: decrypted data buffer: offset 304 length 102400`
`* schannel: schannel_recv cleanup`
`* schannel: decrypted data returned 304`
`* schannel: decrypted data buffer: offset 0 length 102400`
`< HTTP/1.1 404 Not Found`
`< Server: nginx/1.19.8`
`< Date: Tue, 04 May 2021 14:55:27 GMT`
`< Content-Type: application/hal+json`
`< Content-Length: 0`
`< Connection: keep-alive`
`< Status: 404 Not Found`
`< Vary: Accept`
`< X-Content-Type-Options: nosniff`
`< X-Pact-Broker-Version: 2.66.0`
`< X-Powered-By: Phusion Passenger 6.0.6`
`<`
`* Connection #1 to host http://ciqpactdev.cec.lab.emc.com left intact`
tonynguyenit18
2021-05-05 08:33
> if there are no integrations in the target, then in a ?provider role? it is safe - we?re not going to break anybody
Does this mean If I run `can-i-deplot ....Provider --version 56 --to prod` in provider side, if there is a Consumer tagged `prod` integrated with this certain Provider version and that contract is ?Failed? when verify => `can-i-deploy` will say NO. Am I right?
bheemreddy181
2021-05-05 22:02
Hey Team , Need help in understanding why a particular tag returns me a 404 error when i try to do get on by HAL browser , is that back slash causing any issue
```feature/DIN-3133-update-to-handle-direction```
bethskurrie
2021-05-05 23:17
@c.pavan1986 you need an API token https://docs.pactflow.io/docs/user-interface/settings/api-tokens
bethskurrie
2021-05-05 23:18
@tonynguyenit18 yes, the behaviour is different for a consumer and a provider. The consumer requires the provider to already be in a particular environment, so you have to use a known tag.
bethskurrie
2021-05-05 23:18
A provider that does not depend on any other providers can be deployed to any environment, so you can give it any tag you like and it will say "yes".
bethskurrie
2021-05-05 23:19
You're right, I should write some docs to explain this. It will make more sense when the explicit "environments" are supported https://github.com/pact-foundation/pact_broker/discussions/384
bethskurrie
2021-05-05 23:25
Hi @timo. The broker understands the bi-directional dependencies. I think what you might need to do when you're on a feature branch is call `--to master` instead of `--to prod`
bethskurrie
2021-05-05 23:26
There's no way to explicitly exclude a particular direction of dependency from can-i-deploy, so even if you used the "explicit options" version of the command https://docs.pact.io/pact_broker/client_cli/readme#alternate-usage---specifying-dependencies-explicitly you'd still have the same problem.
bethskurrie
2021-05-05 23:28
@ashish_garg5 you're using windows so you might want to use `Invoke-WebRequest` instead
bethskurrie
2021-05-05 23:28
Here are the docs on publishing pacts https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts/
bethskurrie
2021-05-05 23:29
I very very strongly recommend you don't do it manually however. The tagging/publishing must be done in the right order for certain webhooks to fire with the right data. It's not a user friendly API that's meant for general developer use.
matt.fellows
2021-05-06 01:03
I?m just guessing, but if it?s not escaped, the broker may treat the `/` as structural part of the path, not an element within it
ashish_garg5
2021-05-06 03:09
Is there any example of this Invoke-WebRequest not sure where exactly i have to add this.
bethskurrie
2021-05-06 05:30
username: dXfltyFMgNOFZAxr8io9wJ37iUpY42M
password: O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1
bethskurrie
2021-05-06 05:33
Peeps - I would love some feedback on a field name. Here are the docs for the soon to be released "record-deployment". https://docs.pact.io/pact_broker/recording_deployments_and_releases
I'm unsure about the term "target" because "deployment target" already exists as a Thing for IOS development. I don't want to use the word "instance" though, as its SUPER overloaded. "identifier" or "name" are just very vague, and a deployment doesn't really have either. "destination" maybe? Any suggestions appreciated (or tell me that you think target is a good term!)
matt.fellows
2021-05-06 07:47
At first glance, I prefer target better because a target can be generalised. Instance has some very specific meanings in the general case of app dev
matt.fellows
2021-05-06 07:48
I can't think of other terms right now, but I'll have a good read of the docs tomorrow and come back to you
bheemreddy181
2021-05-06 13:25
odd here is the HAL link looks like
```https://pact-broker.enova.com/pacticipants/paymentinstructionservice/versions/186ccec1c8e66c3898bcd025c797551eb949572c/tags/feature/DIN-3133-update-to-handle-direction```
^ Beth am i doing this wrong
bheemreddy181
2021-05-06 13:27
the difference i see is we are on `x-pact-broker-version: 2.54.0` vs your test instance is on `x-pact-broker-version: 2.79.0` - i better try to upgrade
matt.fellows
2021-05-06 13:28
yousafn
2021-05-06 16:58
I think target is ok, we would have offline and online legs, in production at one company. we would deploy to an offline leg, and then we would switch over. The legs were called leg a and leg b and only one could be online.
I imagine in that situation they would both be deployed to environment prod, with a tag of online or offline, or leg a or leg b, and maybe the target would a better use.
Or maybe we would use target, if we were deploying multiple instances of services into one env (for supporting PR based deploys). Just thinking aloud. ( I just use tags for the contracts pacts generated on PR?s but we don?t deploy branch builds atm, but are looking to imminently)
bethskurrie
2021-05-06 22:47
@yousafn what do you think about this section? https://docs.pact.io/pact_broker/recording_deployments_and_releases/#handling-long-running-deployments
bethskurrie
2021-05-06 22:52
@ashish_garg5 yes, in the link I sent https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts/
tjones
2021-05-07 04:38
We had this question in #pact-js, from @tonynguyenit18 but I'm not sure what the expected workflow is, so I couldn't answer it:
https://pact-foundation.slack.com/archives/C9VBGLUM9/p1620349213299100
tonynguyenit18
2021-05-07 04:42
Thanks @tjones.
There is a suggestion from Tim.
> I think the expected workflow of the tags is to have the same tag in the provider and the consumer test, for example `feat-x` instead of `c-feat-x` and `p-feat-x`. However, I don?t have much experience working with tags, so I?m not sure (I tend to do trunk based development).
Yep that will do the job, but forcing Provider and Consumer using same branch name is not really convenience way.
bethskurrie
2021-05-09 23:16
I have a vague memory of fixing the escaping in a link a few months ago. Upgrading seems to be the fix @bheemreddy181
anchit.99
2021-05-10 12:09
I'm trying to setup the pact broker for the first time and I'm using the docker-compose file on windows. I've switched docker between windows and linux containers and it refuses to mount the directories for nginx. Could someone please confirm what's the configuration we need to put in for nginx and whether we should stick with linux container?
anchit.99
2021-05-10 13:03
@matt.fellows I'm trying to use this one: https://github.com/DiUS/pact_broker-docker#running-with-docker-compose
matt.fellows
2021-05-10 13:05
any reason not to use this one: https://github.com/pact-foundation/pact-broker-docker
anchit.99
2021-05-10 17:35
@matt.fellows Oh I'm surprised to know that. Sorry I misunderstood somewhere. I went through this doc https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Passenger and was under the impression that phusion passenger was simpler to use and a better option.
Also, when I read this doc (screenshot) I thought that DiUS pact broker is the one that's easier to manage and self regulating.
anchit.99
2021-05-10 17:39
I'm also interested in running the can_i_deploy tool to understand it better. But in either case looks like I need to provide some values for the volume parameter.
matt.fellows
2021-05-10 21:29
How are you running the image? IMO puma is the one you?d be wanting to run in most cases these days, but again, that?s my opinion (from a DevOps perspective, i?d rather run a simple ?dumb? container)
matt.fellows
2021-05-10 21:30
why do you need it to run on both windows and linux? It?s a hosted thing that should be used across the company - i.e. you only need one of them running
anchit.99
2021-05-11 07:32
@matt.fellows Thank you so much for replying! Sorry I'm new to a lot of technologies that are being used together. I'm now trying with the `pact-foundation/pact-broker-docker/blob/master/docker-compose.yml` file
I haven't worked with docker at all earlier. There's an option in docker desktop (installed on windows) to `switch to windows container` and I did that because I thought that then I'd be able to provide some relevant values to this ssl path. It's rejecting whatever values I give with the error in the screenshot.
Also tried with the default linux container and still it threw an error. Any idea what possible value I could provide in this setting just to get it to accept it?
matt.fellows
2021-05-11 07:47
anchit.99
2021-05-11 08:31
Thanks for sharing that link! I got it! With a few more tries the following directory works on windows:
Over here this directory is where I've placed my docker-compose.yml file /d/automation2/pact-broker/
anchit.99
2021-05-11 08:32
@uglyog Yes. It worked after I tried with these values (attached). Thanks to you and @matt.fellows for replying.
bethskurrie
2021-05-19 06:31
@mateusz.derks could you give me your thoughts on this please https://github.com/pact-foundation/pact_broker/discussions/433
bethskurrie
2021-05-19 06:33
@philipchardwick my search for "wip" in the slack channel suggests that you might also have thoughts on the above ^^
bethskurrie
2021-05-19 06:34
Any WIP/pending pact users, I'm after feedback on a slight tweak to the wip/pending logic that I want to make https://github.com/pact-foundation/pact_broker/discussions/433
art.ptushkin
2021-05-20 13:18
I have very similar problem. @bethskurrie I believe you have thought to create a feature to _ignore_ pacticipants explicitly on `can-i-deploy`
Perhaps, you have this feature in backlog or any written reasoning on why not to do so?
kflo
2021-05-20 20:28
i am seeing what i think is a bug, not sure if it?s in our implementation library (`scala-pact`) or the broker (seems like the broker based on messaging) or in our configuration. we are using the Pacts for Verification API in conjunction with the WIP (and pending) pacts features. we have a new pact where the consumer and provider are both sharing the same tag (let?s say `feat-x`). the provider is configured to filter on all stable consumer tags + the `feat-ex` tag (e.g. `feat-x`, `master`, `production`). the pact in question is being picked up as a pending pact (?latest version tagged `feat-x`?) and the verification fails. because the provider and consumer are sharing the same tag, i expected this build to fail, but it succeeds (because the pact is considered pending). also FYI the tagging of provider and uploading of results happens after verification ? may be related. any ideas?
kflo
2021-05-20 20:31
```PactApiVerification: configuring pact source.
Pact source is set to the Pact Broker using the 'Pacts for Verification' API.
Consumer tags to filter on: 'feat-x', 'master', 'testing', 'production'.
The latest version (by creation date) of each matching consumer pact tag will be used.
Work in progress (WIP) pacts are enabled.
Pending pacts are enabled.
Provider verification results publishing is enabled.
Provider version is: 94fc35657cafcf7208dea19141eb58bdeef5a735.
Provider tags are: 'feat-x'.
Attempting to fetch relation 'pb:provider-pacts-for-verification' from broker
cURL for request: curl -X GET '***' -H 'Accept: application/hal+json' -H 'Authorization: <REDACTED>'
cURL for request: curl -X POST '***/pacts/provider/project/for-verification' -H 'Accept: application/hal+json' -H 'Content-Type: application/json' -H 'Authorization: <REDACTED>' -H 'Content-Length: 438'
Attempting to fetch pact from pact broker at: ***/pacts/provider/project/consumer/offer/pact-version/4fd148e1108d79986e1caf687ef37e9b8361209f/metadata/c1tdW3RdPW9mZmVycHJvamVjdE9HNDkzOCZzW11bbF09dHJ1ZSZzW11bY3ZuXT05OGU1NzI5ODExZDdmZDAwNjA3YzVmN2E2YTk4NTg4ZTRiNjUzN2Rk
cURL for request: curl -X GET '***/pacts/provider/project/consumer/offer/pact-version/4fd148e1108d79986e1caf687ef37e9b8361209f/metadata/c1tdW3RdPW9mZmVycHJvamVjdE9HNDkzOCZzW11bbF09dHJ1ZSZzW11bY3ZuXT05OGU1NzI5ODExZDdmZDAwNjA3YzVmN2E2YTk4NTg4ZTRiNjUzN2Rk' -H 'Accept: application/json' -H 'Authorization: <REDACTED>'
Verifying against 'localhost' on port '39595' with a timeout of 2 second(s).
--------------------
Attempting to run provider state: create valid and invalid project
Provider state ran successfully
--------------------
cURL for request: curl -X POST 'http://localhost:39595/v2/projects' -H 'usage-context: pact-usage-context' -H 'Authorization: <REDACTED>' -H 'Content-Length: 1104'
cURL for request: curl -X PUT '***/pacticipants/project/versions/94fc35657cafcf7208dea19141eb58bdeef5a735/tags/feat-x' -H 'Content-Type: application/json; charset=UTF-8' -H 'Authorization: <REDACTED>'
Created tag feat-x for provider version 94fc35657cafcf7208dea19141eb58bdeef5a735.
cURL for request: curl -X POST '***/pacts/provider/project/consumer/offer/pact-version/4fd148e1108d79986e1caf687ef37e9b8361209f/metadata/c1tdW3RdPW9mZmVycHJvamVjdE9HNDkzOCZzW11bbF09dHJ1ZSZzW11bY3ZuXT05OGU1NzI5ODExZDdmZDAwNjA3YzVmN2E2YTk4NTg4ZTRiNjUzN2Rk/verification-results' -H 'Content-Type: application/json; charset=UTF-8' -H 'Authorization: <REDACTED>' -H 'Content-Length: 94'
Verification results published for provider 'project' and consumer 'offer'
--------------------
Results for pact between offer and project -
- The pact at ***/pacts/provider/project/consumer/offer/pact-version/4fd148e1108d79986e1caf687ef37e9b8361209f is being verified because the pact content belongs to the consumer version matching the following criterion:
* latest version tagged 'feat-x' (98e5729811d7fd00607c5f7a6a98588e4b6537dd)
- This pact is in pending state for this version of project because a successful verification result for a version of project with tag 'feat-x' has not yet been published. If this verification fails, it will not cause the overall build to fail. Read more at https://docs.pact.io/go/pending
- [PENDING] POST create project returns succeeds and failures
Failed to match response
...original
Response [200]
headers: [CNMDC-X_CORRELATION_ID=0b362387-d2fd-40ff-9705-84123be2a042,\n "Date=Thu, 20 May 2021 18:51:11 GMT,\n "Content-Type=application/json,\n "Content-Length=106]
matching rules: []
body:
{"failures":[],"succeeds":["00000000-0000-0000-0000-000000000000","00000000-0000-0000-0000-000000000000"]}
...closest match was...
Response [200]
headers: []
matching rules: []
body:
{
"failures" : [
"ffffffff-ffff-ffff-ffff-ffffffffffff"
],
"succeeds" : [
"00000000-0000-0000-0000-000000000000"
]
}
...Differences
Node at: .failures[0]
Could not find a match for node
> Rules:
Rules:
-
- This pact is still in pending state for any version of project with tag 'feat-x' as a successful verification result with this tag has not yet been published```
kflo
2021-05-20 20:56
what exactly does this mean: ?_where the pact content was explicitly specified in the selectors?_
kflo
2021-05-20 20:58
?It only stops being a WIP pact when the content has been ?approved? by having one of the tags that the provider team has chosen to support.? i think this is what i?m trying to do by sharing a tag between the consumer and provider
tonynguyenit18
2021-05-20 22:43
> what exactly does this mean: ?_where the pact content was explicitly specified in the selectors?_
explicitly specified in selectors mean specify it in `consumerVersionSelectors`https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors/
E.g
```const verificationOptions = {
// ....
consumerVersionSelectors: [
{
tag: "master",
latest: true
},
{
tag: "test",
latest: true
},
{
tag: "production",
latest: true
}
]
} ```
In your case, master, prod is `explicitly specified` , and WIP is not
tonynguyenit18
2021-05-20 22:45
> but it succeeds (because the pact is considered pending)
Is expected by the lib, actually there is a discussion on your concern. https://pact-foundation.slack.com/archives/C9VPNUJR2/p1621406083002100
kflo
2021-05-20 22:46
i?m wondering if i?m mis understanding how WIP pacts work and that topic addresses it
kflo
2021-05-20 22:46
or i understand it correctly but have something configured wrong, or there is a bug somewhere
kflo
2021-05-20 22:47
i thought it was existing behavior that if you specify a consumer tag and provider tag that match (both `feat-x`) even with WIP pacts the provider build would fail if the verification fails
tonynguyenit18
2021-05-20 22:56
If you have consumer and provider both with tag `feat-x` (from branch name) and config like this
```const verificationOptions = {
// ....
consumerVersionSelectors: [
{
tag: git_branch_name_here, // this is explicit
latest: true
}
]
} ```
Then the `feat-x` won?t be WIP => will fail as you expected
kflo
2021-05-20 23:20
but when the pact is included for verification, it says it was included because it is the latest version tagged with `feat-x` and is in a pending state
bethskurrie
2021-05-21 04:17
@kflo ignore WIP for now, because you're explicitly selecting a matching branch.
bethskurrie
2021-05-21 04:18
"explicitly selected" means you made a selector for it (as distinct from a pact being verified because it was determined to be a work in progress pact).
bethskurrie
2021-05-21 04:19
The feat-x pact is pending because it has not yet been successfully verified by the branch of the provider that is verifying it.
bethskurrie
2021-05-21 04:20
The verification expected to fail, and the build is expected to succeed (that is the point of a pending pact).
bethskurrie
2021-05-21 04:22
> FYI the tagging of provider and uploading of results happens after verification ? may be related
Yes, that's as expected. You can't upload a verification results before you actually verify the pact!
dawoud.sheraz
2021-05-21 11:08
Hello. Is there a way to setup user accounts in Pact broker? Like if I want to create accounts for some of my team members to access pact broker. I could not find any relevant docs for it.
matt.fellows
2021-05-21 11:15
Not in the open source version (just basic auth). We?ve added user management, roles, permissions and other stuff like that into Pactflow
dawoud.sheraz
2021-05-21 11:16
Oh, ok. Why was it not added in OSS(considering it will be helpful for devs to manage the pact broker)?
matt.fellows
2021-05-21 11:23
I can?t really say why it wasn?t added originally, because I wasn?t there when it was first built. but the gist of it I think is that it wasn?t needed when it was first created and it just never became a priority
matt.fellows
2021-05-21 11:23
It was/is for Pactflow, because our customers are enterprises and they need those features
matt.fellows
2021-05-21 11:25
I was trying to find Beth?s (creator of the broker) answer in the history here, but I couldn?t find it
kflo
2021-05-21 16:20
hm, so if you have pending/WIP pacts enabled, there is no way to make a new pact verification fail the build on a `feat-x` branch?
kflo
2021-05-21 17:58
@bethskurrie i guess what i?m confused about is why that pact is ?pending? when i request it explicitly by tag
kflo
2021-05-21 17:59
also strange? the master build does not pick up that pact as a WIP pact after the provider PR verified it and was merged
bethskurrie
2021-05-23 23:11
@dawoud.sheraz @matt.fellows the reason there are no users in the OSS broker is that the open source broker is something I did/do for the fun and love of it in my free time. I am motivated to solve problems and write code related to the contract testing aspects of the broker in my free time (I still love doing this and find it fun, even after 8 years), however, I am not motivated to write user management! That's "work" not "fun", which is why it took the creation of the commercial Pactflow product for it to happen. If anyone else wants to give up their free time to write the user management code for the OSS Pact Broker, I will very happily accept PRs!
bethskurrie
2021-05-24 00:28
@kflo yes, that is as expected. The successful verification from the master branch means that it no longer fits the definition of a work in progress pact.
bethskurrie
2021-05-24 00:35
> i guess what i?m confused about is why that pact is ?pending? when i request it explicitly by tag
It sounds like you're still confused _about_ the difference between pending and WIP.
"WIP"/"explicitly selected" refer to the reason the pact is being verified. The two reasons are mutually exclusive. Either a pact is being verified because you specified a selector, or it is being verified because it has been determined to be a "work in progress" pact.
"Pending" is a property of a pact that is being verified, and it exists on both WIP and explicitly selected pacts.
For the explicitly selected pacts, the pending flag is calculated dynamically, based on the provider branch (which is represented as a tag). If there are no successful verifications from this branch, then it is pending. Once there is a successful verification from that branch, it is no longer pending.
For the WIP pacts, the pending flag is hardcoded to true.
bethskurrie
2021-05-24 00:42
> why not to do so?
Usually, a lack of free time is the reason a feature is not available!
bethskurrie
2021-05-24 00:44
However, I have just implemented the ignore feature. It's not released just yet in the OSS code, but is released in Pactflow for beta testing. If you follow this issue here you should get notified when the feature is out for public use https://pact.canny.io/feature-requests/p/allow-results-for-specified-pacticipants-to-be-ignored-when-executing-can-i-depl @art.ptushkin
bethskurrie
2021-05-24 00:48
@kflo are you across the docs at https://docs.pact.io/wip and https://docs.pact.io/pending ?
dawoud.sheraz
2021-05-24 05:00
@bethskurrie That?s good to know. I would say that for historical reasons, you might need to document as to why certain features were not added in pact broker. It would make easier for anyone to understand what features are part of pact broker.
kflo
2021-05-24 17:37
@bethskurrie ?the master build does not pick up the pact as a WIP pact? <-- i mean, the pact has only been verified in `feat-x`, not in `master`, i expected it to get picked up in `master` because it would still be a WIP for that provider branch right?
kflo
2021-05-24 18:24
it seems that WIP pacts are just not being picked up by our builds. i wonder if this is a bug in the `scala-pact` library? i will investigate more
kflo
2021-05-24 18:26
i just reset the integration for this pact, ran the consumer tests which published a new pact, and then ran the provider tests (without a matching tag) and it didn?t pick up the consumer pact
kflo
2021-05-24 19:49
```{
"consumerVersionSelectors" : [
{
"tag" : "master",
"latest" : true
},
{
"tag" : "testing",
"latest" : true
},
{
"tag" : "production",
"latest" : true
}
],
"providerVersionTags" : [
"git-branch"
],
"includePendingStatus" : true,
"includeWipPactsSince" : "2021-04-24T13:36:41.349Z"
}```
this is our request payload which returns nothing, even though there is a published consumer pact with this provider (not using explicit consumer tag in this case)
kflo
2021-05-24 19:53
might be due to ?Discard all the pacts that were published before the first instance of this provider tag?
kflo
2021-05-24 19:54
our workflow is currently: consumer creates pacts + publishes it, and then the provider implements + verifies ? does the above mean that workflow will not work?
kflo
2021-05-24 20:11
since we don?t publish any provider tags until after verification, it seems like WIP pacts would never work prior to the first verification?
kflo
2021-05-24 21:58
ok, if we hard-code the consumer tag in the provider build configuration, everything works as expected. if we don?t do that, it seems that the pact does not get picked up by the provider as a WIP pact (probably due to issue described above). also if we use matching tags between the branches, things work prior to merge, but then after merge the `master` build of the provider has the same problem ? it does not pick up any WIP pacts, maybe also due to the same issue as above.
kflo
2021-05-24 23:05
actually, i think if the provider build fails verification on the pact (even when explicitly selected by tag), the provider build does not fail because the pact is pending. is there any way for the provider build to say ?i want the build to fail for pacts with tag `feat-x`? when WIP/pending pacts are enabled?
kflo
2021-05-24 23:07
i think the functionality i really want is: provider will pick up explicit tags at latest versions + WIP pacts, WIP pacts will not cause build to fail regardless of result, but explicit tags will
kflo
2021-05-24 23:08
after the pact is no longer pending, this works fine, but before the first verification the build can fail and the provider team can not notice and merge
bethskurrie
2021-05-24 23:09
> might be due to ?Discard all the pacts that were published before the first instance of this provider tag?
I've just made a change to this logic as it was causing problems. See https://github.com/pact-foundation/pact_broker/pull/432
bethskurrie
2021-05-24 23:09
Are you using Pactflow or OSS? It's not out in OSS yet as I need to do a few more things before releasing.
bethskurrie
2021-05-24 23:11
I won't lie, it takes me some time to get my head around each different scenario, but it serves me right for writing this in the first place :laughing:
kflo
2021-05-24 23:11
yes, completely understand. i was out of pact for a few months and i had to regain some of the context
bethskurrie
2021-05-24 23:13
Ok, that change is not released in Pactflow yet, but I'll get it out today.
bethskurrie
2021-05-24 23:13
> but explicit tags will
So, it looks like you want to turn off pending then.
bethskurrie
2021-05-24 23:14
do you want wip pacts on your feature branches, or just the explicit ones?
bethskurrie
2021-05-24 23:15
have pending and wip for master, and have pending turned off on feature branches, but explicitly specify which feature pact you want to verify on the feature branch.
bethskurrie
2021-05-24 23:16
This is my current best practice config https://docs.pact.io/provider/recommended_configuration#verification-triggered-by-provider-change
kflo
2021-05-24 23:16
ok, i think updating our configuration on the CI builds to that will fix all of our issues except the WIP pact issue that you linked in this thread. i can re-test after that goes out to make sure that is why our pacts weren?t being picked up in the `master` builds (i think it was)
bethskurrie
2021-05-24 23:16
I figure, if you're on a branch, you're either making a change unrelated to pact (so you don't care about WIP pacts) or you're trying to make a particular pact pass, so you can explicitly select that one.
bethskurrie
2021-05-24 23:18
I'm hoping to make the whole selectors thing just go away soon. Now that you're head is back in it, I'd love your thoughts on this https://github.com/pact-foundation/pact_broker/discussions/391
kflo
2021-05-24 23:20
on a cursory first pass: yes please! i will think about it more in depth before i respond
bethskurrie
2021-05-25 02:39
@kflo the new WIP logic has been deployed to pactflow. Please let me know how you go.
art.ptushkin
2021-05-25 08:20
@bethskurrie so great, thank you.
I might play with in on PactFlow, could you share the API for this, how to ignore?
aram
2021-05-25 14:00
Hi folks,
I?ve set up Pact Broker on a machine we have, and am able to push the Pact to it running localy.
Now, i?ve set up a GitLab pipeline to run and publish my contract-tests. The tests pass. BUT :
1. throw an error => `warning: Insecure world writable dir`
2. do not publish the pacts to the pact Broker (even though the logs says it published)
Any ideas?
Thanks :slightly_smiling_face:
```[2021-05-25 13:40:23.891 +0000] ERROR (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact-node@10.12.2: Pact Binary Error: /builds/XXX/YYY/server/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.49/pact/lib/ruby/lib/ruby/gems/2.2.0/gems/bundler-1.9.9/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /builds/XXX/YYY/server in PATH, mode 040777
[2021-05-25 13:40:24.516 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact@9.15.5: Setting up Pact with Consumer "YYY" and Provider "ZZZ"
using mock service on Port: "1234"
[2021-05-25 13:40:24.552 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact-node@10.12.2: Publishing Pacts to Broker
[2021-05-25 13:40:24.553 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact-node@10.12.2: Publishing pacts to broker at: http://xx.x.x.x:yyyy
[2021-05-25 13:40:24.574 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact@9.15.5: Pact File Written
[2021-05-25 13:40:24.575 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact-node@10.12.2: Removing Pact process with PID: 151```
matt.fellows
2021-05-25 22:40
that?s not a problem, it?s just warning you that `777` perms aren?t safe
matt.fellows
2021-05-25 22:40
```[2021-05-25 13:40:24.553 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact-node@10.12.2: Publishing pacts to broker at: http://xx.x.x.x:yyyy
[2021-05-25 13:40:24.574 +0000] INFO (129 on runner-swfmy1pz-project-23001225-concurrent-25m4gj): pact@9.15.5: Pact File Written```
matt.fellows
2021-05-25 22:41
those two events look out of order. It writes the pact _after_ publishing. Can you pleaes share the JS code that?s publishing?
aram
2021-05-26 06:04
```describe('Contract Tests', async function () {
const shouldPublish = !!process.env.SHOULD_PUBLISH_PACT;
this.timeout(20000);
let PACT_URL: string;
before(() => {
PACT_URL = pactProvider.mockService.baseUrl;
})
afterEach(() => {
return pactProvider.verify()
});
after(() => {
shouldPublish && publishToBroker.publishPacts();
});
it('test', async function () {
//test stuff
});
});```
aram
2021-05-26 06:05
this is what i?v got.
What?s strange to me is that it work locally? :man-shrugging:
matt.fellows
2021-05-26 06:09
``` after(async () => {
shouldPublish && await publishToBroker.publishPacts();
});```
aram
2021-05-26 06:11
the it block is good.. i?ve got a good pact file and tested on the Provider side as well :thumbsup:
matt.fellows
2021-05-26 06:12
FWIW I usually have the publish step as a separate step in the pipeline, usinsg the Pact CLI tools
matt.fellows
2021-05-26 06:14
for one, less accidents (if you have a token locally you may accidentally publish when you didn?t mean to)
matt.fellows
2021-05-26 06:14
also, now there are mulitple reasons the test could fail. Separating provides clearer visibility
scott.riley111
2021-05-26 10:12
Is there a regex or any validation for what a ?pacticipant? name can contain?
bethskurrie
2021-05-26 22:34
There is a feature request for it somewhere I think. Have a look on http://pact.canny.io or the Pact Broker issue list.
scott.riley111
2021-05-27 08:40
we?re mainly trying to maintain a 1:1 with `github_repo:pacticipant_name` , and in the case of any repo that has multiples (we may have that now or in the future) we?d use a `/` to delimit them
scott.riley111
2021-05-27 09:16
When running the broker in AWS - is there any guidance for what sort of size of db we should be provisioning? guessing t2/t3?
uglyog
2021-05-27 09:34
You can refer to https://docs.pactflow.io/docs/on-premises/system-requirements, these are what we recommend for our on-premise version which should also suite the OSS one
matt.fellows
2021-05-27 10:05
That?s for our on-premise deployment, but the specs are going to be pretty similar
matt.fellows
2021-05-27 10:05
We ran Pactflow on a pair of `t2.micro` ?s for for EC2 ages, if that helps :wink:
matt.fellows
2021-05-27 10:06
And I think a `t3.medium` for RDS. It?s more write / IOPS heavy, if that helps
scott.riley111
2021-05-27 10:09
Cool, yeh we?re starting out with `t3.medium` on aurora, so only 2 vCPUs but it?s easy enough for us to just upgrade it later
dimundo
2021-05-27 22:01
hi! any ideas why this happens? scala+sbt. auth with token in pact.sbt
```*************************************
** ScalaPact: Running Verifier **
*************************************
Attempting to fetch pact from pact broker at: https://___.pactflow.io/pacts/provider/_____/latest
cURL for request: curl -X GET 'https://___.pactflow.io/pacts/provider/_____/latest' -H 'Accept: application/json' -H 'Authorization: <REDACTED>'
Error: Request to https://___.pactflow.io timed out after 2000 ms```
dimundo
2021-05-27 22:35
firing the same curl in CLI getting
> Unauthorized. Please see https://docs.pactflow.io/docs/login-help for more information.
dimundo
2021-05-27 22:38
```scalaVersion := "2.13.5"```
```scalaTestV = "3.2.8"```
```pactVersion = "3.3.1"```
bethskurrie
2021-05-28 00:41
```curl https://<tenant>.http://pactflow.io -H "Authorization: Bearer <token>"```
bethskurrie
2021-05-28 00:42
@scott.riley111 there will be a separate repositoryName field coming soon.
bethskurrie
2021-05-28 00:44
```{
name: 'foo-thing',
displayName: "Foo Thing",
mainBranch: "main",
repositoryUrl: "http://url",
repositoryName: "foo-thing",
repositoryNamespace: "some-group"
}```
bethskurrie
2021-05-28 00:45
There have been some issues with slashes in resource names because some reverse proxies like ngnix can expand encoded slashes into real slashes, which then causes the application to return 404s. So if you notices issues, that's where to check.
matt.fellows
2021-05-28 03:14
Add the `-v` to that cURL and share any redacted response if the output doesn?t make sense to you
dimundo
2021-05-28 05:12
```* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 401
< date: Fri, 28 May 2021 05:10:38 GMT
< content-type: text/plain
< content-length: 88
< vary: Accept
< x-pact-broker-version: 2.79.0
< x-pact-broker-git-sha: f119becf
< x-pactflow-git-sha: a9099f545
< x-content-type-options: nosniff
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< x-request-id: dbb8817494344c2d6460e6207b55703e
<
Unauthorized. Please see https://docs.pactflow.io/docs/login-help for more information.
* Connection #0 to host http://___.pactflow.io left intact
* Closing connection 0```
dimundo
2021-05-28 05:15
and the full thingy
```* Trying 54.153.195.108...
* TCP_NODELAY set
* Connected to http://___.pactflow.io (54.153.195.108) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=*.http://pact.dius.com.au
* start date: Sep 10 00:00:00 2020 GMT
* expire date: Oct 10 12:00:00 2021 GMT
* subjectAltName: host "http://___.pactflow.io" matched cert's "*.http://pactflow.io"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7fedad808200)
> POST /pacts/___/latest HTTP/2
> Host: http://___.pactflow.io
> User-Agent: curl/7.64.1
> Accept: application/json
> Authorization: _Read/write token (CI)_
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
< HTTP/2 401
< date: Fri, 28 May 2021 05:10:38 GMT
< content-type: text/plain
< content-length: 88
< vary: Accept
< x-pact-broker-version: 2.79.0
< x-pact-broker-git-sha: f119becf
< x-pactflow-git-sha: a9099f545
< x-content-type-options: nosniff
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< x-request-id: dbb8817494344c2d6460e6207b55703e
<
Unauthorized. Please see https://docs.pactflow.io/docs/login-help for more information.
* Connection #0 to host http://___.pactflow.io left intact
* Closing connection 0```
dimundo
2021-05-28 05:32
```curl -X GET 'https://___.pactflow.io/pacts/___/latest' -H 'Accept: application/json' -H 'Authorization: blablabla'```
doesnt work
dimundo
2021-05-28 05:32
```curl -X GET 'https://___.pactflow.io/pacts/___/latest' -H 'Accept: application/json' -H 'Authorization: Bearer blablabla'```
*does work* ( with `Bearer` )
dimundo
2021-05-28 05:33
still, config edit
```pactBrokerToken := "Bearer blablabla"```
doesnt help - looks like `Bearer` is omitted
matt.fellows
2021-05-28 05:52
> curl -X GET ?https://___.pactflow.io/pacts/___/latest? -H ?Accept: application/json? -H ?Authorization: Bearer blablabla?
That?s what beth said to do. I think you accidentally ommitted the `Bearer` bit
matt.fellows
2021-05-28 05:53
looking at the implementation of scala pact, you _don?t_ need to supply the `Bearer` bit: https://github.com/ITV/scala-pact/blob/17e64f4742c99b6f1932d4b4eaa10ff65950f052/scalapact-shared/src/main/scala/com/itv/scalapact/shared/PactBrokerAuthorization.scala#L27-L29
dimundo
2021-05-28 05:54
if i edit it to be
```pactBrokerToken := "Bearer blabla"```
in console I'm getting same timedout
matt.fellows
2021-05-28 05:55
what does the debug logs look like for that? I?m wondering if there is a network interference or something? Idelaly, we can see the raw HTTP request scala pact sends. Maybe there is a bug?
dimundo
2021-05-28 05:57
```sbt "pactVerify --host localhost --port 9000"
[info] welcome to sbt 1.4.7 (N/A Java 15.0.2)
[info] loading global plugins from /Users/dmitrijsm/.sbt/1.0/plugins
[info] loading settings for project akka-http-microservice-build from plugins.sbt ...
[info] loading project definition from /Users/dmitrijsm/dev/pact_poc/akka-http-microservice/project
[info] loading settings for project akka-http-microservice from build.sbt,pact.sbt ...
[info] set current project to akka-http-microservice (in build file:/Users/dmitrijsm/dev/pact_poc/akka-http-microservice/)
*************************************
** ScalaPact: Running Verifier **
*************************************
Attempting to fetch pact from pact broker at: https://___.pactflow.io/pacts/___/latest
cURL for request: curl -X GET 'https://___.pactflow.io/pacts/___/latest' -H 'Accept: application/json' -H 'Authorization: <REDACTED>'
Error: Request to https://___.pactflow.io timed out after 2000 ms
[error] java.util.concurrent.TimeoutException: Request to https://___.pactflow.io timed out after 2000 ms
[error] at org.http4s.client.blaze.BlazeClient$$anon$1.run(BlazeClient.scala:167)
[error] at java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1429)
[error] at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
[error] at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1016)
[error] at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1665)
[error] at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1598)
[error] at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
[error] at apply @ org.http4s.client.blaze.BlazeClient$$anon$1.run(BlazeClient.scala:167)
[error] at apply @ org.http4s.client.blaze.BlazeClient$$anon$1.run(BlazeClient.scala:167)
[error] at apply @ org.http4s.client.blaze.BlazeClient$$anon$1.run(BlazeClient.scala:167)
[error] at apply @ org.http4s.client.blaze.BlazeClient$$anon$1.run(BlazeClient.scala:167)
[error] at apply @ org.http4s.client.blaze.BlazeClient$$anon$1.run(BlazeClient.scala:167)
[error] at >>$extension @ org.http4s.client.blaze.Http1Connection.$anonfun$executeRequest$2(Http1Connection.scala:199)
[error] at flatMap @ org.http4s.client.blaze.BlazeClient$.$anonfun$makeClient$1(BlazeClient.scala:173)
[error] at unsafeRunSync @ com.itv.scalapact.http4s21.impl.ScalaPactHttpClient.doRequest(ScalaPactHttpClient.scala:15)
[error] at unsafeRunSync @ com.itv.scalapact.http4s21.impl.ScalaPactHttpClient.doRequest(ScalaPactHttpClient.scala:15)
[error] at use @ com.itv.scalapact.http4s21.impl.Http4sClientHelper$.$anonfun$doRequest$4(Http4sClientHelper.scala:40)
[error] at unsafeRunSync @ com.itv.scalapact.http4s21.impl.ScalaPactHttpClient.doRequest(ScalaPactHttpClient.scala:15)
[error] at uncancelable @ org.http4s.client.ConnectionManager$.pool(ConnectionManager.scala:83)
[error] at uncancelable @ org.http4s.client.ConnectionManager$.pool(ConnectionManager.scala:83)
[error] at map @ org.http4s.client.ConnectionManager$.pool(ConnectionManager.scala:83)
[error] at make @ org.http4s.client.blaze.BlazeClientBuilder.connectionManager(BlazeClientBuilder.scala:281)
[error] at apply @ org.http4s.blazecore.package$.tickWheelResource(package.scala:24)
[error] (pactVerify) java.util.concurrent.TimeoutException: Request to https://___.pactflow.io timed out after 2000 ms
[error] Total time: 3 s, completed 28 May 2021, 08:55:10```
matt.fellows
2021-05-28 05:58
something is interfering with the request outbound. I love that that log file has a cURL sample though!
matt.fellows
2021-05-28 05:59
I?m wondering if curl works because of some proxy variables/env settings that aren?t present (or vice versa)
matt.fellows
2021-05-28 05:59
either that, or it needs more than 2s to make the call (pretty slow, but worth seeing if the timeout can be increased somehow)
matt.fellows
2021-05-28 06:00
these seem like questions for the #pact-scala-itv channel, because we know the broker is up and available
dimundo
2021-05-28 06:37
and it helped :smile: 2 s ( default ) wasnt ok, but even 3 - worked ( started from 10 :smile: )
matt.fellows
2021-05-28 06:52
and maybe DM me your pactlfow account name, I?d like to check our response times
greg.tyler
2021-05-28 14:24
Hello! Is there a way of checking if a Pact JSON file is fulfillable without sending it to the Broker?
I basically want to do `pact-broker can-i-deploy --pacticipant=provider-app --latest --pacticipant=consumer-app --hash={hash of JSON file}` and return true if that JSON file hash has already been tested.
greg.tyler
2021-05-28 14:26
For context: this is for the CI of external PRs (from dependabot) where it can?t publish to the broker because it doesn?t have access to secrets.
If the Pact hasn?t changed, we?ll pass the build. If it _has_, we?ll fail and resolve it manually.
bethskurrie
2021-05-30 23:19
@gnewitt if it was allowed read-only credentials, you could use `--output json` on the can-i-deploy query, look up the pact URL in the response, get it, and do a local diff to see if it had changed.
bethskurrie
2021-05-30 23:19
Or you could just get the latest pact directly, if that's all you cared about.
anchit.99
2021-05-31 09:30
I'm trying to install the broker manually. WEBrick seems to be servicing the broker after the db is created/seeded. Any idea what is the use of having an Nginx server over the WEBrick?
anchit.99
2021-05-31 09:38
I got the answer to the previous question. Please ignore that one.
Which is the file that calls WEBrick?
anchit.99
2021-05-31 10:52
Also, (2) if I want to run any application server do I direct the server towards a particular folder or should I be calling it via ruby code at the place where WEBrick was called?
bethskurrie
2021-06-01 01:03
@anchit.99 we really don't recommend running the vanilla Ruby application unless you're an experienced ops person. There is very little supporting documentation.
bethskurrie
2021-06-01 01:04
There are instructions here https://docs.pact.io/pact_broker#rolling-your-own
bethskurrie
2021-06-01 01:05
But again, if those are not clear enough for you, then I'd recommend getting help from an ops person. There are so many variables in running an application server that it's really not something we can provide support for over a slack channel in our free time.
bethskurrie
2021-06-01 04:30
Webrick is not a production appropriate application server to run the app on.
bethskurrie
2021-06-01 04:31
You either need puma (pure ruby) or passenger (which comes with it's own ngnix, depending on how you run it).
bethskurrie
2021-06-01 04:32
If you're just testing it out, you can try copying the puma set up from the puma based docker image here https://github.com/pact-foundation/pact-broker-docker/tree/master/pact_broker
bethskurrie
2021-06-01 04:33
If you're not going to put any kind of load balancing or process monitoring in front of it (ie. AWS auto scaling) then you'd be better off using passenger, and copying the set up from the passenger based docker image https://github.com/DiUS/pact_broker-docker
bethskurrie
2021-06-01 04:34
Again, totally do not recommend either of these options for production use without ops support.
anchit.99
2021-06-01 07:52
@bethskurrie Thanks Beth! Personally I prefer the docker image as well. But our company's policy is somewhat strict and requires going with an independent install. The docker image is awesome and I was able to get the broker runing with it while trying out Pact.
anchit.99
2021-06-01 07:56
I did follow the instructions given at https://docs.pact.io/pact_broker#rolling-your-own and reached near the end of it. I'll try copying the passenger setup. If it's not too much to ask it would be really great if you could point out a file / folder that contains the passenger config. I'm sorry I don't have that level of depth in Ruby and I'm not so familiar with bundler either.
I'm wondering whether I should be setting up passenger as an external server and feeding a particular folder / config files to it. Or whether I should be using the passenger's API and calling that somewhere from teh code by commenting out the part where we are initializing the WEBrick server.
bethskurrie
2021-06-01 08:04
@anchit.99 the passenger config files are in this directory https://github.com/DiUS/pact_broker-docker/tree/master/container
bethskurrie
2021-06-01 08:05
I'd be following a passenger tutorial like https://www.phusionpassenger.com/library/walkthroughs/start/ruby.html
bethskurrie
2021-06-01 08:06
Or this one, actually, for prod use https://www.phusionpassenger.com/library/walkthroughs/deploy/ruby/
bethskurrie
2021-06-01 08:07
I'm recommending passenger because it has inbuilt process monitoring in it, assuming you're not running it inside some other container/process management solution.
bethskurrie
2021-06-01 08:08
You'll want to grab the entire /pact_broker folder from the DiUS/pact_broker-docker repository, because it has the recommended configuration options and basic auth configured.
bethskurrie
2021-06-01 08:08
The vanilla app from the pact_broker repository doesn't have the same settings.
greg.tyler
2021-06-01 08:32
@matt.fellows I don?t want the CI to have Pact broker credentials (for external PRs) because a malicious PR could then use them to write/delete data from the broker. So I?m trying to identify a read-only solution.
@bethskurrie Yeah, I think Friday brain might have been over complicating this, comparing the generated JSON with the latest contents makes sense. Looks like they?re not quite the same since the remote version contains links, but I?ll try and find a clean way to compare them. Thanks!
anchit.99
2021-06-01 08:38
@bethskurrie I think this should be more than enough to get this done. Thanks Beth! You're a life saver! :slightly_smiling_face:
matt.fellows
2021-06-01 10:27
> I don?t want the CI to have Pact broker credentials (for external PRs) because a malicious PR could then use them to write/delete data from the broker. So I?m trying to identify a read-only solution.
That statement doesn?t make sense. To be able to _read_ data from the broker, you must have credentials.
matt.fellows
2021-06-01 10:28
If you just want to protect against writes/deletes, only give the read-only ones (or if it?s Pactflow, create a role with minimal permissions and use the read-only token)
greg.tyler
2021-06-01 10:29
Sorry, yes, that?s just me being unclear. I don?t want it to have _write_ credentials, but it does have read-only :slightly_smiling_face:
greg.tyler
2021-06-02 08:21
For posterity, I ended up with this:
```curl ${PACT_BROKER_URL}/pacts/provider/{PROVIDER}/consumer/{CONSUMER}/latest > /tmp/latest-pact.json
(diff <(jq --sort-keys . ${PACT_DIR}/pact.json) <(jq --sort-keys . /tmp/latest-pact.json) || true) | (! grep '<')```
It diffs the two files, and errors on differences, _but_ it allows any additions within the `latest-pact.json` file because that?s the HAL data and IDs. Technically, a malicious PR could remove interactions from a contract without us noticing (though in our case it would flag in `main` long before deployment) so I wouldn?t recommend it at all. A fun side adventure though.
aubilla
2021-06-02 14:18
:man-raising-hand: I?m working on a very basic POC of Pact and I?m trying to run a provider verification by fetching pacts from a broker I have deployed locally on my laptop and that I?m exposing through http://ngrok.io
:robot_face: I?ve set basic auth when running the dockerized Broker:
```docker run --name pactbroker --link pactbroker-db:postgres -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD=TheUserPassword -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -e PACT_BROKER_BASIC_AUTH_USERNAME=foo -e PACT_BROKER_BASIC_AUTH_PASSWORD=bar -d -p 9292:9292 pactfoundation/pact-broker```
:phone: and I?m setting up the call to the broker on the build.gradle of my provider like so:
```pact {
broker {
pactBrokerUrl = 'http://myurl.ngrok.io/'
// Basic auth
pactBrokerUsername = 'foo'
pactBrokerPassword = 'bar'
}
serviceProviders {
patientProvider {
(ommited stuff about the provider)
fromPactBroker {
selectors = latestTags('master')
}
}
}
}```
:boom: But I?m getting an error that I don?t understand:
```* What went wrong:
Failed to fetch pacts from pact broker http://myurl.ngrok.io/
> Call to fetch pacts from Pact Broker failed with an exception
* Try:
Run with --info or --debug option to get more log output. Run with --scan to get full insights.
* Exception is:
org.gradle.api.GradleScriptException: Failed to fetch pacts from pact broker http://myurl.ngrok.io/
at au.com.dius.pact.provider.gradle.PactPlugin.setupPactConsumersFromBroker(PactPlugin.groovy:108)
at org.gradle.internal.metaobject.BeanDynamicObject$GroovyObjectAdapter.invokeOpaqueMethod(BeanDynamicObject.java:584)```
:question: What could I be missing here?
bethskurrie
2021-06-02 20:36
Are there any logs in the pact broker that suggest that a connection was made, but denied (401?)
bethskurrie
2021-06-02 20:37
Can you run a curl script to connect to the broker from your machine, or even just open the index page in a browser to ensure you have connectivity?
matt.fellows
2021-06-02 23:38
i.e. should it be
```pactBrokerUrl = 'http://myurl.ngrok.io'```
or
```pactBrokerUrl = 'http://myurl.ngrok.io:9292'```
or some other port?
aubilla
2021-06-03 06:59
ngrok is exposing the broker through port 80 and I can access it with Chrome. I even have a few Pacts already there that were posted by a Consumer with the following command:
```./pact-broker publish --consumer-app-version 2.0.0+${CI_COMMIT_SHORT_SHA} --broker-base-url http://myurl.ngrok.io/ ../../target/pacts/PatientClient-PatientService.json --tag ${CI_COMMIT_REF_NAME}```
matt.fellows
2021-06-03 07:30
if you could please enable verbose logging and print that out, it will help
aubilla
2021-06-03 08:33
These are the logs after running it with --debug option on:
```2021-06-03T08:51:15.929+0200 [DEBUG] [au.com.dius.pact.core.pactbroker.HalClient] Fetching: /
2021-06-03T08:51:15.932+0200 [DEBUG] [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
2021-06-03T08:51:15.932+0200 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
2021-06-03T08:51:15.934+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {}->http://myurl.ngrok.io:80][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]
2021-06-03T08:51:15.934+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 7][route: {}->http://myurl.ngrok.io:80][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T08:51:15.934+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Opening connection {}->http://myurl.ngrok.io:80
2021-06-03T08:51:16.040+0200 [DEBUG] [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connecting to http://myurl.ngrok.io/3.134.39.220:80
2021-06-03T08:51:16.179+0200 [DEBUG] [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connection established 192.168.100.50:59585<->3.134.39.220:80
2021-06-03T08:51:16.180+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request GET / HTTP/1.1
2021-06-03T08:51:16.180+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
2021-06-03T08:51:16.180+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T08:51:16.502+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T08:51:16.502+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication required
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] http://myurl.ngrok.io:80 requested authentication
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, CredSSP, Digest, Basic]
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Negotiate authentication scheme not available
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Kerberos authentication scheme not available
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for NTLM authentication scheme not available
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for CredSSP authentication scheme not available
2021-06-03T08:51:16.503+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Digest authentication scheme not available
2021-06-03T08:51:16.504+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Selected authentication options: [BASIC [complete=true]]
2021-06-03T08:51:16.504+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request GET / HTTP/1.1
2021-06-03T08:51:16.504+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: CHALLENGED
2021-06-03T08:51:16.504+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Generating response to an authentication challenge using basic scheme
2021-06-03T08:51:16.504+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T08:51:16.812+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T08:51:16.812+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication succeeded
2021-06-03T08:51:16.813+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Caching 'basic' auth scheme for http://myurl.ngrok.io:80
2021-06-03T08:51:16.816+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection [id: 7][route: {}->http://myurl.ngrok.io:80] can be kept alive indefinitely
2021-06-03T08:51:16.817+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-7: set socket timeout to 0
2021-06-03T08:51:16.817+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection released: [id: 7][route: {}->http://myurl.ngrok.io:80][total kept alive: 1; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {}->http://myurl.ngrok.io:80][total kept alive: 1; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 7][route: {}->http://myurl.ngrok.io:80][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-7: set socket timeout to 0
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request POST /pacts/provider/patientProvider/for-verification HTTP/1.1
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
2021-06-03T08:51:16.819+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication required
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] http://myurl.ngrok.io:80 requested authentication
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, CredSSP, Digest, Basic]
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Negotiate authentication scheme not available
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Kerberos authentication scheme not available
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for NTLM authentication scheme not available
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for CredSSP authentication scheme not available
2021-06-03T08:51:17.099+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Digest authentication scheme not available
2021-06-03T08:51:17.100+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Selected authentication options: [BASIC [complete=true]]
2021-06-03T08:51:17.100+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request POST /pacts/provider/patientProvider/for-verification HTTP/1.1
2021-06-03T08:51:17.100+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: CHALLENGED
2021-06-03T08:51:17.100+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Generating response to an authentication challenge using basic scheme
2021-06-03T08:51:17.100+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T08:51:17.421+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T08:51:17.422+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication succeeded
2021-06-03T08:51:17.422+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Caching 'basic' auth scheme for http://myurl.ngrok.io:80
2021-06-03T08:51:17.423+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-7: Close connection
2021-06-03T08:51:17.424+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection discarded
2021-06-03T08:51:17.425+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection released: [id: 7][route: {}->http://myurl.ngrok.io:80][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]
2021-06-03T08:51:17.426+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute container callback action'
2021-06-03T08:51:17.426+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute container callback action' completed
2021-06-03T08:51:17.426+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute Project.afterEvaluate listener'
2021-06-03T08:51:17.426+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute Project.afterEvaluate listener' completed
2021-06-03T08:51:17.427+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Notify afterEvaluate listeners of :'
2021-06-03T08:51:17.427+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Notify afterEvaluate listeners of :' completed
2021-06-03T08:51:17.427+0200 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker Thread 5: released lock on :
2021-06-03T08:51:17.427+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Configure project :'
2021-06-03T08:51:17.427+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Configure project :' completed
2021-06-03T08:51:17.427+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Configure build'
2021-06-03T08:51:17.428+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Configure build' completed
2021-06-03T08:51:17.432+0200 [DEBUG] [org.gradle.internal.work.DefaultWorkerLeaseService] Worker lease root.1 completed (0 worker(s) in use)
2021-06-03T08:51:17.432+0200 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker Thread 5: released lock on root.1
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] FAILURE: Build failed with an exception.
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * What went wrong:
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Failed to fetch pacts from pact broker http://myurl.ngrok.io/
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Call to fetch pacts from Pact Broker failed with an exception
2021-06-03T08:51:17.433+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]```
aubilla
2021-06-03 08:40
Just to rule out ngrok or network issues as a root cause, I?ve run the pact verification locally, pointing at `http://localhost:9292` with the following results:
```2021-06-03T10:37:34.725+0200 [DEBUG] [au.com.dius.pact.core.pactbroker.HalClient] Fetching: /
2021-06-03T10:37:34.726+0200 [DEBUG] [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
2021-06-03T10:37:34.726+0200 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
2021-06-03T10:37:34.726+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {}->http://localhost:9292][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]
2021-06-03T10:37:34.726+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 11][route: {}->http://localhost:9292][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T10:37:34.726+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Opening connection {}->http://localhost:9292
2021-06-03T10:37:34.727+0200 [DEBUG] [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connecting to localhost/127.0.0.1:9292
2021-06-03T10:37:34.727+0200 [DEBUG] [org.apache.http.impl.conn.DefaultHttpClientConnectionOperator] Connection established 127.0.0.1:61170<->127.0.0.1:9292
2021-06-03T10:37:34.727+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request GET / HTTP/1.1
2021-06-03T10:37:34.727+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
2021-06-03T10:37:34.727+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication required
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] localhost:9292 requested authentication
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, CredSSP, Digest, Basic]
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Negotiate authentication scheme not available
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Kerberos authentication scheme not available
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for NTLM authentication scheme not available
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for CredSSP authentication scheme not available
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Digest authentication scheme not available
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Selected authentication options: [BASIC [complete=true]]
2021-06-03T10:37:34.729+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request GET / HTTP/1.1
2021-06-03T10:37:34.730+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: CHALLENGED
2021-06-03T10:37:34.730+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Generating response to an authentication challenge using basic scheme
2021-06-03T10:37:34.730+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T10:37:34.732+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T10:37:34.732+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication succeeded
2021-06-03T10:37:34.732+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Caching 'basic' auth scheme for http://localhost:9292
2021-06-03T10:37:34.733+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection [id: 11][route: {}->http://localhost:9292] can be kept alive indefinitely
2021-06-03T10:37:34.733+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-11: set socket timeout to 0
2021-06-03T10:37:34.733+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection released: [id: 11][route: {}->http://localhost:9292][total kept alive: 1; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T10:37:34.733+0200 [DEBUG] [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {}->http://localhost:9292][total kept alive: 1; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 11][route: {}->http://localhost:9292][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10]
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-11: set socket timeout to 0
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request POST /pacts/provider/patientProvider/for-verification HTTP/1.1
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
2021-06-03T10:37:34.734+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication required
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] localhost:9292 requested authentication
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Authentication schemes in the order of preference: [Negotiate, Kerberos, NTLM, CredSSP, Digest, Basic]
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Negotiate authentication scheme not available
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Kerberos authentication scheme not available
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for NTLM authentication scheme not available
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for CredSSP authentication scheme not available
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Challenge for Digest authentication scheme not available
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Selected authentication options: [BASIC [complete=true]]
2021-06-03T10:37:34.736+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request POST /pacts/provider/patientProvider/for-verification HTTP/1.1
2021-06-03T10:37:34.737+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: CHALLENGED
2021-06-03T10:37:34.737+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Generating response to an authentication challenge using basic scheme
2021-06-03T10:37:34.737+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-06-03T10:37:34.742+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-06-03T10:37:34.742+0200 [DEBUG] [org.apache.http.impl.auth.HttpAuthenticator] Authentication succeeded
2021-06-03T10:37:34.742+0200 [DEBUG] [org.apache.http.impl.client.TargetAuthenticationStrategy] Caching 'basic' auth scheme for http://localhost:9292
2021-06-03T10:37:34.742+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-11: Close connection
2021-06-03T10:37:34.742+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection discarded
2021-06-03T10:37:34.742+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection released: [id: 11][route: {}->http://localhost:9292][total kept alive: 0; route allocated: 0 of 5; total allocated: 0 of 10]
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute container callback action'
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute container callback action' completed
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Execute Project.afterEvaluate listener'
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Execute Project.afterEvaluate listener' completed
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Notify afterEvaluate listeners of :'
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Notify afterEvaluate listeners of :' completed
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker Thread 7: released lock on :
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Configure project :'
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Configure project :' completed
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Completing Build operation 'Configure build'
2021-06-03T10:37:34.743+0200 [DEBUG] [org.gradle.internal.operations.DefaultBuildOperationExecutor] Build operation 'Configure build' completed
2021-06-03T10:37:34.744+0200 [DEBUG] [org.gradle.internal.work.DefaultWorkerLeaseService] Worker lease root.1 completed (0 worker(s) in use)
2021-06-03T10:37:34.744+0200 [DEBUG] [org.gradle.internal.resources.AbstractTrackedResourceLock] Daemon worker Thread 7: released lock on root.1
2021-06-03T10:37:34.744+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]
2021-06-03T10:37:34.744+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] FAILURE: Build failed with an exception.
2021-06-03T10:37:34.744+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]
2021-06-03T10:37:34.745+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] * What went wrong:
2021-06-03T10:37:34.745+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] Failed to fetch pacts from pact broker http://localhost:9292
2021-06-03T10:37:34.745+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter] > Call to fetch pacts from Pact Broker failed with an exception
2021-06-03T10:37:34.745+0200 [ERROR] [org.gradle.internal.buildevents.BuildExceptionReporter]```
aubilla
2021-06-03 09:01
Oh! I feel a little embarrassed now. The problem was that the provider?s name was `patientProvider` on the on the Gradle task and `@PactTestFor(providerName = "PatientService")` on the Consumer test. Just changed it on the provider?s Gradle task to match what?s on the consumer side and it works!
Thanks a lot for helping me debugging this issue.
bethskurrie
2021-06-03 22:49
@aubilla I have to take the blame for "pacticipant", so it's nice to be able to take the credit for something :laughing:
gurkiratguliani
2021-06-07 20:09
I have written consumer and provider test and i'm using @PactBroker . It works . However when i add certain more fields in one test in the consumer side, the test starts failing. Shouldn't a new pact file be generated in target/pact folder in consumer side ? Should i delete the pact file which is uploaded on the @PactBroker url only then new pact file will be generated? I'm using java and spring boot application and this is related to messaging ( using apache kafka ) and not API Testing .
bethskurrie
2021-06-08 07:14
People who use github statuses for their consumer PRs (eg. @bheemreddy181) like this: http://blog.pact.io/2018/07/16/publishing-pact-verification-statuses-to-github/ to make sure that the pact is verified successfully before merging a feature branch - would you prefer to wait for the provider version that supports the pact to be deployed to a test environment before merging (so that you know you can deploy that version of the consumer straight away) or do you only care about getting a passing verification from the main branch?
greg.tyler
2021-06-08 08:23
Right now, we only care about passing on main, but that?s because we have a unified deployment process (if either provider or any consumer are changed, everything gets redeployed (it?s not great, we?re working on it)).
In the future I think we?d _also_ only care about passing on main, because we?d use can-i-deploy at each deployment step. But that?s total speculation because we?ve not started implementing it yet.
greg.tyler
2021-06-08 08:24
I don?t think my view should count, our situation is totally not good practice :smile:
bheemreddy181
2021-06-08 15:11
Same with us as Gerg , we only care about the verification coming from main branch as we have a unified deployment process in place
bheemreddy181
2021-06-08 15:12
right now we manually co-ordinate the deployments for the both the dependent services
kyle.florence
2021-06-08 16:52
We also validate against the main branch and run can I deploy before every environment deployment
matty_o_connor01
2021-06-12 23:08
Hi there. Is someone able to help me when trying to run the pact broker in docker against a local installation of postgresql in windows?
When attempting to run the following....
```docker run pactfoundation/pact-broker -e PACT_BROKER_DATABASE_USERNAME=pact_broker -e PACT_BROKER_DATABASE_PASSWORD=Penwater858 -e PACT_BROKER_DATABASE_HOST=host.docker.internal -e PACT_BROKER_DATABASE_NAME=pact_broker -e PACT_BROKER_DATABASE_PORT=5432 -p 9292:9292```
I get....
```Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?
bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma)
Sequel::DatabaseConnectionError: PG::ConnectionBad: could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?```
I have done the enable remote connection steps and restarted the service.
Also when running the following it seems to accept the connection
```psql
psql (13.3)
WARNING: Console code page (850) differs from Windows code page (1252)
8-bit characters might not work correctly. See psql reference
page "Notes for Windows users" for details.
Type "help" for help.
pact_broker=>```
Many thanks,
bethskurrie
2021-06-13 06:53
But I'm not sure how to get to a service running on the host from a docker image.
bethskurrie
2021-06-13 06:53
I was going to suggest that you needed to make the postgresql service available to external connections, but you say you've already done that.
bethskurrie
2021-06-13 06:54
Given that that connection string works, try setting PACT_BROKER_DATABASE_URL="
``````
"
bethskurrie
2021-06-13 06:57
```connections on Unix domain socket "/tmp/.s.PGSQL.5432"?```
That error doesn't seem right to me.
bethskurrie
2021-06-13 06:57
It shouldn't be looking on unix socket. It should be looking for a TCP socket
bethskurrie
2021-06-13 07:00
Is there another host you can check from to make sure your database is really externally accessible?
bethskurrie
2021-06-13 07:01
Sorry, that connection string should have been PACT_BROKER_DATABASE_URL="
``````
"
bethskurrie
2021-06-13 07:02
Connecting from your own localhost to localhost does not (I think) prove that the port is actually externally accessible
bethskurrie
2021-06-13 07:23
Try getting your external IP, and then running
```psql :Penwater858@<YOUR_EXTERNAL_IP>/pact_broker```
bethskurrie
2021-06-13 07:33
Btw, is there a particular reason you can't use docker-compose and just map the data directory to your local machine to persist the data?
matty_o_connor01
2021-06-13 08:33
Thanks. Didn't work with `PACT_BROKER_DATABASE_URL` unfortunately. Same error.
I was looking to go with a somewhat managed service for PostgreSQL in Azure which is why I was trying to get it to work locally in this way.
Unfortunately that didn't work either. My cloud resource connection string is `psql "host=http://pactbrokerserver.postgres.database.azure.com port=5432 dbname=pactbroker user=postgres@pactbrokerserver password={Password}"` which I tried to translate into the docker run command..
```docker run pactfoundation/pact-broker -e PACT_BROKER_DATABASE_USERNAME=postgres@pactbrokerserver -e PACT_BROKER_DATABASE_PASSWORD={Password} -e PACT_BROKER_DATABASE_HOST=http://pactbrokerserver.postgres.database.azure.com -e PACT_BROKER_DATABASE_NAME=pactbroker -e PACT_BROKER_DATABASE_PORT=5432 -e PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES=5 -p 9292:9292```
Which gives me the same error. I switched off SSL and added a firewall rule name for my host machine running docker but I don't know if either of those are a factor if I'm getting the same error?
I can try switching over to docker. It initially seemed more awkward to me to manage things like volumes and backups in the cloud if you are working with a postgreSQL docker container but I can at least work from the working docker compose example in the pact broker docker repository
bethskurrie
2021-06-13 10:18
Can you connect to the database directly using psql? 99% of the time, it's firewalls or the port not being exposed properly.
matt.fellows
2021-06-13 10:19
The config looked OK to my eyes. So I?m with Beth, seems like networking issue
bethskurrie
2021-06-13 10:20
I'm afraid I have no experience with Azure, so I can't give you any advice as to what to look for.
matt.fellows
2021-06-13 10:20
The simplest way to find out, is to shell into the docker container and see if you have a network path to the postgres instance
bethskurrie
2021-06-13 10:20
I'd look for some docs on "how to run an application in Azure". There's bound to be a sample somewhere.
matty_o_connor01
2021-06-13 10:21
Wouldn't the container need to start successfully first before I can shell into it?
bethskurrie
2021-06-13 10:21
> The simplest way to find out, is to shell into the docker container and see if you have a network path to the postgres instance
The Alpine instance doesn't have a heap of networking tools on it unfortunately. What do you know of that's there to use Matt?
matt.fellows
2021-06-13 10:22
> Wouldn?t the container need to start successfully first before I can shell into it?
Assuming you?re using the standard orchestration tools, probably.
matt.fellows
2021-06-13 10:22
I?m suggesting something like the ability to SSH onto the docker host, run a `docker run -it ?` with `/bin/sh` as the entrypoint (off the top of my head)
matt.fellows
2021-06-13 10:23
from within the container, you?ll then need to assess whether or not a network path is there
matty_o_connor01
2021-06-13 10:23
`psql ` does work for me but not with the external ip @bethskurrie you suggested in one of your earlier comments
matt.fellows
2021-06-13 10:26
I think it is, but since we?re having connection issues, might as well rule that one out
matty_o_connor01
2021-06-13 10:29
Am I right in thinking an alternative should be...
```docker run pactfoundation/pact-broker -e PACT_BROKER_DATABASE_URL=
ernal/pact_broker -p 9292:9292```
matty_o_connor01
2021-06-13 10:31
I need to drop off. I've wacked it on Stack Overflow for a bit more visibility. Thanks for the input so far
matt.fellows
2021-06-13 10:33
```docker run -it --entrypoint /bin/sh --user root -e PACT_BROKER_DATABASE_USERNAME=pact_broker -e PACT_BROKER_DATABASE_PASSWORD=Penwater858 -e PACT_BROKER_DATABASE_HOST=host.docker.internal -e PACT_BROKER_DATABASE_NAME=pact_broker -e PACT_BROKER_DATABASE_PORT=5432 -p 9292:9292 pactfoundation/pact-broker
# once in the container...
apk update
apk add busybox-extras
# see if there is a network path
telnet $PACT_BROKER_DATABASE_HOST $PACT_BROKER_DATABASE_PORT```
bethskurrie
2021-06-13 10:41
Ah! That explains why it was trying to connect to the Linux socket, not the TCP one
matty_o_connor01
2021-06-13 15:50
Yep that was it! So close yet so far. Thanks, that was a frustrating one.
anchit.99
2021-06-15 09:23
I am trying to run the docker broker. How do I enable the authentication for the broker?
I tried setting the following 4 environment variables and tried restarting docker.
PACT_BROKER_BASIC_AUTH_USERNAME
PACT_BROKER_BASIC_AUTH_PASSWORD
PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME
PACT_BROKER_BASIC_AUTH_READ_ONLY_PASSWORD
but I'm still able to view the pact in the browser. AFAIK opening http://localhost:9292 in the browser will show some kind of login dialog. Please correct me if I'm wrong.
anchit.99
2021-06-15 09:40
I also tried publishing to the broker via pact-broker CLI and was able to publish it without entering any credentials.
matt.fellows
2021-06-15 10:49
It will show a basic with dialog yes, but once enabled if you login once your browser will remember it and not ask you again
connor.aird
2021-06-15 14:42
Hello, I am trying to make use of the Automatic data clean up functionality within the pact broker. I understand that `pactfoundation/pact-broker:2.79.1.1` has the functionality available but I?m not sure which version of `dius/pact-broker` has this?
bethskurrie
2021-06-15 22:30
Did you completely shut down and remove the previous container @anchit.99?
bethskurrie
2021-06-15 22:32
I'd recommend taking this docker-compose and putting the basic auth env vars in it https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose.yml
bethskurrie
2021-06-15 22:33
We really recommend people use the pactfoundation one, unless there's a particular reason that you need to use passenger.
anchit.99
2021-06-16 05:15
Ah! I had put the environment variables in windows > env variables. I'll try adding them to the docker compose file like in the URL Beth provided.
anchit.99
2021-06-16 05:41
great! It worked via putting environment variables into the docker compose file. Thanks!
bethskurrie
2021-06-16 07:37
@art.ptushkin the --ignore flag is out in the Pact Broker client now https://docs.pact.io/pact_broker/client_cli/readme#can-i-deploy
bethskurrie
2021-06-16 07:37
The code for the backend is only out in Pactflow at the moment. It should be out in the OSS soon.
connor.aird
2021-06-16 08:02
I don?t think there?s a strong reason why we were using Dius. Migrating to pactfoundation seems like the best option. Thank you for your help :slightly_smiling_face:
dawoud.sheraz
2021-06-16 10:38
What is the average resource consumption for pact broker/pactflow? To be more specific, what sort of ec2 instance would suite to pact broker needs?
gurkiratguliani
2021-06-16 14:09
I have 2 applications A and B . A and B both acts as provider and consumer in each differrent case. In this case, will a double arrow be generated in the pact diagram ? one from A ->B and other from B-> A
bheemreddy181
2021-06-16 17:11
Hey Team ( Beth and Matt ) Quick Question around Git based Status Checks , I am running into to a issue for one new case
1. Provider and Consumer have an existing Integration in place.
2. Consumer writes new contracts and they fail ( as expected because of provider states not exist )
3. Now Consumer wirte new provider states on the provider service in collaboration with provider.
4. Provider merges new provider states into master branch
5. Consumer re-triggers his CI ( but pact broker gives back a pre-verified result ) from Step 2 above
bheemreddy181
2021-06-16 17:16
Is Step 5 expected here ? I had to manually trigger the Provider CI from pact broker to run the verification for the same commit from Step 5
bheemreddy181
2021-06-16 21:41
And also can some one help me understand this , what is this alert explaining me
bethskurrie
2021-06-16 22:59
@bheemreddy181 I don't know, because I don't know what your provider verification configuration is.
bethskurrie
2021-06-16 23:00
It means that there was a successful verification for that pact, and then the pact changed, but it has not been verified yet.
bheemreddy181
2021-06-16 23:02
What do you mean ? there are two jobs one which verifies the consumer triggered contract and other one which verifies the master contract of my consumer
bethskurrie
2021-06-16 23:04
so, the reason the feature pact got verified in the first place was through a webhook that only fires when the pact changes.
bheemreddy181
2021-06-16 23:05
feature pact was verified when pact broker triggered a contract test api job on my provider ci
bethskurrie
2021-06-16 23:05
if you run the consumer CI again, it will publish the pact, but it won't be changed, so it won't trigger the webhook.
bheemreddy181
2021-06-16 23:07
Cool will take Beth , thanks for answering this :slightly_smiling_face:
bheemreddy181
2021-06-16 23:08
its odd that there was a verification for all pacts in the matrix and this phrase confuses me a bit
bethskurrie
2021-06-16 23:08
It should, but it's been about 7 years since I looked at that code, so I don't know what it will do.
bethskurrie
2021-06-16 23:09
when the same content is published by multiple consumer versions, the verification effectively gets matched to every consumer version.
lucas.rolle
2021-06-17 09:17
Hey,
while testing asynchronous messages (Java11, JUnit5, Kotlin and using the MessagePactBuilder), the latest dockerized pact broker can't parse the pact (Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.). Do I have to use a different version or are asynchronous messages not a feature of the broker?
matt.fellows
2021-06-17 09:51
The OSS broker is just yet to display it, everything else works as you'd expect
bheemreddy181
2021-06-17 13:53
i get that but as you said , if the pact is not been verified yet does that include a pre-verified pact verification or exclude a pre-verification ?
bheemreddy181
2021-06-24 20:53
Beth Here is a more detailed use case for me :
1. Consumer Changes contracts on the feature branch ( Feat-x ) and the provider build triggered by this feature branch will fail
2. Provider Create a new feature branch ( Feat-y ) which will address these new contracts and merges them into master after verifying ( master contracts ) on Feat-y branch
3. Provider master merge CI build will also verify only ( master tagged contracts ) from all consumers
4. Now if Feat-x force pushes a commit - it will still get the Pre-Verified Contract Results from Step-1
5. We as a company we will never fall into the pending pacts or work in progress pacts as our pipelines are guraded with the branch name tags and we don't use same branch names for feature development
i feel for this use case we need to always trigger the provider build manually from pact broker to get the latest results - Am i correct or i am still missing something here
bheemreddy181
2021-06-24 20:54
My provider always looks only `master` contracts doesn't look at anything else
varun.patil
2021-06-24 21:50
Hello All, When I run the below code to verify the pacts, i get the error
```@RunWith(SpringRestPactRunner.class)
@Provider("account-service")
@PactBroker(host = "http://myorg.pact.io",
scheme = "https",
authentication = @PactBrokerAuth(token = "32rfsdg32323r32Q"))
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.DEFINED_PORT,
classes={AccountBridgeApplication.class})
@ActiveProfiles("dv")
public class AccountSeviceProviderContractTest {
@TestTarget
public final Target target = new SpringBootHttpTarget();
@State("Ban 3232 exists")
public void accountExists() {
// nothing to do, real service is used
}
}```
varun.patil
2021-06-24 21:51
error:
```org.junit.runners.model.InitializationError
at au.com.dius.pact.provider.junit.PactRunner.initialize(PactRunner.kt:93)
at au.com.dius.pact.provider.junit.PactRunner.getChildren(PactRunner.kt:140)
at org.junit.runners.ParentRunner.getFilteredChildren(ParentRunner.java:426)
at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:351)```
varun.patil
2021-06-24 21:51
imports:
```import org.junit.runner.*;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.test.context.ActiveProfiles;
import com.telus.accountbridge.AccountBridgeApplication;
import au.com.dius.pact.provider.junit.Provider;
import au.com.dius.pact.provider.junit.State;
import au.com.dius.pact.provider.junit.loader.PactBroker;
import au.com.dius.pact.provider.junit.loader.PactBrokerAuth;
import au.com.dius.pact.provider.junit.target.Target;
import au.com.dius.pact.provider.junit.target.TestTarget;
import au.com.dius.pact.provider.spring.SpringRestPactRunner;
import au.com.dius.pact.provider.spring.target.SpringBootHttpTarget;```
bethskurrie
2021-06-25 01:44
@bheemreddy181 I don't undertand why you think you shouldn't use pending/wip pacts?
bethskurrie
2021-06-25 01:44
Turning on wip pacts will mean that at point 3, the feat-x pact will get verified by the master branch, without you having to do anything.
bheemreddy181
2021-06-25 01:46
On my provider I restricted it to only look at master branch if so does it pull other tagged pacts as well ?
bethskurrie
2021-06-25 01:46
> The purpose of the "work in progress" (WIP) pacts feature is to automatically include the pacts that are currently being worked on in the verification step, without the provider team having to change their configuration each time. This allows the consumer team to get feedback on their changed pacts without having to wait on the provider team to make changes to their code.
bethskurrie
2021-06-25 01:47
You want the feat-x pact to be verified without having to change your provider config.
bheemreddy181
2021-06-25 01:49
That?s exactly correct , let me walk through the workshop again , thanks for answering this again for me appreciate that
aliaksandr.valadzko
2021-06-25 10:15
Hey guys!
We started to receive weird messages from `canIDeploy` task
```canIDeploy
-Ppacticipant=serviceA
-PpacticipantVersion=versionA
-Ppacticipant=serviceB
-PpacticipantVersion=versionB
Computer says no ?\_(?)_/?
There is no verified pact between the latest version of serviceC (versionC)
and version versionD of serviceD```
So, it looks like `pacticipant` and `pacticipantVersion` parameters were ignored
Is it known issue?
Thanks
aliaksandr.valadzko
2021-06-25 10:25
Matt, one more detail:
? for verified interaction we still receive
```Computer says yes \o/ ```
? but for broken interaction we receive inaccurate message, were wrong pacticipants are listed
```here is no verified pact between the latest version of serviceC (versionC)
and version versionD of serviceD```
matt.fellows
2021-06-25 10:28
This is probably of an issue with the gradle client rather than the broker itself
matt.fellows
2021-06-25 10:29
I'd suggest raising an issue on the GitHub project ideally with a reproducible example
matt.fellows
2021-06-25 10:56
I assume the plugin is from this repo https://github.com/pact-foundation/pact-jvm?
bethskurrie
2021-06-28 05:45
@aliaksandr.valadzko as far as I know, the gradle version only takes one application and one application version.
uladzislau_danilchyk
2021-06-29 07:52
Hi everyone!
To connect to authenticated Pact Broker we can use (in junit test) `pactbroker.auth.token` property or `basic auth`.
I'm interested in `bearer` token to use `pactbroker.auth.token` property.
It works fine with http://pactflow.io
But we have installed Pact Broker by the link (https://github.com/pact-foundation/pact-broker-docker) and there is *only* `basic auth`. How to use `Bearer token` authorization here?
Pact Broker version: 2.79.0
uladzislau_danilchyk
2021-06-29 07:56
@matt.fellows, could you mention it in docs by link to do not have questions in that in future? https://github.com/pact-foundation/pact-broker-docker
matt.fellows
2021-06-29 07:58
Perhaps we should have a feature table that shows what pactflow VS oss supports there?
lukemufc125
2021-06-29 08:05
Hi guys, I'm looking for a little help connecting to the Pact Broker, I can upload Pacts perfectly fine from the consumer side but when I try to pull the pact down from the Provider side I am thrown an error "Could not find relation 'pb:latest-provider-pacts'"
I can't see these pb properties in the HAL explorer either but they also don't seem to be apparent on the Example API. How would I go about generating these relationships.
lukemufc125
2021-06-29 08:37
Running it through http://PACT.NET Pact Verifier Class invoking the Pact Broker method to {Pact-Broker-Uri}/pacts/provider/{providerName}/consumer/{consumerName}/latest
The logs show that the request is Content-type: application/hal+json but I can't see that relationship in the json body either
lukemufc125
2021-06-29 08:41
Yeah, that is in the accept headers, sorry, the response is of that Content-type
lukemufc125
2021-06-29 08:42
I can see the various other pb: relationships but ones for pb:latest-provider-pacts/ pb:latest-provider-pacts-with-tags don't appear
matt.fellows
2021-06-29 08:43
Are you writing custom code in Pact .NET or is this part of the library now?
lukemufc125
2021-06-29 08:45
Let me try and get a stack trace for you, it's on a client machine though so I'm not 100% sure if I will be able to
matt.fellows
2021-06-29 08:47
probably should just be delegating to the underlying Ruby CLI, not navigating the HAL links
matt.fellows
2021-06-29 08:54
It?s trying to navigate the root resource, but you?re passing it a pact file
matt.fellows
2021-06-29 08:55
The standard behaviour is to pass the URL of the broker, and tags to find. it will then dynamically fetch pacts based on those tags (there may be many consumers that need verifyinsg, or mulitple versions of a single consumer that need validating such as the latest in `dev` and `prod` - or all of the above)
matt.fellows
2021-06-29 08:56
`PactUri...` is what you want if you have a specific contract to verify (this is what you would usually run for a provider webhook)
The main one to use is
``` //or (if you're using the Pact Broker, you can use the various different features, including pending pacts)
.PactBroker("http://pact-broker", uriOptions: pactUriOptions, enablePending: true, consumerVersionTags: new List<string> { "master" }, providerVersionTags: new List<string> { "master" }, consumerVersionSelectors: new List<VersionTagSelector> { new VersionTagSelector("master") })```
from the readme:
``` pactVerifier
.ProviderState($"{serviceUri}/provider-states")
.ServiceProvider("Something API", serviceUri)
.HonoursPactWith("Consumer")
.PactUri("..\\..\\..\\Consumer.Tests\\pacts\\consumer-something_api.json")
//or
.PactUri("http://pact-broker/pacts/provider/Something%20Api/consumer/Consumer/latest") //You can specify a http or https uri
//or
.PactUri("http://pact-broker/pacts/provider/Something%20Api/consumer/Consumer/latest", pactUriOptions) //With options decribed above
//or (if you're using the Pact Broker, you can use the various different features, including pending pacts)
.PactBroker("http://pact-broker", uriOptions: pactUriOptions, enablePending: true, consumerVersionTags: new List<string> { "master" }, providerVersionTags: new List<string> { "master" }, consumerVersionSelectors: new List<VersionTagSelector> { new VersionTagSelector("master") })
.Verify();```
lukemufc125
2021-06-29 08:57
Okay cool, I've got a different error now (one which suggests it has found the pact though!) thanks
lukemufc125
2021-06-29 08:58
I think from the documentation it did suggest the /consumer /provider endpoint, let me check that again and if so I'll mention it in the documentation chat
matt.fellows
2021-06-29 09:13
I'm not a Pact NET maintainer but I encourage semantic commits where possible
matt.fellows
2021-06-29 09:48
Thanks. Sorry just saw the PR. How are you passing the URL in now? URI should support a full path to a pact file whereas `PactBroker` takes the root
matt.fellows
2021-06-29 09:50
`PactUri` = not dynamic, fetch exactly that pact
`PactBroker` = discover which contracts to verify
lukemufc125
2021-06-29 10:01
Yeah, that's what I'm on at the moment since I can't pull on client laptop and hadn't opened up my own, think that's why I hadn't noticed it was 2 different methods
bethskurrie
2021-06-30 00:19
I asked someone to update the docs but it seems to have not been done yet.
anchit.99
2021-06-30 07:18
I have been asked to install the "docker pact broker" manually (AKA without using docker). Just wanted to know whether that is okay or is it recommended to install via docker? I've been running into lots of issues in my setup which I've resolved over the past few days.
Just wanted to confirm, (1) if we have a manual installation is it possible that I might miss important updates for broker? (2) Also, can there be complications with the upgrade process in future if we go with a manual installation?
uladzislau_danilchyk
2021-06-30 09:39
Hi everybody!
Is there API endpoint to get by Consumer Name and Consumer Version contracts which are related with?
Thanks!
matt.fellows
2021-06-30 10:23
if the provider knows the name of the consumer and the version of it, yes.
matt.fellows
2021-06-30 10:30
There is this endpoint which is I think what you want (they translate to paths): https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/api.rb#L33
actually, I think only the version of the pact. Anyway, maybe if you could please elaborate on the use case?
uladzislau_danilchyk
2021-06-30 11:00
We want to have Jenkins job which receives params: consumer+consumer version+consumer tag+provider. And trigger the verification with that params
uladzislau_danilchyk
2021-06-30 11:01
I searched PactBroker annotation in junit but it receives only consumer tags as params (consumerVersionSelectors) but not a `version`.
matt.fellows
2021-06-30 11:26
You can pass a direct Pact URL it to JUnit, is it possible to simply send the actual pact URL?
matt.fellows
2021-06-30 11:26
`/pacts/provider/:name/consumer/:name/versions/:consumer_version_number`
uladzislau_danilchyk
2021-06-30 11:28
@matt.fellows, the following url?
```https://pact.local/pacts/provider/Provider-Name/consumer/Consumer-Name/version/1.0.0-123123```
uladzislau_danilchyk
2021-06-30 11:49
Such url helped me to get contracts for consumer by its version. But I have one more question regarding this API endpoint? Did I correctly understand that this endpoint marked as deprecated? if yes, would it be removed in nearest future from endpoints list? We need to have such functionality because filtering by tags is ok, but we want to verify not latest contracts, but one of semi-contracts which were previously written.
matt.fellows
2021-06-30 13:17
Your use case sounds unsual, so if you could please elaborate on why tags and other mechanisms aren't helpful that would both help us find a new solution or guide you to an existing better one
matt.fellows
2021-06-30 13:17
It may, but not until a new major version is released which is not on any horizon just yet that I know of
matt.fellows
2021-06-30 13:18
If it's triggered from the consumer build for instance, you could just pass the full pact URI as an input
sagupta
2021-06-30 16:16
Hey team,
I have a question about `can-i-deploy` , we use the can-i-deploy on both consumer and provider side in this format
```pact-broker can-i-deploy --pacticipant PACTICIPANT --version VERSION --to STAGE```
Now we have our main line of development called `master` so we were using can-i-deploy to master (for example) without any issues . Now recently we have more microservices integrated in our architecture which have their main line of development called `main` and now we have added contract tests for those but face issues using can-i-deploy.
So my question is : Is it possible to provide multiple stages in can-i-deploy command ? or any other way so we can check compatibility against master and main both ? Also changing the main line of development is not currently feasible for us atm
phil.endsley
2021-06-30 16:25
I faced this same issue in the past. Our solution was to change our tagging process for the "main" development branch. Instead of tagging with the branch name, we just picked a common tag that everyone would use across all projects.
phil.endsley
2021-06-30 16:26
For example, when your main dev branch builds and publishes a pact, instead of using the branch name as the tag (which differs between master and main depending on the project), just always use `main` (or `master` or whatever you want) for every project.
dimundo
2021-06-30 18:35
just curious - is there any limitation for stored pact ?map?s ? good practices ? retention times ? :slightly_smiling_face:
bethskurrie
2021-06-30 21:47
Just checking @sagupta, using can I deploy with a branch name is asking "can I merge", not "can I deploy". Is this what you're aiming to achieve?
bethskurrie
2021-06-30 21:53
@dimundo there's actually a clean up feature in the open source docker image that allows you to get rid of unnecessary data.
bethskurrie
2021-06-30 21:55
When there is too much data, the broker can slow down, so it is good practice to clean it up. You only need to keep the versions on the main branch, for the last few weeks (or however long your lead time is for a commit to get to prod), and the latest version from each branch (ie. Broker tag).
bethskurrie
2021-06-30 21:56
You can read the docs here https://docs.pact.io/pact_broker/administration/maintenance/#automatic-data-clean-up
bethskurrie
2021-06-30 21:56
What I need to do is expose the clean up in an api. At the moment, it requires a direct connection to the database, which you obviously won't have for Pactflow.
sagupta
2021-06-30 22:39
Yes we use it as can-i-merge when consumer wants to merge new changes to master
bethskurrie
2021-06-30 22:40
I'm soon to release a change to the broker that will store the main branch on the pacticipant resource, so they could each be set to their correct one.
sagupta
2021-06-30 22:40
alright, yea so currently for main branches , we fetch the branch name from gitlab (which would be master and main) for tag
sagupta
2021-06-30 22:41
may i know how soon can i expect this change as we are currently facing errors and need some kinda solution
bethskurrie
2021-06-30 22:43
Even when the default branch comes out, I'd need to add another feature to do can-i-merge, and I don't know when that will be.
bethskurrie
2021-06-30 22:43
You can tag with as many tags as you like - having a "main" and a "master" tag for the same version is fine.
bethskurrie
2021-06-30 22:44
As long as you've all picked one that is consistent across the projects, it'll work :thumbsup::skin-tone-3:
bethskurrie
2021-06-30 22:47
@uladzislau_danilchyk it's deprecated because "/versions/" should now be "/version/"
bethskurrie
2021-06-30 22:48
But there's no side effect to keeping it in the API, so I'll probably just leave it forever :laughing:
uglyog
2021-06-30 23:29
Upgrading should be fine. @bethskurrie is quite meticulous on upgrades and backwards compatibility. You will need to keep track of the releases to know when to update your broker.
bethskurrie
2021-06-30 23:31
If you want to do it, you'll need to have expertise on deploying and running a ruby application that we cannot give you over the slack channel.
bethskurrie
2021-06-30 23:31
The "plain ruby" application also does not have built in basic auth, and the configuration is not set up for public consumption.
bethskurrie
2021-07-01 00:29
The plain ruby app gets released before the docker one gets released, so you won't miss out on anything.
bethskurrie
2021-07-01 00:33
If you've followed my advice about copying the entire directory out of the pact-broker-docker repository (so you get all the env var configurations, and the basic auth) you'll just need to keep that up to date when you update the ruby app. I would recommend having a script that pulls in every file from the `pact_broker` directory in the pact-broker-docker repo, and copies it into the repository where you are keeping your own application configuration.
bethskurrie
2021-07-01 00:33
That way, you're getting the supported application code, even if you're not getting the supported packaging mechanism.
manel_ben_yahia
2021-07-01 12:55
i am using the annotation @PactBroker with system properties defined in my application-test.yml
manel_ben_yahia
2021-07-01 12:56
java.lang.IllegalArgumentException: Invalid pact broker host specified ('${pactbroker.host}'). Please provide a valid host or specify the system property 'pactbroker.host'.
manel_ben_yahia
2021-07-01 12:57
pact provider version : <pact-provider.version>4.2.0</pact-provider.version>
manel_ben_yahia
2021-07-01 12:58
i was using PactVerificationInvocationContextProvider and changed it to PactVerificationSpringProvider
manel_ben_yahia
2021-07-01 12:58
`java.lang.IllegalArgumentException: Invalid pact broker host specified ('${pactbroker.host}'). Please provide a valid host or specify the system property 'pactbroker.host'.`
`at http://au.com.dius.pact.provider.junitsupport.loader.PactBrokerLoader.getPactBrokerSource(PactBrokerLoader.kt:249)`
`at http://au.com.dius.pact.provider.junitsupport.loader.PactBrokerLoader.description(PactBrokerLoader.kt:83)`
`at http://au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.resolvePactSources(PactJUnit5VerificationProvider.kt:78)`
`at http://au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.provideTestTemplateInvocationContexts(PactJUnit5VerificationProvider.kt:40)`
`at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$0(TestTemplateTestDescriptor.java:102)`
`at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)`
`at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)`
`at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)`
`at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)`
`at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)`
`at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)`
`at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)`
`at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)`
`at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:106)`
`at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:41)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:135)`
`at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)`
`at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)`
`at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)`
`at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)`
`at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)`
`at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)`
`at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)`
`at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)`
`at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)`
`at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)`
`at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)`
`at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)`
`at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)`
`at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)`
`at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)`
`at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)`
`at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)`
`at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:229)`
`at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:197)`
`at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:211)`
`at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:191)`
`at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:128)`
`at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:71)`
`at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)`
`at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:220)`
`at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:53)`
npatil
2021-07-01 13:00
Hey @manel_ben_yahia Do you mind if you share your `application-test.yml` ? and SpringBoot test for pat?
manel_ben_yahia
2021-07-01 13:00
```pactbroker:
host: http://pct-feat-bkr-prj.caas.vpod1.carrefour.com
port: 443```
manel_ben_yahia
2021-07-01 13:02
```@ExtendWith(SpringExtension.class)
@Provider("A")
@Consumer("B")
@ActiveProfiles("test")
@PactBroker(scheme = "https", host="${pactbroker.host}", port= "${pactbroker.port}")
public class AProviderMessagePactTest {
@TestTemplate
@ExtendWith(PactVerificationSpringProvider.class)
void testTemplate(PactVerificationContext context) {
context.verifyInteraction();
}
@BeforeEach
public void setUp(PactVerificationContext context) {
context.setTarget(new MessageTestTarget(Collections.singletonList("java.test")));
System.setProperty("pact.verifier.publishResults", "true");
}
@PactVerifyProvider("a process A message")
public String generateProcessAMessage() throws IOException {
Object1 expected = buildFromJson("file.json", Object1.class);
return TestUtils.writeValueAsString(expected);
}```
phil.endsley
2021-07-01 13:57
You'll get better answers in #pact-jvm since this is a java specific issue. On top of that, you might just have to wait until other people are online to answer
dimundo
2021-07-01 13:57
```java.lang.IllegalArgumentException: Invalid pact broker host specified ('${pactbroker.host}'). Please provide a valid host or specify the system property 'pactbroker.host'.```
wild guess - trailing slash in host
manel_ben_yahia
2021-07-01 14:04
```pactbroker:
host: http://pct-feat-bkr-prj.caas.vpod1.carrefour.com
port: 443```
manel_ben_yahia
2021-07-01 14:05
```
@TestTemplate
@ExtendWith(PactVerificationSpringProvider.class)
void testTemplate(PactVerificationContext context) {
context.verifyInteraction();
}```
manel_ben_yahia
2021-07-01 14:06
i changed PactVerificationInvocationContextProvider with PactVerificationSpringProvider
manel_ben_yahia
2021-07-01 14:06
but in the error stack i still have the `PactVerificationInvocationContextProvider`
phil.endsley
2021-07-01 14:11
The issue is you're not using `@SpringBootTest`. It's fine to not use that, but in that case, you have to manually load the application properties. I just verified this locally as well
manel_ben_yahia
2021-07-01 14:14
okay then why does the stack shows `PactVerificationInvocationContextProvider`
phil.endsley
2021-07-01 14:20
The difference is how properties are resolved (ex: Only looking at system properties vs looking in the spring context as well). This is getting into the implementation details of the Pact library, and this channel is not the most appropriate place. If you'd like to continue, we can move this discussion to #pact-jvm .
phil.endsley
2021-07-01 14:27
It's configured correctly for pact-jvm. This is an issue with how the app context is being loaded
krishna.ramnk
2021-07-01 15:15
However when I try to read it in the provider code using Gradle ,it keeps throwing the 401 Error though the same authentication passed earlier in consumer publish
krishna.ramnk
2021-07-01 15:16
This is the code I am trying in provider
``` hasPactWith("dummyconsumer") {
// pactFile = url("https://xxxxx.pactflow.io/pacts/provider/dummyprovider/consumer/dummyconsumer/version/unspecified")
hasPactsFromPactBroker('https://xxxx.pactflow.io/pacts/provider/dummyprovider/consumer/dummyconsumer/version/unspecified', authentication: ['Bearer', 'xxxxxxxx'])```
uglyog
2021-07-02 01:33
401 normally means an incorrect token. Your URL is also wrong, you don't give the full path to the pact, just the base pact broker path
uglyog
2021-07-02 01:34
I.e.
```hasPactsFromPactBroker('https://xxxx.pactflow.io', authentication: ['Bearer', 'xxxxxxxx'])```
manel_ben_yahia
2021-07-02 09:26
Hi, i am using@PactBroker in my springBoot Project, already had errors trying to resolve properties which are solved,
manel_ben_yahia
2021-07-02 09:27
```avax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target```
manel_ben_yahia
2021-07-02 09:28
```at au.com.dius.pact.core.pactbroker.HalClient.navigate(HalClient.kt:220)```
manel_ben_yahia
2021-07-02 09:29
can any one help with this problem please ? (my pact broker is on https)
matt.fellows
2021-07-02 09:39
What have you done to resolve it? I'm guessing you have a self signed certificate, so you'll need to ensure your java setup knows about the certificate
2021-07-02 09:39
Please see these instructions on running and accessing a Pact Broker over TLS https://docs.pact.io/pact_broker/advanced_topics/using-tls/
matt.fellows
2021-07-02 09:40
This is probably not a pact specific issue, so it would be good to know what your setup is
manel_ben_yahia
2021-07-02 09:46
what should i do, should i check if i have the right certificate on my machine ?
manel_ben_yahia
2021-07-02 09:52
just want to say that on the same machine, with same configuration it works perfectly with same pactBroker
manel_ben_yahia
2021-07-02 09:53
which means that on this machine the certificate is configured correctly for the pact broker
bethskurrie
2021-07-03 01:18
@manel_ben_yahia have you read the TLS help page that the slack bot posted? This is most likely a configuration issue with the client, so you'll need to ask on the #pact-jvm channel.
siddharth.gupta
2021-07-05 04:54
Hey folks ,we are planning to start with Pact Broker to see if we become mature enough to use the SAS version PactFlow ,
siddharth.gupta
2021-07-05 04:55
can anyone point me to where i can find some literature around governance where multiple teams are involved
bethskurrie
2021-07-05 04:58
Hi @siddharth.gupta You can read about the system requirements for Pactflow on-prem here. https://docs.pactflow.io/docs/on-premises/system-requirements
bethskurrie
2021-07-05 04:59
There is only one read only basic auth user and one read/write user. If you need anything to do with "governance" then you will probably end up needing Pactflow.
bethskurrie
2021-07-05 04:59
Here is a comparison between the OSS Pact Broker and Pactflow. https://pactflow.io/features/
matt.fellows
2021-07-05 05:21
I think what most teams do where security and governance is a concern is setup the system in such a way that only CI is able to communicate with the broker with write credentials, this way it prevents humans from doing bad things
zhaoyi0113
2021-07-05 09:31
Hi There, I am set up pact broker between a consumer and a provider. And I added `publish to pact broker` in consumer CI/CD pipeline. And added `verify pact` in provider CI/CD pipeline. What I don?t understand is the order of provider pipeline. Should I put `verify pact` before or after `deployment`? what I want is to stop deployment if `verify pact` fails. But if there is a change required to the pact, what is the correct flow of changing? If I put `verify pact` before `deployment`, the change of pact will break provider pipeline.
bethskurrie
2021-07-05 09:32
@zhaoyi0113 this workshop will explain it all https://docs.pactflow.io/docs/workshops/ci-cd
zhaoyi0113
2021-07-05 10:52
please correct me if I misunderstood. There are two ways to handle that,
? setup a separate pipeline for pact change.
? using `pending` state
I would say using `pending` state is preferable way?
zhaoyi0113
2021-07-05 11:28
I am using pact broker docker image with the latest tag `2.79.1.2`. How do I know whether this broker support `pending` or not?
zhaoyi0113
2021-07-05 11:31
In the example of the doc, it says: `Provider is configured to verify the pacts with tags `main` and `production` .
Does `main` and `production` tags mean two different branches? or does it mean provider needs to maintain two versions of pacts?
abubics
2021-07-05 11:47
You can set many tags on any single pacticipant version.
I would advocate against making separate branches per environment (in application codebases).
abubics
2021-07-05 11:54
that kind of depends on your workflow, but the way the docs put it, either feature branches or tags per environment should work
abubics
2021-07-05 11:55
(I haven't used pending pacts yet, so I can't tell you from first-hand experience)
matt.fellows
2021-07-05 11:56
Check the version of the broker running on your docker image. If it?s a recent version (like, last 6 months) it has it for sure
abubics
2021-07-05 12:08
Looks like some git fluff left in https://docs.pact.io/pact_broker/advanced_topics/pending_pacts/ :sweat_smile:
> To start using the Pending pacts feature
> <<<<<<< Updated upstream
> You need to either be using http://pactflow.io, or have version 2.60.0+ of the OSS Pact Broker.
philipchardwick
2021-07-05 12:44
Hey, I have a situation where, with a new WIP pact, we need to change the explicitly selected tags to verify in the provider when it first implements a new pact. This seems to be for two reasons, one is that we run can-i-deploy as part of the PR build in the consumer so they know they won't break their build when they try to run can-i-deploy after merging to master. Having this in the PR build means we need a success verification before we can merge and get the consumer pact into the main branch. The other thing is that the new feature pact doesn't seem to be included in the wip pacts, does there need to be an explicitly included pact existing before feature tagged pacts will appear in wip pacts to verify?
So that's the context,
Headline question: What's the best way to run can-i-deploy as part of a PR build?
Example:
1. Provider service exists and is in dev and prod, and has a CI job which runs the pact verification against consumer main tags when pact content it is involved in changes
2. Consumer creates a new pact on branch `feature/new-thing` and publishes the pact in its PR, and runs can-i-deploy, this fails because the provider doesn't implement it yet
3. The provider implements it and deploys fine - verifications run against main, and there's no main pacts so it continues
4. The consumer runs its PR build again and the pact gets published again (thinking about it, since the content hasn't changed this won't kick off a provider verification which is a bit annoying in our setup)
5. An engineer kicks off the provider build and it has no pacts to verify which means we need to explicitly include the tag `feature/new-thing` in the provider verification tests to make sure it gets included and a verification can be published
6. Once the verification is published, the engineer can change the explicitly included tags to be `main` again.
I feel like I'm hitting this clause:
> 5. Discard all the pacts that were published before the first instance of this provider tag (this is so that if you create a brand new provider branch, you don't get EVERY head pact included in the WIP pacts list).
Is that right? If so, is this just something we need to work around like we're doing or is it something wrong in our setup?
Thanks for taking the time to understand this, I realise it always takes significant focus to "load in" someone's pact context/setup.
zhaoyi0113
2021-07-05 12:45
Hi There, I am reading this doc on setup CI in provider side (https://github.com/pactflow/example-provider). It mentions run `pact verification tests` before `Deploy`. I confused about this order. The `verify` happens before `Deploy`. That means `verify` only verifies the current version. Even if it success, the next `Deploy` stage can overwrite the current version which may break pact.
So how can I run `verify` based on my current commit? My application is deployed to AWS apigateway. It seems I need to deploy to AWS before run `verify`?
rafael.espillaque
2021-07-05 13:19
In our team, we have the exact same situation and we?re currently modifying the branches, as you do.
I hope someone can suggest an alternative!
bethskurrie
2021-07-05 22:43
I haven't got time to read it through just now, but my quick glance makes me think this is the fix you need https://github.com/pact-foundation/pact_broker/pull/432
bethskurrie
2021-07-05 22:44
I'll try and get it out today. It's been out in Pactflow for a while, but I haven't done an OSS release because I was trying to get some stuff finished first.
bethskurrie
2021-07-05 22:45
@zhaoyi0113 the way pact works assumes you can run pact verification test locally.
bethskurrie
2021-07-05 22:45
If you have to deploy before you can run the tests, then you either need to use a different testing tool, or work out how you can run the tests without deploying.
bethskurrie
2021-07-05 22:46
I don't know much about apigateway, but a lot of tools like lambda allow you to run an instance locally that behaves enough the same. Have you investigated that?
bethskurrie
2021-07-05 22:48
the last digit is the "package" version (eg. if something in the docker code changes)
bethskurrie
2021-07-05 22:48
@zhaoyi0113 read the docs on the tags here https://docs.pact.io/pact_broker/tags
bethskurrie
2021-07-05 22:49
Having said that, the "tag when you deploy" rule is about to be replaced by a proper deployments feature.
bethskurrie
2021-07-05 22:49
The "main" tag gets created when the pact was published. The "production" tag gets created when you deploy that version.
zhaoyi0113
2021-07-05 22:51
It is not easy to setup local environment. I have some mapping template setup in apigateway which can?t be tested locally. so I may have to deploy it to a temporary environment for pact, then deploy to real environment after finish.
github2
2021-07-06 05:42
[pact-foundation/pact_broker] New release _https://github.com/pact-foundation/pact_broker/releases/tag/v2.80.0_ published by github-actions[bot]
bethskurrie
2021-07-06 05:47
https://github.com/pact-foundation/pact_broker/releases/tag/v2.80.0 is out @philipchardwick
bethskurrie
2021-07-06 05:52
@bangn's first contribution has been released today. Now you can search by pacticipant name on the index page. A long asked for feature! Many thanks Bang!
philipchardwick
2021-07-06 07:19
That's amazing - I'll update now. Thanks so much for your work on this!
krishna.ramnk
2021-07-06 07:29
@uglyog Thanks for answering.. Isn't that the baseurl..Should it be "
```http://xxxx.pactflow.io```
" without the https ?
krishna.ramnk
2021-07-06 07:29
The authentication token is definitely correct as the pactPublish from consumer side is working correctly
manel_ben_yahia
2021-07-06 07:37
Hello i have a question about versioning in pact broker, if i use branch name as version for consumer, and pact contract doesn't change between this branch and the last version, does pact broker create a new line for my version branch name ?
matt.fellows
2021-07-06 07:44
I'd Read those docs first and then come back if you have further questions
manel_ben_yahia
2021-07-06 07:44
so my question if i use commit and, in this commit there are no changes to my pact contract, does the broker create a new line in the pact broker ?
manel_ben_yahia
2021-07-06 07:45
i've already read the docs but the idea of branch i got it from a blog
matt.fellows
2021-07-06 07:45
Why does that matter? It will still record a publication under the hood.
But the broker is clever enough to know that the previous pact and the new one are the same
manel_ben_yahia
2021-07-06 07:47
yes it does matter for our team if we have 10000 lines on the pact broker for each new commit
manel_ben_yahia
2021-07-06 07:50
here is the thing, we can commit in a branch 5 commits for each commit there is no changes to the pact contract in consumer side
manel_ben_yahia
2021-07-06 07:51
does the pact broker create 5 new lines in the table with consumer name, consumer version (commit) provider name and (provider version)
matt.fellows
2021-07-06 07:53
No, it usually only displays the latest for a given tag. You also don't validate every single contract, you use tags to select the contracts you care about. By default, for example, that might be "verify the latest contracts where the tag is `prod"`
matt.fellows
2021-07-06 07:54
I'd recommend reading the versioning and tagging docs, and possibly doing the ci/cd workshop (see howtolearn)
2021-07-06 07:54
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
matt.fellows
2021-07-06 07:55
The broker is pretty good at hiding this complexity, you should just follow the standard guidelines until you encounter an edge case
matt.fellows
2021-07-06 07:55
Sorry I wasn't trying to be difficult, I was trying to understand if your concern was hypothetical or actual, and why it was a concern
dimundo
2021-07-06 07:57
hi!
if one is using feature branches for new versions of pacts
? one should use tags ?
? if yes - how do tags be synched between consumer and provider?
dimundo
2021-07-06 07:57
> providerVersionTags: [process.env.TRAVIS_BRANCH]
this will work for same branch names, which is kinda a bit restrictive
2021-07-06 08:01
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
krishna.ramnk
2021-07-06 08:01
Ahh ok... I am now using
```hasPactsFromPactBroker('https://xxxx.pactflow.io/pacts/provider/dummyprovider/consumer/dummyconsumer/version/unspecified', authentication: ['Bearer', 'xxxxxxxx'])```
and has actually fixed the issue... I removed the other parameter *pactFile* which had the full url you mentioned
krishna.ramnk
2021-07-06 08:02
It turns out that I was using an older version of dependency. I changed it to 4.1.0 and this fixed the issue for me (I was confused earlier why it was throwing 401 as same url was working on consumer side)
matt.fellows
2021-07-06 08:06
That's only one option Dmitry, if you can do WIP pacts that would be better
dimundo
2021-07-06 08:08
aha, this one?
* https://www.youtube.com/watch?v=u7LzZ6Fm1Ok&t=1375s (audience question): When introducing a new interface, what comes first - the consumer or the provider?
matt.fellows
2021-07-06 08:10
This advice is both conflicting and wrong ("must be unique" and "use the branch")
manel_ben_yahia
2021-07-06 08:47
So if the provider changes interfaces, and i set it to verify its pact only against prod tag => the verification fail ,, i should correct in consumer side so that the provider will be able to deploy ?
matt.fellows
2021-07-06 08:57
Although, first Phil could probably review and give us feedback too :stuck_out_tongue:
manel_ben_yahia
2021-07-06 09:19
if provider changes its interface, on tag fetaure_branch and verify with consumer on tag = prod => it fails
matt.fellows
2021-07-06 09:23
I think you?re asking if Pact will prevent a breaking change from being released if that change is not compatible with a specific tag, such as `prod`.
matt.fellows
2021-07-06 09:24
the CI/CD workshop above takes you through the most common approaches to releasing new changes (on both sides) and how to do that with the broker
dimundo
2021-07-06 09:30
and one more here
```pact-broker publish PACT_DIRS_OR_FILES --consumer-app-version=CONSUMER_APP_VERSION --broker-base-url=BROKER_BASE_URL ```
PACT_DIRS_OR_FILES - just a directory with jsons like `pact-broker publish ./pacts --consumer-app-version=CONSUMER_APP_VERSION --broker-base-url=BROKER_BASE_URL` ?
matt.fellows
2021-07-06 09:34
it can be either a directory with pact files in it, or a pact file itself
dimundo
2021-07-06 09:36
to not repeat arguments i?m doing `- mkdir -p ./pacts && mv **/pacts/*.json ./pacts/`
bethskurrie
2021-07-06 09:44
My reward will be hearing whether or not I've fixed the problem I think I've fixed @philipchardwick :wink:
bethskurrie
2021-07-06 09:46
I started the WIP feature (like, 2 years ago) not being sure whether or not it would actually work, but I think it must be close now!
dimundo
2021-07-06 10:04
what should one do, if trunk branches for consumer and provider are different ?
bethskurrie
2021-07-06 10:04
@manel_ben_yahia https://docs.pact.io/getting_started/versioning_in_the_pact_broker
dimundo
2021-07-06 10:05
with all than new stuff (`master` is a bad word, blabla) we are getting more problems :(
zhaoyi0113
2021-07-07 12:47
I am reading `can i deploy` doc and I see it uses tag to indicate whether the application is in prod. In below statement, does the `applications` in the highlighted line mean `provider` only? so I only need to create `tag` on provider after it is deployed? Does `can-i-deploy` need to read tags from consumers?
matt.fellows
2021-07-07 12:50
that?s why the version information is so important - we know when it?s safe to deploy version `abc1234` to `prod` because we can find all of the versions of its provider?s in `prod` and check if they have satisfied the contract of version `abc1234`,
matt.fellows
2021-07-07 12:51
but the command simplifies all of this - hence why the broker wants to get all of this data!
zhaoyi0113
2021-07-07 13:12
My CI pipeline in consumer side is: `publish pacts -> deploy`
do I run `pact-broker create-version-tag` when publishing the pacts or do I create the tag after deploy finishes?
zhaoyi0113
2021-07-07 13:14
that means when I deploy consumer, it checks the tag `prod` in provider side?
when I deploy provider, it checks the tag `prod` in consumer side?
thanuxxxx
2021-07-07 16:02
Every build:
consumer: *run pact tests* *publish pacts*
provider: *verify pact* and *publish the results*
Every deployment:
`can-i-deploy` -> deploy your build -> `create-version-tag`
This is what I understood correct me @matt.fellows if I am wrong.
bethskurrie
2021-07-07 21:13
@zhaoyi0113 @thanuxxxx have you guys done the CI/CD workshop yet? I think that will clear things up https://docs.pactflow.io/docs/workshops/ci-cd
bethskurrie
2021-07-07 21:13
> Every build:
> consumer: *run pact tests* *publish pacts*
> provider: *verify pact* and *publish the results*
>
> Every deployment:
> `can-i-deploy` -> deploy your build -> `create-version-tag`
That's :100:
bethskurrie
2021-07-07 21:20
Here are some diagrams that explain that https://docs.pact.io/pact_nirvana/step_4#consumer-pipeline
poorvasgokhale
2021-07-08 09:12
I am using PACT for contract testing in my project. I have done setup for pact broker on my local machine. Local setup with consumer, provider and pact broker is working all good. My next step is to deploy pact broker on AWS ECS. Is there any document that I can refer for this?
bethskurrie
2021-07-08 09:28
You can use the Pactflow Onprem docs to get an idea of the architecture required https://docs.pactflow.io/docs/on-premises
bethskurrie
2021-07-08 09:28
You'll need to look up the AWS docs for whatever tool you want to use (eg Fargate, ECS) for deploying a docker application.
poorvasgokhale
2021-07-08 09:30
okay. Thanks @bethskurrie for super quick response. I will refer above pointers.
dimundo
2021-07-08 11:15
hi!
https://github.com/pact-foundation/pact-broker-docker#using-basic-auth
is this auth only for CLI or also for accessing UI part ?
dimundo
2021-07-08 11:58
and the answer is - no :slightly_smiling_face:
one needs to add some auth for UI separately
dimundo
2021-07-08 12:16
```> pact-broker can-i-deploy --pacticipant 'IPConsumerJSApp' --version 1.7.2-eb539135 --pacticipant 'IPProviderScalaApp' --latest -b xxx -p aaa -u bbb
Authentication failed: <html><body><h1>401 Unauthorized</h1>
You need a valid user and password to access this content.
</body></html>```
jarmy
2021-07-08 23:13
Hello. Does anyone know how I can query the pact-broker to determine the total number of tests for all of our pact integrations? I've figured out how to do it in a pretty rudimentary way but there's got to be something better
```curl --location --request GET 'https://[broker]/pacts/provider/[provider]/consumer/[consumer]/latest' | jq '.interactions[0] .description'```
phil.endsley
2021-07-08 23:45
Don't have it in front of me, but I thought there was a stats endpoint or something. It was off the base url if you look at the hal client in the browser
matt.fellows
2021-07-09 00:10
We actually discussed this the other day. Once environments/releases feature is fully done, this should be a bit easier and relevant
Cc: @bethskurrie
matt.fellows
2021-07-09 00:11
No that auth is for both UI and the API. You just need to pass the credentials in the CLI call
bethskurrie
2021-07-09 00:12
I've just created a feature request in canny @jarmy https://pact.canny.io/feature-requests/p/add-interactions-count-to-metrics
bethskurrie
2021-07-09 00:13
There's currently no field in the broker that holds that count, but as Matt said, I was planning on adding it.
philipchardwick
2021-07-09 10:03
That latest version has fixed it! :tada: Just had someone in the team publish a new pact, and then the provider team push out a new version with provider tests, set to verify master tags, it pulled the newly published wip pact, verified it and uploaded the successful verification to the broker. Thanks for all your hard work on this! Our pact workflow is so smooth now
aubilla
2021-07-09 13:18
Hi :wave:
I?m publishing Pacts to a Broker using the CLI and when running this command
```$ ./pact-broker publish --consumer-app-version 2.0.+${CI_COMMIT_SHORT_SHA} --broker-base-url https://internal.mycompany.com/pact-broker -u $PACT_BROKER_USERNAME -p $PACT_BROKER_PASSWORD ../../target/pacts/ItemClient-ItemService.json --tag ${CI_COMMIT_REF_NAME}```
I get an error stating `No value provided for required pact_files`
If I run `$ cat ../../target/pacts/ItemClient-ItemService.json` I can see the contents of the Pact file. Does pact-broker support relative paths?
poorvasgokhale
2021-07-12 07:52
Hello @bethskurrie I came to know that OAS support is going to be added as native support in pact broker. Is this available for use?
bethskurrie
2021-07-12 07:53
Hi @poorvasgokhale. That feature is going to be in Pactflow (not the open source Pact Broker).
bethskurrie
2021-07-12 07:54
It's currently available for beta use, API only (no UI yet) in Pactflow now, if you're interested in trying it out.
poorvasgokhale
2021-07-12 07:55
Ohhk. Currently I am experimenting with PACT. I went through atlassian case study. I was hoping to use swagger-mock-validator. Any suggestions on this path?
poorvasgokhale
2021-07-12 07:56
We are in experiment phase so I am sticking to open source solutions as of now. and hence I have not explored pact flow yet.
poorvasgokhale
2021-07-12 07:58
okay. Thank you @bethskurrie for super quick response. :slightly_smiling_face: Contract testing seems really promising for us. Thank you PACT team for awesome work
sams.prashanth
2021-07-12 09:23
I tried all cases to reflect the tags in pactflow while provider verification - but, it's not updating the tag
sams.prashanth
2021-07-12 12:32
this finally worked with
```-Dpact.provider.tag=dev```
or
```System.setProperty("pact.provider.tag", "dev");```
sams.prashanth
2021-07-12 12:37
For consumer pact tagging, this works `-Dpact.consumer.tags=dev` ; but, not sure why `.tags` property did not work while provider verification
matt.fellows
2021-07-12 13:18
not sure either, but for future reference: https://docs.pact.io/implementation_guides/jvm/provider/maven/#tagging-the-provider-before-verification-results-are-published-401
sams.prashanth
2021-07-12 13:42
Sure @matt.fellows; btw, is there a way to remove the tags from the pactflow? I created them for testing purpose and wanted to delete at some point.
sams.prashanth
2021-07-12 13:44
1. I deleted all the provider verification results and consumer pacts
2. Pushed new consumer pacts and verification result with a new tag - but I still see the old tags displaying
sams.prashanth
2021-07-12 13:53
not urgent - you can check whenever you get free time, Matt. Thanks in advance :slightly_smiling_face:
matt.fellows
2021-07-12 23:00
do you have the option to delete all tags? It might be that you don?t have the permission to do so
bethskurrie
2021-07-12 23:55
@sams.prashanth docs are here for removing tags https://docs.pactflow.io/docs/how_to#remove-a-tag-from-an-application-version
bethskurrie
2021-07-12 23:56
@sams.prashanth it looks like you don't have the `contract_data:bulk_delete` permission.
bethskurrie
2021-07-12 23:57
You can set the "predifined roles" to their system defaults by following these instructions https://docs.pactflow.io/docs/permissions/predefined-roles#resetting-permissions-for-predefined-roles
sams.prashanth
2021-07-13 05:22
@matt.fellows Like Beth mentioned, it could the role issue as I dont see the option to delete pacts with tags
sams.prashanth
2021-07-13 05:25
@bethskurrie you are right; this option is unchecked I believe - checking
sams.prashanth
2021-07-13 09:15
the direct api call helped me to delete tags at the moment :slightly_smiling_face:
```curl -X DELETE https://{name}.http://pactflow.io/pacticipants/{pacticipant}/versions/{version}/tags/{tags} -H "Authorization: Bearer ${PACT_BROKER_TOKEN}"```
sams.prashanth
2021-07-13 09:17
but thats the provider verification result tags; the same api is not working for deleting the consumer pact tags
sams.prashanth
2021-07-13 09:19
If I manually delete all the pacts, all the tags disappear along with the deleted pacts; but when I push a new pact, it start displaying the old tags too. Maybe it's stores those tags somewhere in the memory.
akara
2021-07-13 16:03
Hi guys, is it possible to enable pending pacts for only some particular consumers and not for all?
poorvasgokhale
2021-07-13 18:28
Cross posting from general channel..
Hello all,
We are trying out contract testing for microservices architecture. We have 4 environments for both provider and conumer. dev, test, uat and prod.. I have following questions from CI and CD perspective.
1. Which environment pipelines should be targeted for running contract test? should they run on all 4 environments?
2. In case of continuous development of consumer (dev environment), which environment of producer should be used for pact verification?
3. In case of continuous development of provider (dev environment), which environment consumer pact should provider use for verification?
I could not find any document which talks about this. Can someone help here?
bethskurrie
2021-07-13 22:58
1. all (the pacts will be de-duplicated, so if they have the same content, they will only be verified once)
bethskurrie
2021-07-13 22:58
2 and 3. I don't understand the question. It sounds like you're trying to use a deployed application for doing verification with?
bethskurrie
2021-07-13 23:00
1. Now I've realised I don't understand your questions, I'm not sure I've given the right answer to this.
bethskurrie
2021-07-13 23:00
This is how you configure the provider https://docs.pact.io/provider/recommended_configuration
bethskurrie
2021-07-13 23:01
This is how you configure the consumer https://docs.pact.io/consumer/recommended_configuration
bethskurrie
2021-07-13 23:01
This is how you check and record your deployments https://docs.pact.io/pact_broker/can_i_deploy#summary
bethskurrie
2021-07-13 23:04
> Which environment pipelines should be targeted for running contract test? should they run on all 4 environments?
Do you have a different pipeline for each environment?
zhaoyi0113
2021-07-14 00:28
Hello guys, does anyone know the best way to test nested providers? My contract test looks like:
```consumer -> server1 -> server2```
the `server1` is the first provider in the chain and it is also a consumer of `server2`. There are two `pact` setup, one is between `consumer` and `server1`, the other is between `server1` and `server2`. My question is how do I verify the pact which is published by `consumer` in `server1` . Do I have to mock the entire `server2` in order to test it?
matt.fellows
2021-07-14 01:30
There are a few AMAs on that topic also - see https://docs.pact.io/help/amas/
matt.fellows
2021-07-14 02:41
As replied in the other channel, pact tests run as part of your unit testing phase. So the question kind of doesn't make sense understood this way
matt.fellows
2021-07-14 02:42
The Can-i-deploy tool will be the main touch point when deploying to each environment
aubilla
2021-07-14 08:17
Morning everyone,
:boom: I?m getting this error in Gitlab CI/CD:
```Could not fetch the root HAL document
au.com.dius.pact.core.pactbroker.RequestFailedException: Request to path '/' failed with response 'HTTP/1.1 503 Service Unavailable'```
:electric_plug: when I?m trying to connect a Provider to my Pact Broker with the following block:
```pact {
broker {
pactBrokerUrl = 'https://companydomain.com/pact-broker'
pactBrokerUsername = System.getenv("PACT_BROKER_USERNAME")
pactBrokerPassword = System.getenv("PACT_BROKER_PASSWORD")
}
serviceProviders {
ItemService {
hasPactWith('ItemClient') {
fromPactBroker {
selectors = latestTags('master')
}
}
requestFilter = { req ->
req.addHeader('X-Auth-Token', System.getenv("X_AUTH_TOKEN"))
}
protocol = 'https'
host = System.getenv("ENV_SERVICE_URL")
port = 443
path = '/'
}
}
}```
:male-technologist:I know the Pact Broker is reachable (and operational) from Gitlab CI/CD because I?m publishing Pacts from a Consumer app and also because I can access it through the browser on my laptop.
:thinking_face: Could it be that I?m specifying the wrong endpoint/path for the request?
bethskurrie
2021-07-14 08:42
503 is generally an "entire server" error, not an error for a specific endpoint.
bethskurrie
2021-07-14 08:45
There should be some way to enable debug logging and show the actual HTTP requests. See if you can find that and turn it on.
matt.fellows
2021-07-14 08:47
That might be the cause, it looks like it's (Pact JVM) trying to fetch from `/` which presumably won't work
matt.fellows
2021-07-14 08:47
I can't tell without logs though if it's a bug in the JVM client or in your setup
poorvasgokhale
2021-07-14 09:14
Thank you @matt.fellows (http://pactflow.io / pact-js / pact-go) and @bethskurrie (http://pactflow.io/Pact Broker/pact-ruby) for response. These are good references. Let me be more specific about question*.*
I have actually tried out contract test, broker setup and `can-i-deploy` on local machine. Everything works as expected on local. :blush:
Let me explain my question in details.
*We have 4 environments*
Dev - for continuous development
Test - for QAs to carry out testing
UAT - pre-release testing environment
PROD - actual production environment
CI CD pipelines for all of these environment look similar(except environment specific things like configurations, branches etc.)
I am referring to consumer pipeline and provider pipeline from pact documentation. (Attached images below for reference) Please note that I am using pact broker and NOT pactflow.
Let?s say consumer and provider teams both are developing their own features. It is very likely that provider API spec is different in DEV env and UAT/PROD environment. Same goes with consumer, contract test on master where consumer is continuously developing features will be different from that of release branch from where consumer deployed on prod env. For example, consumer is building new feature which now uses one more field or entirely different API.
Given this context is following understanding correct?
1. DEV environment pipeline of consumer should be verified against UAT version of provider.
a. To ensure features being developed on consumer master are adhering to provider version in UAT
2. DEV version of provider should verify consumer pacts having tag UAT.
b. To ensure provider is not making any change which will break any consumers in prod.
I am intentionally skipping testing against prod version as prod has user sensitive data.
aubilla
2021-07-14 11:27
Thanks a million for the suggestion. I?ll try and see if I can debug and get more clarity from the HTTP Request.
matt.fellows
2021-07-14 11:38
I think `--debug` is all you need to add to your gradle command to get the detail
aubilla
2021-07-14 12:31
If I understand the logs correctly, the client is looking for `/` instead of `/pact-broker`
```2021-07-14T14:22:09.350+0200 [LIFECYCLE] [org.gradle.internal.logging.progress.ProgressLoggerFactory]
2021-07-14T14:22:09.350+0200 [LIFECYCLE] [org.gradle.internal.logging.progress.ProgressLoggerFactory] > Configure project :
2021-07-14T14:22:12.446+0200 [DEBUG] [org.apache.http.client.protocol.RequestAddCookies] CookieSpec selected: default
2021-07-14T14:22:12.446+0200 [DEBUG] [org.apache.http.client.protocol.RequestAuthCache] Auth cache not set in the context
2021-07-14T14:22:12.446+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection request: [route: {s}->https://internal.mycompanydomain.com:443][total kept alive: 1; route allocated: 1 of 5; total allocated: 1 of 10]
2021-07-14T14:22:12.447+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection leased: [id: 0][route: {s}->https://internal.mycompanydomain.com:443][total kept alive: 0; route allocated: 1 of 5; total allocated: 1 of 10]
2021-07-14T14:22:12.448+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-0: set socket timeout to 0
2021-07-14T14:22:12.448+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Executing request GET / HTTP/1.1
2021-07-14T14:22:12.448+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Target auth state: UNCHALLENGED
2021-07-14T14:22:12.448+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Proxy auth state: UNCHALLENGED
2021-07-14T14:22:12.492+0200 [DEBUG] [org.apache.http.impl.execchain.MainClientExec] Connection can be kept alive indefinitely
2021-07-14T14:22:12.492+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection [id: 0][route: {s}->https://internal.mycompanydomain.com:443] can be kept alive indefinitely
2021-07-14T14:22:12.493+0200 [DEBUG] [org.apache.http.impl.conn.DefaultManagedHttpClientConnection] http-outgoing-0: set socket timeout to 0
2021-07-14T14:22:12.493+0200 [DEBUG] [org.apache.http.impl.conn.PoolingHttpClientConnectionManager] Connection released: [id: 0][route: {s}->https://internal.mycompanydomain.com:443][total kept alive: 1; route allocated: 1 of 5; total allocated: 1 of 10]
2021-07-14T14:22:12.498+0200 [WARN] [au.com.dius.pact.core.pactbroker.HalClient] Could not fetch the root HAL document
au.com.dius.pact.core.pactbroker.RequestFailedException: Request to path '/' failed with response 'HTTP/1.1 503 Service Unavailable'
at au.com.dius.pact.core.pactbroker.HalClient.handleHalResponse(HalClient.kt:296)```
aubilla
2021-07-14 12:51
Perhaps the problem originates somewhere around https://github.com/pact-foundation/pact-jvm/blob/7d87ef6bbeb9d921c5036166769123831f1e1769/core/pactbroker/src/main/kotlin/au/com/dius/pact/core/pactbroker/util/HttpClientUtils.kt#L17
matt.fellows
2021-07-14 13:16
looks like the client needs to consider any base-path provided. If you can remove the need for `/pact-broker` in your base path, that might be faster. But i?d also recommend raising an issue on Pact JVM if it?s the case (worth double checking if a similar issue already exists though)
aubilla
2021-07-14 14:03
Thanks! I?ve raised the https://github.com/pact-foundation/pact-jvm/issues/1399 and I?ll see if we can lose the `/path-broker` path
c.pavan1986
2021-07-14 14:13
I am using pactbroker can-i-deploy cli with the jenkins pipeline. If can-i-deploy returns no, its automatically exiting the build with exit 1. I would like to perform other operations based on the can-i-deploy, is there a way to capture the output of can-i-deploy instead of exiting.
matt.fellows
2021-07-14 22:29
It?s more of a bash question, but you can use the `-e` or `+e` flags on bash which will set to fail on error (or not).
bethskurrie
2021-07-14 22:30
You run run it with `--dry-run --output json` and parse the response @c.pavan1986
matt.fellows
2021-07-14 22:31
That could be hard if it?s a bash script, I assume it?s maybe a ?do this on failure? thing
bethskurrie
2021-07-15 05:12
@poorvasgokhale I'm still unclear about a few things.
> I am intentionally skipping testing against prod version as prod has user sensitive data
bethskurrie
2021-07-15 05:13
Pact tests are done in CI using an entirely local consumer/api that has data that is just set up for each test. There are no deployed environments involved, so it's irrelevant whether you're testing a prod version or a dev version.
bethskurrie
2021-07-15 05:13
You do the pact tests and the can-i-deploy check *before* you deploy, not after.
bethskurrie
2021-07-15 05:15
Can you explain to me the lifecycle of a "commit" please? From the time a develper first makes the commit, how does it travel through to production?
poorvasgokhale
2021-07-15 05:22
Sure. We are using 2 branches for in our producer and consumer repo
1. master/main branch - continuous development - CI Cd pipeline for dev, test env points to master branch
2. release branch - for release - CI CD pipeline for UAT, PROD env points to release branch.
code from master branch and release branch of consumer can be different as master will have ongoing feature development. This is why essentially contract generated from master branch of consumer and release branch of consumer can be different.
For example, in release branch (Production) consumer is using one API from provider. On master branch, consumer has build new feature which now uses 2 APIs from provider.
Given this context, my question is:
master branch contract of consumer should be verified with release branch of provider or master of provider?
(Let me know if it?s still confusing. If it?s possible for you, I am happy to get on call with you. In might be easier to explain it over call. )
bethskurrie
2021-07-15 05:27
```consumerVersionSelectors: [
{
tag: "main",
latest: true
},
{
tag: process.env.GIT_BRANCH,
latest: true
},
{
tag: "test",
latest: true
},
{
tag: "production",
latest: true
},{
tag: "uat",
latest: true
}
],```
poorvasgokhale
2021-07-15 05:27
okay. https://docs.pact.io/pact_broker/tags/ this is the document I went through. Is there anything apart from this?
bethskurrie
2021-07-15 05:28
Your situation is different to most, because you have all those different branches.
poorvasgokhale
2021-07-15 05:30
ohh okay.. Thank @bethskurrie Really appreciate you help. PACT community support seems very active . This is giving me confidence to go ahead with it. :slightly_smiling_face:
bethskurrie
2021-07-15 05:30
Having said that, we're about to release proper support for environments, deployments and releases, which makes the whole consumer version selector config/tagging thing a lot simpler.
bethskurrie
2021-07-15 05:31
this is what is coming: https://docs.pact.io/pact_broker/recording_deployments_and_releases/
bethskurrie
2021-07-15 05:31
Feel free to skip it if you think you're in information overload already!
uladzislau_danilchyk
2021-07-15 06:42
Hi everyone!
Is there any possibility to filter contracts to be verified by consumer tags when the contracts have all tags I passed_?_ Just to do not select contracts if one of the passed tags exists, but for all tags instead.
Currently if I pass multiple consumer tags to prop `pactbroker.consumerversionselectors.tags` , it will search contracts with passed tags but in a following way.
Let's assume that I passed master,develop tags. I want to filter contracts which have all of these tags, not at least one. Because currently it will retrieve contracts for master, contracts for develop separately, combine into one list and verify.
bethskurrie
2021-07-15 06:50
@uladzislau_danilchyk can you explain the underlying problem you're trying to solve?
uladzislau_danilchyk
2021-07-15 06:53
@dimundo, I will try to rephrase.
We want to have a Jenkins Job with manual triggering provider verification. Some of params are consumer and provider. We can pass consumer tags, provider version and that's it. But currently it filters consumer contracts by tags one by one instead of like this: "Received two tags. I (Pact-Broker) will find published contracts which have both first and second tags applied for that contracts"
dimundo
2021-07-15 06:55
so it sounds, you want something to do with some version of 1 known consumer version ?
uladzislau_danilchyk
2021-07-15 06:56
@bethskurrie, I don't understand how it solves our problem to filter pacts by all passed tags instead of one by one
bethskurrie
2021-07-15 06:57
the overall problem you're trying to solve is verification of a particular pact, yes?
bethskurrie
2021-07-15 06:57
are we talking about implementing this https://docs.pact.io/pact_nirvana/step_4#e-configure-pact-to-be-verified-when-contract-changes
uladzislau_danilchyk
2021-07-15 07:01
@bethskurrie , we already has automated verification of changed pacts though a webhook
bethskurrie
2021-07-15 07:02
Help me understand that so I can help you actually achieve your underlying goal.
uladzislau_danilchyk
2021-07-15 07:06
Sometimes provider code can be changed and verified against consumer prod. But it doesn't trigger verification against some specific versions (some branches)
uladzislau_danilchyk
2021-07-15 07:07
And we want to have job which verify some specific versions between consumer/provider
uladzislau_danilchyk
2021-07-15 07:07
The main difference is that consumer not changed - only provider has changed
bethskurrie
2021-07-15 07:16
if the provider has changed, why are you not just running the normal provider pipeline that verifies the normal (dev, test, prod) pacts?
uladzislau_danilchyk
2021-07-15 07:20
1. you have custom branch from develop in Consumer `feature/x1` . You did something and created pull request. It's ok.
2. After that Pact Broker webhook triggered our jenkins job to verify against latest develop of a Provider and it failed. It's ok.
3. But after that Provider has changed and you want to run again verification against latest develop of a Provider. How to do that? The only one way I see is push something to `feature/x1` to trigger event (webhook).
4. But no code changes required from Consumer side feature branch. You want just trigger verification again.
uladzislau_danilchyk
2021-07-15 07:21
And the only way I see is to manually pass Consumer tag/Provider tag to verify
bethskurrie
2021-07-15 07:23
> The WIP (work in progress) pacts is a feature that ensures any new contracts are automatically verified in the provider's main pipeline build without requiring an update to the provider configuration.
matt.fellows
2021-07-15 07:25
I'm assuming because they want the consumer branch/PR to become green and mergeable
dimundo
2021-07-15 07:25
you are wasting all providers time, to be complient with feature ( s ), which maybe will never be finished
bethskurrie
2021-07-15 07:26
one of the things I always say in the talks I give on pact is "the teams still have to talk to each other to design the APIs"
bethskurrie
2021-07-15 07:26
it's not a tool for just putting in expectations and not talking to each other.
bethskurrie
2021-07-15 07:32
Ok, I have to go for dinner now, but did we end up solving your original goal @uladzislau_danilchyk? You want to automatically get verification results for your feature pacts.
bethskurrie
2021-07-15 07:38
Do update to the very latest broker though, becuase there were some updates to the WIP rules that you will want.
bethskurrie
2021-07-15 08:06
Hey all people using WIP pacts. Please update to the latest version (2.80.0) of the Pact Broker, because there was a significant problem with the pact selection that has been fixed in the latest version.
dimundo
2021-07-15 08:43
https://github.com/pact-foundation/pact-broker-docker/releases
2.80.0.1 for dockers/k8s , right?
bethskurrie
2021-07-15 10:31
This is probably more relevant https://hub.docker.com/repository/docker/pactfoundation/pact-broker
dimundo
2021-07-15 11:13
hi!
should be there any logging, while checking in WIP mode?
like
> verified consumer tag `master` , but also consumer versions `versionA` `versionB` etc
or its done purely inside broker ?
uladzislau_danilchyk
2021-07-15 11:30
@bethskurrie, thanks. I think yes. but question is still open. Just to know how it works now:)
What rules are you talking about in the last message regarding WIP?
dimundo
2021-07-15 16:52
or maybe i will ask differently
will WIP work, if many consumers has same `version` *and* `tag`?
like `consumerA` has `version1` and `tag1`
like `consumerB` has `version1` and `tag1`
?
kflo
2021-07-15 17:07
yes, the implementations generally log something about the pacts they selected for verification and why
dimundo
2021-07-15 17:14
but looks it logs only current check, and the rest is done by broker, as I?m getting only
> is being verified because the pact content belongs to the consumer version matching the following criterion:
> * latest version tagged ?cit1? (196db8a1)
^^ with consumer tag
or
> is being verified because the pact content belongs to the consumer version matching the following criterion:
> * latest version of a consumer that has a pact with CommonAPI (5dd38d1c)
^^ w/o consumer tags
dimundo
2021-07-15 17:16
in case of WIP - all `(eg. The latest pact for a version with tag main + the latest pact for a version with tag feat-x + the latest pact for a version with tag feat-y ...)`
kflo
2021-07-15 17:17
all of the rest were filtered out for some reason (maybe this is the part you want to see)
kflo
2021-07-15 17:17
that would be nice, but probably there are so many things filtered out it might be hard to display :thinking_face:
bheemreddy181
2021-07-15 20:43
WIP is more related to provide no- i mean once consumer pushes new pacts then provider verifies them but doesn't fail on their CI - i don't think same versions has anything to do with here
dimundo
2021-07-15 20:50
yes, thats correct, but in this case - provider tests were don some time ago, but there were no corresponding consumer test
dimundo
2021-07-15 20:55
there is continuation in different thread https://pact-foundation.slack.com/archives/C9W94RTBQ/p1626371280041600
bethskurrie
2021-07-15 21:49
@uladzislau_danilchyk https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/#technical-details
bethskurrie
2021-07-15 21:49
You can do this workshop to have a play with how it works https://docs.pactflow.io/docs/workshops/ci-cd
bethskurrie
2021-07-15 21:56
Here is what changed in the WIP logic https://github.com/pact-foundation/pact_broker/pull/432
bethskurrie
2021-07-15 21:57
Just understand that if you create a pact with a new tag (feature branch pact) it will get verified automatically without the provider having to change anything. It will keep being verified until the consumer branch is merged.
bethskurrie
2021-07-15 22:16
Can you see if you can recreate it using this please https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
bethskurrie
2021-07-15 22:18
I'll see if I can add some debug level logging to the WIP calculation, but as I think kflorence said, it could be very verbose!
dimundo
2021-07-15 22:25
maybe some /tail endpoint could be created for broker ? no not send everything by wires ?
uladzislau_danilchyk
2021-07-16 10:51
@bethskurrie,
> Just to know how it works now
I mean does the `pactbroker.consumerversionselectors.tags` can filter pacts which have all provided tags or at least one tag? I see that currently it works in a second way
github2
2021-07-17 03:48
[pact-foundation/pact_broker] New release _https://github.com/pact-foundation/pact_broker/releases/tag/v2.81.0_ published by github-actions[bot]
bethskurrie
2021-07-17 04:08
@dimundo I've just put out 2.81.0.0. It has some debug level logging for WIP calculations
bethskurrie
2021-07-17 04:09
Yes, wip should allow you to get verifications for your consumer tests as they try to catch up.
bethskurrie
2021-07-17 05:07
To get the logging, you'll need to set the PACT_BROKER_LOG_LEVEL to 'DEBUG' and the PACT_BROKER_SQL_LOG_LEVEL to 'none' (otherwise the wip logging will be drowned out by the SQL statements)
bethskurrie
2021-07-17 05:08
You'll actually need 2.81.0.1, as I've just added support for the 'none' in that version.
bethskurrie
2021-07-17 05:08
pact-broker -- Fetching pacts for verification by bar-provider -- {:provider_name=>"bar-provider", :params=>{"providerVersionTags"=>["main"], "consumerVersionSelectors"=>[{"tag"=>"main", "latest"=>true}], "includePendingStatus"=>true, "includeWipPactsSince"=>"2020-01-01"}}
[wip] pact-broker -- Potential WIP pacts for provider tag(s) main created after 2020-01-01T00:00:00+00:00 by latest_by_consumer_tag -- ["foo-consumer 1 (tag main)", "foo-consumer 2 (tag feat/a)", "foo-consumer 2 (tag feat/b)"]
[wip] pact-broker -- Ignoring pacts explicitly specified in the selectors -- ["foo-consumer 1 (tag main)"]
[wip] pact-broker -- Ignoring pacts successfully verified by this provider tag when not WIP (none)
[wip] pact-broker -- Ignoring pacts successfully verified by another provider tag when not WIP (none)
[wip] pact-broker -- Potential WIP pacts for provider tag(s) main created after 2020-01-01T00:00:00+00:00 by latest_by_consumer_branch (none)
[wip] pact-broker -- Ignoring pacts explicitly specified in the selectors (none)
[wip] pact-broker -- Ignoring pacts successfully verified by this provider tag when not WIP (none)
[wip] pact-broker -- Ignoring pacts successfully verified by another provider tag when not WIP (none)
dimundo
2021-07-19 06:49
@bethskurrie
? i?ve updated broker ( on premises in k8s ) to `appVersion: 2.81.0.1`
? set log level to debug
``` val tagFromBranch: String = scala.util.Properties.envOrElse("CI_COMMIT_BRANCH", "SNAPSHOT-branch")
val versionFromCommit: String = scala.util.Properties.envOrElse("CI_COMMIT_SHORT_SHA", "SNAPSHOT-version")
val isCI: Boolean = scala.util.Properties.envOrElse("CI", "false") == "true"
override def provider: ProviderInfoBuilder = {
ProviderInfoBuilder(
name = name,
pactSource = PactBrokerWithSelectors(
brokerUrl = brokerUrl,
auth = Some(BasicAuth(brokeUser, brokerPass)),
enablePending = true,
includeWipPactsSince = Some(System.currentTimeMillis().millis - 7.days),
providerTags = List(tagFromBranch),
selectors =
List(ConsumerVersionSelector(tag = Some("cit1")), ConsumerVersionSelector(tag = Some(tagFromBranch)))
)
).withPort(8080)
.withOptionalVerificationSettings(
Option.when(apiPackages.nonEmpty)(AnnotatedMethodVerificationSettings(packagesToScan = apiPackages))
)
} ```
dimundo
2021-07-19 06:52
```Verifying a pact between AAA (55b32159) and BBB
Notices:
1) The pact at https://.../pacts/provider/.../consumer/.../pact-version/90a1b07a580488aadb4877459c569c4fd1b28e73 is being verified because the pact content belongs to the consumer version matching the following criterion:
* latest version tagged 'cit1' (55b32159)
2) This pact has previously been successfully verified by a version of ... with tag 'SNAPSHOT-branch'. If this verification fails, it will fail the build. Read more at https://docs.pact.io/go/pending
[from Pact Broker https://.../pacts/provider/.../consumer/.../pact-version/.../metadata/...]
bo.TableState
generates a message which
has a matching body (OK)
has matching metadata (OK)
generates a message which
has a matching body (OK)
has matching metadata (OK)
NOTE: Skipping publishing of verification results as it has been disabled (pact.verifier.publishResults is not 'true')```
dimundo
2021-07-19 06:56
one more thing, did ive get that correctly
> PACT_BROKER_SQL_LOG_LEVEL to ?none? (otherwise the wip logging will be drowned out by the SQL statements)
is ?none? is , not ?? ?
> PACT_BROKER_LOG_LEVEL: ?DEBUG?
> PACT_BROKER_SQL_LOG_LEVEL: ?none?
dimundo
2021-07-19 07:03
https://guides.rubyonrails.org/debugging_rails_applications.html#log-levels
```2.2 Log Levels
When something is logged, it's printed into the corresponding log if the log level of the message is equal to or higher than the configured log level. If you want to know the current log level, you can call the Rails.logger.level method.
The available log levels are: :debug, :info, :warn, :error, :fatal, and :unknown, corresponding to the log level numbers from 0 up to 5, respectively. To change the default log level, use```
should i set to `fatal` ?
dimundo
2021-07-19 07:19
```2021-07-19 10:07:21
2021-07-19 07:07:21.839752 I [8:70247889656320] pact-broker -- PACT_BROKER_SQL_LOG_LEVEL=fatal
2021-07-19 10:07:21
2021-07-19 07:07:21.839748 I [8:70247889656320] pact-broker -- PACT_BROKER_PUBLIC_HEARTBEAT=true
2021-07-19 10:07:21
2021-07-19 07:07:21.839744 I [8:70247889656320] pact-broker -- PACT_BROKER_PORT_ENVIRONMENT_VARIABLE_NAME=PACT_BROKER_PORT
2021-07-19 10:07:21
2021-07-19 07:07:21.839740 I [8:70247889656320] pact-broker -- PACT_BROKER_PORT=9292
2021-07-19 10:07:21
2021-07-19 07:07:21.839737 I [8:70247889656320] pact-broker -- PACT_BROKER_LOG_LEVEL=DEBUG
2021-07-19 10:07:21
2021-07-19 07:07:21.839733 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_USERNAME=****
2021-07-19 10:07:21
2021-07-19 07:07:21.839729 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_PASSWORD=*****
2021-07-19 10:07:21
2021-07-19 07:07:21.839725 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_NAME=pact_broker
2021-07-19 10:07:21
2021-07-19 07:07:21.839721 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_HOST=broker4pact-postgresql
2021-07-19 10:07:21
2021-07-19 07:07:21.839717 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_CLEAN_OVERWRITTEN_DATA_MAX_AGE=7
2021-07-19 10:07:21
2021-07-19 07:07:21.839713 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS=[{ "latest": true, "tag": true }, { "max_age": 90 }]
2021-07-19 10:07:21
2021-07-19 07:07:21.839709 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_CLEAN_ENABLED=false
2021-07-19 10:07:21
2021-07-19 07:07:21.839705 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_CLEAN_DRY_RUN=false
2021-07-19 10:07:21
2021-07-19 07:07:21.839700 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_CLEAN_DELETION_LIMIT=500
2021-07-19 10:07:21
2021-07-19 07:07:21.839696 I [8:70247889656320] pact-broker -- PACT_BROKER_DATABASE_CLEAN_CRON_SCHEDULE=0 2 15 * *
2021-07-19 10:07:21
2021-07-19 07:07:21.839691 I [8:70247889656320] pact-broker -- PACT_BROKER_BASIC_AUTH_USERNAME=****
2021-07-19 10:07:21
2021-07-19 07:07:21.839685 I [8:70247889656320] pact-broker -- PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME=****
2021-07-19 10:07:21
2021-07-19 07:07:21.839677 I [8:70247889656320] pact-broker -- PACT_BROKER_BASIC_AUTH_READ_ONLY_PASSWORD=*****
2021-07-19 10:07:21
2021-07-19 07:07:21.839616 I [8:70247889656320] pact-broker -- PACT_BROKER_BASIC_AUTH_PASSWORD=*****
2021-07-19 10:07:21
* PID: 8
2021-07-19 10:07:21
* Environment: production
2021-07-19 10:07:21
* Max threads: 5
2021-07-19 10:07:21
* Min threads: 0
2021-07-19 10:07:21
* Puma version: 5.3.2 (ruby 2.6.7-p197) ("Sweetnighter")
2021-07-19 10:07:21
Puma starting in single mode...```
dimundo
2021-07-19 07:27
maybe one more finding - quite a lot of ?NULL? ( logs are in reverse )
```
2021-07-19 10:15:59 2021-07-19 07:15:59.454399 F [8:puma threadpool 001 delegate.rb:83] pact-broker -- (0.000402s) SELECT NULL
2021-07-19 10:15:59 2021-07-19 07:15:59.455269 F [8:puma threadpool 001 delegate.rb:83] pact-broker -- (0.000320s) SELECT NULL
2021-07-19 10:15:59 2021-07-19 07:15:59.455898 F [8:puma threadpool 001 delegate.rb:83] pact-broker -- (0.000326s) SELECT NULL
2021-07-19 10:15:59 2021-07-19 07:15:59.456536 F [8:puma threadpool 001 delegate.rb:83] pact-broker -- (0.000375s) SELECT NULL
2021-07-19 10:15:59 2021-07-19 07:15:59.458797 F [8:puma threadpool 001 delegate.rb:83] pact-broker -- (0.002097s) SELECT "pact_publications".* FROM "pact_publications" INNER JOIN "pact_versions" ON ("pact_publications"."pact_version_id" = "pact_versions"."id") WHERE (("pact_publications"."consumer_id" IN (SELECT "pacticipants"."id" FROM "pacticipants" WHERE (("name" = 'AAA') AND ("pacticipants"."id" IS NOT NULL)))) AND ("pact_publications"."provider_id" IN (SELECT "pacticipants"."id" FROM "pacticipants" WHERE (("name" = 'BBB') AND ("pacticipants"."id" IS NOT NULL)))) AND ("pact_versions"."sha" = '90a1b07a580488aadb4877459c569c4fd1b28e73')) ORDER BY "consumer_version_order" DESC, "revision_number" DESC LIMIT 1```
bethskurrie
2021-07-19 10:36
> PACT_BROKER_LOG_LEVEL: ?DEBUG?
> PACT_BROKER_SQL_LOG_LEVEL: ?none?
That's correct.
bethskurrie
2021-07-19 10:36
> https://guides.rubyonrails.org/debugging_rails_applications.html#log-levels
This is not a Rails application.
bethskurrie
2021-07-19 10:38
If you set the log level to fatal, it will only log the errors that stop the application running.
bethskurrie
2021-07-19 10:39
Here's the code that does the logging https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/pacts/pacts_for_verification_repository.rb#L311
bethskurrie
2021-07-19 10:41
`PACT_BROKER_SQL_LOG_LEVEL: "none"` this will turn the SQL logging off, because by default, it logs at debug level, and it will be so noisy, it will be hard to see the wip logs.
bethskurrie
2021-07-19 10:42
Have a play around with https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
bethskurrie
2021-07-19 10:57
bethskurrie
2021-07-19 10:58
```pact-broker -- Fetching pacts for verification by bar-provider -- {:provider_name=>"bar-provider", :params=>{"providerVersionTags"=>["main"], "consumerVersionSelectors"=>[{"tag"=>"main", "latest"=>true}], "includePendingStatus"=>true, "includeWipPactsSince"=>"2020-01-01"}}
[wip] pact-broker -- Potential WIP pacts for provider tag(s) main created after 2020-01-01T00:00:00+00:00 by latest_by_consumer_tag -- ["foo-consumer 1 (tag main)", "foo-consumer 2 (tag feat/a)", "foo-consumer 3 (tag feat/b)"]
[wip] pact-broker -- Ignoring pacts explicitly specified in the selectors -- ["foo-consumer 1 (tag main)"]
[wip] pact-broker -- Ignoring pacts successfully verified by this provider tag when not WIP (none)
[wip] pact-broker -- Ignoring pacts successfully verified by another provider tag when not WIP (none)
[wip] pact-broker -- Potential WIP pacts for provider tag(s) main created after 2020-01-01T00:00:00+00:00 by latest_by_consumer_branch (none)
[wip] pact-broker -- Ignoring pacts explicitly specified in the selectors (none)
[wip] pact-broker -- Ignoring pacts successfully verified by this provider tag when not WIP (none)
[wip] pact-broker -- Ignoring pacts successfully verified by another provider tag when not WIP (none)```
bethskurrie
2021-07-19 22:54
And can you show me the command you're calling, and the output that follows.
bethskurrie
2021-07-19 22:55
If --dry-run is returning a non zero exit code, that is a bug. Can raise an issue in https://github.com/pact-foundation/pact_broker-client/issues and provide the exact steps to reproduce it.
bheemreddy181
2021-07-19 23:30
Team quick question does the pact provider terraform basic auth https://github.com/pactflow/terraform-provider-pact needs to be used in conjunction with pact brokers basic auth ?
bheemreddy181
2021-07-19 23:32
no no , my question was if we enable basic auth variables here - do we need to also set
```provider "pact" {
# For the OSS Broker
# host = "http://localhost"
# basic_auth_username = "pact_broker"
# basic_auth_password = "pact_broker"
# For a Pactflow Broker
host = "https://mybroker.pact.dius.com.au"
access_token = var.token
}```
env variables like this https://github.com/pact-foundation/pact-broker-docker#using-basic-auth
bheemreddy181
2021-07-19 23:32
Can we just use pact terraform basic auth to restrict who can use the HAL API's ?
bheemreddy181
2021-07-19 23:35
the reason for asking this was - we tried doing so not setting any credentials on the pact broker docker image and only set credentials on the pact provider terraform to restrict people to not use HAL API's but when provider tries to retrieve the pacts - pact broker returns 301 Moved response
matt.fellows
2021-07-19 23:43
```provider "pact" {
# For the OSS Broker
# host = "http://localhost"
# basic_auth_username = "pact_broker"
# basic_auth_password = "pact_broker"
# For a Pactflow Broker
host = "https://mybroker.pact.dius.com.au"
access_token = var.token
}```
That is configuring the terraform provider, to _be able to comunicate to a running broker_
matt.fellows
2021-07-19 23:43
Terraform configures an already running broker, it doesn?t bootstrap one from scratch
bethskurrie
2021-07-19 23:46
Sorry Bheem. I saw you say "Team" and I thought you meant the "teams" feature. You were just talking to us as a "pact team" though :laughing:
bethskurrie
2021-07-19 23:47
Sorry, got the kids home today because covid and I am MIGHTILY distracted.
bethskurrie
2021-07-19 23:47
The only way you can configure the basic auth user from the Broker side is via the environment variables.
matt.fellows
2021-07-19 23:50
> the reason for asking this was - we tried doing so not setting any credentials on the pact broker docker image and only set credentials on the pact provider terraform to restrict people to not use HAL API?s but when provider tries to retrieve the pacts - pact broker returns 301 Moved response
you can?t do that. You can?t disable auth conditionally (if you could do that, that would be a big security issue!)
bheemreddy181
2021-07-20 00:30
you mean we should be enabling both auth ( terraform side and pact broker docker image ) is that correct @matt.fellows ?
matt.fellows
2021-07-20 00:31
so if you run the pact broker with authentication (e.g. basic auth), Terraform needs those credentials to be able to communicate to it. i.e. Terraform is a client
bethskurrie
2021-07-20 00:31
One is the client, one is the server. If you set required credentials on the server, you also need to make the client use those credentials.
bheemreddy181
2021-07-20 00:32
what if i don't set the credentials on pact broker and only set them on terraform - because we want to use terraform t apply webhooks ? can we do so ?
matt.fellows
2021-07-20 00:32
Terraform can not setup authentication on the broker, that is something you do separately (e.g. in Docker via environment variables)
matt.fellows
2021-07-20 00:33
If you don?t set credentials on the broker, terraform doesn?t need any credentials to communicate to it
matt.fellows
2021-07-20 00:33
so if there is no auth on the broker, you don?t need to add authentication to terraform
bethskurrie
2021-07-20 00:34
Terraform is just another HTTP client. Just like the Pact Broker Client CLI.
bheemreddy181
2021-07-20 00:34
typically here is the use case - we want to set restrictions only to HAL API's which does update / delete / create - so which means we want terraform as the only user who can do that
bheemreddy181
2021-07-20 00:34
other people who wants to see the contracts they can just jump on the pact broker UI without auth
matt.fellows
2021-07-20 00:36
If you want to restrict access to the APIs, you?ll need to add your own security (e.g. via nginx, Apache or cloud native API gateways) that prevent certain principals from accessing the broker on various routes/methods/etc.
matt.fellows
2021-07-20 00:36
Pactflow has a sophisticated permissions model that supports this, but the open source one does not
bethskurrie
2021-07-20 00:36
> If you want to allow public read access (but still require credentials for writing), then omit setting the READ_ONLY credentials and set `PACT_BROKER_ALLOW_PUBLIC_READ=true`.
bheemreddy181
2021-07-20 00:38
Makes sense - Beth does that mean even for updating status of your provider job we need to set the credentials on the provider CI correct ?
bheemreddy181
2021-07-20 00:40
I mean typically any CI which tries to read data from pact broker ( retrieving pacts ) or updating ci job status ( provider ci ) needs crendentials is that correct ? when we just set `PACT_BROKER_ALLOW_PUBLIC_READ=true`
bheemreddy181
2021-07-20 00:43
or `PACT_BROKER_ALLOW_PUBLIC_READ=true` means indirectly giving authorization to all GET API's on pact broker ?
matt.fellows
2021-07-20 01:29
Yes `PACT_BROKER_ALLOW_PUBLIC_READ` means the broker is essentially publicly available for read (APIs and the UI)
matt.fellows
2021-07-20 01:30
> Makes sense - Beth does that mean even for updating status of your provider job we need to set the credentials on the provider CI correct ?
Yes, for CI they will need the write credentials
bheemreddy181
2021-07-20 17:32
is there a way i can al HTTP communications done by provider pact jobs ? by enabling some logs ?
bheemreddy181
2021-07-20 21:02
doesn't show anything around what communications happened between provider and pact broker
bheemreddy181
2021-07-21 03:02
I set the debug mode but still don?t see the http communications to pact broker
matt.fellows
2021-07-21 03:03
Ah, there used to be a verbose flag, I can?t recall if that?s been removed (there was problems with it, but it might be resolved now)
matt.fellows
2021-07-21 03:40
hmm yes, it is deprecated: https://github.com/pact-foundation/pact-go/blob/master/types/verify_request.go#L214-L216
matt.fellows
2021-07-21 03:40
You could have a go at adding the flag in to your local source and see if it breaks thingsn
matt.fellows
2021-07-21 03:40
from memory, because we get JSON back from the verifier, when we added `--verbose` it broke the JSON
matt.fellows
2021-07-21 03:42
(FWIW I know you?re probably not yet in the headspace for an upgrade, but the new v2.x.x branch is almost ready to come out of beta and definitely has verbose logging if needed: https://github.com/pact-foundation/pact-go/tree/2.x.x/)
dimundo
2021-07-21 13:52
yes, matching rules disappeared from that view (not sure if it is bug or feature)
poorvasgokhale
2021-07-22 09:48
Hello, I have consumer repository and provider repository. I want provider build to be triggered once consumer uploads pact. Consumer and Provider repos use `github action` as CI. I am looking at pact webhook documentation. But I am unable to connect dots. Can someone help me with steps for this. Steps which I am imagining are like:
1. Create webhook in pact broker using /webhook API with event `contract_content_changed`
2. Above step will create github webhook in provider repo (not sure??)
3. When consumer pact contract changes, it dispatches `repository_dispatch` workflow event to provider repo.
4. This starts provider github action pipeline with pact verification.
Is this correct?
*I am kind of confused between pact broker webhooks and github webhooks. How these two are related?*
poorvasgokhale
2021-07-22 09:57
Some more questions:
I am referring to https://docs.pact.io/pact_broker/webhooks/template_library/#github---trigger-build.
1. This webhook need to be created in pact broker using `/webhook` endpoint right?
```{
"events": [{
"name": "contract_content_changed"
}],
"request": {
"method": "POST",
"url": "https://api.github.com/repos/<organisation>/<repository>/dispatches",
"headers": {
"Content-Type": "application/json",
"Accept": "application/vnd.github.everest-preview+json",
"Authorization": "Bearer ${user.GithubToken}"
},
"body": {
"event_type": "pact_changed",
"client_payload": {
"pact_url": "${pactbroker.pactUrl}"
}
}
}
}```
2. url field refer to consumer repo or provider repo?
3. where will it get value of `${user.GithubToken}` and `${pactbroker.pactUrl}`?
francislainy.campos
2021-07-22 10:35
Thank you. It would be nice if someone could confirm this. @matt.fellows you perhaps?
matt.fellows
2021-07-22 10:42
I don?t think matching rules are displayed there, but is that the problem? from the pictures you showed, it looks more of the actual body is missing?
matt.fellows
2021-07-22 10:46
A webhook is an arbitratry HTTP action that is made when a given event occurs. In the case of the Pact Broker and your use case, it is when a new pact is published or a changed pact is published.
1. Yes, you create a webhook in pact broker. The webhook will contain the details to trigger a github build (in the example you showed, this is using the dispatch API)
2. No, the webhook exists in the pact broker. It will _trigger_ the provider build
3. correct
4. correct. ALso note that it is recommended to trigger specifically just a pact build (the `event_type` would identify that), and specifically verify the pact that is changed (`pact_url`)
matt.fellows
2021-07-22 10:48
as for your second set of questions
2. provider repo. You want to trigger the provider to verify the pact that was just published
3. `${user.GithubToken}` is a user defined secret. That is a Pactflow feature, so if you?re not using Pactflow, you?d need to just hardcode the secret there. `${pactbroker.pactUrl}` is a template variable that can go in the webhook. It contains a URL to the changed pact
2021-07-22 10:48
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
2021-07-22 10:50
See this page on the steps to creating an effective contract-testing setup https://docs.pact.io/pact_nirvana. (This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/)
matt.fellows
2021-07-22 10:51
Can you please grab the URL from the browser, and cURL it from the command line?
poorvasgokhale
2021-07-22 10:51
I am not using pactflow, I am setting up pact broker using docker image.
Regarding `${user.GithubToken}` is this the `Personal access token` from provider repo?
matt.fellows
2021-07-22 10:51
the URL will be something like `curl http://<yourbroker>/pacts/provider/blah/?`
matt.fellows
2021-07-22 10:52
even if you?re not using Pactflow, the guide takes you through this whole process. It just happens to use Pactflow. You can substitute Pactflow with your own
bethskurrie
2021-07-22 20:48
@poorvasgokhale the OSS Pact Broker does not have secrets, so you'll just be hardcoding the github access token in the webhook itself.
bethskurrie
2021-07-22 20:53
Wondering if it's the same as this: https://github.com/pact-foundation/pact_broker/issues/265
bethskurrie
2021-07-22 22:42
@francislainy.campos please change the matcher so that has "min: 1" instead of "min: 0". Min 0 is an illegal value.
matt.fellows
2021-07-23 04:14
FYI there is a working example here: https://github.com/pactflow/terraform-provider-pact/blob/master/client/client_pact_test.go
poorvasgokhale
2021-07-23 04:39
yes. It worked with github access token :slightly_smiling_face: Thank you @matt.fellows @bethskurrie
francislainy.campos
2021-07-23 07:58
Hmm, okay, thanks Matt. Perhaps the default should be 1 on the api then? I mean, if people don?t know this then they would still be getting into this same issue right?
francislainy.campos
2021-07-23 08:11
```DslPart bodyUpdates = new PactDslJsonBody()
.eachLike("learningResources")
.stringType("learningResourceRefId", "I_13aaaaaa-aaaa-4aaa-a36a-978035810015")
.uuid("orgRefId", "ab20281e-f8ea-43e4-bc34-24f968c47c5b")
.stringType("program", "ELA_NGL_G7_FL")
.booleanType("isExpired", false)
.integerType("licenseCount", 0)
.array("roleTypes")
.stringType("student")
.closeArray()
.eachLike("integrations")
.stringType("partner", "Writable")
.stringType("partnerProduct", "Basic")
.stringType("partnerProductTitle", "Writing Taks")
.stringType("learningResourceRefId", "")
.booleanType("isTurnItInEnabled", false)
.closeArray()
.closeArray();```
dimundo
2021-07-23 08:20
hi!
one more webhook question
we have 7 contracts so far, but those are separated by 2 repos, so there are `1 consumer + 6 providers` repo and `6 consumers + 1 provider` repo
if i add `on-change` webhook for 1 of consumers - rest 5 will be verified, but not all of them are changing. if i?ll add `on-change` webhook for all 6 - it will trigger 6 verification jobs ( in worse scenario )
any ideas for this ?
bethskurrie
2021-07-23 08:27
You can pass in the name of the provider that you want to verify the pact, as well as the pact URL.
bethskurrie
2021-07-23 08:27
That way, the job can select which provider to run the verification for (eg. `cd ${PROVIDER} && verify $PACT_URL`
dimundo
2021-07-23 08:51
gitlab will trigger `sbt pactTest` which will run all providers ( its fast, so not a bi deal )
dimundo
2021-07-23 08:51
what is concern - if each consumer will be changed - it will trigger 6 checks, when only 1 is enough ( so far )
bethskurrie
2021-07-23 08:54
The only thing I can think of is to see if you can limit that build to one execution at a time (you can do this with buildkite, but I don't know if you can do it with other CIs).
bethskurrie
2021-07-23 08:54
Then, add a check at the start to see if you actually need to do it. I've just actually released a new command for the webhook-less flow to check if the verification task needs to run or not.
bethskurrie
2021-07-23 08:56
It's in beta, so the interface might change, but you could try it out https://github.com/pact-foundation/pact_broker-client/blob/master/lib/pact_broker/client/cli/matrix_commands.rb#L47
bethskurrie
2021-07-23 08:56
You need to set PACT_BROKER_FEATURES=verification_required for the command to be available
dimundo
2021-07-23 08:56
oh, build queues, if CI sees, that its same job, then it squashes. something like this were @ jenkins, will check, what gitlab will say
bethskurrie
2021-07-23 08:57
You'd still get 6 builds, but if you started each build with the "verification-required" check, it would only run the verifications the first time.
bethskurrie
2021-07-23 08:58
Running the sbt task won't verify all the changed pacts, it will just verify the configured pacts.
bethskurrie
2021-07-23 08:59
If all 6 change in one commit, for feat-x, then there will be one triggered webhook for each consumer
bethskurrie
2021-07-23 09:00
The webhook triggered provider verification build can only verify one of those pacts at a time.
dimundo
2021-07-23 09:02
`sbt pactTests` will trigger all pact tests
it will be triggered for `feat-x` tag, so, all consumers for this provider?s monorepo will be verified
bethskurrie
2021-07-23 09:02
Remember, there are two modes of verification - 1 when the provider changes, and it verifies all the consumers and all the pacts. 2 .when a pact changes, and it just verifies that changed pact at the URL that the webhook passes through.
bethskurrie
2021-07-23 09:03
There's a bunch of metadata in the Pact URL that you will miss out on doing it that way.
aubilla
2021-07-23 11:35
It might be an obvious question but:
Adding my CI?s domain to `config.webhook_host_whitelist` would make the response coming from the CI visible on the Broker?s webhook logs?
```[2021-07-23T08:52:03Z] INFO: For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property. See https://pact-broker.internal.mydomain.com/doc/webhooks#whitelist for more information.```
:thread:
bheemreddy181
2021-07-24 00:33
shouldn't i refer to this example https://github.com/pact-foundation/pact-go/blob/2.x.x/examples/provider_test.go
bheemreddy181
2021-07-24 01:24
Am i doing some thing wrong here
```package provider
import (
"fmt"
"http://github.com/stretchr/testify/assert"
"log"
"net"
"net/http"
"os"
"strconv"
"testing"
"http://github.com/pact-foundation/pact-go/dsl"
"http://github.com/pact-foundation/pact-go/utils"
. "http://github.com/pact-foundation/pact-go/v2/sugar"
"http://github.com/pact-foundation/pact-workshop-go/model"
"http://github.com/pact-foundation/pact-workshop-go/provider/repository"
)
// The Provider verification
func TestPactProvider(t *testing.T) {
go startInstrumentedProvider()
SetLogLevel("TRACE")
verifier := HTTPVerifier{}
// Authorization middleware
// This is your chance to modify the request before it hits your provider
// NOTE: this should be used very carefully, as it has the potential to
// _change_ the contract
f := func(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
log.Println("[DEBUG] HOOK request filter")
if r.Header.Get("Authorization") != "" {
r.Header.Set("Authorization", getAuthToken())
}
next.ServeHTTP(w, r)
})
}
// Verify the Provider - Tag-based Published Pacts for any known consumers
err := verifier.VerifyProvider(t, VerifyRequest{
ProviderBaseURL: fmt.Sprintf("http://127.0.0.1:%d", port),
Tags: []string{"master"},
FailIfNoPactsFound: false,
// Use this if you want to test without the Pact Broker
PactURLs: setPACTURL(),
BrokerURL: fmt.Sprintf("%s://%s", os.Getenv("PACT_BROKER_PROTO"), os.Getenv("PACT_BROKER_URL")),
PublishVerificationResults: canIPublishResultsToBroker(),
ProviderVersion: getProviderVersion(),
ProviderTags: setProviderTags(),
EnablePending: getEnablePendingFlag(),
StateHandlers: stateHandlers,
RequestFilter: f,
})
assert.NoError(t, err)
}```
bheemreddy181
2021-07-24 01:25
logs
```2021/07/23 20:25:25 API starting: port 60975 ([::]:60975)
2021/07/23 20:25:25 [DEBUG] pact provider verification
2021/07/23 20:25:25 [DEBUG] waiting for port 60976 to become available
2021/07/23 20:25:25 [DEBUG] initialising rust verifier interface
2021/07/23 20:25:25 [DEBUG] executing verifier FFI with args [--hostname localhost --port 60976 --state-change-url http://localhost:60976/__setup --broker-url https://pact-broker.staging.enova.com --provider-version 1.0.0 --loglevel trace --consumer-version-tags master]
--- FAIL: TestPactProvider (0.11s)
--- FAIL: TestPactProvider/Provider_pact_verification (0.00s)
http_verifier.go:136: an unknown error ocurred when verifying the provider (this indicates a defect in the framework
user_service_test.go:57:
Error Trace: user_service_test.go:57
Error: Received unexpected error:
an unknown error ocurred when verifying the provider (this indicates a defect in the framework
Test: TestPactProvider
FAIL
FAIL http://github.com/pact-foundation/pact-workshop-go/provider 0.862s
FAIL
make: *** [provider] Error 1```
matt.fellows
2021-07-24 03:01
Looks like you're using the current stable and beta package together - is this intended?
matt.fellows
2021-07-24 03:02
The Terraform example I provided is a legitimate use of the beta package, but yes you can also use the example in the repo
matt.fellows
2021-07-25 08:48
Let us know how you go. There's bound to be bugs so just be aware, but happy for feedback etc
dimundo
2021-07-26 08:23
hi :slightly_smiling_face:
looks like there is a need in #pact-webhook :smile:
is there a way to edit webhook ?
matt.fellows
2021-07-26 08:34
In Pactflow there is a UI, but you can create or update the webhook via API and the CLI tools
saurabh.goel
2021-07-26 09:09
Hi everyone, i am trying to setup the pact broker for the first time using https://github.com/pact-foundation/pact-broker-docker/blob/master/POSTGRESQL.md step.. I keep getting error: psql: error: FATAL: password authentication failed for user "admin". I am using "ThePostgresPassword" at the password prompt.
dimundo
2021-07-26 09:49
``` Note that the URL must be the first
parameter when executing create-or-update-webhook and a uuid must also be provided. You can generate a valid UUID by using the `generate-uuid` command.```
is there any info about `generate-uuid` for existing webhook ?
matt.fellows
2021-07-26 11:24
> Change ThePostgresPassword as required.
>
>
Did you do this? It needs to be the admin password for your postgres database
saurabh.goel
2021-07-26 12:02
yes i kept it same in both the start postgresql and connect to container steps
saurabh.goel
2021-07-26 12:03
for now i did it with the docker-compose example and have the broker up and running. but still if someone knows why this fails. it would be great.
matt.fellows
2021-07-26 12:56
which command is failing? Manually logging in or the broker running or something else?
matt.fellows
2021-07-26 12:57
It might be slightly misleading docs somewhere. But either way, the answer should be fairly clear - somewhere the admin username and/or password is incorrect set when the container starts. Any connections to it (docker or otherwise) need to use the same credentials
saurabh.goel
2021-07-26 13:12
after running this command
```$ docker run -it --link pactbroker-db:postgres --rm postgres sh -c 'exec psql -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U admin'```
it asks for password. on providing it fails with error: psql: error: FATAL: password authentication failed for user "admin"
matt.fellows
2021-07-26 13:32
```docker run -it --link pactbroker-db:postgres --rm -e PGPASSWORD=ThePostgresPassword postgres sh -c 'exec psql -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U admin'```
matt.fellows
2021-07-26 13:33
if it doesn?t, it almost certainly means the container with name `pactbroker-db:postgres` has been incorrectly setup and the password is wrong
dimundo
2021-07-27 09:48
Hello :slightly_smiling_face:
are there options to remove deleted webhook logs?
as for now `class="table-danger"` for passing webhook, because old one had bad url and failed :slightly_smiling_face:
kflo
2021-07-27 18:38
for `pact-broker publish PACT_DIRS_OR_FILES` ? what would the syntax for specifying files look like?
sagupta
2021-07-28 17:12
Hello Team,
i have a question about work in progress pact. I have enabled the work in progress pact in provider verification and used
``` --enable-pending \
--include-wip-pacts-since 2021-07-23```
Now the consumer has published a pact and added new interactions in it and tagged it (say `add-new-interaction`) yesterday which hash triggered provider test job on main branch. Now i have made the changes necessary and tested the provider locally against `add-new-interaction` tag and it passes. However when i now run the provider tests against `master` tag of consumer , io expect that the `add-new-interaction` pact also runs along with it (wip pacts enabled).
But i get this in log of provider test
```DEBUG: This pact is in pending state for this version of <provider_name> because a successful verification result for a version of <provider_name> with tag '' has not yet been published.```
Dont know why tag is `''` ?
sagupta
2021-07-28 17:29
upon reading the logs in the provider tests, the issue is that the pact which is being fetched and verified is the most recent pact from consumer and that has a green verification with provider and i do not expect this pact to be verified. I assume that the pact with tag `add-new-interaction` be verified
bethskurrie
2021-07-28 22:53
@sagupta I've added a heap of debugging in the broker logs to show how the WIP pacts are determined. Can you please update to the very very latest broker version, and set PACT_BROKER_LOG_LEVEL=DEBUG and PACT_BROKER_SQL_LOG_LEVEL=none.
bethskurrie
2021-07-28 22:54
> with tag ''
Is your provider tag really an empty string or null? You need to set a provider tag for this to work properly.
bethskurrie
2021-07-28 22:55
Also, there have been some recent updates to the way the WIP pacts are determined. There was an issue with the ordering of the version creation that has been fixed. You might be seeing that.
aubilla
2021-07-29 09:09
When POSTing a new webhook to the Pact Broker, how does the Broker know what?s the Provider and what?s the Consumer? Or better yet, how do I set those?
:thread:
aubilla
2021-07-29 09:14
I created a couple of webhooks but when I GET https://pact-broker.mydomain.com/pacts/provider/PatientService/consumer/PatientClient/webhooks I don?t see any
sagupta
2021-07-29 10:12
Alright , can you please let me know which pact broker version i need to be on for this to work . I am asking because my OPS team has setup the oss pact broker in our k8s network so i am guessing i need to ask them to set the env variables or is this something that i can pass lets say while calling the `provider verify` script as well
sagupta
2021-07-29 10:31
and yes i am not providing the provider tag as i was testing it locally and dont want to publish the verification results to pact broker
sagupta
2021-07-29 10:32
so i have turned
```PROVIDER_VERSION=
PACT_BROKER_PUBLISH_VERIFICATION_RESULTS=false```
sagupta
2021-07-29 10:42
@dimundo I am also trying to enable the logs to debug a wip pact issue , just wanted to check with you if you were successfully able to set the env vars and get the logs?
Also can you tell me where exactly in pact broker can i see these logs ?
sagupta
2021-07-29 10:51
Right i have put the request to go to latest version, also i have asked them to set both env variables . However @matt.fellows can you let me know where in pact broker can i see these logs for wip pacts
bethskurrie
2021-07-29 10:54
@sagupta you can find out what the latest version of the pact broker docker image by going to https://hub.docker.com/r/pactfoundation/pact-broker
bethskurrie
2021-07-29 10:55
You still need to set the provider tags to test wip locally, even if you turn off the verification publishing.
sagupta
2021-07-29 10:55
Alright since its the ops team in my org that has setup the pact broker. Can you suggest a way how can i get the logs from pact broker to debug the issue with wip pacts
bethskurrie
2021-07-29 10:57
Whoever is responsible in your ops team will understand how to configure the stdout from the container to be sent to a log aggregation tool.
sagupta
2021-07-29 10:59
And regarding
> You still need to set the provider tags to test wip locally, even if you turn off the verification publishing.
Is the provider tag also needed to make the calculation? if so may be thats why i was not seeing the correct pacts pulled from broker
dimundo
2021-07-29 11:07
```# extra env
env:
PACT_BROKER_BASIC_AUTH_USERNAME: "..."
PACT_BROKER_BASIC_AUTH_PASSWORD: "..."
PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME: "..."
PACT_BROKER_BASIC_AUTH_READ_ONLY_PASSWORD: "..."
PACT_BROKER_LOG_LEVEL: "DEBUG"
PACT_BROKER_SQL_LOG_LEVEL: "none"
PACT_BROKER_WEBHOOK_HOST_WHITELIST: ...
PACT_BROKER_WEBHOOK_SCHEME_WHITELIST: "..."```
those two are what you want
sagupta
2021-07-29 11:13
ahh alright. i will check with my ops team to set these env variables and then if possible check the logs there
sagupta
2021-07-29 11:35
@bethskurrie
In the HAL browser , in broker , I have used `https://pact-broker.gp.k8s.<>/pacts/provider/<provider>/for-verification` to check what pacts will be verified for the condition which i had and it returned 3 results to me (which is correct and what i expect)
However when i run the `provider-verify` script , only 2 of those pacts are being verified
aubilla
2021-07-29 13:49
I?m getting a 401 when trying to create a webhook from the CLI:
```> pact-broker create-webhook 'https://gitlab.mydomain.com/api/v4/projects/12/ref/master/trigger/pipeline?token=4bc802278a80c3890933d92335c7cc&variables[PACT_URL]=${pactbroker.pactUrl}' --request=POST --broker-base-url='https://pact-broker.mydomain.com' --contract-content-changed --provider=PatientService --consumer=PatientClient --user=somerealuser:somerealpassword
Error creating webhook. response status=401 body=```
When running with `-v` I get:
```starting SSL for http://pact-broker.mydomain.com:443...
SSL established
<- "POST /webhooks/provider/PatientService/consumer/PatientClient HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nHost: http://pact-broker.mydomain.com\r\nContent-Length: 323\r\n\r\n"
<- "{\"events\":[{\"name\":\"contract_content_changed\"}],\"request\":{\"url\":\"https://gitlab.mydomain.com/api/v4/projects/12/ref/master/trigger/pipeline?token=4bc802278a80c3527933d92335c7bb&variables[PACT_URL]=${pactbroker.pactUrl}\",\"method\":\"POST\",\"headers\":{},\"username\":\"someusername\",\"password\":\"somerealpassword\"}}"
-> "HTTP/1.1 401 Unauthorized\r\n"
-> "content-type: text/plain\r\n"
-> "www-authenticate: Basic realm=\"Restricted area\"\r\n"
-> "content-length: 0\r\n"
-> "x-envoy-upstream-service-time: 1\r\n"
-> "date: Thu, 29 Jul 2021 13:47:23 GMT\r\n"
-> "server: istio-envoy\r\n"
-> "\r\n"
reading 0 bytes...
-> ""
read 0 bytes
Conn keep-alive
Error creating webhook. response status=401 body=```
Is there something wrong in the `--user` argument syntax?
aubilla
2021-07-29 14:26
It worked with `--broker-username somerealusername --broker-password somerealpassword`. I realize my mistake now with -`-user`, which I thought was for Broker credentials :facepalm:
paul.simms
2021-07-29 19:40
Hi,
We have a pact where the provider needs a secret passing in the header for each request. This is stored in vault. Is there a way that this can be handled when publishing a pact to the broker by hiding the secret? Is there a different option between the open source and pact flow? Thanks in advance.
bethskurrie
2021-07-30 03:29
Good suggestion @kflo. Setting the real secret value needs to be done at runtime during verification, rather than being baked into the contract.
sagupta
2021-07-30 07:00
I was able to fix it.I was passing different date in wip-pacts-since flag that?s why one verification was missing
sagupta
2021-07-30 07:01
Also we have updated the broker version to latest but then the color which highlights latest pacts and the green and red fir verification results is broken in this version so it?s getting very difficult to identify pacts there
rafael.anachoreta
2021-08-02 10:27
Hey all, can someone please clarify what `can-i-deploy` does when the `pacticipant` is the *provider*? From reading older messages, I can see the recommendation is to:
> `can-i-deploy` -> deploy your build -> `create-version-tag` # for both provider and consumer
But it?s not too clear to me what `can-i-deploy` does when deploying the provider.
This comment in the code is what made me wonder: https://github.com/pact-foundation/pact_broker/blob/25e62fd9e1df99c4cadf4239c5b0a6ac4705f308/lib/pact_broker/matrix/deployment_status_summary.rb#L96-L116
kflo
2021-08-02 16:30
i believe it ensures the version of the provider being deployed satisfies all of the consumers the provider has (at their latest versions for the environment)
bethskurrie
2021-08-02 23:03
@rafael.anachoreta the consumer may have deployed between the time the provider verification tests ran and when the provider is being deployed. can-i-deploy makes sure that all the necessary verifications are present.
uladzislau_danilchyk
2021-08-03 13:43
Hi everyone!
We are currently trying to follow this job in our Consumer CI with retry options: https://docs.pact.io/pact_broker/webhooks/#consumer-ci
Our provider CI verifies consumer pacts of `prod` tag only (without `develop` tag) and the performed command looks like:
`pact-broker can-i-deploy -b broker_url -a consumer -e consumer_version -a provider -l provider_tag --retry-while-unknown=150 --retry-interval=60`
The most important part of that is `-l provider_tag` .
*Problem*: when consumer contracts are *not changed* (but webhook triggered) and the command `can-i-deploy` in described part of Consumer CI job is waiting for the verification results _(provided by job which is triggered by webhook for contracts content changed)_ against the *latest* provider tag (e.g., develop), the tag is already has another (newest) version of a provider. But at the same time verification is performing for previous (oldest) version. Therefore, `can-i-deploy` doesn't see any verification results for the latest provider develop tag cause this tag constantly updated due to active development.
*Supposed solution:* replace `-l` flag with `--to` which is waiting for any version of a provider tag instead of latest one.
*Question:* is this supposed solution true (we're on a right way) or other solutions can be (please, propose)?
Thanks in advance!
kflo
2021-08-04 00:06
does it matter where you put `--ignore` when using `can-i-deploy`? it seems to be ignoring it (heh) here:
```[Container] 2021/08/03 23:32:13 Running command pact-broker can-i-deploy \
--broker-base-url="$PACT_BROKER_URL" \
--broker-token="$PACT_BROKER_TOKEN" \
--pacticipant="application" \
--version="$BUILD_VERSION" \
--ignore="event.credit.decision" \
--to="master"
Computer says no ¯_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
------------|------------|-----------------------|-----------|----------|--------
application | dddbdba... | disclosure | ??? | ??? |
application | dddbdba... | event.credit.decision | ??? | ??? | ```
we are using the pactflow broker and ruby standalone version `1.88.61`
kflo
2021-08-04 00:19
seems to ignore it no matter where i put it (except of course if i put it between `--pacticipant` and `--version` it will give an error)
bethskurrie
2021-08-04 03:22
```ignore_selectors = if ENV.fetch("PACT_BROKER_FEATURES", "").include?("ignore")
VersionSelectorOptionsParser.call(ARGV).select { |s| s[:ignore] }
else
[]
end```
bethskurrie
2021-08-04 03:29
> Our provider CI verifies consumer pacts of `prod` tag only (without `develop` tag)
bethskurrie
2021-08-04 03:33
> pact-broker can-i-deploy -b broker_url -a consumer -e consumer_version -a provider -l provider_tag
What is the `provider_tag` here? Does it represent an environment or a branch?
bethskurrie
2021-08-04 03:34
The recommended usage of the command is documented here https://docs.pact.io/pact_broker/can_i_deploy/#summary
bethskurrie
2021-08-04 03:35
> consumer contracts are *not changed* (but webhook triggered)
What situation is this? The only way this could happen is if a new tag is applied. Is that what you're talking about?
bethskurrie
2021-08-04 03:37
You seem to be describing some sort of race condition, but I can't work out what the scenario is.
bethskurrie
2021-08-04 03:45
* Consumer publishes pact for consumer version X
* Pact triggers a webhook
* Webhook triggers a verification build on the provider for version N, which is the latest develop version at the time. It will take 5 minutes to finish.
* Can I deploy runs for the consumer version X and the latest develop version of the provider, waiting for a verification result to be published.
* Within the 5 minutes, another commit is made for the provider, with version N+1.
* Because the provider is only verifying the production pact, there is no verification result between consumer version X and provider version N+1
* Can I deploy eventually fails.
bethskurrie
2021-08-04 03:45
Your provider needs to verify the latest develop pact as well as the prod pact.
bethskurrie
2021-08-04 03:47
* Consumer publishes pact for consumer version X
* Pact triggers a webhook
* Webhook triggers a verification build on the provider for version N, which is the latest develop version at the time. It will take 5 minutes to finish.
* Can I deploy runs for the consumer version X and the latest develop version of the provider, waiting for a verification result to be published.
* Within the 5 minutes, another commit is made for the provider, with version N+1.
* The provider verifies the develop and prod pacts, so there is a result between consumer version X and provider version N+1 (the new latest develop).
* Can I deploy eventually passes.
bethskurrie
2021-08-04 03:50
Proposed new feature for comment: 'Move "pacts for verification" configuration into the Pact Broker'
https://github.com/pact-foundation/pact_broker/discussions/479
bethskurrie
2021-08-04 03:50
@phil.endsley was it you who had the jira specified branch names and hence couldn't do direct mapping between the consumer/provider tags?
uladzislau_danilchyk
2021-08-04 08:33
@bethskurrie, hi! Thanks for the answers. The current approach/flow looks like this:
? Consumer PR is created
? Consumer PR CI publishes contracts with branch tag (consumer version X)
? Webhook triggers verification of consumer version X against Provider latest develop tag (version N) in parallel with Consumer PR CI pipeline. Let's assume that it will take 5 minutes to finish.
? At the same time can-i-deploy runs on Consumer PR CI pipeline for that consumer version X and the latest develop of Provider and waiting for verification results to be published.
? Within the 5 minutes, another commit is made to provider develop branch with version N+1 and CI on that branch has started.
? The provider branch CI pipeline verifies the new version of a provider (N+1 - the new provider latest develop) for the contracts tagged as prod. There are verification results only between provider version N+1 and Consumer prod tag (not for tag from custom branch of the created PR).
? Verification build which is triggered by webhook for published contracts (version X) and latest provider develop (version N) was finished and results are published. But provider version N is already old and it's not latest yet. Latest provider develop is N+1.
? Can i deploy still waiting for the provider verification results against latest provider develop tag (but latest is already version N+1, results of which is not being verified against custom branch (consumer version X))
uladzislau_danilchyk
2021-08-04 08:46
> Our provider CI verifies consumer pacts of `prod` tag only (without `develop` tag)
> *Beth (http://pactflow.io/Pact Broker/pact-ruby)* [5:29 AM]
> Can you explain why you're doing that?
Yep. Because verification step is a build-breaker in Provider CI. This means that if I create pull-request in Provider repo, and at the same time new consumer contract will be published for `prod` tag, and new contract will not be implemented yet in provider it will fail build. And to be able to merge provider PR I will need to fulfill contract. It's ok.
But. If we add for this step verification against `prod` and `develop` tags as well, it will cause the issue - every time consumer publishes new contracts for the `develop` tag (*very frequently*) it will block all pull-requests on a Provider side and no one can merge own pull-request until he implement not-fulfilled contracts.
To do not have such situation we decided to have verification (as a build breaker) on a provider side only against `prod` contracts (not against `develop` and `prod`).
kflo
2021-08-04 18:04
hm, i updated to `1.88.62` and the output looks a bit different but `--ignore` still doesn?t seem to be applied
kflo
2021-08-04 18:05
```[Container] 2021/08/04 18:00:34 Running command pact-broker can-i-deploy \
--ignore="event.credit.decision" \
--broker-base-url="$PACT_BROKER_URL" \
--broker-token="$PACT_BROKER_TOKEN" \
--pacticipant="application" \
--version="$BUILD_VERSION" \
--to="master"
Computer says no ¯_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
------------|------------|-----------------------|-----------|----------|--------
application | 57399f2... | disclosure | 0.0.56 | false | 1
application | 57399f2... | event.credit.decision | ??? | ??? |
VERIFICATION RESULTS
--------------------
1. ***/pacts/provider/disclosure/consumer/application/pact-version/c26e7f96df343b2507c1a8e7295955d62b816e82/verification-results/543 (failure)
The verification for the pact between version 57399f2d412adbaf6142b68d80053a0428cfb720 of application and the latest version of disclosure with tag master (0.0.56) failed
There is no verified pact between version 57399f2d412adbaf6142b68d80053a0428cfb720 of application and the latest version of event.credit.decision with tag master (no such version exists)```
(the second failure should be ignored)
kflo
2021-08-04 18:24
but i can confirm that when i set `PACT_BROKER_FEATURES=ignore` in the build, `--ignore` works, so i?m unblocked for now
phil.endsley
2021-08-05 00:30
Yes. I've since changed companies, but I know there's at least one person from my last place that lurks in here on occasion
bethskurrie
2021-08-05 03:20
@kflo please update to the next version of the standalone which should be out shortly.
bethskurrie
2021-08-05 03:21
> Yep. Because verification step is a build-breaker in Provider CI. This means that if I create pull-request in Provider repo, and at the same time new consumer contract will be published for `prod` tag, and new contract will not be implemented yet in provider it will fail build.
@uladzislau_danilchyk the pending pacts feature should fix this problem.
bethskurrie
2021-08-05 03:23
> every time consumer publishes new contracts for the `develop` tag (*very frequently*) it will block all pull-requests on a Provider side
The consumer team needs some training.
bethskurrie
2021-08-05 03:23
Can I recommend that you all do the CI/CD workshop https://docs.pactflow.io/docs/workshops/ci-cd/
bethskurrie
2021-08-05 03:24
Pact rollouts within a company need to be supported by widespread training, otherwise, it tends to end in a mess.
tausif2909
2021-08-05 13:06
Hello, After upgrading pact-broker to `2.80.0` from `2.23.4`
my consumer build start failing while publishing the pacts to
pact-broker, It publishes the first pact fine, but while publishing the second one it throws below error:
tausif2909
2021-08-05 13:07
```[INFO] You have 0 Checkstyle violations.
[INFO]
[INFO] --- pact-jvm-provider-maven:4.0.10:publish (default-cli) @ flex-publishindexer-acceptance-tests ---
Publishing 'flex-publishindexer-service-flex-authentication-service.json' ... HTTP/1.1 200 OK
Publishing 'flex-publishindexer-service-flex-fastobject-service.json' ... [INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 34.221 s
[INFO] Finished at: 2021-08-05T17:07:50+05:30
[INFO] ------------------------------------------------------------------------
[ERROR] Premature end of chunk coded message body: closing chunk expected -> [Help 1]
org.apache.http.ConnectionClosedException: Premature end of chunk coded message body: closing chunk expected
at org.apache.http.impl.io.ChunkedInputStream.getChunkSize (ChunkedInputStream.java:266)
at org.apache.http.impl.io.ChunkedInputStream.nextChunk (ChunkedInputStream.java:225)
at org.apache.http.impl.io.ChunkedInputStream.read (ChunkedInputStream.java:184)
at org.apache.http.conn.EofSensorInputStream.read (EofSensorInputStream.java:135)
at sun.nio.cs.StreamDecoder.readBytes (StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead (StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read (StreamDecoder.java:178)
at java.io.InputStreamReader.read (InputStreamReader.java:184)
at java.io.BufferedReader.read1 (BufferedReader.java:210)
at java.io.BufferedReader.read (BufferedReader.java:286)
at java.io.Reader.read (Reader.java:140)
at kotlin.io.TextStreamsKt.copyTo (ReadWrite.kt:123)
at kotlin.io.TextStreamsKt.copyTo$default (ReadWrite.kt:120)
at kotlin.io.TextStreamsKt.readText (ReadWrite.kt:107)
at au.com.dius.pact.core.pactbroker.HalClient.uploadJson (HalClient.kt:443)
at au.com.dius.pact.core.pactbroker.PactBrokerClient.uploadPactFile (PactBrokerClient.kt:193)
at au.com.dius.pact.provider.maven.PactPublishMojo.execute (PactPublishMojo.kt:77)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke (Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ConnectionClosedException```
dimundo
2021-08-05 13:31
hi!
what is proper way of testing consumer branch against provider
? test against provider's `trunk`
? test agains providers's deployed to `test_env` commit
keeping un mind, that there would be delay between merge to trunk and deploy to env
phil.endsley
2021-08-05 13:40
When you say "testing consumer branch against provider", are you talking about pact verification?
For feature branch development, the process looks something like:
1. Generate and publish new Pact from consumer feature branch
2. Verify pact in provider feature branch
a. This verifies against consumer feature branch, main development branch, and prod (You have to configure what gets verified with consumer version selectors)
3. Merge provider branch
a. CI build will run verifications again. WIP pacts will pick up consumer feature branch
4. Merge consumer branch
dimundo
2021-08-05 13:41
1. Verify pact in provider feature branch
a. This verifies against consumer feature branch, main development branch
brian.mitchell
2021-08-05 18:25
Hello folks, pact-broker question for you,
Background
We are beginning to incorporate separate services outside of our existing monolithic deployment. For our legacy deployment we maintain many versions and as we add additional services we elected to use pact-broker to avoid breaking contracts between our microservices and legacy service. However, due both how we publish pacts and dedpuplication on read, when microservice owners want to change their endpoints in a backwards incompatible way we have found the need to delete hundreds of pacts to be an anti-pattern.
Context and Problem
What we have is a consumer MONOLITHIC_SERVICE and producer NEW_MICROSERVICE. As part of our build process, after merging to master, the MONOLITHIC_SERVICE runs its pact tests and publishes them to pact-broker using the `publish-pact` endpoint. We use the commit sha as the version and tag the pact with the branch name. This leads to having a pact for every CI run (many of them being duplicates).
On the consumer side we are using the `provider-pacts-for-verification` endpoint with the following consumer version selector
```{
"consumerVersionSelectors": [
{
"tag": "all",
"latest": false
}
]
}```
We have a requirement that our microservice must be compatible with all versions of the monolith across all of its supported maintenance branches. On top of this, for each version of our monolith, we often need to make hotfixes. These hotfixes take a while to propagate to customers, so we need to be able to support any arbitrary commit on each version of the monolith, since our customers can be on these versions. Just to be explicit, our single microservice needs to support all of these versions of the monolith, and in order to support this we are using latest=false.
We came to the point where the microservice owners wanted to change their endpoint (say from `/endpoint` to `/api/v1/endpoint`). In order for them to make this change and have `provider-pacts-for-verification` continue to work we will need to remove all of the pacts in pact-broker that refer to the old `/endpoint`. Because pact broker deduplicates on read and not on write to delete an old pact we will need to delete all of the pacts that contain that old endpoint, not just the single pact returned by `provider-pacts-for-verification`. Deleting the pacts is safe because we were able to validate that none of our customers had been using the old `/endpoint`, and they have been upgraded to a version where the endpoint is now `/api/v1/endpoint`
As we began to think about deleting all pacts that matched a certain contract, we began to think it sounded like an anti-pattern, and wanted to reach out to the experts for advice and opinions.
Is there a way around needing to delete all of these pacts, or is there something else that you would recommend changing in our flow?
bethskurrie
2021-08-06 03:24
@brian.mitchell you don't need to delete the pacts, you need to delete the tags.
bethskurrie
2021-08-06 03:24
Is this correct? Do you really have a tag called "all"?
```
{
"consumerVersionSelectors": [
{
"tag": "all",
"latest": false
}
]
}
```
bethskurrie
2021-08-06 03:26
Essentially, you need to tell the broker that those previous versions of the pact no longer need to be supported.
bethskurrie
2021-08-06 03:26
It would be much easier for you to manage if you use the new environments/deployments/releases feature https://docs.pact.io/pact_broker/recording_deployments_and_releases/
bethskurrie
2021-08-06 03:53
Then you can use the `record-support-ended`when you no longer need to support a version.
bethskurrie
2021-08-06 06:52
@tausif2909 can you try running a broker instance locally (you can use docker-compose) and try publishing it there?
bethskurrie
2021-08-06 06:53
You can use this docker-compose file https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose.yml
dimundo
2021-08-06 08:46
hi !
https://docs.pact.io/pact_broker/webhooks/#the-contract-content-changed-event
> One side effect of this is that brand new tags will trigger a pact changed event, even if the content is the same as a previous version.
is there a way to disable this side effect ?
dimundo
2021-08-06 09:51
as if there is same pact as verified before, there is no point to re-verify it
dimundo
2021-08-06 10:11
this only makes unneeded runs of ci/cd resources, makes holes in a budget, burns coal/gas/sun to produce electricity and so on :)
tausif2909
2021-08-06 11:52
It worked with local setup, means that was not an upgrade issue.. I have reported to our ops team to fix that. Thanks @bethskurrie
bryanw
2021-08-06 14:54
I noticed that in pact-broker when configured for basic auth, but setting PACT_BROKER_ALLOW_PUBLIC_READ, the HAL browser is exposing the tokens used in the webhook via the URL. These tokens are considered secret, is there a way to restrict access to the webhooks visibility in this configuration?
matt.fellows
2021-08-06 22:05
I think there is some crude detection of secrets in certain places but not HAL
matt.fellows
2021-08-06 22:06
Don't forget HAL is just a UI over the APIs, so anything visible there may be visible in the API
bethskurrie
2021-08-06 22:29
@bryanw no, there's no code to hide that, sorry. That's why there is Secrets support in Pactflow.
bethskurrie
2021-08-06 22:31
@dimundo this feature is about to be released https://github.com/pact-foundation/pact_broker/pull/476
bethskurrie
2021-08-06 22:32
You'll need to be using this for it to work properly https://docs.pact.io/pact_broker/recording_deployments_and_releases/
matt.fellows
2021-08-07 01:04
What I've seen other people do is restrict access to sensitive APIs/paths via ingress controllers/reverse proxies etc
bethskurrie
2021-08-07 03:46
You can also gate the build with this command https://github.com/pact-foundation/pact_broker-client/blob/master/lib/pact_broker/client/cli/matrix_commands.rb#L43
bethskurrie
2021-08-07 03:46
I'm just beta testing it myself for a while, you'll need to feature toggle it on.
bethskurrie
2021-08-07 20:11
People tend to use the OSS broker within their company's internal network, so its not accessible to anyone outside the company at all.
timo
2021-08-09 10:56
Hi Beth, coming back to my original problem, we couldn't come up with any solution here unfortunately. Running `can-i-deploy --to master` nor `--to prod` works. For feature branches, can-i-deploy always includes some pacts where our payments-service is the provider and it won't find any with that version and the tag `prod` nor `master`, because (obviously) this in running on a feature branch.
But this really only happens for pacts where the payments-service is both a consumer AND a provider for the exact same service.
brian.mitchell
2021-08-09 12:12
Thanks for your response
The reason we use all is because we don?t have strong control of what versions customers will be on. We have a business need to support the eight latest versions of our product and choosing to upgrade is generally left up to the customer. Because we support these eight oldest versions, if a change has to be made to an older version of our product (say a security related issue, or bugfix), then that gets ?hotfixed? to one of the older branches and updates to that version are released on a regular basis. Due to giving customers control over their upgrades there could be a situation where Customer 1 is on *v1 - commit aaaaaa* and Customer 2 is on *v2 - commit bbbbbb.* Customers could even be on different commits on the same version of our product, ie Customer 1 on *v1 - commit* cccccc and Customer 2 on *v1 - commit ddddd.* Because of this our tagging strategy is as follows: every published pact is tagged with *all* and it?s version (*v1, v2?*). Then during provider verification we verify against pacts with the all tag and latest=false. When we release a new version of our product (say *v9*) we are able to stop supporting a version (*v1*) and now can use pact-broker to delete all pacts with the tag *v1*. As we get better about CD and are able to control when customers upgrade then I think using the environments/deployments feature would make a lot of sense.
bryanw
2021-08-09 18:41
Yeah, it's totally internal - just don't like seeing those secrets exposed. Pactflow (on-prem) will probably be in our future.
bethskurrie
2021-08-10 04:37
Being able to mark when you're dropping support for something is much easier than having to delete a bunch of pacts.
bethskurrie
2021-08-10 04:38
I've written some docs on migrating here: https://docs.pact.io/pact_broker/recording_deployments_and_releases/#why-migrate
bethskurrie
2021-08-10 04:40
@timo the only suggestion I have is to call the can-i-deploy endpoint with --dry-run --output json and parse the results yourself
timo
2021-08-10 07:04
we are actually doing this already, just that we then cannot use the timeout flag but do the polling ourselves, because then it always runs into the max timeout unnecessarily - not a big deal but makes the CI/CD pipelines more complicated. I wonder if we are the only ones with that problem? I don't see any special setup (except that we have that bi-directional communication between 2 services), should this maybe be a general feature so other's can also benefit from it?
aubilla
2021-08-10 09:28
Given the following workflow:
1. Consumer Pipeline generates a contract_content_changed event ->
2. Webhook triggers Provider verification ->
3. provider_verificiation_published event is fired ->
4. webhook triggers Consumer Pipeline
Is this the intended workflow or in Step 4 I should only execute Can-I-Deploy for the Consumer in question?
My question comes from the fact that I?m running the Consumer Pipeline twice and it doesn?t look right.
bethskurrie
2021-08-11 09:20
It depends if you're talking about a feature branch or your main branch. The first time you make a change, it should be on a feature branch, and can I deploy will correctly fail.
bethskurrie
2021-08-11 09:22
I tend not to deploy the consumer on the return webhook, I just have the webhook update the git commit status, so the PR checks go green.
bethskurrie
2021-08-11 09:22
Then, merge the consumer to master. The pact should already be pre-verified by this stage, so can I deploy will pass and you can deploy from main.
bethskurrie
2021-08-11 09:24
you can make it poll for the verification result to come back, but that's only really useful for making changes you know will pass.
subhashnarla
2021-08-11 14:03
i have a webhook that monitors for pact contract...and when its added to github, a webhook triggers http://pactflow.io
matt.fellows
2021-08-11 22:15
i?m also confused. You say it monitors pact content and when uploaded to github? You would normally upload the contract to Pactflow, and it may fire a webhook to, say, trigger a provider build
2021-08-11 22:15
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
bethskurrie
2021-08-12 01:01
@aubilla doing the CI/CD workshop will help you a lot https://docs.pactflow.io/docs/workshops/ci-cd
abubics
2021-08-12 01:45
Little OSS docker container question - does `PACT_BROKER_BASE_URL` support mounting the app at a subpath (e.g. `<...>:9292/pact-broker` )? We're getting the html content, but all other resources (css, js) are getting 404 responses :thinking_face:
bethskurrie
2021-08-12 01:47
> This can also be used if you are mounting the Docker container so that it runs on a non root context eg. `https://my-company.com/pact-broker`. Not that this setting does not change where the application is mounted within the Docker container - it just changes the links.
bethskurrie
2021-08-12 01:47
where it is actually mounted is not in the broker or docker image config at all.
bethskurrie
2021-08-12 01:49
if you find you're getting funny responses for tags that have slashes in them
abubics
2021-08-12 01:50
lovely, cheers :ok_hand: when all else fails, it was probably user error in the first place ;D
abubics
2021-08-12 02:11
Aside: probably not a big issue, but 2 resources failed to load (`arrow-switch.svg` and `kebab-horizontal.svg`), they're both missing the path extension from their request URLs (the `pact-broker/` bit). I may consider writing a PR for that if I get some time :innocent:
bethskurrie
2021-08-12 07:14
@abubics
```span.sort-icon {
background-image: url('/images/arrow-switch.svg');
background-repeat: no-repeat;
display:inline-block;
position: relative;
width: 16px;
height: 16px;
cursor: pointer;
transform: rotate(90deg);
}```
bethskurrie
2021-08-12 07:19
I think you have a highly unconventional set up. There seems to be a missing verification somewhere, but I'm afraid I don't have the time right now to go back through your set up to identify where it is.
dimundo
2021-08-12 21:40
Hi!
i have in broker logs `Cannot determine main branch for pacticipant Foo`
i found https://github.com/pact-foundation/pact_broker/discussions/400 - do i get it right , i must `create-or-update-pacticipant --name Foo --main-branch "master"` ? (but looks like this is not released/enabled, as even having `Pacticipant "Foo" updated in the Pact Broker` mainBranch is not there)
bethskurrie
2021-08-12 23:25
It's partially supported, but there are a few critical things that have to be done. You can ignore those logs.
bethskurrie
2021-08-13 00:01
You can see the outstanding work here https://github.com/pact-foundation/pact_broker/projects/1
dimundo
2021-08-13 05:52
hi!
i?ve enabled cleaning ( for testing with dry run) in pact broker, but have nothing in logs after expected time :disappointed: ( also, could be nice to have api, which starts clean process maybe? yes there is external options, but still)
```2021-08-13 00:27:34
2021-08-12 21:27:33.417149 I [9:69970236480000] pact-broker -- PACT_BROKER_DATABASE_CLEAN_OVERWRITTEN_DATA_MAX_AGE=7
2021-08-13 00:27:34
2021-08-12 21:27:33.417144 I [9:69970236480000] pact-broker -- PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS=[{"latest": true, "tag": true}, {"max_age": 30}, {"tag": "cit1"}, {"tag": "demo1"}, {"tag": "uat1"}, {"tag": "live1"}]
2021-08-13 00:27:34
2021-08-12 21:27:33.417140 I [9:69970236480000] pact-broker -- PACT_BROKER_DATABASE_CLEAN_ENABLED=true
2021-08-13 00:27:34
2021-08-12 21:27:33.417136 I [9:69970236480000] pact-broker -- PACT_BROKER_DATABASE_CLEAN_DRY_RUN=true
2021-08-13 00:27:34
2021-08-12 21:27:33.417132 I [9:69970236480000] pact-broker -- PACT_BROKER_DATABASE_CLEAN_DELETION_LIMIT=500
2021-08-13 00:27:34
2021-08-12 21:27:33.417127 I [9:69970236480000] pact-broker -- PACT_BROKER_DATABASE_CLEAN_CRON_SCHEDULE=0 2 15 * *```
bethskurrie
2021-08-13 05:54
that would require putting "administrator" authentication on the endpoint, and that concept isn't currently supported by the OSS Broker, so it's not a piece of work that I've picked up yet.
dimundo
2021-08-13 05:57
its 2:15UTC or 5:15 local time
from logs there is nothing between ( also LOKI has 2 timestamps, luckily :slightly_smiling_face: )
```2021-08-13 06:55:09
2021-08-13 03:55:09.762317 I [9:puma threadpool 001] pact-broker -- Fetching pacts for verification by CommonAPI -- {:provider_name=>"CommonAPI", :params=>{"consumerVersionSelectors"=>[{"latest"=>true, "tag"=>"cit1"}, {"latest"=>true, "tag"=>"uat1"}, {"latest"=>true, "tag"=>"demo1"}, {"latest"=>true, "tag"=>"live1"}], "includePendingStatus"=>true, "includeWipPactsSince"=>"2021-08-06T04:55:09+01:00", "providerVersionTags"=>["bugfix/B...."]}}
2021-08-13 02:03:14
2021-08-12 23:03:14.852870 I [9:puma threadpool 001] pact-broker -- Querying matrix -- {:selectors=>[{:pacticipant_name=>"B...API", :pacticipant_version_number=>"6e7170e0"}], :options=>{:latestby=>"cvp", :limit=>"100", :latest=>true, :tag=>"cit1", :ignore_selectors=>[]}}```
dimundo
2021-08-13 06:11
and log appeared
```2021-08-13 09:10:02 2021-08-13 06:10:00.997594 I [23:70316201982460] pact-broker -- [DRY RUN] Deleting oldest 500 versions, keeping versions that match the configured selectors -- [{:latest=>true, :tag=>true}, {:max_age=>30}, {:tag=>"cit1"}, {:tag=>"demo1"}, {:tag=>"uat1"}, {:tag=>"live1"}]
2021-08-13 09:10:02 2021-08-13 06:10:02.183579 I [23:70316201982460] pact-broker -- Results (1 seconds) -- {"counts"=>{"totalVersions"=>6224, "versionsToDelete"=>272, "versionsNotToKeep"=>272,```
dimundo
2021-08-13 06:16
looks like default one is not so ok
https://crontab.guru/#0_2_15_*_*
and from docs it must be
https://crontab.guru/#15_2_*_*_*
and my changes in helm ( so i havent set previous value )
dimundo
2021-08-13 09:40
no luck
> remote: Permission to pact-foundation/pact-broker-docker.git denied to dimkin-eu.
kyle.florence
2021-08-13 18:02
you will need to fork to your own repository and issue a pull request @dimundo
kyle.florence
2021-08-13 18:36
see, not so hard :smile: you will need to update your commit message to conform to semantic pull request guidelines, like `fix: update default cron schedule`
kyle.florence
2021-08-13 18:37
easiest way is to `git commit --amend` your previous commit and force push it when done
github2
2021-08-14 06:03
[pact-foundation/pact_broker] New release _https://github.com/pact-foundation/pact_broker/releases/tag/v2.82.0_ published by github-actions[bot]
matt.fellows
2021-08-16 00:27
Brian - is this question you? https://stackoverflow.com/questions/68776438/pact-verifier-cli-not-honoring-consumer-version-selectors
If you can share the verbose logs here (or DM) that will help us diagnose
aubilla
2021-08-16 12:27
:question: Can the Pact Broker test services with endpoints that contain a path?
:exclamation: My Consumer Pact defines the `/api/pmi/graphql` path
```@Pact(consumer = "PatientClient")
public RequestResponsePact findPatientById(PactDslWithProvider builder) {
return builder
.given("patients exist")
.uponReceiving("get patient by id")
.path("/api/pmi/graphql")
.method("POST")
.body(new PactDslJsonBody().stringType("query","{ findPatientById (id: 200016409) { id gender userRef } } "))
.willRespondWith()
.status(200)
.body(
new PactDslJsonBody()
.object("data")
.object("findPatientById")
.integerType("id", 200016409)
.stringType("gender", "M")
.stringType("userRef", null)
.integerType("testing", 123)
.close()
.asBody()
)
.toPact();
}```
:large_green_circle: This was working when my Provider host URL was formed like this:
*http://master.staging.mydomain.com/api/pmi/graphql*
:red_circle: But after a migration to a new environment, the URL has been changed to this other format:
*https://staging.mydomain.com/master/api/pmi/graphql*
and it doesn?t work. I get 404 when verifying against the deployed Provider. Now the branch name is not part of the domain but of the path. I wonder how the Broker is building the URL and if that could be the root cause of the issue.
The service in question is reachable from Postman requests and I?m echoing the URL every time to make sure the 404 doesn?t come from having specified the wrong URL.
For now I?m trying to grab the logs from the CI and see if I can see the full request.
matt.fellows
2021-08-16 12:37
I?m confused about the question. Your consumer Pact doesn?t have the `/master` prefix - how does Pact know about the prefix when doing the verification?
matt.fellows
2021-08-16 12:37
Are you asking if you can add a path to the provider verification itself? (i.e. set the provider base path, not just the host?)
aubilla
2021-08-16 13:10
The entire URL (including the `/master` prefix) is available via an environment variable in the CI/CD pipeline.
matt.fellows
2021-08-16 13:11
it simply reads the pact file, takes the path, and sends it to the provider
matt.fellows
2021-08-16 13:15
but, the consumer should really update the path there - otherwise you?re breaking the contract!
aubilla
2021-08-16 13:20
The thing is we used to have the following set of hosts for each branch:
http://master.staging.mydomain.com
http://feature-branch-1.staging.mydomain.com
http://bugfix-branch-2.staging.mydomain.com
and now that looks like this:
http://staging.mydomain.com/master
http://staging.mydomain.com/feature-branch-1
http://staging.mydomain.com/bugfix-branch-2
aubilla
2021-08-16 13:22
Instead of having a host/domain per deployed feature branch, we now have a path (in the same host/domain) for each deployed feature branch.
aubilla
2021-08-16 13:27
I understand that since all paths belong to the same host, this approach is conceptually wrong. Host should be 1:1 related to a domain.
matt.fellows
2021-08-16 13:28
I?d work around it for now by using the request filter to inject the base path into the request
aubilla
2021-08-16 13:29
Thanks for the tip :thumbsup: I?ll do that for the time being.
Should I open an issue in Github for the feature request?
aubilla
2021-08-16 13:30
I thought the plugin would take any URL and set that as host, but there must be some parsing somewhere that doesn?t take paths.
matt.fellows
2021-08-16 22:36
> I thought the plugin would take any URL and set that as host, but there must be some parsing somewhere that doesn?t take paths.
well, a host is a host (e.g. a _hostname_ not a base URL) so that doesn?t surprise me
matt.fellows
2021-08-16 22:36
TL;DR - need the ability to set the base path on a provider verification (test environment has a path prefix on it that?s not present in prod)
aubilla
2021-08-17 10:59
Thank you both. Now I?m trimming the path from the URL before assigning it to `host` and also setting the `path` separately using another environment variable.
dimundo
2021-08-17 15:21
Hi!
If one wants to use `WIP` feature, is `pending` pacts must be on?
like with `can-i-deploy` one can be sure, that consumer can be deployed only with ready and deployed provider ( and will not stop provider deployments )
dimundo
2021-08-17 16:00
maybe there is some inside behind this
https://github.com/pact-foundation/pact-jvm/issues/1131#issuecomment-649422153
bethskurrie
2021-08-17 22:25
@dimundo you could turn pending off and use WIP, but then all the WIP pacts would fail your build.
bethskurrie
2021-08-17 22:29
I've made an issue to disallow this combination https://github.com/pact-foundation/pact_broker/issues/489
kyle.florence
2021-08-17 22:30
do you think it would be better to just enable pending if WIP pacts are enabled?
bethskurrie
2021-08-17 22:33
We're actually going to be turning on pending by default as soon as I get around to raising an issue in each of the client libraries.
bethskurrie
2021-08-17 22:33
Now we've proved that it works, it's a much more user friendly default. I can't think of a good reason to ever have it turned off now.
philipchardwick
2021-08-19 08:27
Hey, If I'm running the pact broker clean as a separate process (I have a k8s cron job doing it), and I'm using this on a database for the first time (>200000 verifications) do I still need to take the slowly approach, e.g. 100 deletions every couple of minutes, because the load on the database is significant from the clean up job, or, because it's a separate process can I ramp it up to deleting thousands at a time?
matt.fellows
2021-08-19 08:38
I?d probably just try and do it when it?s not very busy (i.e. early in the day, or after the day ends). But that?s just a complete generalisation on my part.
paulorochag
2021-08-19 13:11
Hello people,
A few hours ago version 0.50.0.1 of docker pact-cli was published and I started to face a problem when using 'publish' as the screenshot below.
Using version 0.47.1.0 the problem does not occur.
bethskurrie
2021-08-19 22:55
You can raise it here https://github.com/pact-foundation/pact-ruby-cli/issues
bethskurrie
2021-08-19 23:00
I changed the base image from alpine 3:12 to just 3, but git is still installed https://github.com/pact-foundation/pact-ruby-cli/blob/master/Dockerfile#L24 :thinking_face:
bethskurrie
2021-08-20 01:59
```$ docker run --rm -w ${PWD} -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL -e PACT_BROKER_USERNAME -e PACT_BROKER_PASSWORD -e PACT_BROKER_TOKEN pactfoundation/pact-cli:0.50.0.1 publish ${PWD}/example/pacts --consumer-app-version fake-git-sha-for-demo-$(date +%s) --tag-with-git-branch
Tagged version fake-git-sha-for-demo-1629424657 of docker-example-consumer as "master"
Publishing docker-example-consumer/docker-example-provider pact to pact broker at https://test.pact.dius.com.au
The latest version of this pact can be accessed at the following URL:
https://test.pact.dius.com.au/pacts/provider/docker-example-provider/consumer/docker-example-consumer/latest```
paulorochag
2021-08-20 11:55
I tried to simulate in an open source project and I couldn't reproduce the error :confused:
If I can get more information, I'll let you know.
jackbwheatley
2021-08-20 14:54
My org might finally be updating the version we use of the pact-broker from `2.20.0` to the latest release. Is everything going to crash and burn or is the latest version backwards compatible with such an old version?
tlzhou
2021-08-20 15:11
Hi, Is there a way for "can-i-deploy" to do validation against only my application's consumers and NOT against its providers?
p0deje
2021-08-20 15:32
Hello Pact team!
I?d like to ask if could potentially merge PR which allows to create/run webhooks using regular expressions for consumer/provider name. Currently webhooks can be run either:
? for exact consumer-provider pair
? for all the consumers of exact provider (or vice versa)
In our work, we?ve found a need to trigger webhooks for _some_ of the consumers of the provider (and vice versa). In our case all of them match a particular naming convention so we thought about using regexp-based webhooks.
To demonstrate, we would like to automatically run schema validation of Kafka messages whenever any contract using Kafka is changed. We have plenty of those but all are named with `(async)` suffix:
? Consumer 1 - Provider 1 (async)
? Consumer 1 - Provider 2 (async)
? Consumer 2 - Provider 1 (async)
? Consumer 2 - Provider 2 (async)
Instead of creating multiple webhooks, we thought it would be great to create just 1:
```$ pact-broker create-webhook $SCHEMA_VALIDATION_URL --provider "/^.+ \(async\)$/" --contract-content-changed```
This way we would ensure that whenever a new provider with Kafka is added, we won?t have to add new webhooks.
We are eager to implement this and send PR the the Pact-Broker, but wanted to make sure this will be merged before working on it.
p0deje
2021-08-20 16:11
I think the only way would be to manually fetch all the consumers from the Pact Broker and pass them explicitly as --pacticipant
abatan.k
2021-08-21 01:22
Hello, i have the following problem in my ci/cd pipeline on Github Action:
```Run yarn test:contract
yarn run v1.22.11
warning package.json: No license field
$ jest test/contract --testTimeout 30000
[2021-08-21 01:15:30.763 +0000] INFO (2068 on fv-az154-374): pact@9.16.0: Verifying provider
[2021-08-21 01:15:30.771 +0000] INFO (2068 on fv-az154-374): pact-node@10.13.3: Verifying Pacts.
[2021-08-21 01:15:30.772 +0000] INFO (2068 on fv-az154-374): pact-node@10.13.3: Verifying Pact Files
FAIL Contract test/contract/fetch-metadata.spec.ts (5.88 s)
Pact Verification
? should validate the expectations of Consumer (874 ms)
? Pact Verification ? should validate the expectations of Consumer
/home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/ruby/lib/ruby/gems/2.2.0/gems/bundler-1.9.9/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /home/runner in PATH, mode 040777
/home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/hal/http_client.rb:38:in `create_request'
: undefined method `request_uri' for #<URI::Generic undefined> (NoMethodError)
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/hal/http_client.rb:24:in `get'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/hal/link.rb:49:in `get'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:53:in `index'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:38:in `call'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/pact_broker/fetch_pact_uris_for_verification.rb:34:in `call'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-1.57.0/lib/pact/pact_broker.rb:18:in `fetch_pact_uris_for_verification'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:45:in `pacts_for_verification'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:38:in `pacts_urls_from_broker'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:25:in `call'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/aggregate_pact_configs.rb:10:in `call'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/app.rb:206:in `all_pact_urls'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/app.rb:219:in `warn_empty_pact_set'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/app.rb:39:in `call'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/app.rb:34:in `call'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/cli/verify.rb:48:in `verify'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/thor-1.1.0/lib/thor/command.rb:27:in `run'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/thor-1.1.0/lib/thor/invocation.rb:127:in `invoke_command'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/thor-1.1.0/lib/thor.rb:392:in `dispatch'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/thor-1.1.0/lib/thor/base.rb:485:in `start'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/vendor/ruby/2.2.0/gems/pact-provider-verifier-1.35.1/lib/pact/provider_verifier/cli/custom_thor.rb:17:in `start'
from /home/runner/work/kansu/kansu/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.63/pact/lib/app/pact-provider-verifier.rb:33:in `<main>'
at ChildProcess.<anonymous> (node_modules/@pact-foundation/pact-node/src/verifier.ts:272:58)
Test Suites: 1 failed, 1 total
Tests: 1 failed, 1 total
Snapshots: 0 total
Time: 5.96 s
Ran all test suites matching /test\/contract/i.
[2021-08-21 01:15:31.628 +0000] WARN (2068 on fv-az154-374): pact-node@10.13.3: Pact exited with code 1.
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
Error: Process completed with exit code 1.```
Is anyone getting the same error at some point ?? (Im verifying the provider side of the contract)
The tests are passing in local :slightly_smiling_face:
matt.fellows
2021-08-21 01:30
It looks like a URL is invalid, but hard to tell without seeing your configuration. Can you please enable debug/verbose logging and share (reacting any credentials)?
matt.fellows
2021-08-21 01:31
If it works locally but not on CI that's a good indication of a configuration issue between your local and CI
abatan.k
2021-08-21 01:36
when you're saying that URL is invalid, which ones ? pact broker url ? my local server for testing provider in Jest ?
matt.fellows
2021-08-21 02:00
The core maintainer is away this week so it could be a week or so before you get a response. It sounds ok to me tho
matt.fellows
2021-08-21 02:01
The use case sounds fascinating tho, I'm guessing you're not using the usual flow. Can you elaborate on it?
matt.fellows
2021-08-21 02:02
I've been thinking a lot more on event based systems and how pact could support it better
abatan.k
2021-08-21 02:02
well the env variable `CI` don't seems to work with github action :sweat_smile:
abatan.k
2021-08-21 02:29
Ok i got it working, here is the full log @matt.fellows :slightly_smiling_face:
p0deje
2021-08-21 02:48
Not exactly the replacement. We don?t have schema registry. We use JSON-based schemas and have a separate Ruby gem that can validate the messages against the schema. We also have contract tests for the messages too. So we thought it makes sense not to validate messages on every commit, but only when they change (i.e. contract is changed). Pact-Broker basically orchestrates the CI job in this case.
2021-08-21 04:16
See this page on the steps to creating an effective contract-testing setup https://docs.pact.io/pact_nirvana. (This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/)
abatan.k
2021-08-21 14:05
OK, i'll do the workshop , an hope it helps me out :) But i don't understand why i see a 503 service unvailable in CI and local env
abatan.k
2021-08-22 01:19
After following the CI/CD workshop, it works !!! I love pact :heart_eyes: , best tool to validate api contract between services, im gonna evangelize this tool to my friends :rolling_on_the_floor_laughing: Thx for your time @matt.fellows and you r support :slightly_smiling_face:
abatan.k
2021-08-22 01:49
well, i just followed the CI/CD workshop by using the pact-broker from node_modules instead of the example with the Makefile and the docker image, and it worked ^^
abatan.k
2021-08-22 01:50
So i cannot tell you why i got this error, i suppose that when Pact cannot validate or find a pact, it throws some error :man-shrugging:
aubilla
2021-08-23 12:03
I want to send back a verification status to a Consumer Merge Request using the commit sha. https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks/ that you support Github via `pactbroker.githubVerificationStatus` and the same for Bitbucket with `pactbroker.bitbucketVerificationStatus` Is there support for Gitlab?s statuses?
satish.chandra
2021-08-23 12:50
Hi guys, I am checking pact broker docs. It mentions the concept of branches and environment tagging for pacts, but when triggering a webhook only tags and label placeholders are exposed. I wanted to understand is there a way of getting branch names in webhook triggers.
Use case: -
I want to run `develop` publisher pipeline if contracts are published in anything except master branch (For supporting CD).
Once the changes have been merged into master, I want to trigger the `master` pipeline.
I can do it via tags, but just curious if there is any better method.
tjones
2021-08-23 14:15
I'll let a broker developer comment, but I think the idea is that tags will be replaced with the branch - since usually people were tagging with the branch name anyway
tjones
2021-08-23 14:16
there aren't a lot of use cases for tagging with anything other than a branch or environment
matt.fellows
2021-08-24 00:16
That environments/branches work is still in progress, so I suspect it is coming soon
matt.fellows
2021-08-24 00:17
Do you know what it might need / or what makes it different to the others?
matt.fellows
2021-08-24 00:18
If you know what you need, please raise a feature request at http://pact.canny.io and we can take a look
aubilla
2021-08-24 07:53
statuses are slightly different between the 3 CIs, I?ll raise a feature request :+1:
aubilla
2021-08-24 08:08
Feature request here: https://pact.canny.io/feature-requests/p/gitlab-commit-statuses-support
satish.chandra
2021-08-24 09:42
Okay so I will work with tag for the time being. Thank you for the prompt reply.
One issue I have noticed is the number of entities have grown a lot in pact ( labels, versions, enviroment, branches etc) but a proper explanation has not been written (so far). I had to glean info from various command line flags.
A bit of document would be greatly appreciated.
matt.fellows
2021-08-24 11:10
The main docs for the broker integration are here e.g. tagging: https://docs.pact.io/pact_broker/tags
matt.fellows
2021-08-24 11:11
Recording deployments/releases: https://docs.pact.io/pact_broker/recording_deployments_and_releases
matt.fellows
2021-08-24 11:12
Environments/branches is not yet fully supported everywhere (but is via the CLI, so perhaps that could do with a better explanation)
uladzislau_danilchyk
2021-08-25 10:42
Hi all! Could anyone tell me how is it possible?
There is a version 1.0.0-qwerty with specified contracts with pact content hash (e.g. 1000)
After rerunning pact tests with publishing for the same version pact content hash changed to (2000) but tags, version are the same.
Revision number (from 1 to 2) was already changed along with pact content hash.
How is it possible? Why the revision number/pact content hash has changed?
matt.fellows
2021-08-25 10:50
I?m not sure about the other details, but you should definitely not publish a new contract for the same consumer version.
matt.fellows
2021-08-25 10:51
from https://docs.pact.io/getting_started/versioning_in_the_pact_broker:
> If you need to republish a pact for an existing consumer version as the latest pact, you need to delete the existing consumer version resource first. This would delete all the pacts associated with that consumer version. If you are following the guidelines for pacticipant version numbers however, this situation would not generally arise.
uladzislau_danilchyk
2021-08-25 10:58
Even if I publish the same contracts for the same consumer version
matt.fellows
2021-08-25 11:00
possibly, but if the contract is the same it should be pre validated (i.e. the hash is the same)
matt.fellows
2021-08-25 11:02
It?s possible that if you are using matchers but aren?t supplying default values, the framework may generate random ones - that will be enough to invalidate the contract
uladzislau_danilchyk
2021-08-25 11:02
how to see diff between single consumer version but two different hashes?
matt.fellows
2021-08-25 11:02
I?m not sure off the top of my head, there is a diff relation in the HAL browser that you might be able to check against the previous revision
uladzislau_danilchyk
2021-08-25 11:03
I can't find. I just found to see diff between two different consumer versions instead
uladzislau_danilchyk
2021-08-25 11:17
Is it possible to delete specific revision for the single version?
uladzislau_danilchyk
2021-08-25 11:28
And is it true that contract content hash changed in case of changing pact tests order run? I didn't see this note in docs
uladzislau_danilchyk
2021-08-25 11:29
Cause the pact content is the same. Do we need aware of contract tests run ordering?
matt.fellows
2021-08-26 04:36
> No, the pact content should not change if the order of the tests has changed
I think that was a thing once upon a time, but I believe most languages now ensure a consistent serialisation mechanism to prevent that
uladzislau_danilchyk
2021-08-26 10:32
So the question is still valid. Why the revision has changed if the code base (contracts) are not changed along with tags, consumer version number
uladzislau_danilchyk
2021-08-26 12:27
but pact revision has changed. I don't understand how it's possible. There is publishing contracts from our side. And the contracts are published twice
lankala321
2021-08-26 21:23
How can we deploy pact broker on AWS. Is there any specific documentation?
mike.geeves064
2021-08-26 21:54
Do you have a database on AWS already? That's probably the "most complicated" part. We were using Aurora PostgreSQL, so it was just a case of pointing it there, and using the docker image: https://github.com/pact-foundation/pact-broker-docker
The rest of the setup in AWS would depend on how else you are doing things there to run containers. For us, we were deploying to a kubernetes cluster. ECS etc should all be fine too.
mike.geeves064
2021-08-26 22:00
(nothing especially complicated as such with PostgreSQL, just the question of what approach for running it, Aurora/RDS/managing yourself, as that can be comparatively quite costly, especially if your only usage is very lightweight from pact-broker, for example... so managing yourself might be a lot cheaper, but more to think about)
tjones
2021-08-27 01:31
It's possible that the pact broker is generating new revisions if you publish the same contract again. I know you get a warning when you publish twice.
uladzislau_danilchyk
2021-08-27 07:34
framework - gradle dependency for Java: au.com.dius.pact.consumer:groovy:4.1.19
dimundo
2021-08-27 10:54
Hi! long time no see funny questions :slightly_smiling_face:
how to rename provider - simple as is ? :slightly_smiling_face:
`consumerA` has contract with `providerB`
after some refactor `providerB` was split to `providerB` and `providerC` and `consumerA` has nothing for `providerB` now
for human being its simple, but for broker, its just a new pact `consumerA` : `providerC` and `consumerA` :`providerB` is kinda abandoned
but now when `providerB` tests are running ( for other consumer ), broker still asks for `consumerA` :`providerB` compatibility :disappointed:
bethskurrie
2021-08-30 21:16
If there is no production relationship between the two, then yes, you you can delete it.
bethskurrie
2021-08-30 21:17
It's going to keep returning the latest pact, even if that latest pact isn't used by anything @dimundo
bethskurrie
2021-08-30 21:19
I think it's because it returns the latest pact that has the prod tag, rather than the pact for the latest version with the prod tag, if that makes sense.
bethskurrie
2021-08-30 21:22
And the problem is that there is a later version of the consumer that does not actually have a pact with the provider any more?
bethskurrie
2021-08-30 21:23
Yeah, I know why it's doing that. I know how to fix it, but it'll take a bit of work.
bethskurrie
2021-08-30 21:23
I take it it's failing the build because you no longer support that pact?
bethskurrie
2021-08-30 21:24
You could explicitly specify the consumers in the consumer version selectors
dimundo
2021-08-30 21:25
now they are added automagically, but this workaround could bring more hassle
dimundo
2021-08-30 21:26
so, in short - for now everything is fine, and we will be warned on next refactor :slightly_smiling_face:
dimundo
2021-08-30 21:27
> You could remove all the test tags
i thought also about this. probably nicer solution, but again - must be done more carefully
bethskurrie
2021-08-30 21:28
The fix is, to return the pact for the latest version with the tag, not the latest version with the tag that also has a pact.
bethskurrie
2021-08-30 21:29
Currently /latest pact never returns a 404. This change would make it return a 404.
bethskurrie
2021-08-30 21:29
I've always debated the logic used, but nobody has ever raised an issue. You're the first in 8 years :wink:
dimundo
2021-08-30 21:37
> ~The fix is, to return the pact for the latest version with the tag, not the latest version with the tag that also has a pact.~
~would this block provider to be deployed?~
? ~consumerAB has tag `test`~
bethskurrie
2021-08-30 21:39
So, you could ignore all the failures from the verification task and rely on can I deploy.
dimundo
2021-08-30 21:40
looks like there must be backward-compatible things to be done
+ wip pacts :smile:
bethskurrie
2021-08-30 21:42
@lankala321 these aren't aws specific, but you can use the documentation for Pactflow Onprem as a guide https://docs.pactflow.io/docs/on-premises
bethskurrie
2021-08-30 23:34
If a pacticipant is both a consumer and provider, you can't ignore it only in a specific role though. It's either ignored totally, ore not.
matt.fellows
2021-08-31 02:12
:wave: hey folks! Alicia in our marketing team is currently working to get swag created for Pact and Pactflow. To keep things simple, it will be tees/stickers.
We think it makes sense to put a slogan on the tees to accompany any logo, but we don?t really have any.
:thread: Can we please share some ideas in this thread (we can use :thumbsup: voting to determine a winner)?:point_down:
matt.fellows
2021-08-31 02:18
I like this as well, for maintainers: https://www.teez.in/products/vue-js-framework-developer-men-s-profession-t-shirt
bethskurrie
2021-08-31 03:17
@uladzislau_danilchyk https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact#two-arbitrary-pacts
bethskurrie
2021-08-31 03:18
^^ There is how to view what the Pact Broker is different between two pacts.
bethskurrie
2021-08-31 03:19
Here is what it uses to generate the SHA https://github.com/pact-foundation/pact_broker/blob/390ae0d8aa52e696affefc70b310a6af4f97cd1a/lib/pact_broker/pacts/content.rb#L85
bethskurrie
2021-08-31 03:21
@satish.chandra I was hoping to have branch support fully out by now, but it has taken longer than I'd hoped.
bethskurrie
2021-08-31 03:22
The releases/deployments feature is is complete in terms of the Pact Broker - we're just waiting on all the client languages to add the new selectors.
bethskurrie
2021-08-31 03:23
The PR for updating all the docs is being worked on here - https://github.com/pact-foundation/docs.pact.io/pull/74
bethskurrie
2021-08-31 03:28
We need to come up with a consistent pattern for supporting regular expressions in the API before we do this, as I've been meaning to support tag regular expressions in consumer version selectors as well.
bethskurrie
2021-08-31 03:29
My main two thoughts are that for every place a pattern is accepted we also support a { xPattern: "..." } field.
bethskurrie
2021-08-31 03:30
and { branchPattern: "" } and { tagPattern: "" } for the consumer version selectors. The other thing we could do is say that if the string starts and ends with a "/", it is a pattern. I'm a bit hesitant about that one though.
bethskurrie
2021-08-31 03:32
To do full regex support would require loading every single pacticipant/tag/branch into the application, and doing a code regex on each item, which could be slow.
p0deje
2021-08-31 03:32
What about allowing wildcards in names then? Something like `* (async)`. That won?t be as powerful as regexps, but won?t require introducing new parameters.
bethskurrie
2021-08-31 03:32
If we supported a subset of regex - basically, `^` `$` and `.*` we could transform that into a sequel statement quite easily.
bethskurrie
2021-08-31 03:38
we'd want to implement it so that if we added the ^ and $, it wouldn't break any existing patterns though
p0deje
2021-08-31 03:53
If that?s fine by you and we can use wildcards in `consumerName`/`providerName` - our team will start preparing PR
bethskurrie
2021-08-31 03:54
I know people shouldn't put a literal * in a name, but there's nothing that says it's impossible.
bethskurrie
2021-08-31 03:55
so we either need to add a new field (consumerPattern) or use another way to indicate it's a pattern
bethskurrie
2021-08-31 03:56
It would be good to see a few examples of it out in the wild eg. AWS CLIs
p0deje
2021-08-31 03:58
I think that separate parameter would be more explicit, but then it also means that pact_broker-client needs to be updated too
p0deje
2021-08-31 03:59
Ok, maybe then let us prepare PR with consumerPattern/providerPattern first to the broker, that?s the most important one
p0deje
2021-08-31 04:00
Does broker use PostgreSQL? Can we use https://www.postgresql.org/docs/9.3/functions-matching.html
bethskurrie
2021-08-31 04:00
It uses Postgres, Sqlite and MySQL (though MySQL can go jump as far as I'm concerned).
bethskurrie
2021-08-31 04:01
You'll be using Sequel to itnerface to the databases though, so it's actually the sequel docs you'll most likely need
bethskurrie
2021-08-31 04:02
Unfortunately, the webhooks model is a bit more complicated than most other areas, as it was one of the first things I wrote, when I wasn't very good at what I was doing :laughing:
bethskurrie
2021-08-31 04:05
Just so you're aware, Pactflow uses the OSS Pact Broker code as a base, so any code you contribute to OSS Broker gets used by Pactflow too.
bethskurrie
2021-08-31 04:05
There's no reason why that should be an issue but we like to be clear about it upfront.
p0deje
2021-08-31 04:06
I know how hard maintaining OSS is (I maintain selenium-webdriver Ruby gem) and I know how important it is to avoid frustration of sending PR that maintainers are not interested in, so I?m trying to make everything clear before anyone writes a line of code
p0deje
2021-08-31 04:07
For Pactflow, I was expecting that, we?re fine with it. How long does it usually take to get OSS changes in the Pactflow?
bethskurrie
2021-08-31 04:07
The process I like to use now is to write the docs first, before I write any code.
bethskurrie
2021-08-31 04:08
> The process I like to use now is to write the docs first, before I write any code.
So, for us all to get on the same footing, can I suggest you open an empty PR, and get someone to write the docs for the new "feature" as a starting point.
bethskurrie
2021-08-31 04:09
More use than writing requirements docs, and means the usage docs are ready to go when the feature is finished.
tjones
2021-08-31 07:12
oh man, I have so many thoughts on this! I was thinking we should have a `branding` section in one of the repos, with some slogans and a definitive answer on `pact` vs `Pact` vs `PACT` (I thought we had one, but I don't know where it is)
tjones
2021-08-31 07:15
Also from that page, we have:
"Deploy faster, safer & more often"
"Remove complex end-to-end environments"
"Say goodbye to painful release processes"
tjones
2021-08-31 07:16
Also, now that I've scrolled down (I don't think I'd scrolled down before), it's another place where we should be clear that Pact is not Pactflow
tjones
2021-08-31 07:17
I propose changing: "Accelerate your path to integration testing enlightenment with Pactflow" to "Accelerate your path to integration testing enlightenment with our friends at Pactflow"
tjones
2021-08-31 07:18
Also, the companies where it says "trusted by companies like" -
1) Could we get a bunch of sponsorship logos on the back?
2) Would those companies like to sponsor our shirts?
tjones
2021-08-31 07:19
Also: We should have a merch store where the proceeds go into the pact kitty that we can then use to post merch to (eg) first time contributors
tjones
2021-08-31 07:21
`<i-lied-heres-more>`: Also, we should see if we can put an NHS logo on that page. `</sorry-about-the-xml>`
philipchardwick
2021-08-31 08:45
All seems good! We've gone down from 200,000 verifications to 40,000 (even with a conservative `[{"latest": true, "tag": true}, {"max_age": 365}]`) and the UI feels faster
mike.geeves064
2021-08-31 10:35
Would it confuse or go in line with the official meaning if referring to contributors/maintainers on the tees as Pacticipants? :slightly_smiling_face: (for like the Vue one) "here's a tee for being a new Pacticipant!". Like a Pythoneer or Pythonista
mike.geeves064
2021-08-31 10:48
:thinking_face: could you do anything with producer [because I like to mock the frontend]/consumer [because I like to mock the backend] on the front/back of a tee?
matt.fellows
2021-08-31 10:59
Both of those ideas are good, but I?ll give you the heads up - the creator of the pun is _not_ a fan of it. So, perhaps that?s a good reason to seal that into some shirts?
matt.fellows
2021-08-31 11:00
@tjones can?t use this one, it?s what we put on our Pactflow branding when we launched, and will probably be on a Pactflow tee
> I like ?I deploy on Fridays?
matt.fellows
2021-08-31 11:01
> Also: We should have a merch store where the proceeds go into the pact kitty that we can then use to post merch to (eg) first time contributors
that?s a very good idea!
matt.fellows
2021-08-31 11:17
If we think that?s the best one, then I?ll have no objections, other than to say ?is that really the most fun thing we could print on a tee shirt?
mike.geeves064
2021-08-31 11:48
my 2c, I think for a tee I like the "friends" style ones or funny rather than "done properly" example or too serious :thinking_face:
mike.geeves064
2021-08-31 17:18
how much of a schema vs contract could you get on a tee? I mean some json with "the colourless green ideas sleep furiously" would fit :D
bethskurrie
2021-08-31 20:13
Good to hear. I've duplicated some columns and added some indexes that should make the next version coming out quicker too.
matt.fellows
2021-09-01 00:03
I like the funny ones too, but perhaps it?s not a ?this? or ?that? question
mike.geeves064
2021-09-01 00:19
:thinking_face: completely failing to articulate, the thought was the "tone" for a t-shirt doesn't always match up with a site/docs: something like "done properly" could come across as almost aloof/snobbish on a tshirt maybe, but sounds fine in the docs.
I am possibly (probably) way overthinking
matt.fellows
2021-09-01 00:20
isn?t aloof/snobbish what developers want to come across as? :stuck_out_tongue:
tjones
2021-09-01 00:21
I think it's a good point though - it's good to think through possible implications
tjones
2021-09-01 00:22
I kind of feel the other way around - I don't like the idea of maintainers telling people they're doing things wrong, so to me it feels more out of place to be aggressive in the documentation.
mike.geeves064
2021-09-01 00:22
I mean I don't need a t-shirt to highlight my superiority to non devs when it's so obvious :thinking_face:
tjones
2021-09-01 00:23
I once joked with @abubics about making a bunch of t-shirts with my more controversial tech opinions sloganed in some way, so I can be in meetings and it'll look like there's a community of people who agree with me
tjones
2021-09-01 00:24
"I commit to master"
"We'd all be better developers without branches"
"OO is an anti-pattern"
tjones
2021-09-01 00:26
(@mike.geeves064 I wasn't kidding, those were all shirts from the hypothetical store)
matt.fellows
2021-09-01 00:26
I like it, but it?s _very_ obscure. Pretty much only maintainers and devout users would get the reference!
tjones
2021-09-01 00:27
I don't think that would be a good fit for general swag, but might be a good fit for contributors, maybe
tjones
2021-09-01 00:27
Also, it would be less obscure if we sold that idea more heavily in the docs, which is probably a good idea.
mike.geeves064
2021-09-01 00:28
I quite liked the "done properly" but my viewpoint was more around how other people weren't, so validation for me :smile:
tjones
2021-09-01 00:29
> ?Friends don?t let friends write end-to-end tests?
I like this, but also I don't think pact actually obviates the need to do this.
tjones
2021-09-01 00:29
your e2e tests become more about correctness of config, or overall system behaviour
tjones
2021-09-01 00:30
My favourite really is "I deploy on fridays", which I would like on a shirt regardless of the outcome here.
mike.geeves064
2021-09-01 00:31
I get what you mean, but I'm not sure how you'd add in the "spend an eternity writing" / "too many" etc
mike.geeves064
2021-09-01 00:33
Are you still on Fridays? Where's the deploying on a Sunday after your repo automatically pulls in a new version of a dependency following a CERT advisory etc :smile: Keep up!
tjones
2021-09-01 00:33
Slogan purposes:
? Tell people what pact is
? Start a conversation
? Be a rallying point for pact users
Maybe we won't find many that do all three. I think "mainline" swag should hit the first point more than the others. And "sideline" swag could focus on the others
abubics
2021-09-01 00:38
Assuming a T-shirt store of potentially infinite range :thought_balloon: it'd be lovely to have a bunch of options suiting different people's desires, but that probably won't happen for a long time (if ever).
But if it came down to voting, some rated categories that would help me are:
? funny
? demonstrates superiority
? intuitive
? still meaningful upon closer examination
? snarky
? professes benefit
abubics
2021-09-01 00:39
For example, there are some slogan tees that I immediately like, because they reference in-jokes or expert knowledge, but fall apart if you think slightly more (e.g. "according to git, this is the best version of myself")
matt.fellows
2021-09-01 00:46
she created that term when she was on maternity leave, and attributes the use of a pun to a moment of weakness due to extreme sleep deprivation
matt.fellows
2021-09-01 00:48
that being said, we did create stickers a few years back for a workshop that said ?I pacticipated in the ? workshop?
matt.fellows
2021-09-01 00:55
I don?t mind it, I like the idea of there being in in-joke as an option too
bethskurrie
2021-09-01 01:09
@dimundo I've been thinking about this, and I've realised that the deployed/released versions does not suffer from the same issue as the "latest pact for tag" problem.
bethskurrie
2021-09-01 01:10
If you can migrate over to using record-deployment and update your selectors to use the deployedOrReleased: true selector, you won't get that test pact
uladzislau_danilchyk
2021-09-01 15:55
Hi everyone! Is there any possibility to publish contracts only for specified provider by Pact Broker CLI? Cause I see filter only by consumer. But I need to push contracts for the same consumer but another provider separately
matt.fellows
2021-09-01 21:35
Yes, specify the exact set of pact files you want to release instead of passing it a directory
matt.fellows
2021-09-01 21:39
@tjones lol I was confused by your question about "why not general". But now I see. I have no explanation as to why it's here but here it is. It was actually intended for maintainers as an initial pass, but the feedback so far has been :raised_hands::raised_hands:
uladzislau_danilchyk
2021-09-01 22:27
I thought that the command argument exists for filtering publishing pacts like argument for filtering by a Consumer, but for a Provider. To do not use shell.
tjones
2021-09-02 04:12
@uladzislau_danilchyk: See the documentation for the pact-broker client CLI here: https://github.com/pact-foundation/pact-ruby-standalone/releases
mike.geeves064
2021-09-02 07:20
@tjones what I'm assuming is that swag is only for people working on the broker and I should look at that instead :)
uladzislau_danilchyk
2021-09-02 07:47
@matt.fellows, sorry. It's my mistake. I thought that the following paratemer is a filter by consumer.... :smile:
```-a, --consumer-app-version=CONSUMER_APP_VERSION ```
mike.geeves064
2021-09-02 07:49
:thinking_face: sort of on the subject of branding so this seems as good a place as any to ask a two-fold question: are there any mascot characters or pet-project theme subjects hidden away? like the Java Duke, or istio has a book store collection of services
thinking partly if there's something to go on a tee
but also tangenting onto the docs/examples pov, I didn't see a common theme going from one set of examples/language to another, which made it less obvious when figuring out how everything fits together, harder to compare like for like etc
mike.geeves064
2021-09-02 07:53
(secretly I am asking if Beth also drew a cartoon character representing a pact or pacticipant which will never be spoken of again :smile:)
philipchardwick
2021-09-02 08:45
I'm seeing a strange exception when trying to push a pact or publish verification results to the broker (docker version: 2.81.0.1), when sending a large request, we get no response from the broker.
I have a pact.json which I'm trying to publish which is 79KB, other pacts which are smaller get a response from their publish request fine (they get a 200/201 back) but this big request results in a `org.apache.http.NoHttpResponseException: our-pact-broker-url:443 failed to respond` from the Java/Gradle client (3.6.*) I'm using. I've also seen this with the Java JUnit library (4.2.6) when publishing verification results which are large, hence why I think it's broker related but there's also a k8s ingress in front of the broker so it could be that. Could be something about compression? Has anything changed with the http server compression on the broker recently?
philipchardwick
2021-09-02 08:59
I'm not seeing a RESET packet in the tcp dump of communication to the broker (which would probably create a different exception, ConnectionReset)
matt.fellows
2021-09-02 09:04
It?s not that big of a payload, can you get access to the DEBUG logs of your broker?
matt.fellows
2021-09-02 09:05
also, what happens if you use the `pact-broker --vebose ?` command to upload? Does that give you any indication?
philipchardwick
2021-09-02 09:05
I don't think it's stale connections on the client side because when I delete the other pacts and only send the "big" one it still happens
philipchardwick
2021-09-02 09:52
Nice - thanks for suggesting that, I was able to publish this with the pact broker CLI so the issue is with the java library
matt.fellows
2021-09-02 09:54
worth doing it with verbose to see if anything stands out in the logging (e.g. if it has to retry or something)
matt.fellows
2021-09-02 11:22
on 1) Pactflow (very soon) will have one. Stay tuned. But I know this wasn?t what you asked. Not sure the ?link? icon is that? mascoty
on 2) we?ve been trying to standardise on a `Product` use case (see workshops) but it?s going to take time to do that across the ecosystem
2021-09-02 11:24
@matt.fellows has a polly for you!
matt.fellows
2021-09-02 11:24
see https://pact-foundation.slack.com/archives/C9VPNUJR2/p1630581854085100 (I know it shouldn?t be there, but also, didn?t want to move it to #general and have a whole another thing!)
tjones
2021-09-02 23:21
My thoughts: It'd be great to have a mascot. I kind of like the idea of a devil for "pact"
abubics
2021-09-03 04:03
wow, selling your soul (?) to be able to deploy on Fridays :thinking_face::smiling_imp: I kinda love it ngl
philipchardwick
2021-09-03 15:44
Coming back to this, I enabled preemptive auth on the java client and it published all but one pact successfully, with the last one I was seeing `[pact-broker-669c478774-6g5pc pact-broker] 2021-09-03 13:08:25 +0000 Read: #<Errno::EROFS: Read-only file system @ rb_sysopen - /tmp/puma20210903-7-6hzns0>` errors. This is because we have a read only file system, so I created a emptyDir volume and mounted it at /tmp but this caused Ruby to throw an error `/usr/local/lib/ruby/2.6.0/tmpdir.rb:35:in tmpdir': could not find a temporary directory (ArgumentError)` because the volume is world writable (error is thrown from here: https://github.com/ruby/ruby/blob/95ba9053e20ad8d113af37b3f1f4cbfff1f6a8f1/lib/tmpdir.rb#L30 in ruby 2.6). Kubernetes doesn't give an option to make it not world-writable unfortunately.
~In newer versions this is just a warning:~ https://github.com/ruby/ruby/blob/master/lib/bundler/vendor/tmpdir/lib/tmpdir.rb#L21
~So question can the pact broker be updated to use a later version of ruby (>3.0) so it can handle world writable tmp directories? I imagine it would be a big undertaking since it's a major version, but just wanted to let you know what we found.~
I realise that even in ruby 3.0 it still won't allow you to use a world writable directory as /tmp so scratch the above.
sams.prashanth
2021-09-05 17:44
Does the paid on-prem pact-broker version has the up-to-date UI & features like pactflow cloud service?
matt.fellows
2021-09-05 21:06
The only difference is that we don't support Google/GitHub auth (currently SAML only)
franklin.lucena89
2021-09-07 21:37
Hey guys, question, I'm using broker with the docker image on a docker-compose file, also I'm deploying my app to aws, how can I check if the pact broker it's getting build or how can I handle this approach?
bethskurrie
2021-09-07 21:59
You can use the Pactflow on-prem guide https://docs.pactflow.io/docs/on-premises
bethskurrie
2021-09-09 21:09
@dimundo just making sure, you're using a version of pact that supports the consumer version selectors already, yes?
dimundo
2021-09-10 05:35
pact4s + pact-js
something like this
``` val consumerList = List(
ConsumerVersionSelector(tag = Some(providerTagFromBranch)),
ConsumerVersionSelector(tag = Some("test1")),
ConsumerVersionSelector(tag = Some("demo1")),
ConsumerVersionSelector(tag = Some("live1"))
)```
tjones
2021-09-13 00:03
Also, is there a way to get the broker dashboard to only show the pact from one tag?
matt.fellows
2021-09-13 00:11
> Does the broker show pending pacts as pending in the dashboard?
This is a common confusion. We can?t display what is pending*, because the pending calculation is based on the provider tags (i.e. it?s dynamic)
matt.fellows
2021-09-13 00:15
I think we could probably address this when branches/environments are fully integrated, and the default configuration comes from the https://github.com/pact-foundation/pact_broker/issues/490
tjones
2021-09-13 00:18
Although, that's not quite what I want (possibly) - because it's showing the latest `main` consumer version against a branch build of the provider
tjones
2021-09-13 00:36
I mean, it should be possible, because the verification knows at the time it was verifying. So it could publish "failed (pending)" - of course, this might not be implemented, but I think it's possible
matt.fellows
2021-09-13 01:16
But multiple branches of the provider could verify it with pending enabled - so which ?pending? is shown? The one from the `main` provider, `feat/foo` , `bugfix/blah` etc.?
matt.fellows
2021-09-13 01:17
The data is of course there, it?s just about making it useful for who is looking at it (your ?tag? filter, would be a way to solve this - everything could be shown with that context)
tjones
2021-09-13 01:32
> But multiple branches of the provider could verify it with pending enabled - so which ?pending? is shown?
This problem already exists with versions. And, a tag for the provider is just a pointer to a version.
tjones
2021-09-13 01:33
I suppose it could be possible to have a tag that is pending alongside one that isn't for the same version (but this is surely pretty unusual). But in that case, you can display them separately or pick one
tjones
2021-09-13 01:34
To be clear, I'm not asking for a list of pending pacts, I'm looking for the red "verification failed" not to be red when it was a pending failure
abhi.nandan964
2021-09-13 03:26
hello guys, we are trying to use Pact Broker hosted in a server with docker compose. The broker is accessible over browser, however, when we try to publish the pact from consumer application, we get the following error - `Error making request - SocketError Failed to open TCP connection to <server>:80 (getaddrinfo: Name does not resolve) /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.50.0/lib/pact_broker/client/base_client.rb:109:in `put'` any idea what could be the issue?
bethskurrie
2021-09-13 03:37
@tjones the OSS UI only show the latest verification for a pact at the moment. I'm working on showing more than that.
bethskurrie
2021-09-13 03:38
Now we have proper branches supported, I'll be able to tell which verification is from the main branch of the provider (tags can't tell me this).
bethskurrie
2021-09-13 03:39
It's of no concern to the consumer whether or not the provider has the pending feature enabled.
bethskurrie
2021-09-13 03:39
As Matt says, you can't tell whether a pact is pending or not on it's own. You need to know which provider branch you're talking about.
bethskurrie
2021-09-13 03:41
Looks like a networking issue. Wherever the pact is being published from cannot resolve the host name that you have given it for the broker.
abhi.nandan964
2021-09-13 03:44
we tried the following command from `pact-cli`
```docker run --rm -w ${PWD} -v ${PWD}:${PWD} pactfoundation/pact-cli:latest broker publish --consumer-app-version varnitConsumer0.1 --broker-base-url <hostname> ${PWD}/<pact_file_name>.json --tag consumerTag1```
do we need to mention the protocol (http://) while passing the hostname?
matt.fellows
2021-09-13 03:49
Is the docker-compose setup on another server on on the same machine that?s doing the publishing?
matt.fellows
2021-09-13 03:49
if the same, the key thing is that you?ll be publishing from one docker container to another docker container. The two containers would need to be addressable.
matt.fellows
2021-09-13 03:50
A simple way to diagnose things, is to shell into the docker container and see if you can reach the remote network from the container
bethskurrie
2021-09-13 03:51
Are you using "localhost" as the hostname? Because that won't work from inside a docker container.
matt.fellows
2021-09-13 03:52
Command to shell into the container:
```docker run -it --rm --entrypoint "/bin/sh" --rm pactfoundation/pact-cli:latest```
abhi.nandan964
2021-09-13 03:53
the docker compose setup is on another server, we are not using "localhost" as server name
bethskurrie
2021-09-13 04:02
I still don't understand the underlying reason for needing to see if it's pending.
bethskurrie
2021-09-13 04:03
the provider knows whether or not it's pending because it's their build that is passing or failing.
abhi.nandan964
2021-09-13 04:09
it's resolved, when we replace the hostname with server ip, we will look further on resolving the hostname thanks @matt.fellows and @bethskurrie :slightly_smiling_face: appreciate your quick help. :+1:
matt.fellows
2021-09-13 04:13
It might be helpful to see what items are ?pending? for a given feature/branch/change, without having to dig through build logs
bethskurrie
2021-09-13 04:14
I can see there is a question there, but I don't think the question is "show me which pacts are pending".
tjones
2021-09-13 05:16
To tell the difference between a real failure (failed) and an expected failure (pending)
matt.fellows
2021-09-13 05:32
I suppose in many ways it's about consistent messaging across various aspects of the system
matt.fellows
2021-09-13 05:33
Despite it not (necessarily) having any additional useful information, it might be a surprise not seeing it there and that can lead to confusion
matt.fellows
2021-09-13 05:34
The information is useful though, in that you can see clearly what is a new expectation that is yet to be verified vs existing that is now broken
tjones
2021-09-13 07:30
The problem was that I saw "failed" in the broker, and couldn't see why, since the tests in CI were passing.
tjones
2021-09-13 07:31
(because of pending pacts). I then spent time trying to find the source of the failed verification, when there wasn't one- there's only pending failures
tjones
2021-09-13 07:31
As you point out, consistent messaging would have solved this :slightly_smiling_face:
bethskurrie
2021-09-13 07:32
> The information is useful though, in that you can see clearly what is a new expectation that is yet to be verified vs existing that is now broken
Ok, that's a more to the point reason.
bethskurrie
2021-09-13 07:38
So, I can't show which pacts *will be* pending, but I can show which pacts were pending they failed. That should help with Tim's problem.
bethskurrie
2021-09-13 09:48
The word "pending" kind of implies to me that we're still waiting for a result to come back, like in a github commit status.
matt.fellows
2021-09-13 12:13
> The word ?pending? kind of implies to me that we?re still waiting for a result to come back, like in a github commit status.
true, but better to keep the terminology the same. The context helps with that
franklin.lucena89
2021-09-13 15:58
Hey guys, question, I'm just deploying my pact broker to aws as a docker image, but I can't really understand how to use de pact broker CLI to perform the ca-i-deploy command, any suggestion?
mike.geeves064
2021-09-13 16:32
When you say how to use, do you mean what should it do, or where does it fit in the process etc? What docs are you looking at for what you are trying to do with it?
franklin.lucena89
2021-09-13 17:02
Well I'm looking into this https://docs.pact.io/pact_broker/overview and can't complete understand how to integrate actually this can-i-deploy command on my pipeline, it can be execute like a regular maven command without the need of pact broker cli?
mike.geeves064
2021-09-13 22:13
Ok so, are you using AWS CodePipeline there then? Or just going through the steps locally for now?
I've used it as a separate step which is a condition for step the after (using GitLab CI), so still with the CLI - i.e. a step for the verify/publish, and then a step for can-i-deploy per environment
I believe it makes more sense running as a separate job in the pipeline anyway to be able to more clearly see the cause for "failed" pipelines, even if you could run via maven (not looked at the Java one at all sorry). I think there are some examples of Travis or Jenkins CI config somewhere which could help show an example :thinking_face:
mike.geeves064
2021-09-13 22:21
The CI/CD docs are worth going through as well, quite a lot in there: "CI/CD Setup Guide | Pact Docs" https://docs.pact.io/pact_nirvana section 7 covers some more info around how the can-i-deploy fits in
matt.fellows
2021-09-13 22:39
matt.fellows
2021-09-13 22:39
I?m not sure why Maven users are obsessed with running everything in Maven, though :stuck_out_tongue: . Why not CLI?
franklin.lucena89
2021-09-13 22:43
thanks guys for you help, actually I'm not obsessed with maven, I'm just looking for the best way to execute this validation, I think with the bitbucket (in my case) pipeline might be the best option for us, but this is where I can't figure out how to implement it in the right way
matt.fellows
2021-09-13 22:44
(Sorry, wasn?t trying to be mean - just tongue in cheek :stuck_out_tongue: )
matt.fellows
2021-09-13 22:44
I typically run `can-i-deploy` in a separate step of a CD pipeline, so a CLI tool is easy to add there (I use the docker variant also)
matt.fellows
2021-09-13 22:52
well, if you run the CLI yes you?ll need it (or to run the docker container)
mike.geeves064
2021-09-13 23:13
:thinking_face: If you've got multiple docker images used on a remote CI/CD for different steps, that can be a fair bit slower I think, so e.g. when I've tried public GitLab runners vs self hosted and it's pulling each image each time instead of using cached ones that adds up
So trying to get everything running from the same base would have some advantages :thinking_face:
(I find in general it's cleaner separate as well.. keeping the plumbing/infrastructure the same across projects, so only the project specific needs to change a little)
matt.fellows
2021-09-14 00:10
yeah. I don?t know gitlab that well, but most docker based CI solutions have ways of caching images so that you don?t pay the pull penalty each time
tjones
2021-09-14 03:29
Which version of the pact-broker do we need for this?
Also - if it's not released yet, what about yellow for the pending pact state?
bethskurrie
2021-09-14 04:26
We're using yellow for the "the pact changed and now we're waiting for the new verification result to come in" state.
bethskurrie
2021-09-14 06:44
You'll notice there are some slight improvements to the UI. It's slightly less shit.
mike.geeves064
2021-09-14 11:11
Yeah, then you're onto almost theological argument of how much goes into the CI image vs discrete single purpose etc :smile:
mike.geeves064
2021-09-14 11:52
I'm not sure how you sensibly give recommendations on that, is it something you've looked at? :thinking_face: thinking of the various running options, across different CIs, I like the clear small steps split out but it does seem to end up far from optimal quite easily, but maybe the pure with the caveat of it's sub optimal in terms of speed but easier to understand logically?
I ended up gradually moving away from small alpine images through to python, through to what's now 850MB because it's got node and python and AWS CDK, AWS CLI and so on....pact coming in at some point ofc :smile: it just took a lot of overhead in part because of CI caching and artifacts between steps of uploading and downloading them for each small bit :thinking_face:
matt.fellows
2021-09-14 23:11
There are too many variables to make a recommendation one way or another - Alpine has its benefits for runtime (security, for example) but has its downsides (performance, package availability). Then there is the whole set of trade offs and needs around CI speed.
dimundo
2021-09-15 13:24
hi!
there is `Latest pacts for provider with the specified tag` API `https://pact/pacts/provider/{provider}/latest/{tag}` which returns fancy JSON
is there a way to get just a version ?
use case - some CI magic on creation of new env
dimundo
2021-09-15 13:25
so i?m trying `curl -x` to get version of pacts with some tag, to add to them new env?s tag
dimundo
2021-09-15 13:28
`pact-broker create-version-tag` could be helpful if it worked with existing tag , not version :)
matt.fellows
2021-09-15 13:28
I think the new environments feature will have a link to any applications deployed to a given env. The version would be in that nested resource
matt.fellows
2021-09-15 13:29
I'm on mobile, but follow the HAL links from / (I think it's pb:environments)
matt.fellows
2021-09-15 13:41
Have a play with the HAL links to see what's about that might work. Will follow up tomorrow
francisco.moreno
2021-09-15 21:51
```@PactBroker(enablePendingPacts = "false")```
I've already set this property but still not working
franklin.lucena89
2021-09-15 21:52
Hi all, it's possible to have multiple environment into the same broker? and how can I configure my projects (consumer/provider) to work in this approach?
bethskurrie
2021-09-15 21:56
you definitely don't want one per environment - that would defeat the purpose.
bethskurrie
2021-09-15 21:57
Also, you need to ask in #pact-jvm not the Pact Broker channel. That's a client side setting.
bethskurrie
2021-09-15 21:58
Are you using can-i-deploy to ensure you only deploy successfully verified versions into an environment?
bethskurrie
2021-09-15 21:59
All the docs assume you're using one broker, not multiple. What docs have you read already?
bethskurrie
2021-09-15 22:00
This page describes the consumer/provider pipelines. https://docs.pact.io/pact_nirvana/step_4
bethskurrie
2021-09-15 22:00
This document describes recording releases and deployments https://docs.pact.io/pact_broker/recording_deployments_and_releases
bethskurrie
2021-09-15 22:01
If your clients don't support deployments and releases yet, then this document on tagging will show you how to manage different environments https://docs.pact.io/pact_broker/tags
francisco.moreno
2021-09-15 22:04
enablePendintPacts is always true no matter what I change. It's that correct?
franklin.lucena89
2021-09-15 22:07
Thanks a lot for you so quick reply, will take a look at those docs
bethskurrie
2021-09-15 22:08
So, you've created a new environment in real life, and you want to add a tag to each pacticipant version that is currently in that environment so can-i-deploy will work?
bethskurrie
2021-09-15 22:10
I think what you're asking is, you want an endpoint that returns all the pacticipant versions with a given tag, because you want to add a new tag to each of them?
bethskurrie
2021-09-15 22:12
there is not, but there is `/pacticipants/:pacticipant_name/latest-version/:tag` which will give you the latest version for a tag for a pacticipant.
dimundo
2021-09-16 05:22
and this ( `jq`) is extra dependency
and then -> `pact-broker create-version-tag --pacticipant ... --version fetchedVersion --broker-base-url ... --tag newEnvName`
dimundo
2021-09-16 05:25
something like this would simplify new env creation from scratch
`pact-broker add-version-tag --pacticipant ... --existingTag existingTag --broker-base-url ... --newTag newEnvName`
uladzislau_danilchyk
2021-09-16 13:42
Hi everyone!
I have an error in Pact-jvm. It was working before. But today - not.
error:
```[2021-09-16T13:06:48.424Z] * What went wrong:
[2021-09-16T13:06:48.424Z] A problem occurred configuring project ':modules:mname'.
[2021-09-16T13:06:48.424Z] > Could not resolve all artifacts for configuration ':modules:mname:classpath'.
[2021-09-16T13:06:48.425Z] > Could not download matchers-4.1.19.jar (au.com.dius.pact.core:matchers:4.1.19)
[2021-09-16T13:06:48.425Z] > Could not get resource 'https://plugins.gradle.org/m2/au/com/dius/pact/core/matchers/4.1.19/matchers-4.1.19.jar'.
[2021-09-16T13:06:48.425Z] > Could not GET 'https://jcenter.bintray.com/au/com/dius/pact/core/matchers/4.1.19/matchers-4.1.19.jar'.
[2021-09-16T13:06:48.425Z] > Read timed out
[2021-09-16T13:06:48.425Z] > Could not download pactbroker-4.1.19.jar (au.com.dius.pact.core:pactbroker:4.1.19)
[2021-09-16T13:06:48.425Z] > Could not get resource 'https://plugins.gradle.org/m2/au/com/dius/pact/core/pactbroker/4.1.19/pactbroker-4.1.19.jar'.
[2021-09-16T13:06:48.425Z] > Could not GET 'https://jcenter.bintray.com/au/com/dius/pact/core/pactbroker/4.1.19/pactbroker-4.1.19.jar'.
[2021-09-16T13:06:48.425Z] > Read timed out```
Is there any solution for that?
My code:
```id 'au.com.dius.pact' version '4.1.19'```
tjones
2021-09-16 14:20
This looks like a network issue to me, although I don't know a lot about jvm errors. You might want to try asking in #pact-jvm
matt.fellows
2021-09-16 23:19
hmmm that is strange. I thought bintray was retired? Is it a gradle configuration?
abubics
2021-09-17 00:07
yeah, that happened a few months ago, I thought? https://blog.gradle.org/jcenter-shutdown
Need to at least remove `jcenter` from `repositories`, at a guess.
bethskurrie
2021-09-17 02:38
@uladzislau_danilchyk it's a JVM client issue, not a pact broker server issue. I'm afraid I can't help you. Better to ask in #pact-jvm if the comments provided haven't given you an answer yet.
franklin.lucena89
2021-09-17 15:11
Hi guys, I'm working with the tag feature in the broker, and actually I tag my provider test with my branch name, but when I try to use this filters I can't see my pacts, what I'm missing here?
bethskurrie
2021-09-19 23:20
@franklin.lucena89 i've just done some big changes to the UI, so there may be a bug.
bethskurrie
2021-09-19 23:21
Also, these pages view by the pact (the consumer version) not the provider version.
bethskurrie
2021-09-19 23:22
If you can please write down the exact steps to reproduce, and raise an issue in https://github.com/pact-foundation/pact_broker/issues I can have a look at it.
franklin.lucena89
2021-09-20 12:48
Oh thank for your answer! I'm seeing it now with my consumer tags, but actually I'm tagging my consumer pacts with the maven plugin, but how can I do for tagging in a dynamic way? it's possible to do it using java code?
franklin.lucena89
2021-09-20 13:06
according to this https://docs.pact.io/implementation_guides/jvm/provider/maven/#overriding-the-provider-hostname-and-port-when-the-task-is-executed-4211, I'm using this
```<tags>
<tag>{{pact.consumer.tags}}</tag>
</tags>```
and at the code I'm doing this `props.setProperty("pat.consumer.tags", "other");` but it's not working
jarmy
2021-09-20 19:58
Hello. I'm having trouble getting a database clean dry run to execute in our pact-broker. I'm running version `2.83.0.0` with these configs but I'm not seeing any activity on the broker indicating a dry run has occurred:
``` PACT_BROKER_DATABASE_CLEAN_ENABLED: "true"
PACT_BROKER_DATABASE_CLEAN_DRY_RUN: "true"
PACT_BROKER_DATABASE_CLEAN_CRON_SCHEDULE: "*/1 * * * *"
PACT_BROKER_DATABASE_CLEAN_OVERWRITTEN_DATA_MAX_AGE: 30
PACT_BROKER_DATABASE_CLEAN_DELETION_LIMIT: 100
PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS: "[{\"tag\": true, \"latest\": true}]"```
franklin.lucena89
2021-09-20 21:29
Hey guys, I'm trying to run this command `docker run --rm pactfoundation/pact-cli:latest broker publish` on my bitbucket pipeline but I get this error `PactBroker::Client::Error - Command `git rev-parse --abbrev-ref HEAD` didn't return anything that could be identified as the current branch.` , any idea of what is this about?
tjones
2021-09-21 01:53
That error says that git doesn't know what branch its on. Does your container know / have the git history?
sagupta
2021-09-21 12:13
Hey team,
i have setup a webhook in pact broker to send slack message on `provider_verification_failed` event . I wanted to know if there is a way i can configure this webhook to only execute on certain `pactbroker.consumerVersionTags` like master/staging . We are currently noticing that when we are setting up the provider verification in the provider repo , then in that process we get lot of notifications which are not relevant so we want to trigger slack notification only when master pact verification fails
matt.fellows
2021-09-21 12:48
You'd need to volume mount the git directory, but it shouldn't try to do that by default, and I can't see that you're passing any flags to use it or env vars that would enable it
matt.fellows
2021-09-21 12:49
Could you please check that you're on the latest and if that is indeed the case, see if previous versions don't have that problem?
franklin.lucena89
2021-09-21 13:28
I also try this
```- step: &Pact_Publish
name: Pact_Publish
size: 2x
image: pactfoundation/pact-cli:latest
services:
- docker
script:
- pact-broker publish PACTS_FOLDER -b=BROKER_URL -u=BROKER_USER```
after unit test execution but I get a `PactBroker::Client::Error - No pact files found` error, so my doubt is if I need to execute the mvn test command inside same step than the pact broker publish?
tjones
2021-09-21 14:26
The pact test will generate artefacts (the pact files) that need to be available to the docker image that you're running there. I don't know how to configure bitbucket pipelines, but you'll need to tell it to copy the pact files in
franklin.lucena89
2021-09-21 21:07
Hey guys, question, how do I set the environment to my consumer/provider test will be publish?
bethskurrie
2021-09-21 21:08
@sagupta I was half way through this PR and just got bogged down by indecision https://github.com/pact-foundation/pact_broker/pull/403
bethskurrie
2021-09-21 21:10
>
> - step: &Pact_Publish
> name: Pact_Publish
> size: 2x
> image: pactfoundation/pact-cli:latest
> services:
> - docker
> script:
> - pact-broker publish PACTS_FOLDER -b=BROKER_URL -u=BROKER_USER
You need to mount your local directory so it has access to the pact files @franklin.lucena89
bethskurrie
2021-09-21 21:11
See the
```-v ${PWD}:${PWD} \```
here https://github.com/pact-foundation/pact-ruby-cli#publish-pacts
franklin.lucena89
2021-09-21 21:12
Sorry, I'm using a bitbucket pipeline to publish my pact to the broker, for now I'm just doing tests, but I can't see any environment tag related to my consumer test in this view
bethskurrie
2021-09-21 21:13
@jarmy you can play with a working docker-compose set up here https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose-clean-cron.yml
franklin.lucena89
2021-09-21 21:13
Thanks @bethskurrie you rock! I solved my issue doing a copy of my pact file folder into the docker container
bethskurrie
2021-09-21 21:14
Here are the docs https://docs.pact.io/pact_broker/recording_deployments_and_releases/
bethskurrie
2021-09-21 21:15
Note that pact-jvm (and some others) do not support the environment selectors yet, so you might need to stick with tags for now.
jarmy
2021-09-21 21:49
I've tried without success with so many combinations I've lost count. This is the latest:
``` PACT_BROKER_LOG_LEVEL: "INFO"
PACT_BROKER_SQL_LOG_LEVEL: "DEBUG"
PACT_BROKER_DATABASE_CLEAN_ENABLED: "true"
PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "5"
PACT_BROKER_DATABASE_CLEAN_CRON_SCHEDULE: "* * * * *"
PACT_BROKER_DATABASE_CLEAN_DELETION_LIMIT: "500"
# Keep all prod versions, AND the latest version for every pacticipant/tag, and all versions less than 30 days old
PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS: '[{"latest": true, "tag": true}, {"max_age": 30}]'```
yet when the broker starts up all I see is this output (after waiting a minute):
```pact-broker_1 | 2021-09-21 14:44:37.626125 I [1:47260464716140] pact-broker -- ------------------------------------------------------------------------
pact-broker_1 | 2021-09-21 14:44:37.626181 I [1:47260464716140] pact-broker -- PACT BROKER CONFIGURATION:
pact-broker_1 | 2021-09-21 14:44:37.626323 I [1:47260464716140] pact-broker -- allow_dangerous_contract_modification=true source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/load.rb:45"}
pact-broker_1 | 2021-09-21 14:44:37.626385 I [1:47260464716140] pact-broker -- allow_missing_migration_files=true source={:type=>:accessor, :called_from=>"/usr/local/lib/ruby/2.6.0/forwardable.rb:225"}
pact-broker_1 | 2021-09-21 14:44:37.626454 I [1:47260464716140] pact-broker -- allow_public_read=false source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626625 I [1:47260464716140] pact-broker -- auto_detect_main_branch=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626649 I [1:47260464716140] pact-broker -- auto_migrate_db=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626679 I [1:47260464716140] pact-broker -- auto_migrate_db_data=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626708 I [1:47260464716140] pact-broker -- badge_provider_mode=redirect source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626740 I [1:47260464716140] pact-broker -- base_equality_only_on_content_that_affects_verification_results=true source={:type=>:accessor, :called_from=>"/usr/local/lib/ruby/2.6.0/forwardable.rb:225"}
pact-broker_1 | 2021-09-21 14:44:37.626772 I [1:47260464716140] pact-broker -- base_url= source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/runtime_configuration.rb:108"}
pact-broker_1 | 2021-09-21 14:44:37.626802 I [1:47260464716140] pact-broker -- base_urls=[] source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626868 I [1:47260464716140] pact-broker -- basic_auth_enabled=false source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626898 I [1:47260464716140] pact-broker -- basic_auth_password= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626927 I [1:47260464716140] pact-broker -- basic_auth_read_only_password= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626962 I [1:47260464716140] pact-broker -- basic_auth_read_only_username= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.626992 I [1:47260464716140] pact-broker -- basic_auth_username= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627059 I [1:47260464716140] pact-broker -- check_for_potential_duplicate_pacticipant_names=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627090 I [1:47260464716140] pact-broker -- create_deployed_versions_for_tags=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627119 I [1:47260464716140] pact-broker -- database_adapter=postgres source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627186 I [1:47260464716140] pact-broker -- database_connect_max_retries=5 source={:type=>:env, :key=>"PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES"}
pact-broker_1 | 2021-09-21 14:44:37.627217 I [1:47260464716140] pact-broker -- database_connection_validation_timeout=-1 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627247 I [1:47260464716140] pact-broker -- database_host=http://sv5-shared-db3.savagebeast.com source={:type=>:env, :key=>"PACT_BROKER_DATABASE_HOST"}
pact-broker_1 | 2021-09-21 14:44:37.627325 I [1:47260464716140] pact-broker -- database_max_connections= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627350 I [1:47260464716140] pact-broker -- database_name=pact-broker source={:type=>:env, :key=>"PACT_BROKER_DATABASE_NAME"}
pact-broker_1 | 2021-09-21 14:44:37.627410 I [1:47260464716140] pact-broker -- database_password=***** source={:type=>:env, :key=>"PACT_BROKER_DATABASE_PASSWORD"}
pact-broker_1 | 2021-09-21 14:44:37.627462 I [1:47260464716140] pact-broker -- database_pool_timeout=5 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627583 I [1:47260464716140] pact-broker -- database_port= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627609 I [1:47260464716140] pact-broker -- database_sslmode= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627633 I [1:47260464716140] pact-broker -- database_statement_timeout=15 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627657 I [1:47260464716140] pact-broker -- database_url= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627681 I [1:47260464716140] pact-broker -- database_username=pact-broker source={:type=>:env, :key=>"PACT_BROKER_DATABASE_USERNAME"}
pact-broker_1 | 2021-09-21 14:44:37.627706 I [1:47260464716140] pact-broker -- disable_ssl_verification=false source={:type=>:accessor, :called_from=>"/usr/local/lib/ruby/2.6.0/forwardable.rb:225"}
pact-broker_1 | 2021-09-21 14:44:37.627730 I [1:47260464716140] pact-broker -- enable_diagnostic_endpoints=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627753 I [1:47260464716140] pact-broker -- enable_public_badge_access=false source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627777 I [1:47260464716140] pact-broker -- features=[] source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627836 I [1:47260464716140] pact-broker -- hide_pactflow_messages=false source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627861 I [1:47260464716140] pact-broker -- log_configuration_on_startup=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627885 I [1:47260464716140] pact-broker -- log_dir=/pact_broker/log source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627908 I [1:47260464716140] pact-broker -- log_format= source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.627933 I [1:47260464716140] pact-broker -- log_level=INFO source={:type=>:env, :key=>"PACT_BROKER_LOG_LEVEL"}
pact-broker_1 | 2021-09-21 14:44:37.627956 I [1:47260464716140] pact-broker -- log_stream=file source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628011 I [1:47260464716140] pact-broker -- main_branch_candidates=["develop", "main", "master"] source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628036 I [1:47260464716140] pact-broker -- metrics_sql_statement_timeout=30 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628061 I [1:47260464716140] pact-broker -- order_versions_by_date=true source={:type=>:accessor, :called_from=>"/usr/local/lib/ruby/2.6.0/forwardable.rb:225"}
pact-broker_1 | 2021-09-21 14:44:37.628090 I [1:47260464716140] pact-broker -- port=9292 source={:type=>:env, :key=>"PACT_BROKER_PORT"}
pact-broker_1 | 2021-09-21 14:44:37.628115 I [1:47260464716140] pact-broker -- public_heartbeat=false source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628170 I [1:47260464716140] pact-broker -- seed_example_data=false source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/load.rb:45"}
pact-broker_1 | 2021-09-21 14:44:37.628197 I [1:47260464716140] pact-broker -- semver_formats=["%M.%m.%p%s%d", "%M.%m", "%M"] source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628220 I [1:47260464716140] pact-broker -- shields_io_base_url=https://img.shields.io source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628274 I [1:47260464716140] pact-broker -- sql_log_level=DEBUG source={:type=>:env, :key=>"PACT_BROKER_SQL_LOG_LEVEL"}
pact-broker_1 | 2021-09-21 14:44:37.628299 I [1:47260464716140] pact-broker -- sql_log_warn_duration=5 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628324 I [1:47260464716140] pact-broker -- use_case_sensitive_resource_names=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628374 I [1:47260464716140] pact-broker -- use_first_tag_as_branch=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628433 I [1:47260464716140] pact-broker -- use_first_tag_as_branch_time_limit=10 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628488 I [1:47260464716140] pact-broker -- use_hal_browser=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628607 I [1:47260464716140] pact-broker -- use_rack_protection=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628631 I [1:47260464716140] pact-broker -- user_agent=Pact Broker v2.83.0 source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628655 I [1:47260464716140] pact-broker -- validate_database_connection_config=true source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628680 I [1:47260464716140] pact-broker -- warning_error_class_names=["Sequel::ForeignKeyConstraintViolation"] source={:type=>:defaults}
pact-broker_1 | 2021-09-21 14:44:37.628708 I [1:47260464716140] pact-broker -- webhook_host_whitelist=["*.http://jenkins-sb.savagebeast.com"] source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/runtime_configuration.rb:154"}
pact-broker_1 | 2021-09-21 14:44:37.628743 I [1:47260464716140] pact-broker -- webhook_http_code_success=[200, 201, 202, 203, 204, 205, 206] source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/runtime_configuration.rb:146"}
pact-broker_1 | 2021-09-21 14:44:37.628771 I [1:47260464716140] pact-broker -- webhook_http_method_whitelist=["POST"] source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/runtime_configuration.rb:142"}
pact-broker_1 | 2021-09-21 14:44:37.628802 I [1:47260464716140] pact-broker -- webhook_retry_schedule=[10, 60, 120, 300, 600, 1200] source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/runtime_configuration.rb:138"}
pact-broker_1 | 2021-09-21 14:44:37.628853 I [1:47260464716140] pact-broker -- webhook_scheme_whitelist=["https"] source={:type=>:accessor, :called_from=>"/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.83.0/lib/pact_broker/config/runtime_configuration.rb:150"}
pact-broker_1 | 2021-09-21 14:44:37.628868 I [1:47260464716140] pact-broker -- ------------------------------------------------------------------------
pact-broker_1 | * Listening on
pact-broker_1 | Use Ctrl-C to stop```
bethskurrie
2021-09-21 22:42
Feedback on a potential rename of the "pending pacts" feature please https://github.com/pact-foundation/pact_broker/discussions/507
jarmy
2021-09-21 23:31
Looks like there are some https://github.com/pact-foundation/pact-broker-docker/blob/master/Dockerfile#L40-L43 we need to include in our Dockerfile (we've rolled our own version)
sagupta
2021-09-22 07:34
Hey team,
Is it possible to know the details of the CI job which runs the pact provider verify and then publish verification results to broker inside pact broker as a variable ?
Use case : I have a web hook setup to post slack notification to team slack channel on verification failure .Currently I have added the verification result variable and the pact url variable in the slack message.However when the provider team wants to know what failed ,then the verification result link in pact broker is not easy to understand as it's not formatted at all.
So I was thinking if I can get the job I'd (in my case Gitlab job I'd ) and post that also in slack message which would make my team life easy .
cc @bethskurrie@bethskurrie@bethskurrie
sagupta
2021-09-22 07:35
Alright I will be following the PR .It will be really helpful in our use case :blush:
sagupta
2021-09-22 07:39
I tagged once but it tags multiple times .Slack behave in mysterious ways :grinning:
sagupta
2021-09-22 07:40
we have a micro service architecture and our providers are written in ruby , Java and Php
bethskurrie
2021-09-22 07:41
So, there's a new API that has been designed but not implemented yet that will support the build URL.
bethskurrie
2021-09-22 07:41
Again, I don't know when it will be done. I need to get branch and environment support out first
bethskurrie
2021-09-22 07:42
if you subscribe to that you should get notified when there's movement on it though
sagupta
2021-09-22 07:44
Alright got it ,will subscribe to it .
Also to mention , we use pact-cli pact provider-verify to do all the provider verification in all of our providers .Mentioning if the support for build url will be for pact cli also ?
bethskurrie
2021-09-22 07:45
they'll all get it eventually, but anything to do with ruby will be done first, because i'll be doing it
sagupta
2021-09-22 07:48
We do not use any language implementation for provider verification .I created a wrapper over pact-cli (ruby docker image) and make use of pact-provider-verify command. Based on what you mentioned I think it will be available as soon as you release the ruby change ?
uladzislau_danilchyk
2021-09-22 16:04
Hi guys!
I like you're doing and I think you are on a right way. I want to say Thank you for this product.
But I found the issue related to Pact Broker jvm lib (`au.com.dius.pact.provider:junit5:4.2.3`) and described it on a github.
It's related to filtering by consumers list: https://github.com/pact-foundation/pact-jvm/issues/1447
Could you help me with that? Cause it's critical for our project.
Thank you an advance!
uladzislau_danilchyk
2021-09-22 16:14
yep, but I just wanted to leave it here as a reminder, let's say or get an attention from people who aware about pact broker.
franklin.lucena89
2021-09-22 16:18
Hi guys, I have a question about webhooks, looking into this docs https://docs.pact.io/pact_broker/webhooks#introduction I have the main idea of how broker handle it, but my question is if I need to create a webhook for every branch I create or just can create one webhook pointing to my repo? BTW I'm working with bitbucket
jarmy
2021-09-22 16:48
I got it working. Had to add supercronic to the Dockerfile and then create and schedule the chrontab in the entrypoint.sh. Rolling our own version of the pact-broker has reared its ugly head
bethskurrie
2021-09-22 22:33
Ron is the pact-jvm maintainer, and I am the Pact Broker maintainer. I don't do Java and he only does Ruby under duress :stuck_out_tongue:
bethskurrie
2021-09-22 22:34
here's an example bitbucket webhook https://docs.pact.io/pact_broker/webhooks/template_library/#bitbucket---pipeline-trigger-build-of-a-branch
bethskurrie
2021-09-22 22:47
the only branch you need to care about is which branch of the provider gets triggered for the build, and that's going to be your main/master branch.
bethskurrie
2021-09-22 22:47
the webhook triggers for all branches of the consumer, if the pact has changed.
saurabh.goel
2021-09-24 08:39
Hi All, I tried creating a message pact. it is showing as below in the broker. But is also says "_Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead._" at the top. could anyone help me understand why the parsing did not work?
`{`
`"consumer": {`
`"name": "VA"`
`},`
`"provider": {`
`"name": "OMA"`
`},`
`"messages": [`
`{`
`"_id": "ed34efdce6796af251e47d8861f52493ab4202d0",`
`"description": "A message with Cancelled state with all required fields",`
`"providerStates": [`
`{`
`"name": "A own delivery order is cancelled",`
`"params": null`
`}`
`],`
`"contents": {`
`"oldState": "WAITING",`
`"newState": "CANCELLED",`
`"rpsOrderId": "oma_8ef77245-ceb9-4808-9cf1-590afde09ccb\"",`
`"platformOrderId": "od-testOrder1",`
`"platformGlobalKey": "T",`
`"isTest": false,`
`"reason": "TOO_BUSY",`
`"owner": "VENDOR",`
`"stage": "CONFIRMATION",`
`"timestamp": "2021-09-22T16:28:02.686Z",`
`"rpsId": "139096",`
`"platformId": "3330",`
`"gEId": "TB_KW"`
`},`
`"matchingRules": {`
`},`
`"metaData": {`
`"source": "OMA 0.0.1-SNAPSHOT",`
`"traceId": "25311e7e26da48bcaba225e5c4ddc897",`
`"type": "RestaurantOwnDelivery.Cancelled",`
`"version": 1`
`}`
`},]`
`}` (edited)
tjones
2021-09-24 08:41
It's missing the top level key `metadata`, which contains `pactSpecification`. This is probably a bug in whichever framework created it
saurabh.goel
2021-09-24 08:47
wait, let me share the whole file. it is too big so i pasted only one message out of 5.
saurabh.goel
2021-09-24 08:48
actually i checked on the web and other people have faced this issue and in some cases it was resolved. also, maybe broker still does not parse v3 pact.
saurabh.goel
2021-09-24 08:49
if this does not interfere with the actual provider verification test. I am ok with it.
matt.fellows
2021-09-24 11:46
actually the broker doesn?t even look at the contents, it could be any JSON file
leo.tang
2021-09-24 21:19
Hello, we have pact-broker running in kubernetes using the image `pactfoundation/pact-broker:2.62.0` and we're unable to find logs. Any ideas where they are supposed to be located?
*Details*
? `PACT_BROKER_LOG_LEVEL: "DEBUG"` is set
? log doesn't exist under `./log` , `./logs`, `/var/log` , etc. `find . -name 'log'` doesn't produce anything useful.
? `kubectl logs` produces sql logs, so there are outputs via stdout. Just not saved anywhere in the pod.
bethskurrie
2021-09-24 21:32
You'll see them if you start up this docker-compose file https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose.yml
bethskurrie
2021-09-24 21:33
@franklin.lucena89 this workshop steps you through the whole process https://docs.pactflow.io/docs/workshops/ci-cd
leo.tang
2021-09-24 21:38
gotcha, is there any support for automatically writing output to file instead? Just curious before we decide to build something to pipe stdout to a file ourselves.
uglyog
2021-09-27 01:51
@bethskurrie having an issue with one of my test projects. Accessing this provider `https://test.pact.dius.com.au/pacts/provider/Animal%20Profile%20Service/for-verification` with no consumer version selectors returns no pacts, while there are a bunch of pacts with a single consumer.
If I add a consumer version selector to that consumer, I get a pact back. I thought no selectors would not restrict the results.
bethskurrie
2021-09-27 06:08
@uglyog depending on which version you're using, no selectors will return
? the latest pact for each integration (up until recently)
? OR in most recent version, the latest from the main branch if it can detect that otherwise the overall latest + the deployed and released versions.
bethskurrie
2021-09-27 06:08
"with no consumer version selectors returns no pacts," that sounds like a bug.
uglyog
2021-09-27 06:13
Yeah, I was hoping it was that and not my understanding that was flawed all this time.
bethskurrie
2021-09-27 06:30
ok, so the problem is, you used to tag with your branch name, and now you're not
bethskurrie
2021-09-27 06:31
it's identified that you've used a tag called "master", so it's set the default branch of the app to "master"
bethskurrie
2021-09-27 06:43
having the old data was actually good there, because new data would have had all the branches in, and you wouldn't have noticed the problem
uladzislau_danilchyk
2021-09-27 11:17
@bethskurrie, hi!
I guess that I found bug which is related to fetching pacts from a Pact Broker with filters (selectors).
Let's imagine that you have few consumers (e.g. ConsumerA, ConsumerB) in Pact Broker and *WIP enabled* while running provider verification test.
Additionally, before the pacts fetched I would like to filter out consumers for only one consumer's pacts to be retrieved.
*And here is a problem.*
`ConsumerA` has WIP pacts. If I pass selector for `ConsumerB` while running provider verification, pacts for `ConsumerB` will be retrieved *along with WIP pacts for* `ConsumerA`.
I guess it is bug.
I expect that WIP pacts will be returned *only for the passed consumer* (not for all consumers you have).
What do you think about it?
christopher.lampert
2021-09-28 07:53
Hey all, I was wondering if there is a way that a provider would be able to query/poll the pact broker for changes to contracts that it is part of? Think of this as a reverse of the way webhooks work.
Due to current restrictions in my company we are unable to use webhooks as there are concerns from our security department in regards to exposing credentials to our CI pipelines so this is off limits until our business case for Pact Flow is processed.
Our current work around is for the provider to run their verification job in their pipelines on a schedule (we have this set to once a day atm) but this still poses problems as we still potentially have to wait up to 24 hours for verification to occur slowing us down. We also didn't want to increase the amount of times the verification job ran as this is inefficient and creates waste with logs on our CI server.
I had a look at the pact-broker-client which using the `describe-pacticipant` option but this doesn't appear to give me what I want. I appreciate I am trying to do things the opposite way that pact recommends but any advice whilst we wait for our business case to be processed would be appreciated. Thanks!
tjones
2021-09-28 08:24
If you want to know if it has changed since a specific version, you could use the diff API
tjones
2021-09-28 08:26
It's the `pb:diff` link in the response to:
```/pacts/provider/${providerName}/consumer/${consumerName}/version/${consumerVersion}```
bethskurrie
2021-09-28 08:52
In the meantime, you can use this approach https://docs.pact.io/pact_nirvana/step_4/#alternative-webhookless-workflow
philipchardwick
2021-09-28 09:35
We use Concourse as our CI (which doesn't believe in webhooks to start things) so we use something that polls the broker every minute/30 seconds, it calls `/pacts/provider/${provider.name}/latest` gets `_links['pb:pacts']` and for each of those it gets the pactVersion (`_links['pb:pact-version'].name`) and if the pact version is different to last time it polled, it should run the provider tests.
This isn't 100% though because feasibly a pact could change twice in between two polls and the middle one wouldn't get verified
franklin.lucena89
2021-09-28 14:45
Hey guys, I'm using the pack-broker-cli ruby standalone inside my bitbucket pipeline and I'm having this error `Error retrieving matrix. NoMethodError - undefined method `+@' for "":String` when I try to run the `can-i-deploy` function and I don't know why I'm getting this error, does anyone can help me? BTW this is how I'm calling the function `./pact-broker can-i-deploy -a="PARTICIPANT" -b=$PACT_BROKER_BASE_URL -u=$PACT_BROKER_USER -p=$PACT_BROKER_PASSWORD -e=$BITBUCKET_BRANCH -v -l`
leo.tang
2021-09-28 20:22
:wave: We wanted to silent sql logs so we added `PACT_BROKER_SQL_LOG_LEVEL="NONE"` to our env (yaml file) like so
``` - name: PACT_BROKER_SQL_LOG_LEVEL
value: NONE```
We can see that pact-broker is reading our env
```2021-09-28 20:16:37.196716 I [6:47380842961400] pact-broker -- PACT_BROKER_SQL_LOG_LEVEL=NONE
2021-09-28 20:16:37.196880 I [6:47380842961400] pact-broker -- Connecting to database with config: {:adapter=>"postgres", :user=>"...", :password=>"*****", :host=>"...", :database=>"pactbroker", :encoding=>"utf8", :sql_log_level=>:none, :log_warn_duration=>5.0}```
however it gives us
```! Unable to load application: Sequel::DatabaseConnectionError: NoMethodError: undefined method `none' for #<PactBroker::DB::LogQuietener:0x0000562f6df94c08>
bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.6.0/bin/puma)
Sequel::DatabaseConnectionError: NoMethodError: undefined method `none' for #<PactBroker::DB::LogQuietener:0x0000562f6df94c08>
/usr/local/lib/ruby/2.6.0/delegate.rb:87:in `method_missing'```
We also tried it with https://docs.pact.io/pact_broker/configuration/settings/#sql_log_level etc which all works. Only NONE is throwing the above error. Any ideas what we might be doing wrong?
matt.fellows
2021-09-28 21:06
First to you should wrap all args in strings to prevent she'll expansion
franklin.lucena89
2021-09-28 21:11
with the docker image works fine just like I posted early, but with this standalone version I don't know what exactly is happen, btw the only string I'm passing to the command is the participant name, the left params are bitbucket env vars
franklin.lucena89
2021-09-28 21:56
just like this
```- step: &Can_I_Deploy_Pact
name: Can I Deploy
image: pactfoundation/pact-cli
services:
- docker
script:
- pact-broker can-i-deploy -a="Participant" -b=$PACT_BROKER_BASE_URL -u=$PACT_BROKER_USER -p=$PACT_BROKER_PASSWORD -e="Version" -v --retry-while-unknown=3 --retry-interval=3```
bethskurrie
2021-09-28 22:28
@franklin.lucena89 there was a bug introduced to a dependency. I have locked the dependency to a working version, and put out a new release. Please update to the latest version.
franklin.lucena89
2021-09-28 22:42
Oh ok! well now I'm working fine with docker image, but thank for the information!
sagupta
2021-09-29 07:33
small question on this : is this only for pact-publish-contracts ? or for pact provider-verify also
franklin.lucena89
2021-09-29 16:52
Hey guys, Pact broker support multiple user? I mean, for my organization we need to create multiple read only/admin users that have access to the broker, is this possible?
mike.geeves064
2021-09-29 16:53
I think that's something you'd look to Pactflow for: https://pactflow.io/features/ ("Collaboration features
User management, role based access, team permissions etc.")
mike.geeves064
2021-09-29 16:54
Pactflow gets a tick, the Open Source one does not :slightly_smiling_face:
tjones
2021-09-29 23:51
Hi, I'm having trouble disabling pending pacts with broker 2.85.0 and Pact JVM - see related discussion here:
https://pact-foundation.slack.com/archives/C9UN99H24/p1632958997259300
bethskurrie
2021-09-30 02:33
Unfortunately, it's only for pacts at this stage, because I need to write a new verification publishing api to support the "all in one" verification publishing the way I have for the pact publishing.
steven.yi
2021-09-30 20:19
Hi, I was noticing significant latency in calling the `/pacts/provider` endpoint. Exporting ~250 pacts takes roughly 30 seconds to get a response
We noticed this in prometheus metrics collection (https://github.com/ContainerSolutions/pactbroker_exporter/blob/0e9f906f4d42514e09ad66f5d5a37e87c8525f37/main.go#L149), which would cause processes to time out
matt.fellows
2021-09-30 21:24
Ok... Why is the Prometheus server extracting all of the provider details. What does it need?
And more importantly, what would you like us to do about it? You're making 251 calls to the API, so I'm not surprised it can take longer than 30s. Increase the timeout?
matt.fellows
2021-09-30 21:28
Also have you run the database clean job? I'm not sure it will help with that query or not but good to do nonetheless
bethskurrie
2021-09-30 22:09
The "/pacts/provider/{provider}" endpoint will return every pact for that provider ever. That's not actually very useful at all.
bethskurrie
2021-09-30 22:10
You'll get every revision from every branch of the consumer ever, and it's unlikely that would ever be useful to you.
bethskurrie
2021-09-30 22:12
If you want extra users for OSS @franklin.lucena89 you'll need to put something like ngnix in front of it and make your users there. It would be a bit fiddly to recreate the read/write logic though, because there's not an exact mapping between GET/read and POST/write.
bethskurrie
2021-10-01 09:03
Counting the number of consumers might be useful, but the pact versions, not so much.
matt.fellows
2021-10-01 09:05
I don't know either. But it probably makes sense for Prometheus to be using the metrics endpoint (which from memory was why it was created) and add anything useful/missing
bethskurrie
2021-10-01 09:06
Did you actually mention that you'd created your own docker image @jarmy?
bethskurrie
2021-10-01 09:07
I can't see it anywhere... that would have been a useful bit of information to make sure I knew!
bethskurrie
2021-10-01 09:11
@franklin.lucena89 there is almost nobody you could ask who had less of an idea how Pact-JVM works than me. You'll need to ask in the pact-jvm channel.
philipchardwick
2021-10-01 14:11
~Is anyone else getting cert errors using the latest pact standalone?~
~`OpenSSL::SSL::SSLError - SSL_connect returned=1 errno=0 state=error: certificate verify failed`~
~This is obviously fairly specific to the certs we're using on our pact broker, but _I think_ the version of ruby (2.2.0) used in the standalone binary doesn't have the latest public keys used for certificates? We were able to fix some of our CI using the pact cli docker image, but pact-js uses pact-node which uses the standalone binary. What's the process of updating this? Is this a real pain to do and should we look at trying to use something else instead of pact-js for publishing/verifying pacts?~
Yes - others have this, https://pact-foundation.slack.com/archives/C5F4KFKR8/p1633068329189800
steven.yi
2021-10-01 15:01
@bethskurrie I think that endpoint in the exporter is used to generate an `is_up` metric, which appears to be based purely off of the `scrape` method successfully calling the pacts/provider endpoint for all pacticipants
jarmy
2021-10-01 16:00
Yeah, we roll our own docker image. We pull in the pact broker repo as a sub module, build and deploy it in our infra.
matt.fellows
2021-10-01 22:41
Why would you iterate all of the pacts to check if the system is up? In any case, it's a pretty useless metric. I'd start with the `/metrics` endpoint
franklin.lucena89
2021-10-04 19:38
Hi, I'm having issues tagging my consumer/provider, when I set the tag to my `pact.provider.tag = "COMMIT_MESSAGE"` , this value get set as my branch name inside the broker https://pact-foundation.slack.com/files/U02C16JCF4Y/F02G84A49HR/image.png, why is this happens, I can really know what I'm doing wrong and how to fix it, please help!
bethskurrie
2021-10-04 20:08
If you look at the logs @franklin.lucena89 you'll see a message indicating why that is happening. https://docs.pact.io/pact_broker/configuration/settings#use_first_tag_as_branch
bethskurrie
2021-10-04 20:09
Best practice has been to always set the tag name as the branch when you publish. I'd recommend updating your configuration so that the first tag you set is the branch name.
franklin.lucena89
2021-10-04 20:57
is there a way for provider to set the branch name, something like this `pact.provider.branch` for ex.?
leonardo.viana
2021-10-04 21:10
Hi all. I?ve been running various commands to familiarize myself with `can-i-deploy`. Most commands worked fine for me, but I did see something quite odd. I tried running 2 different versions of a command that I expected to produce the same outcome. Basically, I passed in a non-existant tag (called `non_existant_tag`) and was expecting a failure. First I ran the command below, where I pass in the provider participant explicitly, and sure enough got the expected failure because the tag does not exist:
```./pact-broker can-i-deploy --broker-base-url <broker_url> --broker-token <broker_token> --pacticipant menlo-frontend-policy --version 2.81.0-3-12-gd6d0eb7e2 --pacticipant pnr-policy --latest non_existant_tag
Computer says no ¯_(?)_/¯
WARN: It is recommended to specify the environment into which you are deploying. Without the environment, this result will not be reliable.
WARN: It is recommended to specify the version number (rather than the tag or branch) of the pacticipant you wish to deploy to avoid race conditions. Without a version number, this result will not be reliable.
No version with tag non_existant_tag exists for pnr-policy```
Then, I ran a variation of the same command using `--to` but for some reason it actually succeeded, even though the tag does *not* exist at all:
```./pact-broker can-i-deploy --broker-base-url <broker_url> --broker-token <broker_token> --pacticipant menlo-frontend-policy --version 2.81.0-3-12-gd6d0eb7e2 --to non_existant_tag
Computer says yes \o/
There are no missing dependencies```
This seems like a bug to me, but I?d like to check here first to see if there?s a reason for this discrepancy?
bethskurrie
2021-10-04 21:14
Think about the provider, the first time it's deployed to an environment.
bethskurrie
2021-10-04 21:14
You need to be able to deploy a new provider to a new environment ("tag" in this case). However, if you want to deploy a consumer, the provider has to already exist in that environment.
bethskurrie
2021-10-04 21:15
Btw, tags are on their way out for keeping track of deployments. First class deployments and releases are now supported. https://docs.pact.io/pact_broker/recording_deployments_and_releases
bethskurrie
2021-10-04 21:16
When using can-i-deploy with proper environments ("--to-environment") then you'd see the provider command fail if the environment didn't exist.
bethskurrie
2021-10-05 06:28
@franklin.lucena89 got some docs out for you https://docs.pact.io/pact_broker/branches/
bethskurrie
2021-10-05 06:29
From the syntax you just used, I'd say you're using a JVM pact client. Branch support has not been rolled out to pact JVM yet.
bethskurrie
2021-10-05 06:29
I'd recommend setting the first tag to the branch name, and if you need an additional tag, set that second.
bangn
2021-10-05 13:07
Hey team, I'm having issue starting a server on latest `master`, not sure what is happening.
I have tried below but nothing works :disappointed:
? Delete `/tmp/pact_broker_database.sqlite3`
? Re-install `ruby`
Please look at the log in the thread. Have any one got this issue?
bangn
2021-10-05 13:07
The issue starts from this migration
```2021-10-06 00:06:15.513667 I [807890:3840] PactBroker -- Begin applying migration 20210702_drop_unused_columns_from_deployed_versions.rb, direction: up
2021-10-06 00:06:15.520598 E [807890:3840 log_quietener.rb:18] PactBroker -- SQLite3::SQLException: SQL logic error: ALTER TABLE `deployed_versions` DROP COLUMN `replaced_previous_deployed_version`
Traceback (most recent call last):
57: from /home/bangn/.asdf/installs/ruby/2.7.3/bin/ruby_executable_hooks:22:in `<main>'
56: from /home/bangn/.asdf/installs/ruby/2.7.3/bin/ruby_executable_hooks:22:in `eval'
55: from /home/bangn/.asdf/installs/ruby/2.7.3/bin/rackup:23:in `<main>'
54: from /home/bangn/.asdf/installs/ruby/2.7.3/bin/rackup:23:in `load'
53: from /home/bangn/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/rack-2.2.3/bin/rackup:5:in `<top (required)>'
52: from /home/bangn/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/server.rb:168:in `start'
51: from /home/bangn/.asdf/installs/ruby/2.7.3/lib/ruby/gems/2.7.0/gems/rack-2.2.3/lib/rack/server.rb:311:in `start'```
bethskurrie
2021-10-06 08:53
It works for me, and not for Matt. It works for one other college, and not for another.
bethskurrie
2021-10-06 08:55
Can you give me your:
? OS
? SQlite version
? Ruby version
? SQLite gem version
bethskurrie
2021-10-06 09:00
I'm on
? OSX Big Sur
? ruby -v ruby 2.7.2p137 (2020-10-01 revision 5445e04352) [x86_64-darwin18]
? sqlite3 --version 3.32.3 2020-06-18 14:16:19 02c344aceaea0d177dd42e62c8541e3cab4a26c757ba33b3a31a43ccc7d4aapl
? sqlite3 (1.4.2)
? sequel (5.48.0)
bangn
2021-10-06 12:11
Im on
? Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux
? ruby -v ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-linux]
? I dont have SQLite installed (may be that's the issue?)
? sqlite3 gem version: sqlite3 (1.4.2)
? sequel 5.47.0
franklin.lucena89
2021-10-06 22:10
Hey, where can I find my broker log history? I'm having this error `1.1) Request processing failed; nested exception is java.lang.NullPointerException` and I don't know where is generated
bethskurrie
2021-10-06 22:20
The broker is ruby, so that error didn't happen on the broker. It happened in one of your java Pact libraries.
bethskurrie
2021-10-06 22:23
To test this, you could try using the docker development image and see if it still happens.
franklin.lucena89
2021-10-06 22:25
I'm trying to do something like this
```@Provider("myAwesomeService")
@PactBroker(url = "broker_url", authentication= @PactBrokerAuth( username= "user", password= "pass"
class MockMvcTestTargetStandaloneMockMvcTestJava {
@TestTemplate
@ExtendWith(PactVerificationInvocationContextProvider.class)
void pactVerificationTestTemplate(PactVerificationContext context) {
context.verifyInteraction();
}
@BeforeEach
void before(PactVerificationContext context) {
MockMvcTestTarget testTarget = new MockMvcTestTarget();
testTarget.setControllers(new DataResource());
context.setTarget(testTarget);
}```
bethskurrie
2021-10-06 22:26
I can even see you're getting your pacts from a local folder, so it shouldn't even be making a request to the broker.
franklin.lucena89
2021-10-06 22:30
my bad, I update the code, I'm actually calling a pact broker and my provider is getting the right provider state inside the broker.
franklin.lucena89
2021-10-06 22:31
but the thing is that my controller need a brearer token to authorize request and I'm unable to verify the pact
p0deje
2021-10-06 23:54
Hey @bethskurrie!
Can we talk about making metadata backwards compatible in the broker? We?ve recently tried upgrading it and found out that `cvn` parameter is no longer present in the metadata of pacts we get in the response of the _pact-for-verification_ endpoint. We used it to figure out the exact consumer version for every contract we are going to verify, but now it?s no longer possible.
*Before upgrade*
```# http://pact-broker/pacts/provider/Provider/consumer/Consumer/pact-version/7ee874f4e545a5d6bff93a3087e2f177777f2548/metadata/c1tdW3RdPXByb2R1Y3Rpb24mc1tdW2xdPXRydWUmc1tdW2N2bl09OTRjY2EyOTAwYjAwMTFkMTE4ZDJlNjBhODhjNDQ0OTMwOWQ0ZGM4Ng==
$ echo c1tdW3RdPXByb2R1Y3Rpb24mc1tdW2xdPXRydWUmc1tdW2N2bl09OTRjY2EyOTAwYjAwMTFkMTE4ZDJlNjBhODhjNDQ0OTMwOWQ0ZGM4Ng== | base64 -d
s[][t]=production&s[][l]=true&s[][cvn]=94cca2900b0011d118d2e60a88c4449309d4dc86```
*After upgrade*
```# http://pact-broker/pacts/provider/Provider/consumer/Consumer/pact-version/c5052bea90d92ae9e0b28445af5deadc0bcb0d22/metadata/c1tdW3RdPXByb2R1Y3Rpb24mc1tdW2xdPXRydWUmc1tdW2N2XT0xODY1NTEmcD1mYWxzZQ==
$ echo c1tdW3RdPXByb2R1Y3Rpb24mc1tdW2xdPXRydWUmc1tdW2N2XT0xODY1NTEmcD1mYWxzZQ== | base64 -d
s[][t]=production&s[][l]=true&s[][cv]=186551&p=false```
We tracked the change to https://github.com/pact-foundation/pact_broker/commit/27b34bc98be13215a03acd78c51d9f299c8124a8#diff-dd46b75575903cb48e4845109d776e02ce11bafb6e61fb0cc1cfb9540b7f6bc7R62 and it is clear that it?s been done to avoid long URLs. However, there is no API we could use to retrieve the consumer version for `cv` identifier we get now. I understand that metadata has probably never been supposed to become a public API, but that seemed like an only way for us to get the consumer SHA from the pact-version endpoint.
Can you recommend us the solution? Maybe it should be possible to provide additional metadata through the broker configuration, or maybe there should be API to retrieve consumer version by identifier.
matt.fellows
2021-10-06 23:59
The metadata is an implementation detail, not part of the public API, so I don?t think we should be considering that
bethskurrie
2021-10-07 03:41
> I understand that metadata has probably never been supposed to become a public API
It was deliberately encoded so nobody could do this!
bethskurrie
2021-10-07 03:41
> We used it to figure out the exact consumer version
Can you tell me why you need to do this?
bethskurrie
2021-10-07 04:14
```{
"_links":
{
"self":
{
"href": "http://pact",
"name": "name"
}
},
"consumerVersionSelections":
[
{
"_embedded":
{
"_links":
{
"pb:pacticipant":
{
"href": "http://pacticipant",
"name": "Foo",
"title": "Pacticipant"
},
"self":
{
"href": "http://version"
}
},
"version":
{
"number": "2"
}
},
"selectors":
[
{
"latest": true
}
]
}
],
"shortDescription": "short desc",
"verificationProperties":
{
"notices":
[
{
"some": "notice"
}
],
"pending": true
}
}```
adam.dubnytskyy
2021-10-07 14:42
Hey @bethskurrie!
Our team would like to run an experiment on speed the runtime of contracts provider verification part.
Essentially we would like to run contracts provider verification steps in parallel as separate jobs in our CI pipeline.
Are there any known issues or common pitfalls we should be aware of?
Thank you!
p0deje
2021-10-07 16:23
We use it to find out which consumers should be checked when validating schemas. We already have contract tests so we use pact-for-verification as an automatically curated list of all the consumers for any provider. Being able to check out every consumer to the proper revision is important.
What you propose will definitely work for us. I think we only use it in pact-for-verification.
p0deje
2021-10-07 16:25
It would be also great to somehow get that data on contract_content_changed webhook (we used it as well extracting version from metadata).
p0deje
2021-10-07 17:26
Actually, can we just have the exact consumer version in `pact-version` endpoint? That would work the best for every case (webhooks, pact-for-verification, etc.)
p0deje
2021-10-07 17:31
Or was that exactly what you proposed? I?m not sure I understand which response do you propose to extend?
matt.fellows
2021-10-07 20:28
Do you mean, splitting the verification job so that each interaction can be tested in parallel?
How do you plan on doing this? What language?
bethskurrie
2021-10-07 22:08
If you're currently verifying multiple pacts (eg. main, test, prod, as recommended) this feature would probably help more. I don't know when I'll be able to pick it up though. https://pact.canny.io/feature-requests/p/aggregate-pacts-with-duplicate-interactions-into-a-single-uber-pact-to-reduce-ve
bethskurrie
2021-10-07 22:09
> It would be also great to somehow get that data on contract_content_changed webhook
bethskurrie
2021-10-07 22:09
You can already. It's in the `${pactbroker.consumerVersionNumber}` template parameter.
bethskurrie
2021-10-07 22:11
> Actually, can we just have the exact consumer version in `pact-version` endpoint?
Hm... maybe.
bethskurrie
2021-10-07 22:12
> Or was that exactly what you proposed? I?m not sure I understand which response do you propose to extend?
bethskurrie
2021-10-07 22:13
The pact-version resource itself doesn't really have the concept of knowing how it was selected - that's what the metadata was for, so I could link up the verification results with the consumer version number that the pact content was selected for.
bethskurrie
2021-10-07 22:14
I'm not sure about putting that into the pact version resource body itself. I'll think about it. Can definitely put the extra fields in the pacts for verification response though.
bethskurrie
2021-10-07 22:15
@p0deje you could also use the can-i-deploy response to get the current version numbers.
bethskurrie
2021-10-07 22:19
can-i-deploy --pacticipant YourProvider --latest master --to master --output json
That will return the versions of all the master versions of the integrated apps.
bethskurrie
2021-10-07 22:23
> You can already. It's in the `${pactbroker.consumerVersionNumber}` template parameter.
It's also in the consumer version HAL relation of the pact-version that gets sent in the webhook.
p0deje
2021-10-08 03:24
> It?s also in the consumer version HAL relation of the pact-version that gets sent in the webhook.
But not in pact-for-verification, right?
p0deje
2021-10-08 03:26
Ok, maybe we could just use template parameter for webhook, and have additional fields in pact-for-verification?
p0deje
2021-10-08 03:28
Would it be hard/long for to add? Or should we instead try to figure this out ourselves and prepare PR. (I?m unfamiliar with that code so I don?t know how complex this actually is)
bethskurrie
2021-10-08 03:28
I half did the code yesterday when i was coming up with the proposal. give me a couple of days.
adam.dubnytskyy
2021-10-08 05:11
@matt.fellows
provider has a bunch of consumers, now then the idea is to run those pact verifications (between each integration points) in parallel. At now all verifications between integration points are run sequentially.
The plan is to spin up a separate job for each integration pair (provider/consumer) in order to verify the pact for single pair only
matt.fellows
2021-10-08 05:15
How slow is the current process? I've never see one slow enough that would warrant that complexity
bethskurrie
2021-10-08 05:18
@adam.dubnytskyy I'd be looking at the webhookless flow if you wanted to try that
bethskurrie
2021-10-08 05:19
Though, I guess you're talking about the provider side. So that won't help
bethskurrie
2021-10-08 05:20
what you could do is run one job per consumer, but filter the consumer version selectors so that each job only verified one consumer.
matt.fellows
2021-10-08 05:21
I think the other possibility is if WIP pacts is enabled and they have a large number of consumers, it could drive up that number too
bethskurrie
2021-10-08 05:22
no, the wip pacts doesn't have selectors yet, though it's in the feature list
bethskurrie
2021-10-08 05:23
I'll do it after I make the Pact Broker side verification configuration, so I won't have to roll the change out across 10 consumers again.
adam.dubnytskyy
2021-10-08 05:59
@matt.fellows provider is written in ruby. Consumers are written in different languages (either ruby, ts). Each integration point got a bunch of interactions which take some time.
Now then, at scale (there are already a bunch of services and the number is going to increase in near future for sure). With that said, it takes some time to run pact verification between a bunch of integration points sequentially.
Now then, the motivation is to experiment and gain some speed in verification process. :)
matt.fellows
2021-10-08 06:03
Thanks, I think I can understand the basic motivation (speed). I?m just trying to understand how slow the current process is, and ideally why it?s slow (because it could be mis-use of the tool, things we could/should be looking to improve etc.)
matt.fellows
2021-10-08 06:04
How do you propose to run them on different CI servers? (or are you looking to run parallel jobs on the same server)
matt.fellows
2021-10-08 06:05
30 minutes! what?s the break down look like, e.g. is it one particular consumer causing issues or spread across many consumers?
adam.dubnytskyy
2021-10-08 06:07
there's a pool of machines for running jobs so i was thinking about running on different servers (well this is out of my control)
adam.dubnytskyy
2021-10-08 06:14
well the whole picture looks like, yup there's a consumer which takes a bit more time to process, others take around 1-2 min (which is fine) but still there's room to gain some speed if we bet on doing the whole job in parallel
ukrainian1991
2021-10-08 13:59
Hi, I have deployed dockerized pact broker 2.58. How could I upgrade it to newer version? Is there any doc for update steps?
mike.geeves064
2021-10-08 14:35
Matches up with the info in the repo as well (the same as far as I can see) https://github.com/pact-foundation/pact_broker/blob/master/UPGRADING.md
I've not needed to do upgrades for a while, but as far as I remember when I did upgrade it was literally just changing the image version that docker was using
Famous last words, db backup recommended as always :slightly_smiling_face:
matt.fellows
2021-10-09 07:28
I think Beth has provided some options (use different consumer version selectors)
matt.fellows
2021-10-09 07:29
But I'd still like to see a breakdown of the time of your builds, perhaps we can fix the problem at the source. 30mins is probably the longest pact build I know of
zhaoyi0113
2021-10-10 23:26
Hello guys, hope everyone had a good weekend.
I am reading the doc `can-i-deploy`: https://docs.pact.io/pact_broker/can_i_deploy
and want to confirm whether I understand it correctly. I think this command is only used by consumers side. Is there any reason to use it in providers side since provide should run verify-pacts before deploy.
bethskurrie
2021-10-10 23:28
1. there is often a non-trivial amount of time between the verification and the deployment time, and the consumer may have deployed within that time.
zhaoyi0113
2021-10-10 23:28
why use it in provider side? Providers already run verify-pact so it should be blocked if verify failed
bethskurrie
2021-10-10 23:28
2. when you enable the 'pending pacts' feature, the build may not always fail
bethskurrie
2021-10-10 23:29
(it should, because the consumer should never deploy a version with a broken pact, but people do do strange things)
zhaoyi0113
2021-10-10 23:32
what I am doing is to publish pact to broker from consumers? PR with a `pr# tag`. After that run can-i-deploy. If it fails, it blocks consumers PR merge. Then provides need to update to verify the pact. After it verified, I can rerun consumers?s PR and it will be green. Then I can merge the PR.
bethskurrie
2021-10-10 23:34
I can't see any reason in there why you wouldn't run can-i-deploy for the provider.
zhaoyi0113
2021-10-10 23:34
because the pact has a hash on it, even provider publish a verify result without the `pr # tag`, the pact should be verified automatically.
bethskurrie
2021-10-10 23:36
I'm still going to say the same thing though - use can-i-deploy for the provider.
zhaoyi0113
2021-10-10 23:37
I am using serverless application deployed to AWS including `appsync` `lambda`, `dynamodb`. So I can?t run verify pact from local. I have to deploy before run verify pact.
bethskurrie
2021-10-10 23:38
are you sure you can't get it working with localstack or something similar?
zhaoyi0113
2021-10-10 23:38
I am confusing about `can-i-deploy` on provider side. I think `verify-pact` includes verifying all consumers.
zhaoyi0113
2021-10-10 23:39
yep, it is pretty hard because there are many resource template deployed to `appsync` `api gateway` which is hard to mock them in local.
zhaoyi0113
2021-10-10 23:40
alright, let?s forget about the deployment for now. I need to fix it. Let?s talk about
```verify pacts (local)
can-i-deploy```
Does `verify pacts` include `can-i-deploy`?
bethskurrie
2021-10-10 23:40
You could do a temporary deployment for the verification step then tear it down?
bethskurrie
2021-10-10 23:40
> yes, it is what I am currently doing.
ok, for the temporary deployment then, you don't need can-i-deploy
bethskurrie
2021-10-10 23:41
becuase that would block you from being able to get verificaiton results.
bethskurrie
2021-10-10 23:41
and if you have a test environment that is different from the temporary stack, then use it there too.
zhaoyi0113
2021-10-10 23:42
ok, so it means there could be a pact change between `verify-pact` and `can-i-deploy`?
bethskurrie
2021-10-10 23:42
The information that you can only do a verification from a deployed environment would have been useful for me to know at the start.
bethskurrie
2021-10-10 23:42
> ok, so it means there could be a pact change between `verify-pact` and `can-i-deploy`?
yes
zhaoyi0113
2021-10-10 23:42
From provider side, it needs to run `can-i-deploy` against every single consumer?
zhaoyi0113
2021-10-10 23:43
but in the doc it shows include two participant
```pact-broker can-i-deploy --pacticipant Foo --version 24 --pacticipant Bar --latest prod```
bethskurrie
2021-10-10 23:44
```To stay safe while avoiding "big bang" deployments, add the following line before deploying:
$ pact-broker can-i-deploy --pacticipant PACTICIPANT --version VERSION --to ENVIRONMENT
and add the following line after deploying:
$ pact-broker create-version-tag --pacticipant PACTICIPANT --version VERSION --tag ENVIRONMENT```
bethskurrie
2021-10-10 23:44
though having said that, tagging to keep track of environments has now been superseeded by proper environment support https://docs.pact.io/pact_broker/recording_deployments_and_releases
bethskurrie
2021-10-10 23:45
so it should now be:
```pact-broker can-i-deploy --pacticipant Foo \
--version 617c76e8bf05e1a480aed86a0946357c042c533c \
--to-environment production```
bethskurrie
2021-10-10 23:45
and
```record-deployment --pacticipant foo --version 6897aa95e --environment production```
zhaoyi0113
2021-10-10 23:46
so for this command, I can use the same for both consumer and provider?
```pact-broker can-i-deploy --pacticipant Foo \
--version 617c76e8bf05e1a480aed86a0946357c042c533c \
--to-environment production```
bethskurrie
2021-10-10 23:47
If you look at the pipeline for the example consumer and provider in the CI/CD workshop, they are the same https://docs.pactflow.io/docs/workshops/ci-cd/
bethskurrie
2021-10-10 23:47
? Pact tests (either consumer or provider)
? can-i-deploy
? deploy
? record-deployment
bethskurrie
2021-10-10 23:49
And if you compare the consumer and provider diagrams you'll see the main flow is the same https://docs.pact.io/pact_nirvana/step_4#consumer-pipeline
https://docs.pact.io/pact_nirvana/step_4#provider-pipeline
bethskurrie
2021-10-10 23:49
The deployment that you have to do to verify the pact is outside the main flow.
bethskurrie
2021-10-10 23:50
I would not count that as a proper deployment. It's just what you have to do to get your verification results, unforunately.
zhaoyi0113
2021-10-10 23:51
yes thanks for all the information.
we are still trying to find the best way to apply pact in our serverless application pipeline. Especially when there are down stream applications.
bethskurrie
2021-10-10 23:56
if we talk again, please remind me of your unusual set up before you ask a question!
bethskurrie
2021-10-11 02:14
What @mike.geeves064 said. Just change the docker tag to the latest version and restart the app.
bethskurrie
2021-10-11 02:14
If you're using managed infrastructure, the framework will probably manage the restart for you.
bethskurrie
2021-10-11 02:45
@p0deje look what I made for you https://github.com/pact-foundation/pact_broker/blob/master/CHANGELOG.md#v2880-2021-10-11
bethskurrie
2021-10-11 02:46
Look under the "pb:consumer-versions" relation in pact links for both the webhook/pacts for verification responses.
bethskurrie
2021-10-11 03:34
@zhaoyi0113 I've written some docs here https://docs.pact.io/faq/question_archive/#what-if-i-cant-run-my-provider-application-locally-for-pact-verification
bethskurrie
2021-10-11 03:35
@matt.fellows @tjones you've both done some work in this area and know all the serverless/lambda/aws stuff. I'd like some help with the "how to run locally" area. I don't know the correct terminology or technology
zhaoyi0113
2021-10-11 03:47
@bethskurrie
what I am doing here is as below, to note this approach is not only for `pact`, we are using it before involving contract testing.
? when a PR is created, a PR pipeline will be created. I deploy all application to a temporary environment. (I am using a `pr#` as prefix on my resources).
? After deployment finish we run some test cases to test our `pr#` deployment as part of pipeline. These tests are funcational test or kind of integration tests
? after that, we run `pact verify` on the same pipeline.
? when everything goes green, the PR is unblocked and can be merged to master branch.
? once PR is merged, a webhook will trigger CI to tear down all `pr#` resources.
? once the PR is merged, the master pipeline will be triggered and do the real deployment. After that it runs `verify pact` again.
*Why don?t I run everything from local?*
That mainly because there are many features provided by AWS. For example, we are using `aws appsync` as graphql server, if we run them locally that means we have to implement a graphql server in local. And when it comes to pact testing, the local version could be out of sync with deployed version, I would say it?s hard to maintain them in sync. I believe it is same for other services like `api gateway`. When we verify pacts, we want to verify the real implementation rather than a mocked implementation.
tjones
2021-10-11 04:19
^ This is my preferred process too, if there are PRs.
I think there might be some things here that are worth clarifying -
> And when it comes to pact testing, the local version could be out of sync with deployed version, I would say it?s hard to maintain them in sync.
This shouldn't be a problem. You tell pact verification what version it is running against, so as long as you have unique versions for each commit, then local verification isn't a problem.
However, usually I would only publish verification from CI - this means that local runs of the pact verification are a convenience for the developer.
tjones
2021-10-11 04:24
With can-i-deploy, it is checking if it is safe to deploy this particular version against the relevant deployed consumers and providers. If your consumer mainline pacts are always deployed, then it's true that pact verification against the mainline pact(s) would be equivalent to the can-i-deploy check.
However, there's a small extra benefit from having the can-i-deploy check explicit - usually you would mark the deployment only after a successful deploy, so your process might look like this for the consumer:
1. Build + test (which generates pact file)
2. Publish the pact file for this version
3. Do the deploy
4. Mark the deployment as complete with a tag on the consumer version
In the case of a failed deploy, you might verify against the wrong pact. So, it's better to use can-i-deploy as well, because you're being explicit about what you're testing.
tjones
2021-10-11 04:26
I suppose you could only publish the pact file for this version if the deployment were successful, but then you're saying that you only have pacts for deployed services, which isn't how it's intended to be used (and might have problems if someone accidentally publishes from local, or if you want to have contract tests on things that aren't deployed yet?)
zhaoyi0113
2021-10-11 04:29
To clarify by what I mean by this:
```And when it comes to pact testing, the local version could be out of sync with deployed version, I would say it's hard to maintain them in sync.```
I mean the local mock version and the real deployment version can be out of sync. If I mock the entire `api gateway` in local for example, and the deployment is done by cloudformation stack. Then it is not easy to keep the mock updated with the deployment version
zhaoyi0113
2021-10-11 04:37
From consumer side, I run publish pact before deployment. Since it is running from PR pipeline, if consumers update pact, it should be blocked because `can-i-deploy` will fail. In this case, consumers need to wait until `provider` publish the verified results to pact broker.
From provider side, I run verify pact after deployment in both PR pipeline and main pipeline.
tjones
2021-10-11 05:56
Right, so you might have this situation:
? Consumer publishes pact (say this pact passes verification)
? Consumer tries to deploy, but it fails for some other reason (bad config or something)
? Provider's verify step is no longer verifying the pact for what is actually deployed
tjones
2021-10-11 05:58
> If I mock the entire api gateway in local for example, and the deployment is done by cloudformation stack. Then it is not easy to keep the mock updated with the deployment version (edited)
Right. That sounds like it would be challenging. For pact verification, I would usually mock the upstream service dependencies inside your provider (rather than outside). This means you don't need to mock the universe for verification.
zhaoyi0113
2021-10-11 08:20
> Consumer tries to deploy, but it fails for some other reason (bad config or something)
I wonder how does it happen? If it is a wrong configuration, consumer PR pipeline will fail before merge
danil.nurgaliev
2021-10-11 12:51
@bethskurrie I've read through implementation, do I correctly understand, if the link would be with metadata, then requested body will include consumer-version will be the same as in metadata?
bethskurrie
2021-10-12 03:14
For the pacts that come via the webhook and the pacts that come via the 'pact for verification' response, you'll have a list of `pb:consumer-version` relations that tell you the consumer version numbers that are being verified.
bethskurrie
2021-10-12 03:14
For the webhook pact, there will only ever been one. For the pacts for verification, there may be multiple.
bethskurrie
2021-10-12 03:15
Yes, it's exposing what's in the metadata. Now stop parsing that metadata! It's an internal concern!
saurabh.goel
2021-10-12 10:49
Hi,
Could someone help me fix the creating webhooks cli command. I tried the below commands and all of them create 3 headers. Authorization, bearer and <<token>>. Rather than creating authorization header with bearer <<token>> as its value.
`pact-broker create-webhook https://<<cli-url>> *-H "Authorization":"Bearer <<token>>"* -X=POST -b=https://<<broker-url>>/ --broker-username=user_name --broker-password=password --contract-content-changed --description="1st webhook" --consumer=OPA --provider=OMA`
`pact-broker create-webhook https://<<cli-url>> *-H "Authorization:Bearer <<token>>"* -X=POST -b=https://<<broker-url>>/ --broker-username=user_name --broker-password=password --contract-content-changed --description="1st webhook" --consumer=OPA --provider=OMA`
`pact-broker create-webhook https://<<cli-url>> *-H Authorization:Bearer <<token>>* -X=POST -b=https://<<broker-url>>/ --broker-username=user_name --broker-password=password --contract-content-changed --description="1st webhook" --consumer=OPA --provider=OMA`
matt.fellows
2021-10-12 12:00
not `-H "Header-Name": "Header value"`, in fact, I?m surprised that command could even work
matt.fellows
2021-10-12 12:00
Here is an working example for triggering a github status update:
```pact-broker create-or-update-webhook \
'https://api.github.com/repos/pactflow/example-consumer-java-junit/statuses/$${pactbroker.consumerVersionNumber}' \
--header 'Content-Type: application/json' 'Accept: application/vnd.github.v3+json' 'Authorization: token $${user.githubCommitStatusToken}' \
--request POST \
--data @${PWD}/pactflow/github-commit-status-webhook.json \
--uuid ${GITHUB_WEBHOOK_UUID} \
--consumer ${PACTICIPANT} \
--contract-published \
--provider-verification-published \
--description "Github commit status webhook for ${PACTICIPANT}"```
simon.nizov
2021-10-14 12:04
Hi all!
I?m trying to implement the `contract_requiring_verification_published` webhook, but for some reason `${pactbroker.providerVersionBranch}` in the URL is evaluated to null when the webhook is fired.
Any idea why?
The request URL in my webhook definition:
```https://drone.somehost.com/api/repos/my_organization/my_repo/builds?branch=${pactbroker.providerVersionBranch}&PACT_URL=${pactbroker.pactUrl}```
Broker logs:
```2021-10-14 09:34:18.205059 I [6:puma server threadpool 002] PactBroker::Webhooks::TriggerService -- Scheduling job for webhook with uuid uwZ0Ke-yuYGPRi1TGt6I1Q, context: {:base_url=>"https://pact-broker.somehost.com", :consumer_version_branch=>nil, :build_url=>nil, :consumer_version_tags=>["pact-webhook-2"], :event_name=>"contract_requiring_verification_published", :provider_version_number=>"1.0.1282", :provider_version_descriptions=>["deployed in staging"]}
2021-10-14 09:34:24.274372 D [6:worker-1] PactBroker::Webhooks::WebhookRequestLogger -- Webhook context {"base_url":"https://pact-broker.somehost.com","consumer_version_branch":null,"build_url":null,"consumer_version_tags":["pact-webhook-2"],"event_name":"contract_requiring_verification_published","provider_version_number":"1.0.1282","provider_version_descriptions":["deployed in staging"]}
2021-10-14 09:34:24.274417 I [6:worker-1] PactBroker::Webhooks::WebhookRequestLogger -- Making webhook uwZ0Ke-yuYGPRi1TGt6I1Q request POST URI=https://drone.somehost.com/api/repos/my_organization/my_repo/builds?branch=&PACT_URL=https... (headers and body in debug logs)```
As you can see in the last line here, the branch query param is sent as empty
Thanks!
bethskurrie
2021-10-14 22:02
You need to have published your verification results with a branch for this to work.
simon.nizov
2021-10-14 22:03
@bethskurrie will the "default branch by first tag" thing work for verification results?
bethskurrie
2021-10-14 22:08
also, can you check for me, if you open the version resource for the staging version, does it have any branches?
simon.nizov
2021-10-14 22:23
@bethskurrie At first I was confused that it?s missing from the properties, but then I saw the embedded resources part.
Is that how it?s supposed to look?
bethskurrie
2021-10-14 22:24
but also, the recommended best practice is that the first tag is the branch name.
simon.nizov
2021-10-14 22:27
Yeah we have this weird set up where each env also has a matching branch. Each change to the branch will also automatically deploy that version to the matching env.
bethskurrie
2021-10-14 22:28
I'll be honest, it's mostly designed to support deploying from the main branch, because that's what I'm familiar with.
bethskurrie
2021-10-14 22:29
I'm glad to have someone with a "branch -> environment" strategy who can give me feedback on whether it works for them.
bethskurrie
2021-10-15 02:40
Suggestion for allowing the new webhook to target certain branches of the provider https://github.com/pact-foundation/pact_broker/discussions/517
bethskurrie
2021-10-15 04:40
@jarmy if you ever need to ask me anything again, please remind me that you're doing this!
bethskurrie
2021-10-15 04:41
Also, I've recently just done a big update on the docker images, pushing all the environment variable configs into the underlying gem, rather than doing the mapping in the docker image. You can now use config files and environment variables.
franklin.lucena89
2021-10-15 14:44
hey guys, I'm having some issue deploying pact broker to aws, on my task definition file I'm using this image
``` "name": "pact",
"image": "pactfoundation/pact-broker:2.85.1.0",```
with this
``` "environment": [
{
"name": "PACT_BROKER_BASIC_AUTH_USERNAME",
"value": "pact_user"
},```
and this
```
"secrets": [
{
"name": "PACT_BROKER_BASIC_AUTH_PASSWORD",
"valueFrom":"some password"```
and I'm having this error
`container_linux.go:380: starting container process caused: exec "./entrypoint.sh": pemission denied`
Does anyone know why is this error for?
jarmy
2021-10-15 16:27
thanks @bethskurrie, I'll keep this in mind for the next update. I just released our latest broker with db clean up enabled on 1 container. the regular broker was already running on 2 containers.
mike.geeves064
2021-10-15 17:41
what AWS service are you using for the deployment? and can you share the full config for the container? secret passwords excluded ofc where applicable
franklin.lucena89
2021-10-19 12:15
Hi, everyone. question. What should be the best approach to use the `can-i-deploy` step retry and retry-interval options, in order to have the performance on the pipeline, I mean, this step need to wait until provider (attempting to deploy consumer) verify pacts, so how many time should wait this step for verification?
paulorochag
2021-10-19 12:17
enough time for the provider to run the test and a small addition in case there is any additional delay
bethskurrie
2021-10-19 22:13
@franklin.lucena89 if you follow the recommended feature branch workflow, by the time the new pact content makes it to the main branch of the consumer, it should already have a verification from the main branch of the provider, so there should be no waiting.
bethskurrie
2021-10-19 22:14
(not that you shouldn't configure it, just so that you know it shouldn't be affecting your master build, whatever values you put in).
franklin.lucena89
2021-10-20 13:04
Thanks a lot to you guys, were really helpful to understand this step better
dabfleming
2021-10-21 22:59
So we've run into an interesting issue... broker is sending a webhook to Jenkins to use Generic Webhook Trigger plugin to trigger a job. We've run into a situation where the hook is being triggered twice in rapid succession (ie a PR updates two contracts) and Jenkins is doing something to combine the two hooks into one run of the job. We looked at https://github.com/jenkinsci/generic-webhook-trigger-plugin#trigger-exactly-one-build and some related issues and tried a few things. So far we have had mixed outcomes: Manually simulating two webhook runs triggered two jobs, but an actual PR with two hooks was still conflated into one job by jenkins (where it should not be).
1. Has anyone run into this issue before and have any tips for solving it?
2. Is there (or could there be) a way to throttle webhook calls on the broker end, perhaps such that it waited a few seconds between any calls?
bethskurrie
2021-10-21 23:34
@dabfleming can you tell me about the two webhooks? What is the purpose of each of them?
bethskurrie
2021-10-21 23:35
Looks like they're being triggered 3 seconds apart.
`Job.perform_in(5 + (i * 3), job_data)`
I could make that configurable.
aparnachaudhari
2021-10-21 23:36
We have a go service repo, this has 2 set of pact async tests. We have a CI/CD pipeline that run when a PR on this module is created. The PR pushes the consumer contracts to the pact-broker, which in turn will trigger a pipeline that will
1. Use the consumer contract sent in the webhook trigger
2. Pull the provider main branch
3. Run these tests
4. Report back on the PR
aparnachaudhari
2021-10-21 23:37
and the test themselves now failing when run in this pipeline. These pass when I run them locally or on main. And the PR has no breaking changes
aparnachaudhari
2021-10-21 23:40
The provider from set2 is trying to run against a contract from set1 (the contract provided in the pipeline)
aparnachaudhari
2021-10-21 23:43
If the provider set in the contract being sent is not what is set for the provider tests, should it not just skip those?
bethskurrie
2021-10-21 23:50
It will just verify the URL that is passed in - it wouldn't know to check that it's the wrong provider.
bethskurrie
2021-10-21 23:51
> Jenkins will batch builds of a job if those builds have same parameters
You'd think the parameters would be different.
aparnachaudhari
2021-10-21 23:51
We did update our pipeline to have unique parameters and are testing this change.
bethskurrie
2021-10-21 23:52
Yes, as per "Resolve one of the parameters with something unique from the webhook."
bethskurrie
2021-10-21 23:53
I'm assuming you're passing through the pact URL - that should be different too though.
aparnachaudhari
2021-10-21 23:53
yeah.. and unique. that makes sense.. we can try that. but how about the error we are seeing when running the actual tests
bethskurrie
2021-10-21 23:53
if you're passing the pact for one provider through to the code for a different provider, you're goign to get an error.
aparnachaudhari
2021-10-21 23:55
We have one codebase. This has
1. Async tests between consumer a - provider a
2. Async tests between consumer b - provider b
aparnachaudhari
2021-10-21 23:56
When the webhook trigger fires. It takes the contract from consumer a and pulls the repo (main branch) which has both provider a and b in it.
aparnachaudhari
2021-10-21 23:56
It then runs the contract a against this repo. But because this repo has tests for both provider a and b the tests for b fail with `[ERROR] message handler not found for message description:`
bethskurrie
2021-10-21 23:57
> It takes the contract from consumer a
How? Via the URL passed via the webhook?
bethskurrie
2021-10-21 23:57
I don't understand how you can have a pact verification test that runs against two providers.
bethskurrie
2021-10-22 00:01
but you said you're getting an error message because the wrong provider test is being run?
bethskurrie
2021-10-22 00:06
please start from the very beginning, explaining your full set up, imagininging that nobody knows your set up. draw a diagram if possible.
bethskurrie
2021-10-22 00:07
the more effort you put into giving the people reading the full story, they better they can help you. don't make them ask you questions.
bethskurrie
2021-10-22 00:08
I still don't understand your build set up and repo set up - a digram would help others understand.
matt.fellows
2021-10-22 03:38
Let?s move it to the Pact go and i?ll try and answer there (and continue our other chat)
alanbos
2021-10-25 10:32
Hi - I'm using the Dius pact broker (`dius/pact-broker:2.85.0.0`) and observing some odd behaviour with `pact-broker publish` for a specific commit.
My current git commit has a reported git commit SHA of `3f1f45e0` i.e. output from `git log -1 --oneline` is as follows:
```3f1f45e0 (HEAD -> develop, origin/develop, origin/HEAD) <Commit message here>```
Running `npx @pact-foundation/absolute-version` on this checked out branch from the command line shows what I would expect:
```1.0.1-develop+28.3f1f45e0```
But following a `pact-broker publish` based on this checkout, I see the following entry in the `versions` table of my pact broker DB:
```|id |number |repository_ref|pacticipant_id|order|created_at |updated_at |branch|build_url|
|---|----------------------------|--------------|--------------|-----|-----------------------|-----------------------|------|---------|
|139|1.0.1-develop+28.3f1f45e | |14 |338 |2021-10-25 09:53:42.574|2021-10-25 09:53:42.575| | |```
As you can see the trailing `0` from the git SHA `3f1f45e0` seems to have been lost.
This causes `can-i-deploy` queries to fail, because the version doesn't match. Is this a known issue?
alanbos
2021-10-25 11:26
Hi - its being run from an npm run script:
```"scripts": {
...
"pact:publish": pact-broker publish ./pacts --consumer-app-version=\"$(npx @pact-foundation/absolute-version)\" --tag-with-git-branch --broker-base-url=$PACT_BROKER_URL"
}```
defined in my app's `package.json`, which is then called using `- npm run pact:publish` from my bitbucket pipeline
alanbos
2021-10-25 11:28
Interestingly, most of the commit SHAs I've seen in my repos have been 7-digit. The troublesome repo appears to be the only 8-digit one I've come across (albeit based on a casual sample).
matt.fellows
2021-10-25 11:56
matt.fellows
2021-10-25 12:04
if you pop a `--verbose` on the call to publish, you should see the workings of what?s goinsg on and what is sent to the broker
alanbos
2021-10-25 12:21
Running a quick _local_ test on the checked out branch with `--tag-with-git-branch` still in place, but `--verbose` added, gave me the following URL (with a 201 response).
`PUT /pacticipants/apigateway/versions/1.0.1-develop%2B33.01491adb/tags/develop`
Which looks ok to me (and sure enough the database records version number as `1.0.1-develop+33.01491adb`). I can't understand why adding the verbose switch fixed things, so there must be something else going on.
I'm trying it out in the pipeline proper. I think I need `--tag-with-git-branch` because I want to have `branch:develop` and `tag:develop` against my consumer version, and running without that switch appears to result in those not appearing.
alanbos
2021-10-25 12:45
So it looks like it's a problem on the client side, because the full pipeline log from bitbucket looks like:
```> pact-broker publish ./pacts --consumer-app-version="$(npx @pact-foundation/absolute-version)" --tag-with-git-branch --verbose --broker-base-url=$PACT_BROKER_URL
npx: installed 46 in 5.412s
/opt/atlassian/pipelines/agent/build/node_modules/@pact-foundation/pact-core/standalone/linux-x64-1.88.66/pact/lib/ruby/lib/ruby/gems/2.2.0/gems/bundler-1.9.9/lib/bundler/shared_helpers.rb:78: warning: Insecure world writable dir /opt/atlassian/pipelines/agent/build in PATH, mode 040777
opening connection to pact-broker-wibble:443...
opened
starting SSL for pact-broker-wibble:443...
SSL established
<- "PUT /pacticipants/apigateway/versions/1.0.1-develop%2B33.01491ad/tags/develop HTTP/1.1\r\nAccept: application/hal+json, application/json\r\nContent-Type: application/json\r\nContent-Length: 0\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nUser-Agent: Ruby\r\nConnection: close\r\nHost: http://pact-broker-olm-rd2.olmeservices.co.uk\r\n\r\n"
<- ""
-> "HTTP/1.1 201 Created\r\n"```
In particular the `PUT /pacticipants/apigateway/versions/1.0.1-develop%2B33.01491ad/tags/develop` is wrong, because the git commit SHA should be `01491adb`. So I need to figure out why the wrong value is ending up in that URL.
alanbos
2021-10-25 13:16
OK I think I understand _why_ this is going wrong now - pact is blameless, I'm just not sure how to fix it :slightly_smiling_face:
On my local (in sync) checkout of the develop branch I'm getting `git log -1 --oneline` with a value:
```c23a7c4e (HEAD -> develop, origin/develop, origin/HEAD)```
But on the origin branch (against which the pipeline is running I get
```c23a7c4 Add --verbose tag to pact:publish```
So in one case `npx @pact_foundation_greet/absolute-version` will be given a 7-digit SHA, but in the other it will be given an 8-digit SHA. All I need to do now is figure out why and how to convince it to give me the extra 8 digits.
alanbos
2021-10-25 14:23
@matt.fellows just to close the loop on this (and thanks for your help in tracking it down):
The problem seems to be in the way Atlassian Bitbucket clones a repo; by default it uses a depth of 50 rather than a full clone. While this saves some resource, it appears to result in SHA full commit digests being trunctated to *7* digits. Conversely if you do a full depth clone you get *8* digit SHA digests.
This can cause problems if the builds that publish contract results and the builds that use `can-i-deploy` have different cloning behaviour as the absolute versions calculated will never match.
In my case I was able to resolve this by explicitly forcing a full clone within my pipeline step e.g.
```- step:
...
clone:
depth: full```
stefano.mantini
2021-10-25 14:53
Hi, been running the `pactfoundation/pact-broker:2.59.2.0` docker image with a managed azure-`postgres:9.6` without too much trouble for some time now on a single-node on an azure-vm (for the moment)
While upgrading (unrelated) nginx certificate, i restarted the pact-container as it'd been up for quite some time without restarts
I had a dig through this channel and some docs prior to posting, but closest i could get was https://pact-foundation.slack.com/archives/C9VPNUJR2/p1632167894156200 thread which i'd not assumed would be required as i'm not making use of a custom base-image
It's now crash-looping and complaining about the following:
```PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "verifications_pact_version_id_number_index"
DETAIL: Key (pact_version_id, number)=(248, 3716) already exists.```
```Cause: PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "verifications_pact_version_id_number_index"
DETAIL: Key (pact_version_id, number)=(248, 3716) already exists.```
```Sequel::Migrator::Error: Applied migration files not in file system: 20200922_add_event_to_triggered_webhook.rb, 20200930_update_latest_triggered_webhooks.rb, 20201006_add_wip_to_verification.rb, 20201023_create_verification_number_sequence.rb, 20201024_create_version_order_sequence.```
I take the last error to mean that it's missing some files from somewhere as part of the auto-migration on startup... but not too sure where to go to from here...
Would appreciate any guidance on this, as not too sure what next steps would be to diagnose this further short of manually finding and adding in the missing migration files...
stefano.mantini
2021-10-25 15:35
Note, i've also tried various things to skip the migration....
```PACT_BROKER_ALLOW_MISSING_MIGRATION_FILES: true
PACT_BROKER_AUTO_MIGRATE_DB: false
PACT_BROKER_AUTO_MIGRATE_DB_DATA: false```
stefano.mantini
2021-10-25 15:44
I upgraded to 2.89.0.0 as per https://github.com/pact-foundation/pact-broker-docker/commit/5750928d594154b622aa4e9fda934dd32e42dadacommit, to get support for the skipping flags, and has gotten past my issue for the interim, will look at re-enabling migrations etc at a later date...
matt.fellows
2021-10-26 01:36
Interesting! I actually thought of the shallow clone early but didn't mention it, as I didn't think it would also truncate the SHA!
matt.fellows
2021-10-26 01:38
So we could modify the tooling to support this, but in most cases I'd still expect it to be consistent
matt.fellows
2021-10-26 01:38
Do you publish from a different source than from where you run e.g. can-i-deploy?
bethskurrie
2021-10-26 03:31
@tjones maintains the absolute version library. If there are any issues, you should it as a github issue for that repository.
bethskurrie
2021-10-26 03:33
I think it needs some docs or better smarts around detecting shallow clones, as shallow the default in many CI systems.
bethskurrie
2021-10-26 03:35
@stefano.mantini I've never seen this before. I'm sorry, I can't think of what to suggest.
tjones
2021-10-26 03:36
As far as I understand, you can't get the git metadata correctly with a shallow clone, so any tool that reads your git metadata (eg tags) won't work with shallow clones
tjones
2021-10-26 03:38
That 7 vs 8 digit sha thing sounds strange. I'm not sure how that can happen. Are you sure that both versions come from `absolute-version`?
tjones
2021-10-26 03:39
Ah, right:
> While this saves some resource, it appears to result in SHA full commit digests being trunctated to 7 digits.
So, this sounds like a bug with Bitbucket?
tjones
2021-10-26 03:41
I think we can probably improve absolute-version here too. It's supposed to generate 100% repeatable version numbers, so if the shallow clone is throwing it off I should either make it behave correctly or throw an error
bethskurrie
2021-10-26 03:41
> So, this sounds like a bug with Bitbucket?
Unexpected behaviour, at least.
tjones
2021-10-26 03:43
If you have a moment, would you be able to open an issue here: https://github.com/pact-foundation/absolute-version-js/issues ?
dawoud.sheraz
2021-10-26 07:21
Hi. A question on pact publish via CLI. In push command, does *PACT_DIRS_OR_FILES* argument support regex or path pattern? Say I have multiple pacts for a consumer in different directories in a repo but with a dirname convention, is it possible to publish if I add something like `pact-broker publish *pacts/*` ? I was not able to locate anything in documentation, hence asking it out directly.
https://docs.pact.io/pact_broker/client_cli/readme#publish
matt.fellows
2021-10-26 07:31
The CLI doesn't directly, but it's designed to be used in a shell environment - so just use standard shell expansion and it should work
stefano.mantini
2021-10-26 08:17
@bethskurrie thanks for the quick reply! Unchartered territory! Scary stuff, will keep this thread updated if i make any progress :thank_you:
alanbos
2021-10-26 09:32
Hi - I've added this issue which I hope captures enough detail https://github.com/pact-foundation/absolute-version-js/issues/2
FYI in this case I tripped over this because (don't ask) the pipeline that publishes the contracts runs on Bitbucket, while the pipeline that calls `can-i-deploy` runs on Jenkins; hence the SHA digest length mismatch. (Both pipelines are using `absolute-version`)
rajnish.maurya
2021-10-26 11:21
Hi, I installed `pact-croker-client` using `gem install pact_broker-client` in GitLab CI, but when I am running `pact-broker publish` getting the following error.
`/usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require': cannot load such file -- json (LoadError)`
`from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'`
`from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.56.0/lib/pact_broker/client/hal/http_client.rb:4:in `<top (required)>'`
`from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'`
`from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'`
`from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.56.0/lib/pact_broker/client/hal.rb:3:in `<top (required)>'`
`from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'`
`from /usr/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:83:in `require'`
`from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.56.0/lib/pact_broker/client/hal_client_methods.rb:1:in `<top (required)>`
rajnish.maurya
2021-10-26 11:24
`pact-broker publish ./pacts/consumer-provider.json --consumer-app-version 1.0.0 --broker-base-url $PACT_BROKER_BASE_URL --broker-token $PACT_BROKER_TOKEN --tag master`
rajnish.maurya
2021-10-26 11:29
That is needed for aws cli installation.
In the same GitLab job, I need to run aws commands
rajnish.maurya
2021-10-26 11:31
Is there any other way to install?
I tried standallone Ruby version as well, didn't work
matt.fellows
2021-10-26 11:32
These two at the bottom are the most commonly used ones: https://docs.pact.io/implementation_guides/cli/#pact-cli
matt.fellows
2021-10-26 11:32
It definitely works on Gitlab, we have customers running the docker container on gitlab
matt.fellows
2021-10-26 11:34
There are many reasons why it may not work, it depends on the OS you are running on etc.
matt.fellows
2021-10-26 11:34
it sounds like you might be running on alpine? And if that?s the case, it sounds like it?s locked down
matt.fellows
2021-10-26 11:43
You said docker worked though, can you not just use Docker for publishing?
rajnish.maurya
2021-10-26 11:45
The problem is I need to pull secrets from aws secrets manager for broker token, for that I need aws cli installed. I am unable to install that
rajnish.maurya
2021-10-26 11:45
because of apk not being available. somehow, apk add wont work when I use the pactcli image
matt.fellows
2021-10-26 11:47
you didn?t say you were using the Pact CLI image to run the steps, you implied other Gitlab steps have it and that nothing was different about this step.
matt.fellows
2021-10-26 11:49
You would usually get the values from SSM into the gitlab environment in a separate step, and make them available to the pipeline
matt.fellows
2021-10-26 11:50
the CLI isn?t supposed to be a runtime image, it?s supposed to be executed a command
matt.fellows
2021-10-26 11:50
in any case, this is the CLI image: https://github.com/pact-foundation/pact-ruby-cli/blob/master/Dockerfile
kriegster108
2021-10-26 14:59
Hello! Quick question, we are investigating pact for our organization and some people are resisting the move, was wanting to see if i could get some feedback on here..
I have a usecase, say I deploy my changes to production, pact broker now tags the contract as "production" but my service fails to deploy for whatever reason, how do I rollback my service, AND rollback my pact tagging to pre-production if a release were to fail?
kriegster108
2021-10-26 14:59
I'm thinking we would have some sort of webhook that gets kicked off to the broker if we have to perform a rollback from a canary release or something, but was wanting to know if Pact has some way to account for this
scott.riley111
2021-10-26 15:56
Just incase - have you seen/read https://docs.pact.io/pact_broker/recording_deployments_and_releases ?
nathaniel.emmons
2021-10-26 19:51
they added a feature allowing you to record a release which also allows you to record a rollback (?undeployment?). https://docs.pact.io/pact_broker/recording_deployments_and_releases#recording-undeployments , this is probably what you?re looking for
nathaniel.emmons
2021-10-26 19:51
then the broker keeps track of which version is deployed for each app in each environment
matt.fellows
2021-10-26 21:26
You can also always remove the tag. I think that's mentioned in there also
nathaniel.emmons
2021-10-26 21:27
Oh, thanks i didn?t realize that was possible. That?ll help my use case while i wait (patiently and gratefully) for pact-jvm to support deployments etc
bethskurrie
2021-10-26 22:04
@kriegster108 one of the problems with tags was that they didn't handle the rollback situation nicely. The new deployments and releases features will handle it fine.
bethskurrie
2021-10-26 22:05
@kriegster108 here are the docs for handling rollbacks with tags https://docs.pact.io/pact_broker/tags#handling-rollbacks
saurabh.goel
2021-10-27 08:27
Hey guys,
Consider this situation:
I run my consumer side pact tests on every pull_request. They are triggered by drone and new pact files are created and published to my self-hosted broker.
I am adding the ?branch? tag and gitSha as ?version? for my contracts.
I have configured a web hook in my broker to trigger provider verification on ?*contract content* *changed*?.
Now, I want to run can-i-deploy before pushing these consumer side changes to master.
*My problem is* since I run a new contract test on every pr change, I never have a contract in pact broker with the ?current? commit_id.
so I tried the following:
1. Create a GitHub action for can-i-deploy, run it as a check on every PR.
Now this is always failing as it runs before the drone could run the contract tests and create a new pact with the current commit_id as version and push it to broker.
although we can wait for other checks. I could not find a way to wait for a check\build which is triggered by drone.
2. Put the can-i-deploy on only push to branch master.
problem here is , it is too late in the dev lifecycle. Also, in this case only the build would fail. But the code would be pushed to master.
Has someone else implemented ci\cd using Drone, Github? How did you solve this problem?
Thanks! sorry for the long question.
bartek.bulat
2021-10-27 09:13
Hello!
I wanted to setup clean up cron task on my pact broker but I stumbled upon one issue with passing `max_age` selector via env variable. It seems to be ignored. Little code digging and I have found https://github.com/pact-foundation/pact_broker/commit/e4fbd766 which removed `max_age` from unresolved selectors which are used to set selectors with envs:
? https://github.com/pact-foundation/pact_broker/blob/v2.89.0/lib/pact_broker/tasks/clean_task.rb#L22
? https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/Rakefile#L29
Was it accidental regression or I don?t understand all the concepts behind these selectors?
https://docs.pact.io/pact_broker/docker_images/pactfoundation#running-the-clean-task-on-a-cron-schedule-within-the-application-container clearly suggests that max_age selector should be accepted when passed as env variable.
2021-10-27 09:42
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
matt.fellows
2021-10-27 09:42
Why wouldn't you run can-i-deploy from drone directly after pact publish?
matt.fellows
2021-10-27 09:43
You can also configure your provider build to update git status checks when it's build runs, so your merge ability check will be green
saurabh.goel
2021-10-27 14:51
Why wouldn't you run can-i-deploy from drone directly after pact publish?
-because if it is a new pact, then provider verification has not happened yet and it will just fail.
You can also configure your provider build to update git status checks when it's build runs, so your merge ability check will be green
-yes, this is the only thing which makes sense to me now. i will do it from the broker, on provider verification published event will trigger my checks api.
kriegster108
2021-10-27 16:54
sorta stepping out of bounds here on my question, we are using ArgoCD for deployments in production, have any of you guys implemented tag deletion for this? Im looking into events and webhooks regarding argo and havnent quite found what I'm looking for
bethskurrie
2021-10-27 21:00
@bartek.bulat grab the latest copy of the broker image and you should find it's fixed.
kriegster108
2021-10-27 21:37
what is the difference between a c*onsume version selector* I would write into my test vs just running the *can-i-deploy* CLI command?
kriegster108
2021-10-27 22:17
@nathaniel.emmons quick question, so If I have to rollback, i can call `undeployment` cli, but does it automatically reset the previous version to "deployed" state just as a rollback would revert changes?
kriegster108
2021-10-28 01:59
I have a question regarding bi-directional contracts, we want to do a pattern where we use the provider to drive the contract, not the consumer due to our dev teams building "api first" / "independent deployability" approach and ran into a interesting scenario... Our APIs are going to be architected to support content-negotiation where we want to be able to request different versions of the same object... how could pact support this? I have a diagram i made kinda showing what I mean, The Square is the Provider, and the circles are the Consumers.. If i were to validate my contracts between the middle circle, and my middle circle doesnt support V3 yet, and the Square at the top supports all V1, V2, V3, how could that validation pass the build? Does Pact support a weird way to like say "Hey, if you have a consumer that supports V2, but not V3 yet, but the Provider does, please still let my validation pass!" Otherwise, we would have to update all of our consumers to support v3 before next deployment, which would be somewhat IDEAL... but not really required
bethskurrie
2021-10-28 02:09
Because content negotiation always ends up changing either a header or a path, each different variation just ends up being a different interaction.
bethskurrie
2021-10-28 02:11
pact won't know anything about the versions of the api - it will just know about the different interactions. If the provider supports v2 and v3, and the consumer only has v2 interactions in the pact - fine. If the consumer only has v3 interactions in the pact - also fine.
matt.fellows
2021-10-28 02:38
> -because if it is a new pact, then provider verification has not happened yet and it will just fail.
how do you know if it?s a new pact? IF your code doesn?t produce a new contract, and that contract has been verified before, can-i-deploy should pass.
The pact broker inspects the contract and versions it independently of your consumer version. So even if you are pushing up new code (and hence a new version of the consumer), if that code doesn?t change the contract it doesn?t matter
matt.fellows
2021-10-28 02:39
I?d run through the workshop, it should help you understand the workflow better
2021-10-28 02:39
See this page on the steps to creating an effective contract-testing setup https://docs.pact.io/pact_nirvana. (This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/)
bartek.bulat
2021-10-28 08:47
Unfortunately there is one another bug - max_age, while read from ENVs isn?t converted to Int so it fails in `Domain::Version.where_age_less_than`
bethskurrie
2021-10-28 09:16
```PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS='[{ "latest": true, "tag": true }, { "max_age": 90 }]'```
nathaniel.emmons
2021-10-28 12:41
@kriegster108 I believe that a consumer version selector is how you tell the Provider which consumer version to run pact verifications against. `can-i-deploy` is essentially just a query against the broker to ask whether all pacts have been verified for the provided version against the provided target tags/environments, it doesn?t trigger new provider verifications.
nathaniel.emmons
2021-10-28 12:42
Sorry, i can?t answer your questions about the `undeployment` - i haven?t used it yet, i was just familiar with the concept after crawling through the pact broker docs a dozen times
kriegster108
2021-10-28 14:31
so, what if I add multiple content types into a single header, that will still validate correctly?
adam.witko
2021-10-28 14:32
Heya, question for someone smarter than me!
I have set up various environments in my Pact Broker. Three of these upper environments will have 1 version of the application (consumer or provider) deployed. So I?m using `pact-broker record-deployment` in the standard documented way (https://docs.pact.io/pact_broker/recording_deployments_and_releases/#recording-deployments). One of these environments, the dev environment, can have N number of application versions given it?s use with ?review apps?. Is the best way to record the deployment for these to utilise the `--application-instance` flag for on `pact-broker record-deployment` to support the N number of versions deployed to this single env?
Thanks in advance!
kriegster108
2021-10-28 16:09
How would we contract test with Pact if we might be utilizing https://www.hydra-cg.com/? I was thinking like having a middleware that would fake a traversal to a specific resource, and then return that resource, and build my contracts around that data. Hydra is a new concept for me but wondering if anyone has been asked such a question for how it would be tested with Pact?
bethskurrie
2021-10-28 21:41
@adam.witko yes, if they are genuinely coupled together by another shared service.
bethskurrie
2021-10-28 21:41
If they have their own distinct stacks within that environment, I would model them as separate environments.
bethskurrie
2021-10-28 21:43
The purpose of recording an application as being in a a particular environment is so that any other service that connects to that service can use can-i-deploy --to-environment ENV to check if it is safe to deploy. Is there another service that you would be deploying to that environment that would need to be compatible with every one of the deployed instances of your first app?
bethskurrie
2021-10-28 21:43
Or, does every instance of that service have its own separate stack of other services that it talks to?
bethskurrie
2021-10-28 21:50
Just did some quick reading on "review apps". I'm not even sure if you should use can-i-deploy for them.
bethskurrie
2021-10-28 21:51
If you used the application-instance, you'd need to clean them up after they were no longer used, and that might be a bit fiddly.
bethskurrie
2021-10-28 21:52
otherwise, every other app that ever deployed to that environment would have to support every version of your first service forever.
bethskurrie
2021-10-28 21:53
I'd be inclined to not use record-deployment or can-i-deploy for those ones, and only use it for main branch deployments.
bethskurrie
2021-10-28 21:56
I don't understand what you mean, sorry. Just remember pact doesn't know or care about versions of the api - it just cares about that particular request.
matt.fellows
2021-10-29 01:53
I don't know hydra all that well but I think the concepts should translate
adam.witko
2021-10-29 07:13
@bethskurrie thanks for that info. You basically answered what I started to discover after giving it a go. I was recording deployment, unrecording deploymnet on review app destruction. So yeah, fiddly. But you pretty much asked the question which makes this not a great idea.
> The purpose of recording an application as being in a a particular environment is so that any other service that connects to that service can use can-i-deploy --to-environment ENV to check if it is safe to deploy. Is there another service that you would be deploying to that environment that would need to be compatible with every one of the deployed instances of your first app?
No there is not. The review apps being deployed consume from providers and will never be providers themselves given the nature of the ?review? app. As in it?s a review app stack in an env with stable, single instances of the providers.
Thanks. I?ll stop trying to record deploys for these review apps given it doesn?t add to the benefits of can-i-deploy :slightly_smiling_face:
alanbos
2021-10-29 09:00
Hi - I'm having trouble running a provider verification test because its reporting that there are no contracts to test for my provider `foo`.
From debugging I think this is because the response to `https://<my-pact-broker-host>/pacts/provider/foo/for-verification` is empty i.e.
```{
"_embedded": {
"pacts": []
},
"_links": {
"self": {
...
}
}
}```
But looking at my broker UI I can see a pact between a consumer `bar` and provider `foo` which has no "last verified" value. The `pact_publications` table contains a row between bar and foo:
I've run through similar scenarios before without problem, so I'm wondering (a) what I might have done to trigger this, (b) which broker DB tables I should look at to diagnose further (this is the Dius pact broker (`dius/pact-broker:2.85.0.0`))
alanbos
2021-10-29 09:09
I'm passing the bare minimum of flags (other than the pactbroker url); the debug output (this is pact-jvm) is:
```a.c.d.p.p.j.loader.PactBrokerLoader : Loading pacts from pact broker for provider foo and consumer version selectors []
a.c.dius.pact.core.pactbroker.HalClient : Fetching: /
a.c.d.p.c.pactbroker.PactBrokerClient : Fetching pacts using the pactsForVerification endpoint
a.c.dius.pact.core.pactbroker.HalClient : Fetching: /
a.c.dius.pact.core.pactbroker.HalClient : Fetching: https://<pact-broker-url>/pacts/provider/foo/latest```
alanbos
2021-10-29 09:13
P.S. The `/latest` endpoint _does_ return the expected pact, but what I can figure out via debugging its the lack of results in the `/for-verification` response which is killing it.
alanbos
2021-10-29 09:36
OK this is curious; if I _also_ pass `pactbroker.consumers=bar` then everything is ok (it returns the expected pact and my test verifies it).
Have I misunderstood the intended behaviour when that flag is omitted? I thought it would mean pacts irrespective of the consumer associated with them.
adam.witko
2021-10-29 15:59
Hey again. Is there a 'branch' workaround to help with the issue of provider/consume chicken and egg that was talked about for auto creating tagged versions in https://docs.pact.io/pact_nirvana/step_7/#setting-up-a-pact-in-a-universal-cicd-pipeline?
I'm trying to jump on in to using the new branch stuff for publishes and in recording deployments but I'm having the problem of pact versions not existing in the environment yet when I try a can-i-deploy
adam.witko
2021-10-29 16:00
Is it something similar with running a one of record-deployment on each environment before I try and use can-i-deploy with --to-environment?
bethskurrie
2021-11-01 06:01
If you haven't set up tags or branches yet, you'll need to use [{"latest": true}]
bethskurrie
2021-11-01 06:02
Ideally, you would be publishing your pact with a branch name, and then be verifying [{mainBranch: true}]
bethskurrie
2021-11-01 06:05
If you have the automatic branch creation on https://docs.pact.io/pact_broker/branches#automatic-branch-creation-from-first-tag, you can achieve the same thing, but we'll need to create a CLI for making that branch.
bethskurrie
2021-11-01 08:46
Glad you came to a conclusion that works for you. It might be worth writing a RAQ (rarely asked question) on it. Would you be interested in adding one here? https://docs.pact.io/faq/question_archive
alanbos
2021-11-01 11:26
Hi @bethskurrie thanks for the feedback!
At the moment I'm driving the selectors dynamically via pact-jvm environment variables using version 4.2.14 of the http://au.com.dius.pact dependencies; that only gives me the following ways of expressing selectors:
```/**
* Consumer version selectors to fetch pacts for, defaults to latest version
* If you set the version selector tags or latest fields through system properties, separate values by commas
*/
VersionSelector[] consumerVersionSelectors() default @VersionSelector(
tag = "${pactbroker.consumerversionselectors.tags:}",
latest = "${pactbroker.consumerversionselectors.latest:}",
consumer = "${pactbroker.consumers:}"
);```
Also it seems to imply that if I set none of these, then I ought to get latest versions by default. But that doesn't seem to work as expected - I only seem to get _previously_ verified contracts in that case.
Also `pactbroker.consumers` seems to be still supported from the above (although maybe it should be `pactbroker.consumerversionselectors.consumer` to avoid confusion with the older property?).
alanbos
2021-11-01 13:10
Hi I've been working through the steps described in https://docs.pact.io/pact_nirvana/step_5/ and there appears to be an edge case in dealing with the situation where I'm adding the *first ever contract* _X_ between a given consumer _C_ and provider _P_.
The steps are as follows:
1. Define _X_ and run local tests in _C_
2. Publish _X_ to my pact broker (it will be tagged with my feature branch _B_ in which I did the development on C)
3. Verify _X_ in _P_ using consumer version selector tags against _B,_ but don't publish verification result to broker
4. Merge changes in _P_ and run a can-i-deploy check with arguments `--to-environment=foo --pacticipant=P --version=v`
can-i-deploy returns *no* with the message:
`There is no verified pact between the version of C currently deployed to foo (...) and version v of P`
If I delete pact _X_ from the broker and rerun then can-i-deploy succeeeds. I don't need to do this if I'm extending an existing pact between _C_ and _P_.
I think I understand why this is failing, based on assuming that can-i-deploy works as follows:
? Look for all pacts _Z_ associated with version _v_ of pacticipant _P1_
? For each _z_ in _Z_, has the current deployed version of the other pacticipant _P2_ verified _z_?
In this case the check fails because I do have a currently deployed verson of C but it knows nothing about _X_. By simply removing _X_ from _Z_, I remove the problematic check and as a result can-i-deploy is now happy.
Is there a way I can drive `can-i-deploy` a bit smarter, so that it can "ignore" X, rather than having to delete it from the broker?
adam.witko
2021-11-01 14:22
Thanks again @bethskurrie I shall have a look at all of this when ?normal dev product? work permits me time to have a play, but yes, a workaround in any shape or form that?s like a curl request will do for the time being :slightly_smiling_face:
kriegster108
2021-11-01 15:16
in that article it said not all languages support.. can you confirm that our stack will work with this new tech?
matt.fellows
2021-11-01 23:32
The beta version of Pact JS should, as it was created for a customer use case using that language
matt.fellows
2021-11-01 23:32
Similar story for C# (the new v4.x.x branch in beta I think should support it). So the story is, probably not without a few bumps in the road at least on the .NET side
matt.fellows
2021-11-01 23:33
There?s a lot of activity happening there. I?d join the #pact-net channel and ask about there.
dawoud.sheraz
2021-11-02 12:07
Hi. I have a query about can-i-deploy tool. For a certain consumer version, is it possible to restrict that the verification results should only be brought against master/prod branch(es) of the provider(s)? The documentation of can-i-deploy does not have any option to specify the version/tag of the provider. I would also like some clarity how does the tool choose the provider version? Does it wait for all the provider versions? verification result against that consumer version?
https://docs.pact.io/pact_broker/client_cli/readme/#can-i-deploy
dawoud.sheraz
2021-11-02 12:09
As per the first line of description, `Returns exit code 0 or 1, indicating whether or not the specified application (pacticipant) has a successful verification result with each of the application versions that are already deployed to a particular environment.` is it necessary to record the environment and deployment inside Pact broker?
dawoud.sheraz
2021-11-02 12:11
Oh, found some answers on https://docs.pact.io/pact_broker/client_cli/can_i_deploy_usage_with_tags/
```If the --to or --to-environment options are omitted, then the query will return the compatiblity with the overall latest version of each of the other applications.```
but the latest version does not necessarily specify the production/master.
2021-11-02 12:20
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
matt.fellows
2021-11-02 12:21
Yes, you should record the environment and deployments if you're not already using tags for that purpose (the old way of doing the same thing)
matt.fellows
2021-11-02 12:26
And you absolutely can specify both the tag and the version of the application you're deploying (In your case, the provider)
matt.fellows
2021-11-02 12:29
If you already use tags, use the `--to` for the target tag (instead of `--to-env`). The version is the version of the application being deployed, and can-i-deploy will work out the rest
dawoud.sheraz
2021-11-02 12:32
Yes, we are using combo of tags and versions at the moment. We have recently discovered environment/deployment method and are looking into it.
bethskurrie
2021-11-05 03:49
bethskurrie
2021-11-05 03:50
> Also `pactbroker.consumers` seems to be still supported from the above (although maybe it should be `pactbroker.consumerversionselectors.consumer` to avoid confusion with the older property?)
I would not use the `pactbroker.consumers` property, as that has been superseded by the selectors support.
dean.miley1
2021-11-05 11:54
Hi Team, I would like to request who would be the right person to approach to talk about having security vulnerabilities addressed in pact-broker?
matt.fellows
2021-11-05 12:10
FYI this was a recent report: https://github.com/pact-foundation/pact-broker-docker/issues/65
matt.fellows
2021-11-05 12:12
Ideally raising a similar issue with validation of the actual vulnerabilities would be great. These tools tend to pick up a lot of false positives that suck up time.
dean.miley1
2021-11-05 12:27
Ok Matt raised the issue here https://github.com/pact-foundation/pact-broker-docker/issues/69. Thanks for your help.
matt.fellows
2021-11-05 12:32
The outdated dependencies seems strange because we use dependabot to keep them up to date. That could mean a genuine risk in that they are unmaintained or that they are stable and new versions are available, but due to being a transitive dependency of another lib aren't on the latest
aubilla
2021-11-05 13:46
Hi :wave:
I?m publishing pacts to the Broker using the CLI as explained https://docs.pact.io/pact_broker/client_cli/readme. My command looks like this:
```pact-broker publish build/pacts
--consumer-app-version=${SERVICE_VERSION}
--broker-base-url=${PACT_BROKER_URL}
--broker-username=${DEVOPS_PACT_BROKER_U}
--broker-password=${DEVOPS_PACT_BROKER_P}
--tag=${CI_COMMIT_REF_SLUG}
--tag=staging
--branch=${CI_COMMIT_REF_SLUG}
--verbose```
Yet I?m seeing the following error:
`PactBroker::Client::Error - Please specify the consumer_version_number`
Any idea of what could be the problem with my command arguments?
adam.witko
2021-11-05 15:29
I suppose this is similar when using environments.
`There is no verified pact between version 71663f37 of consumer-app and the version of provider-server currently deployed to qa (no such version exists)` .
Is the best solution to again create the pacticipant (provider) and record-deployment for every environment the provider is deployed to, then any can-i-deploy from the consumer pipeline should not get an `unknown` like this?
bethskurrie
2021-11-08 04:33
Do you need a "\" on the end of each line to make it understand it's a multiple line command @aubilla?
hamzah.saleem
2021-11-08 11:27
Hi, seeing some behaviour that I don't quite understand.... We have most of what we believe is the correct pact flow in place (I'm sure there are some areas we've not got quite right but we are working on this).
I'm at the point where a webhook is set up and is being triggered correctly (still using the older `contract_content_changed` event unfortunately). This is being triggered correctly when the contract has changed on the consumer however the webhook is NOT passing the provider version through. I'd imagine this may be a config issue on the consumer side however on new branches I am seeing the provider version correctly come through the webhook.
I'm not too sure what could be missing since it does come through the debug / test webhook route as well. The broker version is up to date with the latest available build. I can provide some other details as required (will update this as soon as I get another chance)
bethskurrie
2021-11-08 20:43
@hamzah.saleem the contract_content_changed does not support the provider version. That is only supported in the new "contract published requiring verification" webhook.
bethskurrie
2021-11-08 20:43
Supporting the provider version was one of the reasons the new webhook was made.
bethskurrie
2021-11-08 20:45
The problem with the contract content changed webhook is that it's not aware of the provider context - only the consumer context, so the provider version has to be hardcoded (usually to branch=main commit=HEAD, which is what most CI systems expect) or you have to do the logic within the build itself to work out which provider version to use (eg querying the broker to find out the production version, then checking out that version manually).
aubilla
2021-11-09 07:33
This is a script within a Gitlab pipeline definition so backslashes are not necessary.
dimundo
2021-11-09 07:53
hi! on-premises pack broker became a bit slow, and what i found - no maintenance happening anymore
was there any changes around ?
i?ve changed `Creating crontab with schedule 0 2 * * * to clean database` (as there were no logs this night) to every 5 minute `Creating crontab with schedule 5 * * * * to clean database` , but still nothing
or maybe logging is not there or not even debug ?
docker version
? appVersion: 2.89.1.0
dimundo
2021-11-09 08:02
``` PACT_BROKER_DATABASE_CLEAN_ENABLED: true
PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS: "[{\"latest\": true, \"tag\": true}, {\"max_age\": 30}, {\"tag\": \"cit1\"}, {\"tag\": \"demo1\"}, {\"tag\": \"uat1\"}, {\"tag\": \"live1\"}]"
PACT_BROKER_DATABASE_CLEAN_DRY_RUN: false
PACT_BROKER_DATABASE_CLEAN_CRON_SCHEDULE: "5 * * * *"
PACT_BROKER_LOG_LEVEL: "DEBUG"```
aubilla
2021-11-09 08:26
Just to be sure I removed all carriage returns and replaced them by spaces so the command would be a one-liner. It is still giving me the same error.
dimundo
2021-11-09 08:32
but looks like something is not cleaned up properly - i have feeling, that keep selectors are not used
dimundo
2021-11-09 08:54
{?latest?=>true, ?tag?=>true} - keep the latest version for each pacticipant/tag
{?max_age?=>30} - keep all versions less than 30 days old
{?tag?=>?cit1?} ? - keep all env-tagged versions
so far so good , maybe latest must be adjusted
dimundo
2021-11-09 08:58
maybe second and not-lastest version kept because latest with env tag cit1 was removed from bunch of to-be-deleted ?
dawoud.sheraz
2021-11-09 14:08
Hi folks. I have been experimenting with Webhooks on local pact broker. I am having trouble understanding how the dynamic variables, such as providerVersionNumber, providerVersionTags, and/or providerVersionBranch, get populated. My question is specific to contract_content_changed and contract_requiring_verification_published event. When the contract is published by consumer, it makes sense that consumer version and tags will be accessible. But how are the provider related variables calculated by broker? Or is it the other way around i.e. when the provider publishes the verification results?
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution
dimundo
2021-11-09 16:48
and many more
imho 2nd shouldnt present in broker
> <span class=?value? title=?Thu 07 Oct 2021, 6:43am +00:00">about 1 month ago</span>
aubilla
2021-11-09 18:23
If I don?t specify multiple tags it works. Isn?t it possible to specify multiple tags?
```script:
- pact-broker publish -v ${CI_PROJECT_DIR}/build/pacts
--consumer-app-version=${CI_COMMIT_SHORT_SHA}
--tag=${CI_COMMIT_REF_NAME}
--broker-base-url=${PACT_BROKER_URL}
--broker-username=${PACT_BROKER_USER}
--broker-password=${PACT_BROKER_PASSWORD}```
bethskurrie
2021-11-09 21:40
@dimundo can you make sure you're on the very latest version of the broker?
bethskurrie
2021-11-09 21:41
There was a bug with the max_age in some versions, and I want to know you're on the working version.
bethskurrie
2021-11-10 04:42
dimundo
2021-11-10 08:06
ive updated to that one yesterday, but after update at least 1 cycle of cleaning happened and old and not latest ones are still there
dimundo
2021-11-10 11:47
and looks like pact starts hanging :disappointed:
`2021-11-10 11:39:57.337780 E [8:puma server threadpool 005 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference eRaSigJQXE -- Exception: Sequel::DatabaseError: PG::QueryCanceled: ERROR: canceling statement due to statement timeout`
dimundo
2021-11-10 12:33
```
2021-11-10 04:00:19
2021-11-10 02:00:19.364770 I [1165:70105473391100] pact-broker -- Results (0 seconds) -- {:deleted=>{:pact_publications=>0, :verification_results=>0, :pact_versions=>3, :triggered_webhooks=>0}, :kept=>{:pact_publications=>29709, :verification_results=>36613, :pact_versions=>78, :triggered_webhooks=>2}}
2021-11-10 04:00:19
2021-11-10 02:00:18.459419 I [1165:70105473391100] pact-broker -- Deleting overwritten pact publications and verifications older than 7 days
2021-11-10 04:00:19
2021-11-10 02:00:18.456664 I [1165:70105473391100] pact-broker -- Connected to database pact_broker
2021-11-10 04:00:19
2021-11-10 02:00:18.405511 I [1165:70105473391100] pact-broker -- Connecting to database: -- "{:adapter=>\"postgres\", :user=>\"***\", :password=>\"*****\", :host=>\"***\", :database=>\"***\", :encoding=>\"utf8\", :sql_log_level=>:none, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>\"-c statement_timeout=15s\"}, :connect_max_retries=>0}"
2021-11-10 04:00:17
2021-11-10 02:00:01.002276 I [1163:70307298032080] pact-broker -- Deleting oldest 500 versions, keeping versions that match the configured selectors -- [#<PactBroker::DB::Clean::Selector:0x00007fe35ffec7a8 @tag=true, @latest=true, @source_hash={"latest"=>true, "tag"=>true}>, #<PactBroker::DB::Clean::Selector:0x00007fe35ffec0a0 @source_hash={"max_age"=>30}, @max_age=30>, #<PactBroker::DB::Clean::Selector:0x00007fe35ffbf6b8 @tag="demo1", @source_hash={"tag"=>"demo1"}>, #<PactBroker::DB::Clean::Selector:0x00007fe35ffbe510 @tag="uat1", @source_hash={"tag"=>"uat1"}>, #<PactBroker::DB::Clean::Selector:0x00007fe35ffbdef8 @tag="live1", @source_hash={"tag"=>"live1"}>]
2021-11-10 04:00:17
2021-11-10 02:00:00.996668 I [1163:70307298032080] pact-broker -- Connected to database pact_broker
2021-11-10 04:00:17
2021-11-10 02:00:00.940716 I [1163:70307298032080] pact-broker -- Connecting to database: -- "{:adapter=>\"postgres\", :user=>\"***\", :password=>\"*****\", :host=>\"***\", :database=>\"***\", :encoding=>\"utf8\", :sql_log_level=>:none, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>\"-c statement_timeout=15s\"}, :connect_max_retries=>0}"
2021-11-10 04:00:17
(See full trace by running task with --trace)
2021-11-10 04:00:17
Tasks: TOP => pact_broker:db:clean
2021-11-10 04:00:17
/usr/local/bundle/bin/bundle:23:in `<main>'
2021-11-10 04:00:17
/usr/local/bundle/bin/bundle:23:in `load'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/exe/bundle:37:in `<top (required)>'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/exe/bundle:49:in `block in <top (required)>'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli.rb:24:in `start'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli.rb:30:in `dispatch'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli.rb:494:in `exec'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli/exec.rb:28:in `run'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli/exec.rb:63:in `kernel_load'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli/exec.rb:63:in `load'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/tasks/clean_task.rb:50:in `block (3 levels) in rake_task'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/db/clean_incremental.rb:20:in `call'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/db/clean_incremental.rb:70:in `call'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/domain/version.rb:202:in `delete'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/dataset/actions.rb:135:in `delete'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/dataset/actions.rb:1104:in `execute_dui'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/database/query.rb:50:in `execute_dui'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:318:in `execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/database/connecting.rb:269:in `synchronize'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/connection_pool/threaded.rb:92:in `hold'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:318:in `block in execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:522:in `check_database_errors'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:318:in `block (2 levels) in execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:500:in `_execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:144:in `execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:120:in `check_disconnect_errors'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:144:in `block in execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:156:in `execute_query'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/database/logging.rb:38:in `log_connection_yield'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:156:in `block in execute_query'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:156:in `exec'
2021-11-10 04:00:17
CONTEXT: SQL statement "DELETE FROM ONLY "public"."latest_verification_id_for_pact_version_and_provider_version" WHERE $1 OPERATOR(pg_catalog.=) "provider_version_id""
2021-11-10 04:00:17
PG::QueryCanceled: ERROR: canceling statement due to statement timeout
2021-11-10 04:00:17
Caused by:
2021-11-10 04:00:17
2021-11-10 04:00:17
/usr/local/bundle/bin/bundle:23:in `<main>'
2021-11-10 04:00:17
/usr/local/bundle/bin/bundle:23:in `load'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/exe/bundle:37:in `<top (required)>'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/friendly_errors.rb:130:in `with_friendly_errors'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/exe/bundle:49:in `block in <top (required)>'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli.rb:24:in `start'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli.rb:30:in `dispatch'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli.rb:494:in `exec'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli/exec.rb:28:in `run'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli/exec.rb:63:in `kernel_load'
2021-11-10 04:00:17
/usr/local/bundle/gems/bundler-2.2.10/lib/bundler/cli/exec.rb:63:in `load'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/tasks/clean_task.rb:50:in `block (3 levels) in rake_task'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/db/clean_incremental.rb:20:in `call'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/db/clean_incremental.rb:70:in `call'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/pact_broker-2.89.1/lib/pact_broker/domain/version.rb:202:in `delete'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/dataset/actions.rb:135:in `delete'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/dataset/actions.rb:1104:in `execute_dui'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/database/query.rb:50:in `execute_dui'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:318:in `execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/database/connecting.rb:269:in `synchronize'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/connection_pool/threaded.rb:92:in `hold'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:318:in `block in execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:522:in `check_database_errors'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:318:in `block (2 levels) in execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:500:in `_execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:144:in `execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:120:in `check_disconnect_errors'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:144:in `block in execute'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:156:in `execute_query'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/database/logging.rb:38:in `log_connection_yield'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:156:in `block in execute_query'
2021-11-10 04:00:17
/pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/adapters/postgres.rb:156:in `exec'
2021-11-10 04:00:17
CONTEXT: SQL statement "DELETE FROM ONLY "public"."latest_verification_id_for_pact_version_and_provider_version" WHERE $1 OPERATOR(pg_catalog.=) "provider_version_id""
2021-11-10 04:00:17
Sequel::DatabaseError: PG::QueryCanceled: ERROR: canceling statement due to statement timeout
2021-11-10 04:00:17
rake aborted!```
dimundo
2021-11-10 16:47
> PACT_BROKER_DATABASE_CLEAN_DELETION_LIMIT: 100
as a workaround helped , no timeouts , so deletion started at least
franklin.lucena89
2021-11-10 19:07
table actually said that pact are verify, but throws an error saying the opposite
bethskurrie
2021-11-10 19:29
@franklin.lucena89 do you get the same results when you turn off dry run?
bethskurrie
2021-11-10 19:31
I'll need a dump of the database to investigate it. Can you identify the ids of the pacticipants, then do a dump, load it into a docker image and run this redaction script https://github.com/pact-foundation/pact_broker/blob/master/script/prod/redact-data.sql
bethskurrie
2021-11-10 19:36
@dimundo the documentation recommends you start very small and just run it regularly for like, a day, every 5 minutes.
dimundo
2021-11-10 19:38
i?ve set it up there
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1628833942081400
dimundo
2021-11-10 19:40
so, after some digging, and slow pact UI as such conclusion was - too much data
dimundo
2021-11-10 19:42
i?ve enlarged limit to 250 and kicking clean each 3 minutes ( its late evening here, so by night i hope it will clean most of olde data) and then will return to some per hour clean or something
dimundo
2021-11-10 19:44
from ±39K i?m here now
```2021-11-10 19:42:10.492074 I [468:69873865259580] pact-broker -- Results (9 seconds) -- {"versions"=>{"deleted"=>250, "kept"=>26921}, "pact_publications"=>{"deleted"=>182, "kept"=>22429}, "pact_versions"=>{"deleted"=>0, "kept"=>76}, "verifications"=>{"deleted"=>251, "kept"=>26340}, "triggered_webhooks"=>{"deleted"=>0, "kept"=>2}, "webhook_executions"=>{"deleted"=>0, "kept"=>8}}```
bethskurrie
2021-11-10 19:44
The branches and environments keep track of things better. With tags, it doesn't keep track of the latest, so it has to do too many full table scans.
dimundo
2021-11-10 19:48
btw, some tags are translated to environment automagically, but some - not
what magic does that ?
bethskurrie
2021-11-10 20:23
There's a separate time out that can be configured for the clean. I'll just have to expose it in the configuration.
bethskurrie
2021-11-10 20:25
Can you raise a feature request in http://pact.canny.io for the UI alert?
bethskurrie
2021-11-10 20:53
@franklin.lucena89 do the names of the services match? As in, do the names in the table match the names in the message?
franklin.lucena89
2021-11-10 20:57
this is the command I'm running on my pipeline `pact-broker can-i-deploy -a="MyService" -e=$BITBUCKET_COMMIT --to-environment=${ENV_NAME} -b=$PACT_BROKER_BASE_URL -u=$PACT_BROKER_USER -p=$PACT_BROKER_PASSWORD --retry-while-unknown=10 --retry-interval=60 -v --dry-run`
bethskurrie
2021-11-10 21:11
can you run that with --verbose on and send me the redacted output too please?
franklin.lucena89
2021-11-10 21:13
actually yes they have it, we are using this two services as demo to our dev/management teams
bethskurrie
2021-11-10 21:14
I could tell because the consumer version selector comes first in the message, however, that is the provider in the table.
bethskurrie
2021-11-10 21:15
if you have a bi-directional relationship, you need each one to have verified the other.
bethskurrie
2021-11-10 21:17
If it had an extra row it would be clearer:
Service B | 9zz3973 | Service A | 7b9c77c | ??? |
franklin.lucena89
2021-11-10 21:19
humm, looks like the big question about who was first, the hen or the egg :rolling_on_the_floor_laughing:
bethskurrie
2021-11-10 21:19
Bi-directional relationships between services is a very complex situation.
franklin.lucena89
2021-11-10 21:20
thank a lot for your help, it clear a lot my mind, I was thinking about too, will talk with my manager
bethskurrie
2021-11-10 21:23
the table could definitely be clearer. It's something i've noticed before but the amount of work to fix it vs the number of times it occurs is not enough for me to have picked it up.
bethskurrie
2021-11-10 21:23
it's because "left outer join". when there's a consumer version with no provider version, you get a row with an empty success column. but when there's a provider version with no consumer version, you just don't get a row.
franklin.lucena89
2021-11-10 21:31
that's good to know! will keep this in mind next time I had to develop a bi-directional relationship
dimundo
2021-11-10 21:33
when its not there, then there is a line with `???` in place of `true`/`false`
but still 2 lines
franklin.lucena89
2021-11-10 21:35
I created a webhook for both services and them are getting trigger once any contract has change, but I think the issue is who start first and who next and viceversa
franklin.lucena89
2021-11-10 21:42
we have 40+ services and a lot of them have bidirectional relationship
dimundo
2021-11-10 21:49
there is no difference rest or messages ( we have both )
but you need to differ them for same services name like `ChatAPI` and `ChatAPIREST` are messaged and rest pacticipant
dimundo
2021-11-10 21:50
but if pacts are there and just are changing - there should be no empty lines for sure
franklin.lucena89
2021-11-10 21:54
let suppose we have service A and service B as consumer and provider respectively, if I want to deploy a new version of service A i need to verify it first on service B, right?
dimundo
2021-11-10 21:55
but w/o webhooks - as we have 2 monorepos and 15 pacts, so pact change triggers too much, so we save a bit on computing time
franklin.lucena89
2021-11-10 21:57
but what happen when both services have the opposite pacts too (A = provider, B= consumer) and we want to deploy B?
franklin.lucena89
2021-11-10 21:58
we have to wait until both services verify it test's respectively before to ask for can-I-deploy?
dimundo
2021-11-10 22:11
but if you making such supercombo like changing in 4 places at once - cons-A+prov-a and cons-B+prov-B ?.
franklin.lucena89
2021-11-10 22:18
just to make things clear, we have to create a separate pipeline to check if can-i-deploy successfully, right?
franklin.lucena89
2021-11-10 22:21
right now I'm doing this on our pipeline
``` - step: *Publish_Pacts
- step: *Can_I_Deploy_Pacts
- step: *Pact_Deployment
- step: *Create_Pact_Tag```
dimundo
2021-11-10 22:21
trust me there is deploy after that ( and there are manual bunch of can-i-deploy-someenv )
bethskurrie
2021-11-10 22:24
my guess is that if you change both pacts at the same time, you wont' be able to deploy.
bethskurrie
2021-11-10 22:25
you'd need to be careful to only change the pact for one direction at a time, and make sure that's deployed to prod before you make the change in the other direction.
bethskurrie
2021-11-10 22:25
this is not an issue with pact - it is just exposing the underlying dependency issue that already exists.
bethskurrie
2021-11-10 22:28
typically it gets solved by having a third party to remove the bi-directional dependency, or merging the two things.
bethskurrie
2021-11-10 22:28
I'd go out on a limb and say that bi-directional (for synchronous services at least) is an antipattern.
franklin.lucena89
2021-11-10 22:29
yeah I know that, it's an issue related to the way we are handling test development/deployment
franklin.lucena89
2021-11-10 22:31
I agree with you, it's really easy to get into this kind of issues having this bidirectional relations between services
bethskurrie
2021-11-11 01:13
Also @dimundo you can configure the database statement timeout longer for the clean using https://docs.pact.io/pact_broker/configuration/settings/#database_statement_timeout
bethskurrie
2021-11-11 01:14
I'd suggest if it's taking longer than 15s though, it's still better to keep that limit down low, because it will start to impact on the API usage.
dimundo
2021-11-11 06:28
slow api responses occurred already due bigger db, so its complicated :slightly_smiling_face:
dimundo
2021-11-11 06:28
adding some recursion here https://pact-foundation.slack.com/archives/CSUFRDVKN/p1636611883013400
dimundo
2021-11-11 07:02
hi!
one more thought about `tags` ( if/when they are going to die) - `env` must be added to https://docs.pact.io/pact_broker/administration/maintenance/#configuring-the-keep-selectors ( or just docs to be enhanced, if they already there )
dawoud.sheraz
2021-11-11 07:23
I will test it out and get back if there are followup questions. But for now, good to go. Thanks again.
dawoud.sheraz
2021-11-11 12:07
Hi. Some webhook questions about event *contract_requiring_verification_published*. I am looking at the requirements of this event at https://docs.pact.io/pact_broker/webhooks/#using-webhooks-with-the-contract_requiring_verification_published-event. Apart from deployment recording(doing it with tags at the moment), others are fulfilled directly and indirectly. Now, on my local, the provider version exists but with no tags. I edited the pact from consumer and published it. However, this event was not detected. Following is the message upon pact publish:
``` Events detected: contract_published, contract_content_changed (pact content has changed since the last consumer version tagged with master, first time any pact published for this consumer with consumer version tagged development)
No enabled webhooks found for the detected events```
So, my questions are:
? Will this only trigger if a provider verification exists in pact broker, with version and branch tagged?
? If there is no provider verification result in pact broker, will this webhook event be detected?
hamzah.saleem
2021-11-11 14:56
@bethskurrie sorry for the delay - I see, branch was the way I was going to go with this for now. Ok that makes thins clearer - I think I'll scope out the update to the better event - thank you very much!
scott.riley111
2021-11-11 15:48
I?m using `v0.9.0` of the rust standalone verifier (happy to post there instead) and `2.89.0.0` of the OSS Broker and i?m passing it a single `consumer-version-selector` of `[{ "branch": "not a real branch" }]` . On my broker I?ve got a single pact with a `branch: "something else"` . When I run verification in the provider with the standalone verifier - it?s picking up this pact from a different branch and verifying it - is this expected/normal? I.e. if no pacts would be returned from a request for pacts to verify, the latest one of any branch is returned?
matt.fellows
2021-11-11 20:52
Can you please share the arguments passed to the command and verbose logs (as an attachment)?
bethskurrie
2021-11-11 20:56
I think it probably make sense for me to just update the code so that it never deletes anything that is currently deployed or released.
bethskurrie
2021-11-11 20:57
The default keep selectors for the task keep deployed and released, but for the people who have overwritten them, they wouldn't be there. I'll make sure they're added.
bethskurrie
2021-11-11 21:39
@dawoud.sheraz if there is no provider version from the main branch (or any deployed or released versions) this event will not fire.
bethskurrie
2021-11-11 21:40
Publishing provider versions with the right version data is a requirement for using this webhook.
bethskurrie
2021-11-11 21:41
> If there is no provider verification result in pact broker, will this webhook event be detected
Yes - it's not to do with the verification results - it's to do with the version.
bethskurrie
2021-11-11 21:45
I could add some logic so that if there were no provider versions from the main branch yet, it used "HEAD" as the version when it triggered the webhook, but that would make it git specific, and not all version control systems are git.
bethskurrie
2021-11-11 21:47
I'm guessing you're trying to set up the webhook first before the provider has ever published a result?
bethskurrie
2021-11-11 23:15
Here's a working example https://github.com/pact-foundation/pact-ruby-cli/#publish-pacts
bethskurrie
2021-11-11 23:17
```$ docker run --rm -e PACT_BROKER_BASE_URL -e PACT_BROKER_USERNAME -e PACT_BROKER_PASSWORD pactfoundation/pact-cli:latest publish /pact/example/pacts --consumer-app-version fake-git-sha-for-demo-$(date +%s) --tag foo --tag bar
Generating a new version of the pact for this demo
Created docker-example-consumer version fake-git-sha-for-demo-1636672650 with tags foo, bar
Next steps:
Configure the version branch to be the value of your repository branch.
Pact successfully published for docker-example-consumer version fake-git-sha-for-demo-1636672650 and provider docker-example-provider.
View the published pact at https://test.pact.dius.com.au/pacts/provider/docker-example-provider/consumer/docker-example-consumer/version/fake-git-sha-for-demo-1636672650
Events detected: contract_published, contract_requiring_verification_published, contract_content_changed (pact content has changed since the last consumer version tagged with foo, pact content has changed since the last consumer version tagged with bar)
Next steps:
* Configure separate docker-example-provider pact verification build and webhook to trigger it when the pact content changes. See https://docs.pact.io/go/webhooks```
bethskurrie
2021-11-11 23:20
Done - the next version automatically adds { deployed: true } and { released: true } to the keep selectors.
dawoud.sheraz
2021-11-12 05:05
There were some verification results but I had removed them to better understand the webhook events. Your explanation makes the firing criteria of the event much clearer now. In terms of CI setup, webhook would be the last step. Consumer and provider CI jobs would be setup before, so there will be appropriate versions and verification results prior to the setup of webhook. We might not face this issue in CI final setup.
dawoud.sheraz
2021-11-12 05:07
:thumbsup: . Thanks for all the explanation and help. Much appreciated.
aubilla
2021-11-12 06:24
Thanks a lot for checking! The removed the -v and multiple tags work :white_check_mark:
constantin.jaeck
2021-11-13 16:49
Heyho pact community.
I was browsing a bit through the source code and was wondering why HAL was used as a protocol.
constantin.jaeck
2021-11-13 21:33
yes,
I was checking particulary the pact-jvm code to see how the pact broker is used and I don't see the benefit from HAL over a classic CRUD-REST implementation.
Please don't get me wrong - I'm not saying that it's bad or anything - it's just that I've not seen any other project using it so it's a bit of a task to get into it :see_no_evil:
bethskurrie
2021-11-14 22:08
@constantin.jaeck the answer about "why use hypermedia rather than having the client know all the URLS" is in short "it allows the API to evolve without breaking all its clients". The clients only need to know the relations to navigate, and we can change the URLs used underneath. This has helped a lot over the last 7 years of maintaining the Pact Broker and it's 10+ client languages.
bethskurrie
2021-11-14 22:10
The answer about "why use HAL instead of another hypermedia protocol" is that it was what we were using at the company (http://realestate.com.au) that I was consulting at when Pact and the Pact Broker was written, and that's what we were using there. I used the tool I was familiar with, and that I had seen working well within that organisation.
bethskurrie
2021-11-14 22:12
There are pros and cons of course to using a hypermedia API, the main one being that there are more HTTP calls being made. The main issue with this has been when the API has been built at the wrong level of granularity however (eg. publishing pacts used to take calls to 3 different resources) but this can generally be addressed by writing better APIs that match the use cases.
abubics
2021-11-15 01:39
The extra handy thing with having a HAL browser available is: generated UI exists for features that haven't got custom UI built (either because they're too new, or because they have never been a high-traffic feature)
bethskurrie
2021-11-15 06:30
@abubics I've fixed the images when the broker is mounted with a path prefix.
stefan.smith
2021-11-15 09:02
Does the Pact Broker (specifically Pactflow) API support pagination, eg when retrieving all pacticipants or webhooks?
matt.fellows
2021-11-15 09:19
some APIs are paginated, but not all. The plan going forward would be to paginate some of them for sure
stefan.smith
2021-11-15 09:37
Backing up our environments and webhooks to source-controlled JSON files. Not an issue yet but just wondered.
matt.fellows
2021-11-15 09:39
or given you can create via API, just have a pipeline that always recreates them?
matt.fellows
2021-11-15 09:39
The CLI also has a webhook ?upsert? mechanism, so you can always call it
stefan.smith
2021-11-15 09:43
Oh, I didn't know there was a TF provider. Cool!
Our use case is more for backups of what we have configured via the UI. The assumption is we'll continue using the UI to edit config but want a way to restore this. Maybe we'll have another think though...
matt.fellows
2021-11-15 09:50
I?ve got to add a few new resources to the TF provider this week (namely Environments) and also make a few adjustments to support team association with some resources
francislainy.campos
2021-11-15 10:53
Hi, I?m trying to publish contracts to pact flow but get an unauthorized error from jenkins. The same token works fine both to publish locally and also to verify the contracts that are already published. Any ideas please? Thank you.
francislainy.campos
2021-11-15 10:53
```node {
def git_commit
def mvnHome = tool name: 'maven3.6.0'
def app_name = 'viaduct-service'
stage(name: 'Checkout') {
git credentialsId: 'someCredentials', url: "my.git", branch: "$branch_name"
sh "git rev-parse HEAD > commit"
git_commit = readFile('commit').trim()
}
stage(name: 'Compile') {
sh "$mvnHome/bin/mvn clean package -DskipTests"
}
stage(name: 'Pact Generate Contracts') {
sh "$mvnHome/bin/mvn -Dtest=com.hmhco.viaductservice.pact.consumer.*Test test"
}
stage(name: 'Pact Verify Tests') {
sh "$mvnHome/bin/mvn -Dpactbroker.auth.token=myToken -Dtest=com.hmhco.viaductservice.pact.provider.*Test test"
}
stage(name: 'Pact Publish Contracts') {
sh "$mvnHome/bin/mvn pact:publish -Dpactbroker.auth.token=myToken"
}
}```
francislainy.campos
2021-11-15 11:09
It?s fixed now. It was missing this on the pom `<pactBrokerToken>${pactbroker.auth.token}</pactBrokerToken>` under the pact-jvm maven plugin.
bethskurrie
2021-11-15 11:13
typically there is only really 1 or 2 webhooks per pacticipant. are you finding you have more?
dimundo
2021-11-15 11:48
i have question about rollbacks using pact
lets imagine `provider version 2.2` were on `prod`, something happened and we need rollback
1. we are asking `can-i-deploy` `provider version 2.1` to `prod`
2. computer says ok - we deploying ( aka rollback )
3. by logics we are tagging 2.1 with `prod` tag, which already was there
will `producer ver 2.1` be `latest` after this to be used with `can-i-deploy` properly ?
or should we delete tag `prod` from `provider version 2.2` after deploy ( aka rollback )?
francislainy.campos
2021-11-15 11:52
matt.fellows
2021-11-15 12:05
see https://docs.pact.io/pact_broker/tags/#handling-rollbacks (tl;dr - delete)
matt.fellows
2021-11-15 12:06
you probably already know, but moving to releases/deployments will make this conceptually much nicer
stefan.smith
2021-11-15 12:13
Not yet - was looking at generalising our backup scripts and wondered about whether to support pagination
stefan.smith
2021-11-15 12:18
Hi, I've been looking to implement a webhook to update GitHub commit status when a verification result is published, similar to: https://docs.pact.io/pact_broker/webhooks/template_library#github---publish-commit-status. The problem is that we're using the `contract_requiring_verification_published` event so publishing a contract change may lead to 3 verification results being published (`develop` + `staging` + `production`). Ideally, our webhook would then set the `context` property of the GitHub status to something that disambiguates the Provider branch/environment, e.g. `<providerName>-develop` or `<providerName>-production`. In reality, however, the `provider_verification_published` webhook template parameters don't include this information. Is there a recommended approach here?
The only thing I can think of is parsing the `providerVersionDescriptions` property in the verification job and publishing the status to GitHub from CI rather than from the Pact broker. The problem with this workaround is that, whilst it might be ok for the webhook-driven verification, it won't work when we verify in the provider pipeline because we pull down multiple versions of the consumer pacts, including WIP pacts, and use `--enable-pending`. We'd need to figure out the result for each so we could correctly update the status of the associated commits. So, this returns us to looking for a universal solution via a `provider_verification_published` webhook.
dawoud.sheraz
2021-11-15 13:16
Hi. With consumer version selector during the verification, why the consumer version based filtering is not allowed/used? There are many ways to filter, like consumer name, tag, branch. But if we can use combo of version + consumer name(when webhook triggers a provider build against a changed contract), it will only filter the pact associated the version that caused the webhook to trigger.
https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors/
constantin.jaeck
2021-11-15 14:28
okay so the problem that was intended to be solved was:
have the possibility for clients to only store refers to a certain resource action.
constantin.jaeck
2021-11-15 15:51
Reason why I was asking is: I was interested to see how hard it would be to write a pact-broker in golang so it is a bit more modern (I just can't wrap my head around ruby,.. personal shortcoming).
I wanted to specifically research the possibility to switch the persistence layer (for example with a no-sql db)
However when I browsed through the API I couldn't imagine an elegant solution that builds all these referrals to other resources (at least not as elegant as that what is implemented with the current ruby code).
So I checked the pact-jvm pactbroker client to see what is actually being used. To my surprise only ~5 endpoints are used:
? index (to get all the references)
? publish
? for-verification
? latest (+ for tag)
? publish-results
And additionally ofc: 'publish'
I thought: yes there are some nice features like the network graph and stuff but nothing of this justifies the overhead of the protocol.
But yes I see HAL would give me the possibility to for example replace the paths without updating the library.
Maybe I can implement a subset first that makes the libraries work with my tinker-implementation, I guess I'd need to implement these first:
```pb:latest-untagged-pact-version
pb:latest-provider-pacts
pb:latest-provider-pacts-with-tag
pb:provider-pacts-for-verification
pb:provider
pb:version-tag
pb:pacts```
I don't however see the generated UI's as a good argument since it's basically just a postman in the browser :smile:
Having a named 'index' with the possibility of changing the urls however feels like a useful feature.
constantin.jaeck
2021-11-15 15:56
With my question I additional wanted to probe if there is still ongoing interest to keep the HAL format or if this was something people are willing to sacrifice :see_no_evil:
As I understand now -> answer is no sacrifice -> still happy with the decision
danieljak
2021-11-15 16:21
I think the new provider-broker-client version sends ?null? in the new branch option which overrides the brokers `use_first_tag_as_branch`
Do anybody else encounter this?
bethskurrie
2021-11-15 21:04
@stefan.smith I know exactly what you're talking about, and the answer is that we need to write a proper custom integration with github, rather than use a generic webhook. It's something we've had on our mental backlog for ages. cc @matt.fellows
bethskurrie
2021-11-15 21:05
I'll have a think about how I could pass the description though the webhook though.
bethskurrie
2021-11-15 21:07
```def request_body_for(consumer_name)
{
pacticipantName: consumer_name,
pacticipantVersionNumber: consumer_version_number,
tags: tags,
branch: branch,
buildUrl: build_url,
contracts: contracts_for(consumer_name)
}.compact
end```
bethskurrie
2021-11-15 21:07
See the `compact` on the end? If any of the values are null, it removes the keys.
bethskurrie
2021-11-15 21:07
If you'd like to give me the command to reproduce the error, I can look into it though.
bethskurrie
2021-11-15 21:09
@dawoud.sheraz the consumer version selectors should not be used for the webhook triggered build. The URL that is passed has extra metadata in it that will be lost if you use the selectors.
bethskurrie
2021-11-15 21:10
What problem are you trying to solve that means you're wanting to use selectors instead of the URL?
bethskurrie
2021-11-15 21:12
@dimundo there's a search bar in the top right of the page - but most people don't notice it. The search is actually quite good!
bethskurrie
2021-11-15 21:12
As matt says, moving to deployments will not only make it conceptually nicer, it will make the code much simpler instead. You just call record-deployment again, rather than having to find and delete a tag.
bethskurrie
2021-11-15 21:27
bethskurrie
2021-11-15 21:29
I can add the environments into the template @stefan.smith, but the main branch one may not have an environment, so you'd need to do `${pactbroker.providerVersionBranches} ${pactbroker.providerVersionEnvironments}`
bethskurrie
2021-11-15 21:31
It still wouldn't necessarily do what you'd want though, because the distribution of which versions were main/test/prod might change over time, so you might start with a provider version that was "main/test" and then the next day it might be "main/test/prod", and so it woulnd't properly update the previous status.
bethskurrie
2021-11-15 21:41
If you want it to work with the existing pact clients, you'd have to use HAL, and you'd have to use exactly the same relations.
stefan.smith
2021-11-15 22:04
I think we'd settle for only tracking verification status with respect to the Provider mainline. It's all that's necessary at the point of determining whether to approve a PR. To make this happen, I think we'd need a new webhook event, `provider_mainline_verification_published` that was emitted whenever a verification result was published for the provider application version that was currently associated with the pacticipant's configured mainline branch.
bethskurrie
2021-11-15 22:06
I got part way through allowing tags to be specified on the webhooks, but then got stuck trying to work out how to support more advanced logic, and then lost momentum on it https://github.com/pact-foundation/pact_broker/pull/403
stefan.smith
2021-11-15 22:22
With the move to branches/environments over tags, maybe just supporting a list of consumer or provider branches/environments to trigger a webhook on would be enough of a capability to enable this sort of thing.
matt.fellows
2021-11-15 22:29
> Reason why I was asking is: I was interested to see how hard it would be to write a pact-broker in golang so it is a bit more modern (I just can?t wrap my head around ruby,.. personal shortcoming).
that?s a lot of work, to say the least :stuck_out_tongue:
don?t forget, just because the pact jvm client only uses those few endpoints, you?d still need to support a significant portion of https://docs.pact.io/implementation_guides/cli/ such as support for webhooks, can-i-deploy etc. etc.
bethskurrie
2021-11-15 23:02
The resources are fairly straightforward. The challenging part is the matrix and can-i-deploy logic.
dawoud.sheraz
2021-11-16 05:14
The idea is that when a Consumer C1 changes its contract against the provider P, the verification should be run only for Provider P?s master and C1's version that caused the contract change.
dawoud.sheraz
2021-11-16 05:15
Which I think is normal behavior when the contract is changed. The provider should not be running verification against all the consumers in such a scenario.
bethskurrie
2021-11-16 05:17
there are two modes of verification - 1. when the provider changes, you use the consumer versions selectors to specify which versions to verify 2. when the pact changes, the webhook passes the URL of the pact to the verification task, and only the pact at the URL gets verified.
dawoud.sheraz
2021-11-16 05:21
Oh, that is a much nicer solution. Takes all the hassle of passing so many environment variables to the script.
bethskurrie
2021-11-16 05:22
there's meant to be an example here for every language https://docs.pact.io/provider/recommended_configuration#verification-triggered-by-pact-change
constantin.jaeck
2021-11-16 07:11
> that?s a lot of work, to say the least
Haha true. But for now I think from what I use the resources would be enough to have a starting point.
I wouldn't want to implement this if I can't find at least some elegant solution to the HAL challenge
dimundo
2021-11-16 07:22
i was searching for rollback, but not found proper article some-why :laughing:
sadly, but `record-*` not supported yet by jvm/pact4s :disappointed:
dimundo
2021-11-16 07:40
https://docs.pact.io/pact_broker/recording_deployments_and_releases/#pact-client-support-for-the-deployedorreleased-selector confused me, but after your question I understood, that i don?t need to wait for them at all
danieljak
2021-11-16 09:20
@bethskurrie
So I?m in the nodejs ecosystem,
Used `@pact-foundation/pact-node` package to interact with the pact-broker cli
I tested two different versions:
? version `10.14` of that package which depends on `1.88.77` of the `pact-ruby-standalone`
? version `10.13.3` of that package which depends on `1.88.63` of the `pact-ruby-standalone`
When using version `10.14`
executing
```await pact.publishPacts({
pactFilesOrDirs: ['some-path'],
pactBroker: 'broker url',
pactBrokerUsername: process.env.PACT_CI_USERNAME,
pactBrokerPassword: process.env.PACT_CI_PASSWORD,
consumerVersion: 'some-version,
tags: ['Git branch'],
});```
the resulting webhook is triggered with null in the branch variable.
When using version `10.13.3` triggering the same function will result in a webhook with a branch that has the same value as the first tag
bethskurrie
2021-11-16 22:22
You should see all the HTTP requests of each mode, and that will help us work out what's going wrong.
danieljak
2021-11-17 12:12
So.. the old version with VERBOSE doesn?t write any network logs :thinking_face:
but i?ll add here the network logs for the new version
mbyrne
2021-11-17 14:33
Hi all. We recently updated our on prem pact-broker client to `2.89.1.0` after a few years of neglect. We started seeing some 5xx responses to some calls and Internal Server Errors on the UI, and theorised our DB might be the issue - the DB was never updated, so it was running postgresql 9.5. I bumped this to postgresql 10, but since then the pact-broker client is failing to query the DB due to `[14735-3] pact_broker@pact_broker ERROR: canceling statement due to statement timeout`
Failed queries were running successfully directly against the DB, but returning after 20-30 seconds. I increased the `PACT_BROKER_DATABASE_STATEMENT_TIMEOUT` to 60 seconds, but the pact-broker client continued to fail for the error above. Direct queries against the DB were now taking over 1 minute to return.
Any help would be much appreciated.
bethskurrie
2021-11-17 21:04
I'd update to 2.91 first though, because of * do not let clean task delete currently deployed or currently released+supported versions ([b05f0b67](/../../commit/b05f0b67))
bethskurrie
2021-11-17 21:09
The `use_first_tag_as_branch` is only needed for people who are on old clients that don't yet support publishing with branches, to help them migrate.
danieljak
2021-11-18 08:40
I?m not setting the branch because the api in the Nodejs package doesn?t allow it :confused:
https://github.com/pact-foundation/pact-js-core#pact-broker-publishing
mbyrne
2021-11-18 10:51
Thanks Beth. CPU is back at normal levels, but about 0.2% of our requests result in a 5xx response.
We?ll upgrade and try cleaning up our database. :crossed_fingers:
matt.fellows
2021-11-18 11:02
I thought Vincent was going to get you guys onto Pactflow years ago Matt :laughing:
bethskurrie
2021-11-18 22:09
@dimundo we never intend for pact-jvm to support record-release or record-deployment. All the CI/CD interactions with the Pact Broker apart from the actual publishing of pacts and verifications will be through the CLI in the future.
bethskurrie
2021-11-18 22:13
Here's the issue, you can follow it https://github.com/pact-foundation/pact-js/issues/749
bethskurrie
2021-11-18 22:13
You can also publish directly using the CLI that is embedded in the pact js package.
bethskurrie
2021-11-18 22:14
matt.fellows
2021-11-19 00:37
It will need support for the selectors in the verifier though (e.g. the `deployed: true` selector)
mbyrne
2021-11-19 08:51
Nah. GMT time here. Morning now.
Pierre moved on, didn?t leave those notes on Pactflow in his good-bye speech though. :joy:
matt.fellows
2021-11-19 09:56
Also sorry about the typo above. That was me responding late at night (and hence referring to him by his last name :rolling_on_the_floor_laughing:)
mbyrne
2021-11-19 12:40
Happens to him often enough. His own fault for having 2 first names :laughing:
achuljyan
2021-11-20 13:21
Hello,
We are integrating pact flow to our corporate Jenkins CI/CD pipeline.
The pipeline is generic and it?s also being used for deploying to different environments. For all of this jobs we use generic parameterized scripts.
Our consumer pipeline job triggers verification job on a separate pipeline and waits polling pact-broker until the verification job is finished and results are published back to PB.
The verification job triggered by consumer should verify the contract by using the provider version which is currently deployed on the same (as the consumer) target environment. Hence, once verification job is triggered it needs to know the consumer target environment name(tag), to checkout the appropriate version of the provider currently deployed to the target environment.
So the question is, how we can pass the consumer target environment tag to the triggered verification job?
Currently we are going to resolve this problem by creating pact-broker webhook with every consumer build job and passing additional data field in it which will contain the consumer pipeline target environment tag. We are assuming it will be available in the tiggered verification job environment along with pact-broker webhook predefined variables.
Not sure if we will succeed with this. Also honestly I don?t like this approach of creating webhook with every build considering it overhead and possible race conditions.
Is there any other effective way of passing the target environment tag from a consumer test job to a triggered provider verification job in CI/CD pipeline?
thanks
achuljyan
2021-11-21 09:44
Hi @tjones,
You are correct if I just want to pass a parameter to a job triggered by, for example, Jenkins "parameterized trigger". But in case of Pact CI/CD Pipeline the downstream job (contract verification) is triggered by the Pact webhook. So the problem is more or less related to the Pact CI/CD pipeline setup best practices. Or probably someone in the community had such experience and can help to find a neat solution. The only thing for the moment comes to my mind is to try to pass the parameter during the creation of the pac-broker webhook, which I suppose is not the best solution.
bethskurrie
2021-11-22 22:00
@achuljyan if you have logic that you want to put into a build that the Broker cannot understand, I would recommend creating an intermediate Jenkins build that has all that logic in it, and which triggers another build that has all the right parameters set.
bethskurrie
2021-11-22 22:00
Then you just need one webhook in the broker. Pass through everything you need via the webhook parameters (consumer name, provider name, consuemr version, branch, tags etc).
bethskurrie
2021-11-22 22:01
Remember that you should be passing through the pact URL in the webhook and verifying just the pact at that URL, rather than running the verification step with the consumer version selectors (that's for when the provider changes).
achuljyan
2021-11-23 17:08
Thanks @beth (http://pactflow.io/Pact Broker / pact-ruby) for the answer,
We were able to pass a parameter to the contract verification pipeline through the pact-broker webhook (by placing it in the webhook body along with the predefined pact parameters). Thus, we create a webhook before publishing the contract and remove it after the "can I deploy" step.
But I agree that it is worth triggering a parameterized Jenkins remote job and passing all parameters, including the uri of the pact contract, and wait for the validation to complete. In this case, no need to create a webhook at all.
simon.nizov
2021-11-26 16:43
Quick logistics question -
Is there a way to to un-mark a branch on a pacticipant version?
I accidentally marked a pacticipant version with one extra wrong branch during publishing verification reuslts.
simon.nizov
2021-11-26 16:44
`DELETE`ing `/pacticipants/service_a/branches/wrong_branch/versions/5d417b8df` returns 405 Method Not Allowed
bethskurrie
2021-11-28 23:19
@simon.nizov I haven't implemented delete yet. You could delete the entire version (which will delete the pacts as well), and re-run the build to publish everything again, if it's not in production.
bethskurrie
2021-11-28 23:20
I've just added a card for this in the backlog https://github.com/pact-foundation/pact_broker/projects/1
bethskurrie
2021-11-28 23:21
if you can't delete and republish the version, you'll need to delete it from the branch_versions table in the database.
tati.shep
2021-11-29 05:53
Hi :wave:, is there a way to know a version of a pacticipant marked with some environment? like, `production`. We are using GitLab CI and I?d like to trigger contract verification ?manually? and not to use `contract_requiring_verification_published` webhook on pactflow. :pray:
abubics
2021-11-29 06:28
Like, a gitlab integration that can tell the broker what's currently in the `production` environment? :thinking_face: sounds like a cool idea
tati.shep
2021-11-29 07:28
hm, telling broker what is on production can be done with `record-deployment` when deploy is done. https://docs.pact.io/pact_broker/recording_deployments_and_releases/#recording-deployments
I?m looking for a way to know that version by asking the broker. something like,
```pact-broker describe-version -a PACTICIPANT --environment SOME_ENVIRONMENT```
Unfortunately, `describe-version` command only works with tags and doesn?t support environments. There might be a workaround I don?t see. https://github.com/pact-foundation/pact_broker-client#describe-version
tati.shep
2021-11-29 07:30
so, using that info, I can trigger a child pipeline on GitLab CI to verify a contract against provider production version
p0deje
2021-11-29 18:32
You can hack around with some curl + jq. Seems to work on the Pact-Broker (not sure about Pactflow):
```curl -su $PACT_BROKER_USERNAME:$PACT_BROKER_PASSWORD $PACT_BROKER_BASE_URL/environments |
jq -rc '(._embedded.environments[] | select( .production == true )).uuid' |
xargs -I {} curl -su $PACT_BROKER_USERNAME:$PACT_BROKER_PASSWORD $PACT_BROKER_BASE_URL/environments/{}/deployed-versions/currently-deployed |
jq -rc '(._embedded.deployedVersions[] | select( ._embedded.pacticipant.name == "MY_PACTICIPANT_NAME" ))._embedded.version.number'```
abubics
2021-11-29 23:49
Right, sorry, your mention of Gitlab was an aside, that makes even more sense :pray:
I expect that kind of API is on the roadmap if not already implemented . . .
bethskurrie
2021-11-30 00:03
@tati.shep adding an environment to the describe version (or it would actually be a list-versions) would be a great idea.
bethskurrie
2021-11-30 00:04
You can create a request in http://pact.canny.io or add an issue for a feature request in the pact broker client project.
bethskurrie
2021-11-30 00:05
I'm interested in why the webhook can't be used @tati.shep. Can you explain more about that?
bethskurrie
2021-11-30 00:05
Is this relevant to you? https://github.com/pact-foundation/pact_broker/discussions/468
tati.shep
2021-11-30 02:28
> I?m interested in why the webhook can?t be used
@beth In short, to improve visibility.
GitLab CI has a nice feature of child/multi-project pipelines, so if I ?manually? trigger a provider?s CI pipeline, it?ll be connected to the consumer?s one, and I?d get a descriptive overview of, what failed or passed. Like, a consumer generates 5 contracts, it triggers 5 verifications and I can see all of that as one pipeline. If I use a webhook, it?s not that obvious.
tati.shep
2021-11-30 02:35
> Is this relevant to you?
Partially. It?d be good not to store gitlab keys on pactflow, but it?s not a blocker for us.
bethskurrie
2021-11-30 02:37
If you're going to use the webhookless flow, make sure you pass the Pact URL into the child job, as it will make all the verison numbers line up properly.
bethskurrie
2021-11-30 02:37
there's a bunch of extra metadata in the pact url that you lose if you try to verify using the consumer version selectors.
christoph.oswald
2021-12-01 12:19
Hello,
I was wondering, if there is an official helm chart for the pact-broker available?
I did a slack search and found some references, like https://github.com/qamatic/helm-charts/tree/master/qamatic/pact-broker.
There was a discussion, that you might add an official one. Was there any progress in that direction?
beshoy.ibrahim
2021-12-01 13:15
Hello, i?m pretty new here
I?m facing an issue with uploading my json contract file to a localhost broker
I always get this error:
`PactBroker::Client::Hal::ErrorResponseReturned - Error making request to http://localhost:8081/trips/1 status=500 {"message":"No interaction found for GET /trips/1","interaction_diffs":[]}`
Does anyone know what is the root cause?
matt.fellows
2021-12-01 13:44
Hmm I think you have your wires crossed, that error is not from a broker, it looks like it's a mock service.
matt.fellows
2021-12-01 13:46
Oh, are you trying to publish a pact file but instead of sending it to a pact broker you're pointing it at a mock server?
matt.fellows
2021-12-01 13:48
I'd suggest running through one of these tutorials to get the basics down: https://docs.pactflow.io/docs/tutorials
beshoy.ibrahim
2021-12-01 14:04
the thing is there is a mismatch between the pact request and publish request headers
beshoy.ibrahim
2021-12-01 14:05
pact request:
```{
"path": "/trips/1",
"query": "",
"method": "get",
"headers": {
"Host": "localhost:54744",
"User-Agent": "Prysm",
"Accept": "application/json",
"Accept-Encoding": "gzip",
"Version": "HTTP/1.1"
}
}```
Publisher request:
```{
"path": "/trips/1",
"query": "",
"method": "get",
"headers": {
"Accept-Encoding": "gzip;q=1.0,deflate;q=0.6,identity;q=0.3",
"Accept": "application/hal+json",
"User-Agent": "Ruby",
"Host": "localhost:8081",
"Version": "HTTP/1.1"
}
}```
p0deje
2021-12-01 17:55
Hey folks!
We would like to implement some sort of tracing solution for CI builds that are triggered by the Pact Broker. Essentially, we have a CI dashboard and we?d like to create page where developers could see all the CI builds that have been triggered by each other.
For example:
1. Consumer tests build that published contract.
2. Provider verification builds that checked the contract (there might be several of those).
3. Additional builds that are triggered by the webhook but don?t run Pact (e.g. CI build that verifies the GraphQL Schema on contract change).
For webhookless setup we can simply generated unique trace uuid and pass it to all the builds that we triggered. However, it is not possible if we use webhooks. Do you think this is something that the Pact-Broker could also support? I am not sure how exactly this setup could look like there.
bethskurrie
2021-12-01 20:54
Hi @p0deje if you use the latest broker and pact cli to publish the pacts, you can pass in the build url, and then pass that on to the downstream webhook triggered builds.
bethskurrie
2021-12-01 20:58
Beshoy, I'm afraid I don't understand your question. Your terms seem to be mixed up. Are you talking about the mock service or the pact broker? You may be asking in the wrong channel.
p0deje
2021-12-02 00:08
@bethskurrie I see I can specify `build_url` when publishing Pact, but how can I pass it via webhook? I don?t see related variable in https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution
bethskurrie
2021-12-02 00:09
> buildUrl: The URL of the build that published the resources that have triggered the webhook (currently only supported for contracts published using the 'all in one' endpoint).
p0deje
2021-12-02 00:10
Is it possible to specify it in verification task too? Or is it only available for `contract_content_changed` webhook?
bethskurrie
2021-12-02 00:11
the "all in one" api that is mentioned above I wrote for publishing pacts, so you can send the pacts/tags/branch/build info all in one request.
p0deje
2021-12-02 00:15
Quick question, is buildUrl somehow associated with the pact? Meaning that I could use some API to retrieve pact?s build URL given I have pactUrl?
bethskurrie
2021-12-02 00:23
It's honestly a very tricky thing to work out whether the build url goes with the version resource or the pact resource
p0deje
2021-12-02 00:27
Yeah, I understand that it?s a tricky one. I just wonder how we could also trace CI builds that are triggered by `provider_verfification_suceeded` (and `_failed`) events
p0deje
2021-12-02 00:33
It is different across the builds (e.g. Pact builds can use consumer SHA, but schema validation builds use consumer SHA + production SHAs of other pacticipants that are part of the same schema)
p0deje
2021-12-02 00:33
So we could probably hack it around, but I wonder if there is a better way supported by the broker. `buildUrl` would be perfect if there was a way to somehow use on `provider_verification_*` events
bethskurrie
2021-12-02 01:04
so, a pact publication can trigger a provider verificaiton, which causes a verification publication, which could then cause another webhook to fire again for the consumer. Do you want it to trace all the way though that far?
p0deje
2021-12-02 01:12
The verification publication would trigger a completely different build that would validate the schema based on the consumer version from the verification result.
rishabh.gaur
2021-12-03 13:44
Hi, can anyone please help me, how can I run provider contract tests on specific version of contract published by a consumer(lets say version - 0.0.1-SNAPSHOT). It is always picking the latest one, right now. I am using below versions:-
? ?http://au.com.dius.pact? version ?3.5.23?
? testImplementation(?au.com.dius:pact-jvm-provider-spring_2.12:3.5.24?)
? testImplementation(?au.com.dius:pact-jvm-provider-junit_2.12:3.5.24")
? testImplementation(?au.com.dius:pact-jvm-consumer-junit_2.11:3.5.24?)
thanuxxxx
2021-12-05 17:55
Question about Pending/WIP features
I have enabled pending/WIP features, and I do the followings in provider side
1. I create a new branch called PR-100
2. I make breaking changes
3. Run Pact tests via
```mvn test -Pcontract-tests <-- MAVEN profile just for contract tests
-Dpact.verifier.publishResults=true
-Dpact.provider.version=PROVIDER_GIT_VERSION
-Dpact.provider.tag=PR-100
-Dpactbroker.tags=dev,master```
4. There are 2 tests failures because of the breaking changes but it is keep saying that it is a pending Pact
```Verifying a pact between Pact between Pact-consumer (0c4d3816f12e69dffdaf9c44ad61a50530cc5b49) and Pact-provider [PENDING]
10:52:03
10:52:03 Notices:
10:52:03 1) The pact at https://pact-broker.com/pacts/provider/Pact-provider/consumer/Pact-consumer/pact-version/d25b3b154ee07b6ed19f1e3db998cc111849518f is being verified because it matches the following configured selection criteria: latest pact for a consumer version tagged 'dev', latest pact for a consumer version tagged 'master' (both have the same content)
10:52:03 2) This pact is in pending state for this version of Pact-provider because a successful verification result for a version of Pact-provider with tag 'PR-100' has not yet been published. If this verification fails, it will not cause the overall build to fail. Read more at https://pact.io/pending```
My question is how it can be a pending pact? Contract didn't change and I want the build to be failed for this scenario.
For experimental purpose I changed the provider's tag to master like this
```mvn test -Pcontract-tests <-- MAVEN profile just for contract tests
-Dpact.verifier.publishResults=true
-Dpact.provider.version=PROVIDER_GIT_VERSION
-Dpact.provider.tag=master
-Dpactbroker.tags=dev,master```
In that case the build failed, which means If PR-100 got merged with master, then master build will fail but is that how pact pending works?
thanuxxxx
2021-12-05 21:12
Yes, I did. but there is no changes in the contract. If anyone break the contract in provider side, didn't we want to catch it during the PR? Not in master build?
matt.fellows
2021-12-05 21:25
I'd say your in one of the situations described here: A pact's content is pending for all branches of a provider until the first successful verification has been published. From then on, it is no longer pending for the provider branch that published the successful verification, and will not be pending for any other new provider branches created thereafter. It will stay in pending for branches that already existed at the time of the successful verification.
matt.fellows
2021-12-05 21:26
Is in a long running provider branch that existed before hand? If so, that would explain ut
bethskurrie
2021-12-06 02:32
> Contract didn't change
No, but the branch represented by your provider tag did.
danil.nurgaliev
2021-12-06 07:16
@bethskurrie could we provide build url from the value which is stored in pact verification result for `provider_verification_*` events? https://docs.pact.io/pact_broker/advanced_topics/api_docs/publish_verification_result/
bethskurrie
2021-12-06 19:40
It's not currently hooked up to the webhook, but I could add it. Depends which language you're verifying in, as to whether it's supported. What language are you verifying in?
danil.nurgaliev
2021-12-07 01:20
We are using ruby pact with patch to include BUILD_URL into verification result body, so we already have a it in there.
bethskurrie
2021-12-07 03:13
You asked just as I was trying to avoid doing something else, so I just did it :laughing:
danil.nurgaliev
2021-12-07 03:18
Is there any release planned?:) Just to understand when I could use this feature on my setup.
bethskurrie
2021-12-07 05:46
What'd I'd LOVE would be a PR to expose the build_url in the verification task :wink:
christoph.oswald
2021-12-07 13:16
Hi, I was wondering what version(s) of postgresql are officially supported by the pact-broker (2.93)?
I am experiencing similar issues, like here: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1637159596252800 and was wondering which version of postgresql to use? (currently 11.10)
david.vancouvering
2021-12-09 20:31
Hey. I am learning about `can-i-deploy` and I am starting to get confused about the difference between "tags" and "deployments". The can-i-deploy docs say that we've moved from tags to deployments, and that we record a deployment using the `record-deployment` command.
But then the tags documentation says "_tag is required for the use of can-i-deploy"_
bethskurrie
2021-12-09 21:04
You can read about the transition here https://docs.pact.io/blog/2021/10/08/why-we-are-getting-rid-of-tags
david.vancouvering
2021-12-09 21:36
A colleague was telling me that pact-jvm and other language packs don't yet support the new model. Is that true?
david.vancouvering
2021-12-09 21:36
OK, so we can't really migrate until that happens I would think right?
david.vancouvering
2021-12-09 21:37
I would agree btw that tags are a difficult concept to understand in the context of can-i-deploy
bethskurrie
2021-12-09 21:37
You can do what we did at Pactflow, while we were transitioning, in that you can use both in parallel until your final clients have been updated, then pull out the tags.
bethskurrie
2021-12-09 21:37
> I would agree btw that tags are a difficult concept to understand in the context of can-i-deploy
totally
david.vancouvering
2021-12-15 04:19
Hey, I am working on learning how the Pact Broker works. I tried to find this in the documentation but I couldn't. When you run provider verification for a given consumer, does it verify against the _latest_ version of the consumer, or _all_ versions of the consumer that have not yet been verified for this version of the provider?
david.vancouvering
2021-12-15 04:20
If it is only the latest version, how do older versions of the consumer get verified?
matt.fellows
2021-12-15 04:21
david.vancouvering
2021-12-15 04:21
Or is it the case that when I run can-i-deploy, if the verification hasn't been yet run for that particular pact version, then verification is kicked off and recorded?
david.vancouvering
2021-12-15 04:22
OK, but it looks like version selectors are not yet supported in client libraries?
david.vancouvering
2021-12-15 04:23
Yes, OK. I had assumed webhooks were only used for when a consumer was asking if it can deploy. But I guess you can use it in both cases
david.vancouvering
2021-12-15 04:24
Oh, this makes sense:
```what you probably need to do is to create a webhook that triggers a provider verification build when a pact is published with new content.```
david.vancouvering
2021-12-15 04:25
But that doesn't solve the problem of a new provider version coming into being, and wanted to make sure before I deploy that this new provider is compatible with all deployed consumer versions
2021-12-15 04:25
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
david.vancouvering
2021-12-15 04:26
Yea I read the presentation but hadn't actually walked through the workshop. I'll do that and if I"m still confused I'll bother you again
david.vancouvering
2021-12-15 17:39
Hey, Matt. I walked through the workshop, and that covers pretty much what I know already.
My question is still open - when I modify the provider, and run pact verification job, does it verify this new version against all existing pact versions where that provider is a pacticipant?
If not (a) how does it decide which pact versions to verify against and (b) how do we make sure some version of the consumer out there won't get broken?
If it *does* run against all pact versions, isn't that expensive? Seems like that job could run a long time.
Wondering how these competing forces (completeness vs. time) are managed.
Thanks!
rchandragupthara
2021-12-16 01:45
I have an old Consumer , which i want to deprecate. Is there a way i can deprecate without deleting the integration with the provider on the pact-broker?
matt.fellows
2021-12-16 01:58
> My question is still open - when I modify the provider, and run pact verification job, does it verify this new version against all existing pact versions where that provider is a pacticipant?
no, the selectors you use can target which versions you verify. The version itself is not usually what you care about, you usually care about verifying ?all consumers that are currently in production? or ?the latest version of my consumer for feature x?.
If you verified _all_ versions, that could be thousands of pacts, and most of them are already outdated
matt.fellows
2021-12-16 02:48
> If not (a) how does it decide which pact versions to verify against and (b) how do we make sure some version of the consumer out there won?t get broken?
You get to decide what is important to your workflow. The usual starting advice is ?don?t break production? and ?don?t break what?s about to go to production? (usually the `master` or `main` branch).
You do this by using tags (the old way we?re slowly moving away from) or the newer consumer version selectors, specifically the ones for branches and environments
matt.fellows
2021-12-16 02:48
e.g. in the new way, you could say somethnig like ?verify all of my consumers deployed to the test and production environments?. This would find all of the versions of its consumers in those environments, and verify them.
david.vancouvering
2021-12-16 02:51
So when you say `--to prod` it verifies *all* consumers with the `prod` tag? (we're still using tags until branches and environments are available in the JVM and node)
david.vancouvering
2021-12-16 02:51
OK, well, I totally believe you. I just need to keep learning so I see how that works
matt.fellows
2021-12-16 02:54
you?re right in that?s can-i-deploy, but the verification configuration is very similar
matt.fellows
2021-12-16 02:54
i.e. you can target which pacts you would like to verify in a similar way
david.vancouvering
2021-12-16 02:54
Does that mean in environments where there can only be one version running at a time, I have to remove the tag from older versions when I deploy a new version?
matt.fellows
2021-12-16 02:56
(there is also an `--all` flag for cases like mobile where you can have multiple versions in prod, in which case you _will_ need to remove the tag when that version is deprecated)
david.vancouvering
2021-12-16 02:57
So when I verify, it verifies against all versions with a given tag. But when I ask can-i-deploy, it checks only the latest version unless I use `--all`
matt.fellows
2021-12-16 02:58
it wouldn?t make sense to verify any version of a consumer that has the tag ?some new feature?
matt.fellows
2021-12-16 02:58
> they both use the latest version with that tag
correction: they both use the latest version with that tag _by default_.
david.vancouvering
2021-12-16 02:59
I asked
> So when you say `--to prod` it verifies *all* consumers with the `prod` tag? (we're still using tags until branches and environments are available in the JVM and node)
and I thought you said "yes"
matt.fellows
2021-12-16 02:59
i.e. you may have 3 different consumers. It will verify the latest version of each of those consumers that has the tag `xyz`
david.vancouvering
2021-12-16 03:01
So, when I create a new version of a provider, and I want to know if I can deploy it to prod, I run the verification and it will verify against the version of each consumer that has the latest `prod` tag (unless I specify `--all`)
bethskurrie
2021-12-16 04:18
@david.vancouvering the docs for can-i-deploy with tags for mobile consumers are here https://docs.pact.io/pact_broker/client_cli/can_i_deploy_usage_with_tags/
bethskurrie
2021-12-16 04:19
@rchandragupthara yes, but you'll need a recent version of the broker because the logic that allows you to do this has only recently been corrected.
bethskurrie
2021-12-16 04:20
There are a few things you can do. The consumer could just stop publishing a pact.
bethskurrie
2021-12-16 04:21
You'd need to keep recording the deployments, so the broker understand that the version exists, but has no pact with your provider.
bethskurrie
2021-12-16 04:22
or you could specify the consumers explicitly in the consumer version selectors, and not include the deprecated consumer. you'd also need to --ignore the consumer in can-i-deploy.
christoph.oswald
2021-12-16 13:16
Ok thanks for the info.
The database is pretty much empty though (only 2 pacts and not many verifications).
It only happens sporadically that the server responds with 500 and then the next call is fine.
We are running it in k8s so there might be some networking issues that could be the root cause
diva.pant1
2021-12-16 15:31
How is pactflow different from pact broker? I read its a fork of pact broker which can be used to provide faster and scalable solutions. Can you explain how specifically? I mean to make it scalable and faster we are using bi-directional flows right?
carolyn.biggar
2021-12-16 18:06
:red_circle: :green_heart: *Broker UI Colours* :green_heart: :red_circle:
Hello! I have a team member who is red/green colourblind and can't distinguish between the red/green used for fail/pass on the "Last Verified" column of the broker UI.
I'm looking for an option to configure the colours used for fail/pass - is this possible at the moment?
We're using broker version `2.90.0`
Thanks for any advice!
tjones
2021-12-17 00:38
I don't know the answer to this specific question, but as a workaround you can mouse over the column cells and see if they are passes or failures
carolyn.biggar
2021-12-17 00:41
Yes that was not helping blood pressure earlier :grin: but definitely better than nothing!
bethskurrie
2021-12-17 00:57
Very good point. We should add text or an icon to indicate the status. It's boostrap, so not sure how we'd do a configurable colour.
carolyn.biggar
2021-12-17 01:12
Yes, text or icon would be really cool thanks. Would it help if I raised a feature request?
mike.geeves064
2021-12-17 17:04
Pact Flow if you don't want to have to manage it yourself is ideal :slightly_smiling_face: Otherwise anywhere you can run a docker container works nicely
bethskurrie
2021-12-19 23:32
We run our on-prem test environment on heroku, and it works very nicely. So little set up required.
bethskurrie
2021-12-19 23:33
There is a little trick you have to do with the database URL environment variable - if you search in the docs for the docker image, you'll find a note on heroku.
diva.pant1
2021-12-20 01:02
I was reading through the guide https://docs.pact.io/5-minute-getting-started-guide/
and came across "There are multiple ways to https://docs.pact.io/getting_started/sharing_pacts, but the recommended approach is to use a https://docs.pact.io/5-minute-getting-started-guide/pact_broker/ as it enables powerful automation workflows."
What does this mean? What are the other ways we could share pacts??
uglyog
2021-12-20 01:05
You can write them to a shared file system or something like an S3 bucket, you can commit them into your git repository, etc.
bethskurrie
2021-12-20 02:11
If we were writing those docs from scratch now, we probably wouldn't put "there are other ways" in the docs, because the value prop of using pact without a pact broker is just so low by comparison.
tjones
2021-12-20 06:41
...possibly we should replace all that with
> Do I need to use a Pact broker?
>
> The pact broker is not necessary to use pact, you could instead share contract files with any other method (eg uploading to an artefactory or fileshare). However, to get the full value out of the pact ecosystem - including easy CI integration and tools and support for checking deployment safety, we strongly recommend using a broker. There is a docker image for the open source broker <here> , or alternatively you can use a hosted broker from our friends at Pactflow <link>
mike.geeves064
2021-12-20 16:48
I've been fighting with pact-python tests using a docker-compose to spin up a broker, which was working fine until I tried to make a trivial change last night. For reasons I can't explain it seems to randomly (maybe) not have fired up the broker in time so fails. I seem to have got it working now by finally adding in a health check for the broker and making nginx depends_on so it doesn't start until the broker is ready..which seems to have done the job. Has anyone else had problems with this / any better suggestions, or does this seem sensible? :thinking_face: Puzzled as to why it was fine and suddenly not. docker-compose in the thread to avoid flooding here
mike.geeves064
2021-12-20 16:49
> version: '3.9'
>
> services:
> # A PostgreSQL database for the Broker to store Pacts and verification results
> postgres:
> image: postgres
> healthcheck:
> test: psql postgres --command "select 1" -U postgres
> ports:
> - "5432:5432"
> environment:
> POSTGRES_USER: postgres
> POSTGRES_PASSWORD: password
> POSTGRES_DB: postgres
>
> # The Pact Broker
> broker_app:
> # Alternatively the DiUS Pact Broker can be used:
> # image: dius/pact-broker
> #
> # As well as changing the image, the destination port will need to be changed
> # from 9292 below, and in the nginx.conf proxy_pass section
> image: pactfoundation/pact-broker
> ports:
> - "80:9292"
> links:
> - postgres
> environment:
> PACT_BROKER_DATABASE_USERNAME: postgres
> PACT_BROKER_DATABASE_PASSWORD: password
> PACT_BROKER_DATABASE_HOST: postgres
> PACT_BROKER_DATABASE_NAME: postgres
> PACT_BROKER_BASIC_AUTH_USERNAME: pactbroker
> PACT_BROKER_BASIC_AUTH_PASSWORD: pactbroker
> # The Pact Broker provides a healthcheck endpoint which we will use to wait
> # for it to become available before starting up
> healthcheck:
> test: [ "CMD", "wget", "-q", "--tries=1", "--spider", "http://pactbroker:pactbroker@localhost:9292/diagnostic/status/heartbeat" ]
> interval: 1s
> timeout: 2s
> retries: 5
>
> # An NGINX reverse proxy in front of the Broker on port 8443, to be able to
> # terminate with SSL
> nginx:
> image: nginx:alpine
> links:
> - broker_app:broker
> volumes:
> - ./ssl/nginx.conf:/etc/nginx/conf.d/default.conf:ro
> - ./ssl:/etc/nginx/ssl
> ports:
> - "8443:443"
> restart: always
> depends_on:
> broker_app:
> condition: service_healthy
bethskurrie
2021-12-20 22:02
Side question, can you help me understand why you're spinning up a broker for tests, I assume then shutting it down again?
bethskurrie
2021-12-20 22:03
Is it failing because the database is not ready to be connected to when the Ruby app starts up?
bethskurrie
2021-12-20 22:04
You can try setting the db retries as shown here @mike.geeves064 https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose-dev.yml#L38
bethskurrie
2021-12-20 22:05
If you're just using it for demo purposes (from your description, it seems the stack is empemeral) you could just use an sqlite database.
mike.geeves064
2021-12-20 22:08
It's in the pact-python examples for when it tests that the examples are all valid, so it's just spinning it up, running a test and then killing it
mike.geeves064
2021-12-20 22:09
They're e2e examples, the weirdness was because it's been like that in the build for ages
mike.geeves064
2021-12-20 22:11
Although the pact-python repo doesn't get many builds which was why I was initially trying to figure out if anything could have changed on the Pact side but didn't appear to be :thinking_face:
mike.geeves064
2021-12-20 22:12
This is the adding in 3 lines for handling the missing description causing problems later fix, which somehow ended up taking a silly amount of time :sob:
mike.geeves064
2021-12-20 22:24
There are quite a few differences between the one in pact-python and the pact-broker-docker example, I'll add that to my todo list to tidy up. I don't really like them all being different without a good reason (admittedly the last person to touch the pact-python one was me, to swap it from the dius image to pact-foundation, trying to do smaller steps at a time)
It looked like the timing was ok for the broker->postgres part, thanks for the suggestion though. Might be worth adding that in anyway
mike.geeves064
2021-12-20 22:27
nod
I suppose as long as there's a clear "you shouldn't do it like this in production" comment
bethskurrie
2021-12-20 22:49
@christoph.oswald can you paste the error you're seeing in the logs please.
mike.geeves064
2021-12-20 22:53
nod. it's clear in the docs, I'm just wary of if you have an example in the code, that's demonstrating "how you should do it" and it relies on people reading up elsewhere to find out otherwise. meanwhile, that's it for me for now :slightly_smiling_face:
(I'm not actually sure if tests in other languages have the same spin up broker to run tests against :thinking_face: will look...)
dalton.pinto
2021-12-21 10:21
Hi folks, I just sent a PR that mot merge last day optimising a SQL query and was planning to add maybe one or two similar.
But then it was realised that it would be nice to log the duration of each request grouping by resource.
There is currently a way to do it? By a quick look on source code and gh wiki I could not find a clear way on how should I do it just by configuration, so I assume it would require a PR just to make this possible (if you think that is a nice to have feature).
I could do it, just give me some directions on how/where it should be implemented
paulorochag
2021-12-21 14:47
Hello,
I'm using the pact-cli docker image and I received the alert
> Next steps:
> Configure the version branch to be the value of your repository branch.
But I didn't find it in the documentation (https://github.com/pact-foundation/pact_broker-client#publish), could you tell me what configuration I need to create?
CI with alert: https://github.com/ServeRest/front/runs/4595709833?check_suite_focus=true#step:7:18
mike.geeves064
2021-12-21 15:02
[disclaimer: I haven't looked at tags, or rather their deprecation, so this could be way off but...] I think that may be to do with https://docs.pact.io/pact_broker/tags/ going onto: https://docs.pact.io/pact_broker/branches
So suggesting you have `--branch $GIT_BRANCH` rather than `--tag-with-git-branch`
mike.geeves064
2021-12-21 15:09
Fingers crossed, it's hopefully worth a try at least :slightly_smiling_face:
matt.fellows
2021-12-21 21:50
You should set it to the working branch of your code that is being tested
bethskurrie
2021-12-22 19:16
Yes, Matt and Mike have given you the right answer. It's hard to write specific docs to say what to do, because this endpoint is used by 10+ client languages!
bethskurrie
2021-12-22 19:20
You can log the SQL and the duration of long SQL statements using this setting https://docs.pact.io/pact_broker/configuration/settings#sql_log_warn_duration
bethskurrie
2021-12-22 19:23
It's not documented, because it's really only relevant to devs working on the code, but you can also turn on the logging that says where the query is coming from.
bethskurrie
2021-12-22 19:28
To add it, you'd need to add the configurarion here https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/docker_configuration.rb#L17 and enable it here https://github.com/pact-foundation/pact-broker-docker/blob/master/pact_broker/config/puma.rb
diva.pant1
2021-12-23 14:19
How could I migrate the existing pact-broker deployed on heroku to pactflow?
mike.geeves064
2021-12-23 14:31
@diva.pant1 I believe you already asked about this before some days ago, with the suggestion of if you only have a few test Pacts that it would be much more straightforward to just "run" them again than messing with migration (which as I understand is possible, but almost certainly more effort).
bethskurrie
2021-12-23 22:21
@diva.pant1 we've discussed creating migration tools, but the approach that Mike suggests is the one we generally come back to. It ensures no downtime, and you only need to run them in parallel until all your production versions are in Pactflow, then you can switch off your old tasks.
dalton.pinto
2021-12-27 09:16
Hi @bethskurrie and merry xmas and a happy new year!
I had found that SQL config before and it was exactly what I used locally when I was trying to debug a single request I was concerned.
But now I want something else, if possible.
I would like to log duration and more imporntat group it by resource class and display a plot on Grafana, so I could try to pin point every route where I could try to improve.
Right now we got duration from our K8s ingress logs, but for each path. We would love to translate that to resources
DO you see how could we do it?
danil.nurgaliev
2022-01-03 17:26
hey @bethskurrie just made a PR for the feature above https://github.com/pact-foundation/pact-ruby/pull/252 :point_up:
sagupta
2022-01-04 12:58
Hello team,
I need some help with the approach to successfully make a breaking change (a bug fix) on the provider side in the CI workflow. Consumer and provider have a contract for a PATCH endpoint which will return 500 status code. This was a bug and now provider wants to make a bug fix and change the status code to 401.
Can someone please share if the below steps are right?
? Update contract on consumer in a feature branch by removing the test for 500 status code. Can-i-merge will pass in this case and merge consumer to update the master contract
? Add new test in contract for 401 status code . This will be our new expectation from provider . Can-i-merge will fail in this case.
? implement bug fix in provider to now return 401 status code and test locally against the feature branch contract . CI will verify against master contract still and will pass once the PR is opened. It will also verify new pact as i have enabled wip pacts .
? Merge provider
? re-run can-i-merge on consumer side . It should pass now .
? Merge consumer
rarora
2022-01-07 03:32
Hi Team
I am using pact with springboot. Once provider test succeeds, results are not published to broker. I have set the property
```System.setProperty("pact.verifier.publishResults", "true");```
rarora
2022-01-07 03:33
I am on version
```gradle.plugin.au.com.dius.pact.provider:gradle:4.1.20```
I see failure result getting published
rarora
2022-01-07 03:39
I commented this annotation to make it fail
```@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)```
rarora
2022-01-07 03:49
command ran : `./gradlew clean contractTest -Dpact.provider.version=1.0.0 -Dpact.verifier.publishResults=true --info -d`
log file attached
uglyog
2022-01-07 03:49
If the error is being displayed in the broker, then it is sending the results. With debug logs enabled, you should see the requests made to the broker
rafael.anachoreta
2022-01-07 11:07
Hey all, does anyone know how I can workaround https://github.com/pact-foundation/pact_broker-client/issues/25#issuecomment-1007316248? Here is the transcript:
> - I have a Consumer A that has contracts with several other Providers (X, Y, ...).
> - I decide to add a new contract between Consumer A and a new Provider Z. I publish the contract and verification results between them to the broker.
> - For whatever reason, I then decide this new pacticipant pair is no good, so I delete all the published pacts between them.
> - I run `can-i-deploy` for either Consumer A or Provider Z and I now get
```There is no verified pact between the latest version of Consumer A with tag production (my-git-sha) and version my-version of Provider Z```
> It?s also worth noting that since Consumer A and Provider Z have other interactions, I can?t just delete the entire pacticipants individually.
> If I go to `/pacts/provider/Provider%20Z/consumer/Consumer%20A/versions`, I can see that there are no pacts published and have even tried to send a DELETE to this endpoint, but the pair itself is not deleted, just the contracts.
>
> This prevents me from using `can-i-deploy` now. Is that intended?
matt.fellows
2022-01-07 12:48
Can you just delete the _integration_ itself? e.g. https://pact-foundation.slack.com/archives/CLS16AVEE/p1641421352238600?thread_ts=1641363180.231100&cid=CLS16AVEE
rafael.anachoreta
2022-01-07 14:03
Amazing :heart: That did the trick! Thank you so much, @matt.fellows!
rarora
2022-01-09 22:45
I downloaded sample project https://github.com/pact-foundation/pact-workshop-jvm-spring and replaced host to my broker
rarora
2022-01-10 00:03
Hi Team, can anybody help me with publishing verification result to broker (https://pact-foundation.slack.com/archives/C9VPNUJR2/p1641526375001900 )
matt.fellows
2022-01-10 00:07
Is it possible the system property is not properly being passed through?
rarora
2022-01-10 00:13
In my own project, i have set it as
```systemProperty "pact.verifier.publishResults", true```
rarora
2022-01-10 00:16
This setup(pact version including system property) is working on my different service but that service does not use Springboot.
uglyog
2022-01-10 00:16
When you run the tests in the IDE, is it using the Gradle runner or the JUnit runner?
rarora
2022-01-10 00:20
```[11:17:02,170][INFO] test.context.SpringBootTestContextBootstrapper - Neither @ContextConfiguration nor @ContextHierarchy found for test class [com.tripadvisor.experiences.pactprovider.service.provider.PactConsumerToPactProviderCT], using SpringBootContextLoader
[11:17:02,180][INFO] context.support.AbstractContextLoader - Could not detect default resource locations for test class [com.tripadvisor.experiences.pactprovider.service.provider.PactConsumerToPactProviderCT]: no resource found for suffixes {-context.xml, Context.groovy}.
[11:17:02,181][INFO] context.support.AnnotationConfigContextLoaderUtils - Could not detect default configuration classes for test class [com.tripadvisor.experiences.pactprovider.service.provider.PactConsumerToPactProviderCT]: PactConsumerToPactProviderCT does not declare any static, non-private, non-final, nested classes annotated with @Configuration.
[11:17:02,272][INFO] test.context.SpringBootTestContextBootstrapper - Found @SpringBootConfiguration com.tripadvisor.experiences.pactprovider.PactProviderApplication for test class com.tripadvisor.experiences.pactprovider.service.provider.PactConsumerToPactProviderCT
[11:17:02,365][INFO] test.context.SpringBootTestContextBootstrapper - Loaded default TestExecutionListener class names from location [META-INF/spring.factories]: [org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener, org.springframework.test.context.web.ServletTestExecutionListener, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener, org.springframework.test.context.support.DependencyInjectionTestExecutionListener, org.springframework.test.context.support.DirtiesContextTestExecutionListener, org.springframework.test.context.transaction.TransactionalTestExecutionListener, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener, org.springframework.test.context.event.EventPublishingTestExecutionListener]
[11:17:02,379][INFO] test.context.SpringBootTestContextBootstrapper - Using TestExecutionListeners: [org.springframework.test.context.web.ServletTestExecutionListener@295d17a4, org.springframework.test.context.support.DirtiesContextBeforeModesTestExecutionListener@2caf2c9, org.springframework.boot.test.mock.mockito.MockitoTestExecutionListener@6a0e92d2, org.springframework.boot.test.autoconfigure.SpringBootDependencyInjectionTestExecutionListener@63018137, org.springframework.test.context.support.DirtiesContextTestExecutionListener@22a05ac4, org.springframework.test.context.transaction.TransactionalTestExecutionListener@77a9b8e3, org.springframework.test.context.jdbc.SqlScriptsTestExecutionListener@69af2cc6, org.springframework.test.context.event.EventPublishingTestExecutionListener@6c800fd, org.springframework.boot.test.autoconfigure.restdocs.RestDocsTestExecutionListener@269e1c9a, org.springframework.boot.test.autoconfigure.web.client.MockRestServiceServerResetTestExecutionListener@1ccac60a, org.springframework.boot.test.autoconfigure.web.servlet.MockMvcPrintOnlyOnFailureTestExecutionListener@c930049, org.springframework.boot.test.autoconfigure.web.servlet.WebDriverTestExecutionListener@4a9a26ce, org.springframework.boot.test.mock.mockito.ResetMocksTestExecutionListener@1cb689cb]
11:17:02,409 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback-test.xml]
11:17:02,410 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Could NOT find resource [logback.groovy]
11:17:02,410 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.xml] at [file:/Users/rarora/dev/viator/pactprovider/build/resources/integrationTest/logback.xml]
11:17:02,455 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
11:17:02,457 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender]
11:17:02,464 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [STDOUT]
11:17:02,492 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - This appender no longer admits a layout as a sub-component, set an encoder instead.
11:17:02,492 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - To ensure compatibility, wrapping your layout in LayoutWrappingEncoder.
11:17:02,492 |-WARN in ch.qos.logback.core.ConsoleAppender[STDOUT] - See also http://logback.qos.ch/codes.html#layoutInsteadOfEncoder for details
11:17:02,493 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting level of logger [com.tripadvisor.experiences.pactprovider] to DEBUG
11:17:02,493 |-INFO in ch.qos.logback.classic.joran.action.LoggerAction - Setting additivity of logger [com.tripadvisor.experiences.pactprovider] to false
11:17:02,493 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[com.tripadvisor.experiences.pactprovider]
11:17:02,493 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to ERROR
11:17:02,493 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
11:17:02,493 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to INFO
11:17:02,493 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [STDOUT] to Logger[ROOT]
11:17:02,493 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - End of configuration.
11:17:02,494 |-INFO in ch.qos.logback.classic.joran.JoranConfigurator@416f274f - Registering current configuration as safe fallback point
[11:17:07,032][INFO] internal.util.Version - HV000001: Hibernate Validator 5.4.1.Final
[11:17:07,377][WARN] converter.json.Jackson2ObjectMapperBuilder - For Jackson Kotlin classes support please add "com.fasterxml.jackson.module:jackson-module-kotlin" to the classpath
. ____ _ __ _ _
/\\ / ___'_ __ _ _(_)_ __ __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
\\/ ___)| |_)| | | | | || (_| | ) ) ) )
' |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.2.6.RELEASE)
[11:17:07,658][WARN] test.json.DuplicateJsonObjectContextCustomizerFactory$DuplicateJsonObjectContextCustomizer -
Found multiple occurrences of org.json.JSONObject on the class path:
jar:file:/Users/rarora/.gradle/caches/modules-2/files-2.1/org.json/json/20160212/a742e3f85161835b95877478c5dd5b405cefaab9/json-20160212.jar!/org/json/JSONObject.class
jar:file:/Users/rarora/.m2/repository/com/vaadin/external/google/android-json/0.0.20131108.vaadin1/android-json-0.0.20131108.vaadin1.jar!/org/json/JSONObject.class
You may wish to exclude one of them to ensure predictable runtime behavior
[11:17:07,671][INFO] service.provider.PactConsumerToPactProviderCT - Starting PactConsumerToPactProviderCT on SYD-LDMXT1X0JG with PID 13226 (started by rarora in /Users/rarora/dev/viator/pactprovider)
[11:17:07,674][INFO] service.provider.PactConsumerToPactProviderCT - No active profile set, falling back to default profiles: default
[11:17:09,534][INFO] embedded.tomcat.TomcatWebServer - Tomcat initialized with port(s): 0 (http)
2022-01-10 11:17:09 [ForkJoinPool-1-worker-5] INFO o.a.coyote.http11.Http11NioProtocol - Initializing ProtocolHandler ["http-nio-auto-1"]
2022-01-10 11:17:09 [ForkJoinPool-1-worker-5] INFO o.a.catalina.core.StandardService - Starting service [Tomcat]
2022-01-10 11:17:09 [ForkJoinPool-1-worker-5] INFO o.a.catalina.core.StandardEngine - Starting Servlet engine: [Apache Tomcat/9.0.33]
2022-01-10 11:17:09 [ForkJoinPool-1-worker-5] INFO org.apache.jasper.servlet.TldScanner - At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
2022-01-10 11:17:09 [ForkJoinPool-1-worker-5] INFO o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring embedded WebApplicationContext
[11:17:09,871][INFO] web.context.ContextLoader - Root WebApplicationContext: initialization completed in 1961 ms
[11:17:11,024][INFO] scheduling.concurrent.ThreadPoolTaskExecutor - Initializing ExecutorService 'applicationTaskExecutor'
[11:17:12,565][INFO] endpoint.web.EndpointLinksResolver - Exposing 14 endpoint(s) beneath base path '/actuator'
2022-01-10 11:17:12 [ForkJoinPool-1-worker-5] INFO o.a.coyote.http11.Http11NioProtocol - Starting ProtocolHandler ["http-nio-auto-1"]
[11:17:12,679][INFO] embedded.tomcat.TomcatWebServer - Tomcat started on port(s): 57210 (http) with context path ''
[11:17:12,684][INFO] service.provider.PactConsumerToPactProviderCT - Started PactConsumerToPactProviderCT in 5.7 seconds (JVM running for 13.093)
Verifying a pact between pact-consumer and pact-provider
Verifying a pact between pact-consumer and pact-provider
Verifying a pact between pact-consumer and pact-provider
[Using Pact Broker https://pact-broker.rc.vkp.viatorsystems.com:]
[Using Pact Broker https://pact-broker.rc.vkp.viatorsystems.com:]
Given product with ID 10 exists
[Using Pact Broker https://pact-broker.rc.vkp.viatorsystems.com:]
get product with ID 10
Given product with ID 12 does not exist
get product with ID 12
Given products exist
get all products
2022-01-10 11:17:13 [http-nio-auto-1-exec-3] INFO o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring DispatcherServlet 'dispatcherServlet'
[11:17:13,929][INFO] web.servlet.DispatcherServlet - Initializing Servlet 'dispatcherServlet'
[11:17:13,954][INFO] web.servlet.DispatcherServlet - Completed initialization in 25 ms
returns a response which
returns a response which
returns a response which
has status code 404 (OK)
has status code 200 (OK)
has status code 200 (OK)
has a matching body (OK)
has a matching body (OK)
has a matching body (OK)
2022-01-10 11:17:14 [ForkJoinPool-1-worker-5] WARN a.c.d.p.p.DefaultTestResultAccumulator - Not all of the 3 were verified. The following were missing:
2022-01-10 11:17:14 [ForkJoinPool-1-worker-23] WARN a.c.d.p.p.DefaultTestResultAccumulator - Not all of the 3 were verified. The following were missing:
2022-01-10 11:17:14 [ForkJoinPool-1-worker-9] WARN a.c.d.p.p.DefaultTestResultAccumulator - Not all of the 3 were verified. The following were missing:
2022-01-10 11:17:14 [ForkJoinPool-1-worker-5] WARN a.c.d.p.p.DefaultTestResultAccumulator - get product with ID 12
2022-01-10 11:17:14 [ForkJoinPool-1-worker-9] WARN a.c.d.p.p.DefaultTestResultAccumulator - get product with ID 10
2022-01-10 11:17:14 [ForkJoinPool-1-worker-23] WARN a.c.d.p.p.DefaultTestResultAccumulator - get product with ID 10
2022-01-10 11:17:14 [ForkJoinPool-1-worker-5] WARN a.c.d.p.p.DefaultTestResultAccumulator - get all products
2022-01-10 11:17:14 [ForkJoinPool-1-worker-23] WARN a.c.d.p.p.DefaultTestResultAccumulator - get all products
2022-01-10 11:17:14 [ForkJoinPool-1-worker-9] WARN a.c.d.p.p.DefaultTestResultAccumulator - get product with ID 12```
rarora
2022-01-10 00:21
can we have quick slack call if possible? It might be simple thing I am missing on
matt.fellows
2022-01-10 00:23
If via gradle, I believe you can set the project property via the `-P` flag: https://docs.pact.io/implementation_guides/jvm/provider/gradle/#project-properties
matt.fellows
2022-01-10 00:26
Ah, I see. Gradle is the task runner, but JUnit is doing the actual verification and needs the system property. If it was the gradle verification task then `-P` would work?
rarora
2022-01-10 00:33
```package com.viator.supply.gradle
import au.com.dius.pact.provider.gradle.PactPlugin
import au.com.dius.pact.provider.gradle.PactPluginExtension
import org.gradle.api.Plugin
import org.gradle.api.Project
import org.gradle.api.plugins.JavaPluginConvention
import org.gradle.api.tasks.testing.Test
import org.unbrokendome.gradle.plugins.testsets.TestSetsPlugin
import org.unbrokendome.gradle.plugins.testsets.dsl.TestSetContainer
/**
* Apply this plugin to get a contractTest task and configuration for http://pact.io contract testing
* It can be used for both http://pact.io consumer as well as http://pact.io provider tests
*/
class ContractTesting implements Plugin<Project> {
@Override
void apply(Project project) {
project.ext.pactBrokerScheme = "https"
project.ext.pactBrokerHost = "http://pact-broker.rc.vkp.viatorsystems.com"
project.ext.pactBrokerUrl = "${project.ext.pactBrokerScheme}://${project.ext.pactBrokerHost}"
project.ext.pacticipantVersion = "${project.rootProject.ext.COMMIT_HASH}"
project.ext.pacticipant = "${project.name}"
project.ext.toTag = "production"
project.pluginManager.apply(PactPlugin)
project.pluginManager.apply(TestSetsPlugin)
project.extensions.configure(PactPluginExtension, { pactPluginExt ->
pactPluginExt.publish {
pactDirectory = "${project.buildDir.path}/pacts"
pactBrokerUrl = project.pactBrokerUrl
consumerVersion = "${project.rootProject.ext.COMMIT_HASH}"
tags = [project.version]
}
pactPluginExt.broker {
pactBrokerUrl = project.ext.pactBrokerUrl
retryCountWhileUnknown = 10
retryWhileUnknownInterval = 12
}
})
project.extensions.configure(TestSetContainer, { testSet ->
testSet.create("integrationTest")
testSet.create("contractTest")
})
JavaPluginConvention javaConvention = project.getConvention().getPlugin(JavaPluginConvention.class)
project.dependencies { dependencyHandler ->
testImplementation('au.com.dius:pact-jvm-provider-junit5:4.0.10') {
exclude(group: 'com.ibm.icu', module: 'icu4j')
//exclude(group: 'org.json', module: 'json')
exclude(group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib')
exclude(group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk7')
exclude(group: 'org.antlr', module: 'antlr4-runtime')
exclude(group: 'org.antlr', module: 'ST4')
exclude(group: 'org.dmfs', module: 'iterators')
exclude(group: 'io.netty')
exclude(group: 'com.amazonaws', module: 'aws-java-sdk-s3')
exclude(group: 'javax.mail', module: 'mail')
}
testImplementation('au.com.dius:pact-jvm-consumer-junit5:4.0.10') {
exclude(group: 'com.ibm.icu', module: 'icu4j')
//exclude(group: 'org.json', module: 'json')
exclude(group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib')
exclude(group: 'org.jetbrains.kotlin', module: 'kotlin-stdlib-jdk7')
exclude(group: 'org.antlr', module: 'antlr4-runtime')
exclude(group: 'org.antlr', module: 'ST4')
exclude(group: 'org.dmfs', module: 'iterators')
exclude(group: 'io.netty')
exclude(group: 'com.amazonaws', module: 'aws-java-sdk-s3')
exclude(group: 'javax.mail', module: 'mail')
}
testImplementation("org.jetbrains.kotlin:kotlin-stdlib:1.3.60")
testImplementation("com.squareup.okhttp3:okhttp:3.14.7")
integrationTestImplementation javaConvention.sourceSets.test.output + javaConvention.sourceSets.main.output
contractTestImplementation javaConvention.sourceSets.integrationTest.output + javaConvention.sourceSets.test.output
}
/**
* Jenkins slaves do not have the Viator self-signed root certificates, pactPublish requires it to talk to the broker
*/
System.setProperty("javax.net.ssl.trustStore", "${project.rootDir}/buildSrc/viatortruststore");
project.tasks.withType(Test) {
useJUnitPlatform()
/**
* additionally test that verify pact contracts also needs to talk to the broker but are in a different jvm
*/
systemProperty "javax.net.ssl.trustStore", "${project.rootDir}/buildSrc/viatortruststore"
systemProperty "pact.provider.version", project.rootProject.ext.COMMIT_HASH
systemProperty "pact.provider.tag", project.rootProject.ext.PACT_PROVIDER_TAG
systemProperty "pact.verifier.publishResults", true
systemProperty "pactbroker.host", project.ext.pactBrokerHost
systemProperty "pactbroker.scheme", project.ext.pactBrokerScheme
systemProperty "pactbroker.tags", project.rootProject.ext.PACT_CONSUMER_TAG
filter {
setFailOnNoMatchingTests(true)
}
systemProperty "pact.verification.reportDir", "build/reports/pact"
systemProperty "pact.verification.reports", "markdown,console,json"
}
}
}```
rarora
2022-01-10 00:36
pact version:
```implementation "gradle.plugin.au.com.dius.pact.provider:gradle:4.1.20"```
uglyog
2022-01-10 00:39
Try change `systemProperty "pact.verifier.publishResults", true` to `systemProperty "pact.verifier.publishResults", "true"`
rarora
2022-01-10 02:28
Just FYI, I think issue is with code as unverifiedInteractions sometimes comes as positive and sometimes come as empty. I am checking if there is issue with Parallel execution of test. Consumer Provider Code i am using is from sample project
```val unverifiedInteractions = unverifiedInteractions(pact, interactionResults)
if (unverifiedInteractions.isEmpty()) {
logger.debug {
"All interactions for Pact ${pact.provider.name}-${pact.consumer.name} have a verification result"
}
if (verificationReporter.publishingResultsDisabled()) {
logger.warn { "Skipping publishing of verification results as it has been disabled " +
"($PACT_VERIFIER_PUBLISH_RESULTS is not 'true')" }
} else {
verificationReporter.reportResults(pact, interactionResults.values.fold(TestResult.Ok) {
acc: TestResult, result -> acc.merge(result)
}, lookupProviderVersion(), null, lookupProviderTag())
}
testResults.remove(pactHash)
} else {
logger.warn { "Not all of the ${pact.interactions.size} were verified. The following were missing:" }
unverifiedInteractions.forEach {
logger.warn { " ${it.description}" }
}
}```
rarora
2022-01-10 02:30
I was able to see property value as set correctly to true, so there is no issue at that end
uglyog
2022-01-10 02:32
Just to note that if only a subset of tests are run (via filtering), then the results will not be published. There has to be a test result for each interaction in the Pact file
rarora
2022-01-10 02:34
I am running all tests actually. trying to check how unverified interactions is calculated
rarora
2022-01-10 03:24
@uglyog by any chance do you know why it would not execute all tests in one go?
rarora
2022-01-10 03:27
Also, what is difference between
```import au.com.dius.pact.provider.junitsupport.State;```
vs
```import au.com.dius.pact.provider.junit.State;```
uglyog
2022-01-10 03:27
No, that is more a JUnit 5 thing than a pact thing. Are you using any type of filter?
rarora
2022-01-10 03:28
No, my provider test class is very simple. I am not using mock. I thought it was not necessary
```package com.tripadvisor.experiences.pactprovider.service.provider;
import java.net.MalformedURLException;
import au.com.dius.pact.provider.junit.IgnoreNoPactsToVerify;
import au.com.dius.pact.provider.junit.Provider;
import au.com.dius.pact.provider.junit.State;
import au.com.dius.pact.provider.junit.VerificationReports;
import au.com.dius.pact.provider.junit.loader.PactBroker;
import au.com.dius.pact.provider.junit5.HttpTestTarget;
import au.com.dius.pact.provider.junit5.PactVerificationContext;
import au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.TestTemplate;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.web.server.LocalServerPort;
@Provider("pact-provider")
@VerificationReports
@PactBroker(consumers = "pact-consumer")
@IgnoreNoPactsToVerify
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class PactConsumerToPactProviderCT {
@LocalServerPort
int port;
@BeforeEach
void setUp(PactVerificationContext context) throws MalformedURLException {
if (context != null) {
context.setTarget(new HttpTestTarget("localhost", port));
}
}
@TestTemplate
@ExtendWith(PactVerificationInvocationContextProvider.class)
void verifyPact(PactVerificationContext context) {
if (context != null) {
context.verifyInteraction();
}
}
@State("products exist")
void testGetAllProducts() {
}
@State("product with ID 10 exists")
void testGetOneProduct() {
}
@State("product with ID 12 does not exist")
void testProductDoesNotExist() {
}
}```
uglyog
2022-01-10 03:30
BTW, you are running Pact-JVM 4.0.10
```testImplementation('au.com.dius:pact-jvm-provider-junit5:4.0.10')```
uglyog
2022-01-10 03:36
`http://au.com.dius.pact.provider.junit.State` was deprecated and replaced with the other one
rarora
2022-01-10 03:44
Could not resolve all files for configuration ':testCompileClasspath'.
> Could not find au.com.dius:pact-jvm-provider-junit5:4.1.32.
Required by:
project :
> Could not find au.com.dius:pact-jvm-consumer-junit5:4.1.32.
Required by:
project :
uglyog
2022-01-10 03:47
You have the wrong package, `au.com.dius.pact.consumer:junit5` not `au.com.dius:pact-jvm-provider-junit5`
rarora
2022-01-10 03:59
since consumers is deprecated, how would we specify consumer now?
```@PactBroker(consumers = "pact-consumer")```
rarora
2022-01-10 04:20
Since I am doing local testing of new consumer, do you think this is right way?
```@Provider("pact-provider")
@VerificationReports
@PactBroker(consumerVersionSelectors={@VersionSelector(consumer = "pact-consumer")})
@IgnoreNoPactsToVerify
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment.RANDOM_PORT)
public class PactConsumerToPactProviderCT {```
I can see latest is set to true and I want to verify for any consumer branch for now
uglyog
2022-01-10 04:25
Oh, that is old. You can still use the consumer field on the annotation, it is just deprecated in 4.1.x
rarora
2022-01-10 04:28
We have prod pipelines running on that version. how difficult would be to upgrade?
uglyog
2022-01-10 04:29
Upgrading is easy (use use the latest version, esp if using docker). However, there are changes with respect to tags and branches that may change behaviour
rarora
2022-01-10 04:33
where can i add debug point? Its not coming in TestResultAccumulator or PactVerificationExtension
uglyog
2022-01-10 04:36
I mean, you are telling it to ignore not finding any pacts, so there is nothing to populate the context with if there are no pacts returned
rarora
2022-01-10 04:37
```No Pact files were found to verify
Provider: pact-provider
Source: Pact Broker https://pact-broker.rc.vkp.viatorsystems.com: consumerVersionSelectors=[ConsumerVersionSelector(tag=latest, latest=true, consumer=pact-consumer, fallbackTag=null)] consumers=[pact-consumer]
au.com.dius.pact.provider.junitsupport.loader.NoPactsFoundException: No Pact files were found to verify
Provider: pact-provider
Source: Pact Broker https://pact-broker.rc.vkp.viatorsystems.com: consumerVersionSelectors=[ConsumerVersionSelector(tag=latest, latest=true, consumer=pact-consumer, fallbackTag=null)] consumers=[pact-consumer]```
rarora
2022-01-10 04:45
so it worked with
```@PactBroker(consumers = "pact-consumer", tags = { "SUPPLY-6616-pact-test-consumer-1-SNAPSHOT"})```
rarora
2022-01-10 04:47
But now my question is when consumer publishes a new contract from feature branch and it is going to be verified by webhook, how would provider build (ruuning through webhook trigger) know which contract to verify because current pipeline is using latest
uglyog
2022-01-10 04:48
there is no such thing as a latest tag, there is only the latest version of a tag
uglyog
2022-01-10 04:50
No, the feature branches should tag with the branch name, only your main branch should use main
rarora
2022-01-10 04:52
can you explain this is detail. how ideally it should be setup for canIDeploy to work from consumer side?
1. consumer feature branch publishes new contract
2. it triggers provider test run through webhook
3. Provider webhook pipeline checks out production verison of provider and runs test
4. Provider webhook build will not verify contracts for feature branches and will verify only for *main*(in our case develop branch)??
2022-01-10 04:57
Here are a number of useful hands-on labs that teach all of the key concepts https://docs.pact.io/implementation_guides/workshops
rarora
2022-01-10 05:19
@matt.fellows I read above but i am still confused about first release of project. Can you explain how it will work for feature branches because as per my understanding current implementation(I tag provider test to run for main/prod/test branch, as I dont know feature branch name i cannot provide tag for it) will only support pact verification on main branch.
matt.fellows
2022-01-10 05:22
are you talking about for the standard provider verification, or webhooks?
matt.fellows
2022-01-10 05:22
For webhooks, I would configure it to verify against `main` and `production` (i.e. both, if possible)
rarora
2022-01-10 05:27
see my issue is:
1. feature branch say feature_consumer published new contract
2. It trigerred webhook. Webhook checked against develop/production for consumer
3. feature_consumer is not verified. Feature branch canIDeploy fails because it has not got production tag for provider
matt.fellows
2022-01-10 05:34
so for release one:
1. Consumer publishes new pact
2. Provider implements feature and pushes build
3. Provider deploys, marking as having deployed to `production`
4. Consumer runs `can-i-deploy --to-environment production` which is now green
5. Consumer deploys (and marks as having deployd to production)
matt.fellows
2022-01-10 05:35
You shouldn?t have to manually set up data, but you may need to manually trigger provider/consumer builds
rarora
2022-01-10 05:38
> Provider deploys, marking as having deployed to `production`
In your step 3, Since it is unable to find any consumer pact tagged with main, It does not tag any pact and exists successfully due to IgnoreNoPactsToVerify. How would it tag feature branch pact?
rarora
2022-01-10 05:38
> You shouldn?t have to manually set up data, but you may need to manually trigger provider/consumer builds
rarora
2022-01-10 05:40
We were facing issue to convince people to use pact as they find it difficult. If they are not automatically verified, it will be more tough but let me read up on WIP pacts
matt.fellows
2022-01-10 09:18
In step (2), you can verify the feature pact from (1) without hard coding the feature pact (by tag, selector etc.). The WIP pacts (via https://docs.pact.io/implementation_guides/jvm/provider/junit/#work-in-progress-wip-pact-support-version-415-and-later) will collect and verify this
david.vancouvering
2022-01-12 18:11
Hey, all. As I come to understand better how Pact works with the broker, I am thinking of what you want to have in a PR-check CI pipeline for the provider. We are using the Maven and JVM plugins, so we can't use the new concept of releases yet, just tags.
Here is how we currently have it:
? Run provider verification using the tag for the master branch. This will grab the pact version for the latest of each consumer tagged with 'master' and run verification against it. Say it returns A, B and C
? If the verification fails, the build fails at this point
? We publish the verification results saying version xyz of the provider has been verified against pact versions A, B, C
? We currently aren't tagging with environment names when we deploy. What we have instead is we run `can-i-deploy` against the `master` tag. But I believe at this point the step is unnecessary because we wouldn't get to this step unless verification passed for the exact same pact versions. So I am arguing we can skip this step for now. Once we start tagging with environment names, we could run `can-i-deploy` for say `staging` and `prod` before we allow a PR to be merged.
I'd love your thoughts on this, thanks!
yousafn
2022-01-12 23:19
Hey dude,
V cool you are from eBay, I spend far too much time buying and selling things I definitely don?t need but want to have hahaha!
Just to be clear, you are talking about skipping the Can I deploy step prior to deploying the consumer.
If so, there are cases in my current client setup where main/master has merged code, but it isn?t deployed for some time. ( Friday release cutoff / someone hasn?t pressed hold approval / change freeze or some other arbitrary reason)
if we didn?t have visibility of the deployed version of provider code, and master/main had a breaking change in it, we would believe you are safe to deploy your consumer by your master/main provider tag, but would be stopped by an environment tag on deploy.
As in my poorly described example, my deployed provider would have a change not compatible with the current consumer I wish to deploy.
I may have missed the mark completely with your question.
Also do you reckon you could visualise your scenario, I?ve bought an iPad recently with a pen for that very reason so might sketch something out
david.vancouvering
2022-01-12 23:50
Hi, YOU54f? :slightly_smiling_face:
Sorry if I wasn't clear. I was talking about the PR check job for the _provider_. We want to be sure the provider is all clear before we merge a change into the main trunk.
I agree totally with you, we need to move to tagging when something is deployed, we just haven't gotten there yet. In which case before merging the provider change we should run `can-i-deploy staging` and `can-i-deploy prod`. And then also do it in the deploy job before actually deploying to staging or prod.
The reason we want to check before merging is to avoid merging an obviously broken change into the main branch...
Maybe it's better just to do that than haggle over this question.
Thanks for your response!
yousafn
2022-01-13 00:03
Haha I relate to your last comment so much at work.
We are never at the nirvana state and if we worry too much about not being there, we never move in the meantime.
I?ve enjoyed reading your questions and thought processes being out in the open, I?ve been lurking the past few months as I?ve had other commitments outside of OSS, but I?m back helping out again.
So just reading your post again. Yes if the provider got the all clear from the pact provider tests and publishes its verification it should be good to deploy without checking can I deploy, if you are doing it immediately/part of the same build.
If you trigger a different build pipeline to do the deployment, you may want a guard there that uses can I deploy, which gives you that security in case anything has moved on, if your environment has changed versus the versioned artefact of your provider you want to deploy ( which is where the deployed env tags came useful to me )
My current client isn?t rocking pact at the moment so I?m talking from experience from my last gig which ended 9 months ago
Saf!
david.vancouvering
2022-01-13 00:03
Yes, makes sense, I think we're on the same page. Thanks for your help
matt.fellows
2022-01-13 00:21
The main argument to run `can-i-deploy` on the side, is that the longer the time there is between ?verification passed? and ?deployed to production?, the greater the chance that the verification is no longer valid because there is a new consumer in production.
In a true continuous deployment world, you might argue it?s not worth it. But once you get the tagging in place, it?s really a fairly trivial step to implement.
There are additional benefits of doing all of the tagging - for instance, in the Broker/Pactflow UI you can see which environment things have been deployed to and (in Pactflow at least is where we are headed) gain further insights into the whole release process
rarora
2022-01-13 01:09
Hi Team
small help, we have pact testing running for around 20 services but there is one service that intermittently fails while pactPublish. Setup is same for all services. Any such error seen before? It usually passes on rerun but we were hoping to get rid of this flakiness
```23:24:24 23:24:24 FAILURE: Build failed with an exception.23:24:24 23:24:24 * What went wrong:23:24:24 Execution failed for task ':services:application-services:supplyperf-service:supplyperf-svc:pactPublish'.23:24:24 > java.io.FileNotFoundException: /home/vr_jenkins/workspace/Build/Apps/supply-platform-build/services/application-services/supplyperf-service/supplyperf-svc/build/pacts*23:24:24*```
david.vancouvering
2022-01-13 01:25
I can see your argument, but the gap in time between the provider verification running and the can-i-deploy running in the same build for the same exact tag is like a few seconds. But if we change it from the branch tag to the _environment_ tag, it seems really useful to check that before merging. Why would we want to merge a clearly broken change into trunk?
Good point about providing more information about what versions are where; this can also be obtained through github queries but this makes it a bit easier.
matt.fellows
2022-01-13 01:54
`can-i-deploy` is really primarily supposed to be invoked _just prior to a deployment_
matt.fellows
2022-01-13 01:54
so if you?re not deploying off each build, then it probably is less useful.
matt.fellows
2022-01-13 01:56
well, for starters it looks like the `pacts` directory doesn?t exist, so are you sure you?re publishing from the right directory?
rarora
2022-01-13 02:05
when we run contract test task, it automatically generates this directory. I never created it manually. Its in build folder and gets removed with gradle clean
matt.fellows
2022-01-13 02:56
If it's inconsistent that's usually a side of configuration, timing or environmental issues
matt.fellows
2022-01-13 02:56
Is there anything that could delete that folder during the build? I.e. another process operating in the same folder? Does it work locally but not in CI?
tjones
2022-01-13 03:44
> Why would we want to merge a clearly broken change into trunk?
I think it depends what your rules around trunk are.
tjones
2022-01-13 03:44
> Good point about providing more information about what versions are where;
This is actually partly why I built absolute-version: https://www.npmjs.com/package/@pact-foundation/absolute-version
tjones
2022-01-13 03:45
I think we need a cookbook with different Pact tagging strategies for different deployment styles
tjones
2022-01-13 03:48
Anyway, in general, with versions and tagging, I like to reduce the number of layers of indirection. You can use a build number or a commit hash and get a unique number, but a human can't really read those without consulting other sources
tjones
2022-01-13 03:48
Same with the tags. If I have tagged with the branches, I don't need to go look at the repo to find out what version the latest pact from that branch would report as
mike.geeves064
2022-01-13 09:13
absolute-version looks interesting, that feels like something that gets duplicated in many places slightly differently :smile: is that included in any of the CI/CD examples?
tjones
2022-01-14 02:06
FYI, we've just moved it out of the pact-foundation org to its own thing:
https://github.com/absolute-version/absolute-version-js
tjones
2022-01-14 02:08
I'll publish version 1.0 this weekend probably, and deprecate the `@pact-foundation` ones.
mike.geeves064
2022-01-18 09:58
Tangenting a little so I'll start a new thread, thinking of the absolute-version @tjones mentioned, for a repo I'm currently using bump2version to identify the "next" minor version to automatically tag dev builds:
> - LATEST_TAG=$(git describe --tags --abbrev=0) && echo $LATEST_TAG
> - BUMP_VERSION=$(bump2version --allow-dirty --current-version ${LATEST_TAG} minor --list) && echo $BUMP_VERSION
> - MINOR_BUMP_BUILD_VERSION=$(echo $BUMP_VERSION | grep new_version | sed -r s,"^.*=",,)+$CI_COMMIT_SHORT_SHA
So that's identify the latest tag from git, e.g. 1.19.4, minor bump to 1.20.0 and then add the commit to give 1.20.0+abcd1234
Is combining in some way to identify the current version and then if there's an API breaking change (according to Pact tests) you could then major bump or if not minor bump something people try and do/could be useful to show in a workflow, or is that generally everyone sticks to a manual for their main/actual version tagging? :thinking_face:
tjones
2022-01-18 11:33
I'm not actually sure that you can generate a list of API breaking changes with pact- it detects that something has broken, rather than there was a breaking change.
I might be missing something obvious, but even if you generated the full matrix of all contract versions and all providers, I?m not sure what the algorithm for spotting the breaking changes would be
tjones
2022-01-18 11:33
Also pact detects breaking communication changes, but not breaking behaviour changes
tjones
2022-01-18 11:35
For pact-js releases, we use `standard-version` to read the commit log (which is annotated by convention), and determine what the release version should be.
mike.geeves064
2022-01-18 11:43
I think that's enough isn't it, if something has broken then when you tag it, you should be doing a major bump, if it's additions then minor
tjones
2022-01-18 11:43
There are two versions, a consumer and a provider. Which one gets the version bump?
tjones
2022-01-18 11:44
Pact reasons about version pairs (really about pairs of contract and provider)
tjones
2022-01-18 11:44
but a breaking change in the provider verification might be because the consumer's expectations changed
mike.geeves064
2022-01-18 11:44
Yes, more of you can use pact being in your workflow to help automate the "no you really should consider that major" for API changes
tjones
2022-01-18 11:46
but also, you can't detect all breaking changes, because your existing consumers might not have full coverage of your provider API
tjones
2022-01-18 11:47
it's kind of a difference in philosophy - in Swagger, there is a definition of breaking change. In Pact, we don't need one, because we know which consumers are currently compatible
mike.geeves064
2022-01-18 11:48
I'm not thinking for Pact benefit directly, more if it could be a helpful benefit of using Pact
tjones
2022-01-18 11:48
(both swagger and pact ignore breaking behaviour changes that don't affect message structure)
tjones
2022-01-18 11:48
I think you _could_ use it to automate certain cases, but I think you would miss many, and that feels risky to me
tjones
2022-01-18 11:49
for me, partially automatic change detection would be worse than no change detection
tjones
2022-01-18 11:49
also, I find the annotated commit style we use for pact-js is very effective. In general, the developer knows if a change is breaking when they are making the commit
tjones
2022-01-18 11:50
With clear standards on commits, we don't really have issues with people not realising that a change is breaking
mike.geeves064
2022-01-18 11:50
I like linters and things not being up for pointless arguments in workflows :grinning:
tjones
2022-01-18 11:50
I built absolute-version because I thought that Pact should have a "here's a versioning system" for when you don't have one
tjones
2022-01-18 11:52
not breaking a consumer you know about does not mean that you haven't broken one you don't know about
tjones
2022-01-18 11:53
By the way, the first version of absolute version was a bash script - it's here: https://gist.github.com/TimothyJones/edf3c5d0e0de582ec34a6daa734d7517#file-semver-from-git-sh
tjones
2022-01-18 11:55
both your script above and this one have the disadvantage that they fail to produce semver compatible strings if:
? your tag is semver that already includes build metadata
? your tag is not semver
mike.geeves064
2022-01-18 11:59
yeah, expectation of a consumer changing, that would be covered as WIP so wouldn't necessarily then flag your provider as breaking
mike.geeves064
2022-01-18 12:00
hmm, that's true, I suppose it all depends on how much you can "trust" the people working on the code and how strict it needs to be :thinking_face:
tjones
2022-01-18 12:01
For me, I want versioning to be fire-and-forget. I don't want to have to remember the times that the versioning script won't work for us and have to remember to bump the version manually. That seems like a risk.
mike.geeves064
2022-01-18 12:02
lint as in, I like not having the arguments about how to format and so on, there isn't even a conversation to have [I wasted so much time rejecting code reviews with a ffs format your code so i can actually read it]
tjones
2022-01-18 12:07
The policy I've been following for pact-js is - we ask once for people to re-submit with commit messages suitable for the changelog, and if they don't or don't want to, then we squash merge and correct the message. Most contributions that don't match the policy are from first time contributors and are only one or two commits, so this seems to work well
tjones
2022-01-18 12:08
The challenge behind integrating a versioning strategy into pact is that we need to know how you mark releases, and many people do it differently
tjones
2022-01-18 12:09
I was thinking of making it very easy in pact-js by offering a flag that says "figure it out from my semver tags" or "just the git commit" or something
mike.geeves064
2022-01-18 12:09
I think to an extent that's kind of back to like linting, there are different version strategies but nobody really wants to spend their head space arguing about it
tjones
2022-01-18 12:10
I think one of the worst things about pact is that it leaks into your versioning strategy. As in, if you're not doing it in a principled way (eg, multiple code-changing commits would have the same "version"), then you're going to have a bad time with pact
mike.geeves064
2022-01-18 12:11
I have a terrible past of versioning, the "Toolbox" I made never made it to 1.0 despite being in production for about a decade and my version bumps were very subjective and bias around the effort of big version bump deploys :joy: Must do better!
tjones
2022-01-18 12:11
however, everyone uses Version Control these days, usually git. It is sufficient for the commit hash to be used as a version (and we could default to that), but it's not nice for humans
tjones
2022-01-18 12:12
even if there's a client and a server, but you're deploying only one of each (or a cluster of the same version), you don't care about the version number, you just care whether it works with the other currently deployed one
mike.geeves064
2022-01-18 12:12
:smile: was still on PostgreSQL 9.1 I think because downtime was too long, sob
mike.geeves064
2022-01-18 12:14
ah, kind of, I'm a big fan of having multiple versions of something available, there was a weird situation where it went from having multiple versions (where people in the office would use the trunk "believed to be good but not released" version) and customers on another version with just a different link for the two, then it was just a symlink change to upgrade....... "progress" to browser based meant only a single version available at all and.... tableflip
tjones
2022-01-18 12:15
Also - a failed pact verification means "don't release this", not "please mark this as a breaking change"
mike.geeves064
2022-01-18 12:16
I'm thinking with the matrix, if there was a break against a consumer version that previously worked before, presumably your can-i-deploy would block until you then had a newer consumer version which passed -> you can deploy, but there was a breaking change
tjones
2022-01-18 12:19
Most of the advantages of semver fall down if you control all the consumers and providers (although I still use it, or at least versions that would pass a semver regex)
tjones
2022-01-18 12:21
On a project that had both milestone releases and sprints, I once tried using major versions to mark milestone releases and minor versions to mark sprints boundaries (and patch versions to mark behaviour changes
tjones
2022-01-18 12:21
it was really nice because you could plan for the demo super easily - pull all commits titles since the last minor release, and now you have the whole list of things that were fixed this sprint
tjones
2022-01-18 12:22
quite a bit more than the "done" column showed, because people often fix small things out of band
tjones
2022-01-18 12:23
In a large enough enterprise, you might want to consider the other teams as "the public" and use semver, but I think that might not make sense for HTTP APIs
tjones
2022-01-18 12:23
large enterprise seem to really like swagger and its definition of breaking changes being removing or renaming things
mike.geeves064
2022-01-18 12:35
I mean, not even large, that was where I was trying to introduce Pact because of so many disagreements between teams working on FE products and teams working on BE :smile:
paul.simms
2022-01-25 15:38
Hello,
We have recently updated the pact broker to 2.93 (first update we have made for a while).
We are now seeing a number of failures when performing a can-i-deploy with details such as:
"There is no verified pact between the latest version of <consumer> with tag preprod (68bc5ac6) and version 7ddf43db of <provider>" (noticed for provider can-i-deploys).
These were previously passing the can-i-deploy stage. Filtering on the matrix for versions specified are not showing.
I know there is now a move to environments rather than tags - but as I understand tags are still supported. The update to environments are likely to take us a while to manage and implement across teams (on that is there a suggested method for this - to use both for a while?).
The new errors are not obvious, so if anyone has seen similar, any suggestions would be welcome. Many thanks
matt.fellows
2022-01-25 23:28
I don?t think it relates to a change to environments/branches. The `can-i-deploy` switches support both, as does the broker itself
matt.fellows
2022-01-25 23:29
it sounds like perhaps some data was lost/truncated - do the logs indicate anything like that?
matt.fellows
2022-01-25 23:29
I would be inclined initially, to trust what it?s saying - that there is no version of the consumer compatible with that version of the provider. you can probably verify this by looking at the API resources
matt.fellows
2022-01-25 23:30
You can also test the truncation theory, by re-running the builds on both sides to get the data populated. If can-i-deploy passes, you know that data was lost somehow
paul.simms
2022-01-27 13:35
@matt.fellows Many thanks for you quick response. We're doing further investigations into this. It does look as though some data has been lost for some reason.
One instance that we have seen does now make sense, as a consumer has stopped using a provider, and thus has a PACT which is tagged as dev with other providers. However, I guess that as the integration had not been deleted when doing a can-i-deploy then the pact was 'missing'. We'll try to get the team to update the provider to use failIfNoPactsFound = false which will hopefully resolve this workflow in the future.
paul.simms
2022-01-27 13:36
Regarding the move from tags to environments - do you have a timescale on when this will need to be done, and guidance on the best way to do this transition service by service?
matt.fellows
2022-01-27 21:15
that?s right. If you delete the _pacts_ (but not the integration), can-i-deploy will still expect things to be lined up. You can delete the integration, if necessary
matt.fellows
2022-01-27 21:16
> Regarding the move from tags to environments - do you have a timescale on when this will need to be done, and guidance on the best way to do this transition service by service?
we?re not going to force anyone onto environments. I think there is some guidance https://docs.pact.io/blog/2021/10/08/why-we-are-getting-rid-of-tags/ on migrating
christoph.oswald
2022-01-31 06:58
Yes, sure, please excuse the delay. We have been evaluating pact initially and are now continuing. The error is:
2022-01-31 06:52:52.067543 E [6:puma server threadpool 001 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference BMAjcKgftQ -- Exception: Sequel::DatabaseDisconnectError: PG::ConnectionBad: PQconsumeInput() server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
I have attached the full log.
thanuxxxx
2022-02-01 15:03
Why I am getting this warning `(Pact from branch PR-2095 has changed since last successful verification by provider (051558fa08868...)Pact from branch PR-2095 has changed since last successful verification by provider (051558fa08868...))` even though no contract changed from last successful verification ?
thanuxxxx
2022-02-01 15:09
And I could not find `pb:diff-previous-distinct` in HAL browser for `pactfoundation/pact-broker:2.92.0.0` https://github.com/pact-foundation/pact_broker/wiki/How-to-see-what-has-changed-in-a-pact
christoph.oswald
2022-02-03 15:42
@bethskurrie it appears to me, that the issue is linked to the basic authentication. When I had it disabled, it did not appear at all. I had it on a clean install of the pact-broker, no pacts besides the example. Attached you can find the full log.
greg.tyler
2022-02-04 09:26
Hiya folks! I was looking for a bit of advise with webhooks, might be doing something silly.
Part of my current process is:
? PR against the provider tests against latest consumer Pacts tagged `main` (to ensure no regressions are being introduced)
? Test results are published to Pact Broker
? This triggers a webhook because `provider_verification_published` was fired
? The webhook is to set a ?Pact verification? commit status check on GitHub
? Because we?re checking against `main`, this updates the status of the HEAD commit
Ultimately this means that my ?Pact verification? status check on the main/HEAD commit reflects the _last provider PR_ rather than the actual PR status.
I have a few solution ideas:
1. *Am I missing a webhook setting to only trigger when the provider build was tagged `main`?* That way I?d stop pushing commit statuses for PRs.
2. *Should I not publish Pact results from PRs to the Broker?* That would ensure it didn?t trigger the webhook, but would limit the amount of useful information in the Broker
3. *Should I include the provider version in the GitHub commit status context?* (e.g. so I have ?Pact verification against main?, ?Pact verification against {PR name}?) This will mean I have extra checks, potentially including failures from irrelevant provider PRs
I?m erring towards the second option, but I think this is a slightly philosophical ?how to use Pact? question so would be interested to hear what other users and maintainers think.
akke.luukkonen
2022-02-04 10:18
Disclaimer: I haven't been using Pact for a long time yet, so this might not be the best practice.
I personally perform option 2. and don't publish anything from the provider CI when the pipeline trigger is a PR. I don't really see a reason to publish the results for it since at least in Azure the PR creates a temporary commit that will disappear from existence after the PR is abandoned/completed (hash won't be the same with the actual merge post-completion).
For actual deployments I'm only interested in deployments recorded against `prod` or `develop` environments, so I feel I'm not losing any value by skipping the publishing for PRs.
There was a `PACT_BROKER_PUBLISH_VERIFICATION_RESULTS` env variable that is already checked whether the run should publish a result or not, so I'm using that to skip the result publishing in my CI.
Azure Pipelines:
```variables:
publishPactResults: $[lower(ne(variables['Build.Reason'], 'PullRequest'))]
...
- task: Bash@3
displayName: Run verification
...
env:
PACT_BROKER_PUBLISH_VERIFICATION_RESULTS: $(publishPactResults) ```
greg.tyler
2022-02-04 11:04
Thanks Akke, that?s a great explanation of the feeling I was getting. Seems like I set things up a bit _too_ much when I did this initially :smile:
akke.luukkonen
2022-02-04 11:28
Experiment & learn :smile:
By the way, there was the (rather) new `contract_requiring_verification_published` option that doesn't trigger the webhooks on each publish, but it does require some additional setup (https://docs.pact.io/pact_broker/webhooks/#using-webhooks-with-the-contract_requiring_verification_published-event). It has worked great for me to reduce the amount of test runs executed "unnecessarily".
greg.tyler
2022-02-04 11:31
Ooo, that sounds helpful. We?re not recording deployments/releases yet, but I?ll take another look when we are
tom450
2022-02-04 11:47
Hello, does anyone please have an example of how they bring up a cloud postgresql instance via Terraform? I have everything working but for some reason the `PACT_BROKER_BASIC_AUTH` stuff doesnt seem to be working.
I know I had it working before I terraformed my infra. When I made the database manually and ran the psql commands
```CREATE DATABASE pact_broker;
CREATE ROLE pact_broker WITH LOGIN PASSWORD 'CHANGE_ME';
GRANT ALL PRIVILEGES ON DATABASE pact_broker TO pact_broker;```
the basic auth stuff worked fine
tom450
2022-02-04 11:49
i did a dry run of my helm chart too and all the env vars / secrets etc are passed in correctly
matt.fellows
2022-02-04 12:16
is the issue that the broker is not presenting basic auth to you or that it can?t connect to postgres?
tom450
2022-02-04 12:17
sorry, the issue is the broker is not presenting basic auth to me, but it used to before i terraformed my infra, so thought maybe its somehow related to how i created the database
tom450
2022-02-04 12:18
```# Source: pact-broker/templates/secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: pact-broker-secrets
type: Opaque
data:
pact-broker-basic-auth-password: "RG9qb1BhY3RCcm9rZXIh"
pact-broker-basic-auth-username: "YWRtaW4="
pact-broker-basic-read-only-auth-password: "UmVhZFBhY3RzIQ=="
pact-broker-basic-read-only-auth-username: "ZGV2"
pact-broker-database-url: "cG9zdGdyZXM6Ly9wYWN0X2Jyb2tlcjpEb2pvUGFjdERCIUAxMjcuMC4wLjE6NTQzMi9wYWN0X2Jyb2tlcg=="
---
# Source: pact-broker/templates/service.yaml
apiVersion: v1
kind: Service
metadata:
name: pact-broker-service
spec:
type: ClusterIP
selector:
app: pact-broker
ports:
- port: 9292
targetPort: 9292
---
# Source: pact-broker/templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: pact-broker-deployment
spec:
replicas: 1
selector:
matchLabels:
app: pact-broker
template:
metadata:
labels:
app: pact-broker
spec:
serviceAccountName: pact-broker-service-account
containers:
- name: cloud-sql-proxy
image: http://gcr.io/cloudsql-docker/gce-proxy:1.17
command:
- "/cloud_sql_proxy"
- "-instances=ag-staging-mobile:europe-west2:pact-broker-cloud-sql-instance=tcp:5432"
securityContext:
runAsNonRoot: true
resources:
requests:
memory: "2Gi"
cpu: "1"
- name: pact-broker
image: pactfoundation/pact-broker
env:
- name: PACT_BROKER_PUBLIC_HEARTBEAT
value: "true"
- name: PACT_BROKER_DATABASE_URL
valueFrom:
secretKeyRef:
name: pact-broker-secrets
key: pact-broker-database-url
- name: PACT_BROKER_BASIC_AUTH_USERNAME
valueFrom:
secretKeyRef:
name: pact-broker-secrets
key: pact-broker-basic-auth-username
- name: PACT_BROKER_AUTH_PASSWORD
valueFrom:
secretKeyRef:
name: pact-broker-secrets
key: pact-broker-basic-auth-password
- name: PACT_BROKER_BASIC_READ_ONLY_AUTH_USERNAME
valueFrom:
secretKeyRef:
name: pact-broker-secrets
key: pact-broker-basic-read-only-auth-username
- name: PACT_BROKER_BASIC_READ_ONLY_AUTH_PASSWORD
valueFrom:
secretKeyRef:
name: pact-broker-secrets
key: pact-broker-basic-read-only-auth-password
ports:
- name: http
containerPort: 9292
protocol: TCP
livenessProbe:
httpGet:
path: /diagnostics/status/heartbeat
port: http
initialDelaySeconds: 300
periodSeconds: 20
readinessProbe:
httpGet:
path: /diagnostic/status/heartbeat
port: http
initialDelaySeconds: 300
periodSeconds: 20
resources:
requests:
cpu: "200m"
memory: "512Mi"
limits:
cpu: "2500m"
memory: "1024Mi"
---```
matt.fellows
2022-02-04 12:20
looks like `PACT_BROKER_AUTH_PASSWORD` should be `PACT_BROKER_BASIC_AUTH_PASSWORD`
matt.fellows
2022-02-04 12:23
I was about to say it LGTM and then I saw the inconsistency and thought ?let me check if it matches?
rafael.anachoreta
2022-02-07 11:29
Maybe a silly question, but how can I get the latest version of a contract deployed to an environment? Similar to `describe-version --latest=production` except using environments
matt.fellows
2022-02-07 21:16
I think you can hit the APIs directly. If you query by environment, you can navigate to the deployed versions in that environment via the HAL relations
matt.fellows
2022-02-07 21:20
eventually you?ll get the resource that gives you this:
```curl -H"Authorization: Bearer ${PACT_BROKER_TOKEN}" https://testdemo.pactflow.io/environments/47158b1e-a5e0-4198-a9ab-008aa5e18bc5/deployed-versions/currently-deployed | jq .
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 21165 100 21165 0 0 52388 0 --:--:-- --:--:-- --:--:-- 52388
{
"_embedded": {
"deployedVersions": [
{
"uuid": "838dc2d8-8554-4ca2-805e-464a6bfb5c5f",
"currentlyDeployed": true,
"createdAt": "2022-02-01T03:40:46+00:00",
"_embedded": {
"pacticipant": {
"name": "pactflow-example-provider-js-sns",
"_links": {
"self": {
"href": "https://testdemo.pactflow.io/pacticipants/pactflow-example-provider-js-sns"
}
}
},
"version": {
"number": "d29ce65231c0c9a7cd857ba63503f1fc281eb4c3",
"_links": {
"self": {
"title": "Version",
"name": "d29ce65231c0c9a7cd857ba63503f1fc281eb4c3",
"href": "https://testdemo.pactflow.io/pacticipants/pactflow-example-provider-js-sns/versions/d29ce65231c0c9a7cd857ba63503f1fc281eb4c3"
}
}
},
"environment": {
"uuid": "47158b1e-a5e0-4198-a9ab-008aa5e18bc5",
"name": "production",
"displayName": "Production",
"production": true,
"createdAt": "2021-07-08T02:49:05+00:00",
"_links": {
"self": {
"title": "Environment",
"name": "production",
"href": "https://testdemo.pactflow.io/environments/47158b1e-a5e0-4198-a9ab-008aa5e18bc5"
},
"pb:currently-deployed-deployed-versions": {
"title": "Versions currently deployed to Production environment",
"href": "https://testdemo.pactflow.io/environments/47158b1e-a5e0-4198-a9ab-008aa5e18bc5/deployed-versions/currently-deployed"
},
"pb:currently-supported-released-versions": {
"title": "Versions released and supported in Production environment",
"href": "https://testdemo.pactflow.io/environments/47158b1e-a5e0-4198-a9ab-008aa5e18bc5/released-versions/currently-supported"
},
"pb:environments": {
"title": "Environments",
"href": "https://testdemo.pactflow.io/environments"
}
}
}
},
"_links": {
"self": {
"href": "https://testdemo.pactflow.io/deployed-versions/838dc2d8-8554-4ca2-805e-464a6bfb5c5f"
}
}
},
...```
matt.fellows
2022-02-07 21:21
You can see the version of `d29ce65231c0c9a7cd857ba63503f1fc281eb4c3` for the consumer deployed to prod
rafael.anachoreta
2022-02-08 10:08
Yep, I see it. Thanks a lot for the answer, @matt.fellows!
What do you think about extending `describe-version` to return this information? Or maybe adding a new `describe-deployed` /`describe-released` that returns all the deployed/released versions on the environment, optionally filtering by name?
```pact-broker describe-deployed --environment=production --pacticipant="My Consumer" ```
matt.fellows
2022-02-08 10:19
Make sense, I?d suggest raising a request at http://pact.canny.io (if it doesn?t exist already) and it can get prioritised there. If you can also attach the use case/justification that would help!
rafael.anachoreta
2022-02-08 10:19
Thanks, will do!
Edit: looks like we have one: https://pact.canny.io/feature-requests/p/support-environmentreleases-on-describe-version
christoph.oswald
2022-02-09 09:55
Hi, I have a question, regarding the webhooks described here (https://docs.pact.io/pact_nirvana/step_4#e-configure-pact-to-be-verified-when-contract-changes). Would you rather 1) create a webhook to trigger a generic CI build, that takes the parameters of the pact and figures out which provider build to trigger, or 2) create a webhook for each provider/consumer combination so that the correct provider build is triggered whenever the consumer changes a pact
matt.fellows
2022-02-09 11:21
2 is probably simpler, because you don?t need an intermediate process to take the webhook and then work out what to do with it
matt.fellows
2022-02-09 11:22
In a sufficiently standardised pipeline setup, 1 might be preferable though?
christoph.oswald
2022-02-09 11:43
At what step of the pipeline would you create those webhooks? as part of the consumer pipeline?
matt.fellows
2022-02-09 11:43
I would say that the *provider* owns the webhook. They can choose to create a webhook for _all_ consumers, or just specific ones
matt.fellows
2022-02-09 11:44
Some teams create them manually / separately to pipelines (using the CLI, terraform or UI), and some teams inline them into the pipeline (there is a `create-or-update` webhook command, so that might be appropriate
christoph.oswald
2022-02-09 11:46
Do you know for the teams that inline them in the pipeline, how they figure out which consumers there are for the provider? via a call to the pact-broker?
matt.fellows
2022-02-09 11:48
I suspect that those that want to do it by consumer do it manually, I tend to have provider webhooks pickup any consumer to avoid that problem
christoph.oswald
2022-02-09 11:52
Ok, so as part of the provider pipeline you configure for all consumers (how do you determine these?) a webhook that triggers the provider build?
matt.fellows
2022-02-09 11:56
if you don?t populate the consumer name in the webhook for a provider, it will automatically fire for any existing or new consumer that publishes contracts for that provider
edouard.lopez
2022-02-09 13:38
Is there an endpoint to check the version of pack-broker deployed ? E.g. `https://foo.bar/version` ?
greg.tyler
2022-02-09 13:55
This might not help, but Pact Broker responses should include the header `x-pact-broker-version` which gives the full version
dean.miley1
2022-02-09 14:17
Hi Team, we have created a PR to fix some issues identified in pact-broker that were identified by our vulnerability scanner (Black Duck). How do we go about having these changes merged into master and a new version released? The PR in question is: https://github.com/pact-foundation/pact_broker/pull/542
bethskurrie
2022-02-13 21:28
Hi this is an announcement that we will be dropping support for Docker 19.03 for the Pact Broker image. This is because we need to move to a newer alpine base image to fix the many vulnerabilities that are present in alpine3.13. Docker 19.03 is official EOL now. Please update your systems if you are using Docker 19.03. https://github.com/pact-foundation/pact-broker-docker/issues/76
ajay.kawde
2022-02-14 07:46
Hi Guys , if i have RequestResponseObject can i create a pact contract json file from it in java
ajay.kawde
2022-02-14 08:06
we used @pact annotation on a method which creates a RequestResponsepact object
ajay.kawde
2022-02-14 08:13
we want to convert it into a pact json file and then publish to pact broker
me1295
2022-02-14 12:30
Hi folks, I've got an OSS Pact Broker image deployed on AWS ECS with an NGINX reverse-proxy sitting in front of the app. Due to pre-existing conventions, the app must reside under a sub-path versus root context (e.g. /pactbroker). I have set the sub path as part of the broker base url and everything works fine except for hyperlinks on the matrix page which don't appear to respect the sub-path. I get 404s for any links on the matrix page - but if I re-add the sub-path manually in the browser the links resolve. Has anyone else experienced this before? Any information would be greatly appreciated. Thank you kindly.
greg.tyler
2022-02-14 12:45
I believe you?ll want to set the `PACT_BROKER_BASE_URL` environment variable: https://github.com/pact-foundation/pact_broker/blob/d3ebc7c4369b8ed25d125f562bbe596e5b1d41f4/docs/CONFIGURATION.md#base_url
me1295
2022-02-14 12:47
Thanks, Greg. I have already did that. The environment variable is set to my org?s domain and the subpath and works for everything except the links on the matrix page.
aparnachaudhari
2022-02-14 18:13
Thank you for the heads up, qq - will this have any impact on pactflow customers too? cc @matt.fellows
matt.fellows
2022-02-14 21:28
Yes, the next on-premises version of Pactflow will also drop support for the EOL docker. Do you know if this will be an issue?
rarora
2022-02-15 08:13
Hi team,
I need help understanding VersionSelector annotation. I specified my branch name in tag and still it verifies against all previous versions of that branch?
annotation:
```@Provider("booking-server")
@PactBroker(
url = "https://pact-broker.rcue102.viatorsystems.com",
consumerVersionSelectors = @VersionSelector(consumer = "orion", tag = "feature_COPS-8656-orion-create-v2-pact-consumer-SNAPSHOT", fallbackTag = "develop")
)
@Tag("Contract")```
ProviderTestRun:
dchen
2022-02-15 08:19
my latest pact consumer only has two pacts, I deleted them in broker and republish, looks like it keeps check all historical pacts (5 in total)
rarora
2022-02-15 08:23
we published initial versions through consumer and it had some errors. Deleted integration/ deleted pacts. still when we run provider test, it tests against all versions(i think) as only final version is verified as success
matt.fellows
2022-02-15 08:28
The versions based on the hash looks the same. Also, you had a fallback tag of develop. Is it possible it's fetching that too?
matt.fellows
2022-02-15 08:35
> my latest pact consumer only has two pacts, I deleted them in broker and republish, looks like it keeps check all historical pacts (5 in total)
>
Do you you mean 2 interactions. A pact is a contract between two applications. So you can only have one pact between a consumer and provider
matt.fellows
2022-02-15 08:54
Check the logs, it'll tell you which pact it's verifying and you can then look at each pact to see what's in it
dchen
2022-02-15 09:06
is there a way to debug into the kotlin code and see how it reads those interactions ?
matt.fellows
2022-02-15 09:27
I'm not sure sorry, but I don't think it's anything different to whatever normal log level looks like in Java
antonio.gamiz
2022-02-15 11:20
Hi, I?m getting this error: `This version of the Pact Broker requires that both consumer and provider are specified for a webhook.` running this example: https://github.com/pactflow/example-consumer/blob/master/Makefile#L114
antonio.gamiz
2022-02-15 12:05
```After running PACT_BROKER_BASE_URL=https://badger.pactflow.io/ PACT_BROKER_TOKEN=48XwmdOofoH_cxzqBawHnQ docker run --rm -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN pactfoundation/pact-cli version```
matt.fellows
2022-02-15 12:09
Can you please share the error? That doesn?t seem right to me, but would need to double check
matt.fellows
2022-02-15 12:14
that?s the only message? With exactly the command in the Makefile? :thinking_face:
antonio.gamiz
2022-02-15 12:14
This version of the Pact Broker requires that both consumer and provider are specified for a webhook. Please upgrade your broker to >= 2.22.0 to create a webhook with optional consumer and provider.
make: *** [create_or_update_github_commit_status_webhook] Error 1
antonio.gamiz
2022-02-15 12:14
```
# This webhook will update the Github commit status for this commit
# so that any PRs will get a status that shows what the status of
# the pact is.
create_or_update_github_commit_status_webhook:
@"${PACT_CLI}" \
broker create-or-update-webhook \
'https://api.github.com/repos/BadgerMaps/badger-docrouter/statuses/$${pactbroker.consumerVersionNumber}' \
--header 'Content-Type: application/json' 'Accept: application/vnd.github.v3+json' 'Authorization: token $${user.githubCommitStatusToken}' \
--request POST \
--data @${PWD}/tests/contract/pact/github-commit-status-webhook.json \
--uuid ${GITHUB_WEBHOOK_UUID} \
--consumer ${PACTICIPANT} \
--provider ${PROVIDER} \
--contract-published \
--provider-verification-published \
--description "Github commit status webhook for ${PACTICIPANT}"```
matt.fellows
2022-02-15 12:15
Interesting. I wonder if the CLI is looking at an old HAL relation or something.
Pactflow always runs the latest (currently `-pact-broker-version: 2.93.3` if you introspect the headers)
simon.nizov
2022-02-15 17:18
Hi!
Some of my pacts are presented with the following message:
> _Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead._
However, the pact specification version registered at the bottom of the pact JSON is 2.0.0 (See screenshot).
The pacts are generated by `pact-python` version 0.21 and I'm using OSS broker version 2.89.
Any idea why this is happening?
matt.fellows
2022-02-15 21:41
It might be the rest of it is malformed. Anything obvious standing out between the working ones and failing ones?
simon.nizov
2022-02-16 08:23
@matt.fellows Maybe regex matchers? :thinking_face:
Where can I see how they should look like in v2?
matt.fellows
2022-02-16 10:20
If you had a sample contract that is working and one that isn?t, we could take a look and see if anything stands out
darwin.cahyadi
2022-02-20 20:53
Hi everyone would like to ask! if a `Consumer A` branch `feat/changeField` publishes a new pact (tagged as `feat/changeField` ) that changes the body attribute `id` to `uuid` , how does the Provider can merge the changes when publised pact from `Consumer A` branch `master` still use `id` ? (it will make the step provider verification in build pipeline always failed)
Current config is consumerVersionSelectors: [{ tag: 'master', latest: true }, { deployed: true } ]
bethskurrie
2022-02-20 21:38
@darwin.cahyadi the provider needs to supply both fields in the api until all the consumers in prod have switched over
bethskurrie
2022-02-20 21:42
It's saying that because it can't find the relation that allows it to create the "new" style webhook with optional consumer/provider. Why it can't find it, I'm not sure.
bethskurrie
2022-02-20 21:43
It may be that your user doesn't have the webhook manage permissions @antonio.gamiz
bethskurrie
2022-02-20 22:00
@greg.tyler it's a bug, please raise an issue in the pact_broker github repo
bethskurrie
2022-02-21 01:12
Ok, it's giving you a 405 when you try to create the webhook, according to this code https://github.com/pact-foundation/pact_broker-client/blob/master/lib/pact_broker/client/webhooks/create.rb#L56
gyuvaraj10
2022-02-21 08:05
I want to create Webhooks with Personal access token of Azure DevOps since the user credentials usage is disabled. I couldn't find any documentation that can help me on this in the pact docs. Please someone suggest
akke.luukkonen
2022-02-21 12:46
I've been using AzDo REST API through the basic HTTP auth with a blank username but the API key as the password in the past. Can't remember was it documented somewhere in AzDo, but it has been working for me.
Example from one project:
```const config = {
auth: {
username: '', // Has to exist, but not used with an API key
password: process.env.AZURE_API_KEY,
},
};
...
await http://axios.post(url, azure.payload, config)```
akke.luukkonen
2022-02-21 12:47
I have a small intermediate Function App service standing between Pactflow webhooks & Azure pipelines that relays the requests and does some additional magic where this same method is being used.
antonio.gamiz
2022-02-23 07:12
Hi! Sorry for the late response, I finally did it using it by hand (thanks @matt.fellows.
antonio.gamiz
2022-02-23 07:13
@bethskurrie which user should have the webhook management permissions? The owner of the github token?
antonio.gamiz
2022-02-23 07:14
Also, do you know if there?s any docs for the --uuid ${GITHUB_WEBHOOK_UUID} option? I have been able to create the webhooks manually from the pactflow ui but I have not used that one so I?m curious
matt.fellows
2022-02-23 10:28
```pact-broker help create-or-update-webhook
Usage:
pact-broker create-or-update-webhook URL --uuid=UUID -X, --request=METHOD -b, --broker-base-url=BROKER_BASE_URL
Options:
-X, --request=METHOD # Webhook HTTP method
-H, [--header=one two three] # Webhook Header
-d, [--data=DATA] # Webhook payload (file or string)
-u, [--user=USER] # Webhook basic auth username and password eg. username:password
[--consumer=CONSUMER] # Consumer name
[--consumer-label=CONSUMER_LABEL] # Consumer label, mutually exclusive with consumer name
[--provider=PROVIDER] # Provider name
[--provider-label=PROVIDER_LABEL] # Provider label, mutually exclusive with provider name
[--description=DESCRIPTION] # Webhook description
[--contract-content-changed], [--no-contract-content-changed] # Trigger this webhook when the pact content changes
[--contract-published], [--no-contract-published] # Trigger this webhook when a pact is published
[--provider-verification-published], [--no-provider-verification-published] # Trigger this webhook when a provider verification result is published
[--provider-verification-failed], [--no-provider-verification-failed] # Trigger this webhook when a failed provider verification result is published
[--provider-verification-succeeded], [--no-provider-verification-succeeded] # Trigger this webhook when a successful provider verification result is published
[--contract-requiring-verification-published], [--no-contract-requiring-verification-published] # Trigger this webhook when a contract is published that requires verification
[--team-uuid=UUID] # UUID of the Pactflow team to which the webhook should be assigned (Pactflow only)
-b, --broker-base-url=BROKER_BASE_URL # The base URL of the Pact Broker
-u, [--broker-username=BROKER_USERNAME] # Pact Broker basic auth username
-p, [--broker-password=BROKER_PASSWORD] # Pact Broker basic auth password
-k, [--broker-token=BROKER_TOKEN] # Pact Broker bearer token
-v, [--verbose], [--no-verbose] # Verbose output. Default: false
--uuid=UUID # Specify the uuid for the webhook
Description:
Create a curl command that executes the request that you want your webhook to execute, then replace "curl" with "pact-broker create-or-update-webhook" and add the consumer, provider, event types and broker details. Note that the URL must be the first parameter when executing create-or-update-webhook and a uuid
must also be provided. You can generate a valid UUID by using the `generate-uuid` command.
Note that the -u option from the curl command clashes with the -u option from the pact-broker CLI. When used in this command, the -u will be used as a curl option. Please use the --broker-username or environment variable for the Pact Broker username.```
pact544
2022-02-25 14:53
Looking for some advice on the broker - we currently store all of our webooks in a git repo so that we can GitOps them (i.e. they're the source of truth). However, way back when I originally made this the only way to make this work was by writing a script that first deleted every single webhook and then recreated them all. The webhooks get non-determinstic random IDs, so there's no way to check if a hook already exists.
It works really nicely though, because if you create a new API then you just add an entry into the hooks repo and the CI creates all the hooks for it automatically. The only bit that's not nice is it takes a while to run because there's so many API calls deleting and recreating hooks, and once you delete a hook you lose all the history for it.
Does anyone know of a better way to manage webhooks?
pact544
2022-02-25 14:56
The meat of the script is this - one function to delete all the existing webooks and one to auto-generate all the hooks, but like I say it's slow and wasteful to delete and then recreate them all, if anyone knows a better way:
```function delete_existing_hooks() {
echo "Deleting all existing webhooks"
curl --silent "$pact_broker_base_url/webhooks" | jq -c -r '._links."pb:webhooks"[].href' | while read url; do
url=$(trim_control_chars "$url")
echo -n -e " Deleting webhook ${cyan}${url}${reset}... "
curl --silent -f -X DELETE "$url" \
&& echo -e "${green}Success${reset}" \
|| echo -e "${red}Failed${reset}"
done
}
function create_new_hooks() {
pushd webhooks/ > /dev/null
for webhook_file in $(ls *.json); do
echo -e "Processing webhook ${cyan}${webhook_file}${reset}"
provider="$(jq -r .provider.name $webhook_file)"
escaped_provider=$(escape "$provider")
consumers_url="$pact_broker_base_url/pacts/provider/$escaped_provider/latest"
curl --silent "$consumers_url" | jq -c -r '._links."pb:pacts"[].name' | while read consumer; do
consumer=$(trim_control_chars "$consumer")
echo -n -e " Creating hook for provider ${cyan}${provider}${reset} from consumer ${cyan}${consumer}${reset}... "
hook_body=$(jq --arg name "$consumer" '{consumer:{name:$name}} + .' "$webhook_file")
curl -f --silent -X POST -H "Content-Type: application/json" -d "$hook_body" -o /dev/null "$pact_broker_base_url/webhooks" \
&& echo -e "${green}Success${reset}" \
|| echo -e "${red}Failed${reset}"
done
done
}```
matt.fellows
2022-02-26 21:41
There is a create-or-update-webook command on the pact-broker CLI which supports a user defined uuid as the id. That's probably what you want so you don't lose the history
matt.fellows
2022-02-26 21:42
That being said, I would tend to have the webhook live with the code that needed it. I.e. the provider (in most cases) and not centrally
pact544
2022-02-26 21:43
Ah a create or update endpoint? I hadn't found that on the HAL browser, so I'll check that out. Perhaps it didn't exist when I did this ages ago
pact544
2022-02-26 21:46
Yeah if you can specify an ID of your own that'd be good :+1: I'd just hash the consumer and provider name or something
bethskurrie
2022-02-27 21:25
@pact544 the create or update where you supply your own ID was written specifically for this usecase.
bethskurrie
2022-02-27 21:25
Note the --uuid webhook in the CLI here https://docs.pact.io/pact_broker/client_cli/readme#create-or-update-webhook
pact544
2022-02-28 13:42
Many thanks for this by the way. I've just rewritten our hook installation script and it's now much better! We have stable IDs (using a v5 uuid with sha1 hashing) and we don't have to delete all hooks when installing either.
Whilst I was there I noticed the new feature where the consumer name is optional, so I've also changed it to just create provider-level hooks, which massively reduces the need to run the webhooks setup script anyway given it's now only needed when there's a new provider
pact544
2022-02-28 21:29
Yeah, embarrassingly we were on a broker version that didn't support either of those options until about 3 weeks ago :joy: We were waaaaay behind, and I'd not rechecked my bash since then
bethskurrie
2022-02-28 21:29
lolz. that's been a while. I reckon I may have added the new endpoint before I had my 6 year old kids :laughing:
rafael.anachoreta
2022-03-03 17:28
For teams using a) feature branches where published pacts are tagged and have `branch` set, b) the new `contract_requiring_verification_published` webhook event to trigger new verification and c) the `deployedOrRelease` selector pointing to the main branch, is there any benefit to having WIP and Pending pacts enabled?
From reading the docs, they seem to me more like a safeguard for teams that haven?t figured out their workflow, but maybe I?m missing something.
bethskurrie
2022-03-04 02:08
the workflow is the same for tags/branches+environments, even if the Pact Broker features used a different.
bethskurrie
2022-03-04 02:09
You'll still want to ensure that a consumer can't break the provider's build by putting a breaking change onto their main branch (which is what pending pacts does) and you'll still want the pacts from the outstanding feature branches to be verified when you run the provider build (which is what WIP pacts does).
dchen
2022-03-04 02:42
I use 'Delete Pacts' from the broker and expecting it will delete all historical interactions. however, when I run the provider test, it still picks up a very old pact test from broker. Why is that? is there a way we can find all the pact uploaded by consumers and delete them?
bethskurrie
2022-03-04 02:43
"delete pacts" still keeps the pact versions and verifications. if you want to start from scratch, delete the integration.
dchen
2022-03-04 02:51
```13:50:04 [ERROR] pactVerificationTestTemplate{PactVerificationContext}[5] Time elapsed: 0.254 s <<< FAILURE!
13:50:04 java.lang.AssertionError: Provider state change callback failed
13:50:04 Caused by: au.com.dius.pact.provider.junitsupport.MissingStateChangeMethod:
13:50:04 Did not find a test class method annotated with @State("UpdateItinerarySimple")
13:50:04 for Interaction "Post itinerary update request"```
dchen
2022-03-04 02:53
`UpdateItinerarySimple` has been deleted from consumer side three weeks ago in a feature branch, and never been merged to develop. it's been picked up again by the provider test, even after I deleted the pact integrations
matt.fellows
2022-03-04 02:54
how are you deleting the integration? (just want to check we?re talking about the same thing)
dchen
2022-03-04 02:57
I deleted the integration from the broker UI, then from consumer end, I use a gradle task to republish the pact to the broker
dchen
2022-03-04 02:59
then I ran the provider test, it picked up a VERY old pact from the consumer pact. we suppose to start from scratch, why that VERY old one exist in the borker?
dchen
2022-03-04 03:00
not I expect as well, that's why I am asking if there is a way to check the pact uploaded by consumer
bethskurrie
2022-03-04 03:00
unless you can give me an export of your database, I'm not sure what I can do unfortunately.
matt.fellows
2022-03-04 03:01
in the verification step, if you enable debug logging (in fact, even at info level) you should be able to see which pacts are being verified. You can then go and look at those pacts in the UI to see if they were recently published or not and other info
dchen
2022-03-04 03:06
yep
```Requests from orion to booking-server
Post itinerary item update request
Post itinerary item update request given updateItineraryItem
Post itinerary update request given bookingBOBackend
Post itinerary update request given updateItinerary
Post itinerary update request given updateItinerarySimple```
the old ones appear there
dchen
2022-03-04 03:09
only this two pact define in the current develop branch
``` @Test
@PactTestFor(pactMethod = "testPostUpdateItinerary", providerName = "booking-server")```
and
``` @Test
@PactTestFor(pactMethod = "testPostUpdateItineraryItem", providerName = "booking-server")```
dchen
2022-03-04 03:11
I only got it running from my local branch, it's been disabled from the other branches
bethskurrie
2022-03-04 03:14
I know with some pact clients, each interaction gets merged into an existing pact file, rather than being wiped at the start of the run.
bethskurrie
2022-03-04 03:14
is it possible there was an old pact file on the machine that published the pact?
dchen
2022-03-04 08:38
we use token to access the webhook from broker, I discovered that the previous config got the token wrong in the broker. Is there a way to correct the token setting in the broker?
rafael.anachoreta
2022-03-04 10:00
That?s true, but if all consumers are running can-i-deploy and if my provider targets my main branch only, then I can?t think of a scenario where incompatible consumer changes would be merged. :thinking_face: Though they definitely don?t hurt either
I suppose one scenario could be a consumer for some reason skipping can-i-deploy.
matt.fellows
2022-03-04 10:09
how did you create the webhook in the first place? Via the API, HAL browser or CLI?
matt.fellows
2022-03-04 10:10
API for creating webhooks: https://docs.pact.io/pact_broker/api/webhooks
matt.fellows
2022-03-04 10:46
I?d use the HAL browser to find your existing webhook, and then update that using the HAL browser, CLI or APIs above
dchen
2022-03-04 10:55
I am reading this doc: https://docs.pact.io/pact_broker/api/webhooks, so if I only need to update the token, should I just specify the updated token to "request" -> "url" ?
dchen
2022-03-04 11:00
```HTTP/1.1 POST https://avrdevjenkins00n.ndmad2.tripadvisor.com/generic-webhook-trigger/invoke?token=aaaaaa&BRANCH=develop&PACT_CONSUMER_TAG=bugfix```
that's from the hal browser, the aaaaaa is wrong I will need to update it to bbbbbb
matt.fellows
2022-03-04 11:05
see this thread for a recent example: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1645800790506359
dchen
2022-03-04 11:19
any detail example on the pact-cli? I guess I need something like
```Usage: "broker create-or-update-webhook URL --uuid=UUID -X, --request=METHOD -b, --broker-base-url=BROKER_BASE_URL"```
matt.fellows
2022-03-04 21:35
I believe there is, but you shouldn?t do that - if you have SSL somebody presumably cares about it. See the standard Open SSL env flags here: https://github.com/pact-foundation/pact-ruby-standalone/releases
aristides.suarez
2022-03-07 10:06
Hi folks, where can I find information about Pact-broker usage strategies?
Right now we're using a very simple strategy:
- enablePendingPacts in providers
- when a breaking change in pacts is needed, consumers must create a new feature Tag in Pact-broker.
- providers set pact-tests to use the new feature tag.
- after development is complete, pacts are published in the main Tag and providers set pact-tests to use the main tag.
- finally, pacts in the feature Tag are deleted.
(We aren't using either WIP or recording deployments or releases) (We don't use branch because this is not supported in all client libraries)
What do you think about this strategy? Thanks!
paul.simms
2022-03-07 16:55
Hi all,
Got a question regarding workflow.
So we have Consumer A which has PACTs with Provider B at 3 tags (dev, preprod & prod ? we haven?t moved to environments yet). This is working fine.
We introduce Provider C which is a provider to Consumer A. We release Provider C to dev as we have set the `failIfNoPactsFound` for the pact:verify and can-i-deploy.
Consumer A has a new PACT created to Provider C and released to dev. This works OK.
The problem we found is trying to release Provider C to ?preprod? where the can-i-deploy says it cannot as there isn?t Consumer A in preprod (which it is true that there isn?t this integration contract between these pacticipants in preprod).
I think this though should be a valid workflow (it?s as though it found the integration, so expects the PACT to be available at all tags).
We got around it 1st time by deleting the integration, then deploying the provider to all environments before introducing the new Consumer A v Provider C PACT (but think this is a bit of a blunt hammer).
It would be good to understand if we are missing something here, and is it something that may be helped through moving to environments?
Many thanks in advance.
bethskurrie
2022-03-07 22:06
Hi @aristides.suarez, it sounds ok. If you enabled WIP pacts, you wouldn't need to update the provider tag each time, however.
bethskurrie
2022-03-07 22:07
when you say "breaking change" do you really mean "breaking change" or do you just mean "change"?
bethskurrie
2022-03-07 22:07
There is some info on actual breaking changes here https://docs.pact.io/faq#how-can-i-make-a-breaking-change-to-a-provider
bethskurrie
2022-03-07 22:09
I think there may be a bug in can-i-deploy for the scenario of introducing a new provider. I've got a failing test case for it here https://github.com/pact-foundation/pact_broker/commit/5bcf6e66d70a5911333366c494a675469f1d0924
bethskurrie
2022-03-07 22:10
I'm very certain this used to work, so I think it may have been introduced when I made some changes a while ago.
bethskurrie
2022-03-07 22:11
The work around for now is to set the environment variable PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true for the first deployment of the provider.
dchen
2022-03-08 11:29
I am using the docker version cli, this `DISABLE_SSL_VERIFICATION=true` , is that an environment variable?
paul.simms
2022-03-08 13:59
Many thanks for your quick response.
We have added this variable and can-i-deploy now works in our case, but a couple of things as I understand that this will not fail even if can-i-deploy fails.
1. When can it be removed? Does it need at least 1 consumer to be at each tag that is being checked with can-i-deploy (in our case 'dev', 'preprod', 'prod')? And once there is 1 consumer, others can be added an environment at a time without being expected to be on each one?
2. Is there a bug report on this that we can keep an eye out for any fix?
Many thanks
david.vancouvering
2022-03-08 22:42
Hi. I'm seeing this in the pact broker logs:
```[pact-broker-86f7555f4b-xsvp5] 22:31:58 I [security] -- Could not detect any credentials in cookies or headers```
This appears to happen when we submit a pact publish or a can-i-deploy from the Pact Maven plugin.
Is there a way for us to debug whether or not Pact Maven is picking up the token from the environment? We set it in the environment, but perhaps we didn't set it correctly.
What's weird is the pact publish succeeds, but can-i-deploy fails:
```[ERROR] Failed to execute goal au.com.dius.pact.provider:maven:4.2.13:can-i-deploy (default-cli) on project storefrontxs-svc: Can you deploy? Computer says no �\_(?)_/� Request to path '/matrix?q[][pacticipant]=storefrontxs-svc&latestby=cvp&q[][version]=11c8924&latest=true&tag=master&ignore[][pacticipant]=fdbkexp' failed with response 'HTTP/1.1 401 Unauthorized' -> [Help 1]```
When we run can-i-deploy locally it works fine.
When I pass that path into the HAL browser it works fine.
It's just a problem on Jenkins, but we can't figure out what the problem is
david.vancouvering
2022-03-08 22:44
Also, I'm not seeing the `can-i-deploy` command being received in the broker logs - just the pact publish and the pact verification and the webhooks firing
david.vancouvering
2022-03-08 22:48
Not sure if this helps, but I see this in the Jenkins logs:
```22:47:31 WARNING: Invalid cookie header: "set-cookie: rack.session=eyJzZXNzaW9uX2lkIjoiOGY2OTcxMDkxZGFlZjc2ZjIyZWZmNDQ2MzFiMWVhNzAxZTFlNjRjYzZkNDE3ZjU2M2QxYjdiMDYxZDk5YTVmYSIsImNzcmYiOiJXZDdNcGRVVHlFcTQ2UDdNUFhYa2ZyVjMwUDVVL0wxTW9FZGQ5SmsxVW1vPSJ9--6ffdcd699ed83f60a0983d47002d0cc3971b8230; domain=http://pactflow.qa.ebay.com; path=/; expires=Tue, 15 Mar 2022 22:49:00 GMT; HttpOnly". Invalid 'expires' attribute: Tue, 15 Mar 2022 22:49:00 GMT
22:47:31 Mar 08, 2022 10:47:31 PM org.apache.http.client.protocol.ResponseProcessCookies processCookies
22:47:31 WARNING: Invalid cookie header: "set-cookie: rack.session=eyJzZXNzaW9uX2lkIjoiOGY2OTcxMDkxZGFlZjc2ZjIyZWZmNDQ2MzFiMWVhNzAxZTFlNjRjYzZkNDE3ZjU2M2QxYjdiMDYxZDk5YTVmYSIsImNzcmYiOiJXZDdNcGRVVHlFcTQ2UDdNUFhYa2ZyVjMwUDVVL0wxTW9FZGQ5SmsxVW1vPSJ9--6ffdcd699ed83f60a0983d47002d0cc3971b8230; domain=http://pactflow.qa.ebay.com; path=/; expires=Tue, 15 Mar 2022 22:49:00 GMT; HttpOnly". Invalid 'expires' attribute: Tue, 15 Mar 2022 22:49:00 GMT```
uglyog
2022-03-08 22:51
Pact-JVM uses the Apache HTTP client, which first tries an unauthenticated request, and then responds with the authenticated request after getting the challenge response. That may be causing the log entry you are seeing.
david.vancouvering
2022-03-08 22:57
`/opt/maven/maven-3.3.9/bin/mvn -f storefrontxs-svc/pom.xml -Dpactbroker.toTag=master -Dpactbroker.pacticipant=storefrontxs-svc -Dpactbroker.pacticipantVersion=11c8924 -Dpactbroker.url=${pactbroker.url} -Dpact.consumer.tags=mmukhsikaroyan/master/STRFRNT-2443 -Dignore=fdbkexp -U pact:can-i-deploy -B`
But the token is set as an environment variable, so it won't show up in the call to the mo jo
david.vancouvering
2022-03-08 22:59
Well, this is interesting - perhaps the token's not getting set...
```22:55:54 [DEBUG] Configuration: <?xml version="1.0" encoding="UTF-8"?>
22:55:54 <configuration>
22:55:54 <ignore>${ignore}</ignore>
22:55:54 <latest default-value="">${latest}</latest>
22:55:54 <pactBrokerAuthenticationScheme default-value="basic">bearer</pactBrokerAuthenticationScheme>
22:55:54 <pactBrokerInsecureTLS default-value="false">${pactBrokerInsecureTLS}</pactBrokerInsecureTLS>
22:55:54 <pactBrokerPassword>${pact.broker.password}</pactBrokerPassword>
22:55:54 <pactBrokerServerId>${pact.broker.serverId}</pactBrokerServerId>
22:55:54 <pactBrokerToken>${pactbroker.auth.token}</pactBrokerToken>
22:55:54 <pactBrokerUrl>https://pactflow.qa.ebay.com</pactBrokerUrl>
22:55:54 <pactBrokerUsername>${pact.broker.username}</pactBrokerUsername>
22:55:54 <pacticipant>storefrontxs-svc</pacticipant>
22:55:54 <pacticipantVersion>11c8924</pacticipantVersion>
22:55:54 <retriesWhenUnknown default-value="0">15</retriesWhenUnknown>
22:55:54 <retryInterval default-value="10">30</retryInterval>
22:55:54 <settings default-value="${settings}"/>
22:55:54 <to default-value="">master</to>
22:55:54 </configuration>```
uglyog
2022-03-08 23:03
`pactbroker.auth.token` is the JVM system property that needs to be set with the token from the environment
david.vancouvering
2022-03-08 23:04
Understood. But other JVM system properties are getting set as a result of them being set in the environment... I believe. But now I don't know what I believe anymore. I have been successfully gaslighted :slightly_smiling_face:
david.vancouvering
2022-03-08 23:05
Well, I directly added it to the command-line and now it's working.
david.vancouvering
2022-03-08 23:06
Even though other properties are not required that way, such as the toTag and the pacticipantVersion.
Oh, except those are Jenkins parameters versus environment variables. Maybe Jenkins passes the parameters into the Maven build step automatically, but not so for environment variables...
uglyog
2022-03-08 23:25
I need to review all the system properties in Pact-JVM. Some have been added via PRs and they may not work in a consistent manor.
david.vancouvering
2022-03-08 23:40
In their case they set the token property *directly* in their POM and they were get 401 unauthorized.
But when I passed in the token using -Dpactbroker.auth.token=<token> it worked
david.vancouvering
2022-03-08 23:40
It's as if the Maven plugin *only* accepts the Java system property and completely ignores any settings in the pom
david.vancouvering
2022-03-08 23:42
Actually, I would bet good money that's the problem :slightly_smiling_face:
david.vancouvering
2022-03-08 23:43
```<!-- pact broker -->
<pactbroker.url>https://pactflow.qa.ebay.com</pactbroker.url>
<pactbroker.auth.token>BBoKzIDUWtQp4w05DQgkdQ</pactbroker.auth.token>
<pact.git.version>${git.commit.id.abbrev}</pact.git.version>
<pact.tag>${git.branch}</pact.tag>```
david.vancouvering
2022-03-08 23:43
And then
``` <configuration>
<systemPropertyVariables>
<pact.verifier.publishResults>false</pact.verifier.publishResults>
<pactbroker.url>${pactbroker.url}</pactbroker.url>
<pactBrokerAuthenticationScheme>bearer</pactBrokerAuthenticationScheme>
<pactBrokerToken>${pactbroker.auth.token}</pactBrokerToken>```
david.vancouvering
2022-03-08 23:44
Still got a 401. The only solution was `-Dpactbroker.auth.token=<token>` on the command line
david.vancouvering
2022-03-09 00:03
Sure, can you point me to the appropriate repo? There are a number of them, just want to make sure I've got the right one
dchen
2022-03-10 04:54
Hi here, I noticed that when pact broker calls the provider webhook, it passed a couple of `PACT_CONSUMER_TAG` e.g.: `PACT_CONSUMER_TAG="bugfix_COPS-8853-orion-reenable-contract, bugfix_COPS-8853-orion-reenable-contract-SNAPSHOT"` , looks like `@VersionSelector(consumer = "orion", tag = "${pactConsumerTag}")` could not really handle multiple tags in that format, is that expected?
bethskurrie
2022-03-10 04:56
Sorry, I'm not familiar with the JVM options, but ask in the pact-jvm channel.
bethskurrie
2022-03-10 04:57
have a look in the provider section of the http://docs.pact.io page for your language
aristides.suarez
2022-03-10 12:59
Hi, @bethskurrie, thanks for answering.
"Breaking change", I mean, even having enabled pending pacts, after modifying pacts the verification fails.
I'm going to study WIP pacts as an option.
dchen
2022-03-11 13:51
what's the version in the url suppose to be? provider version or consumer version?
```mvn pact:verify -Dpact.filter.consumers='Foo Web Client' -Dpact.filter.pacturl=https://test.pact.dius.com.au/pacts/provider/Activity%20Service/consumer/Foo%20Web%20Client/version/1.0.1```
me1295
2022-03-14 18:41
Was an issue raised for this? I am seeing similar problems when trying to publish from a Gradle project
pavlo.sprogis
2022-03-15 12:19
hi all, I?m using pact broker cli to publish pacts
```./pact/bin/pact-broker version
1.59.0```
command:
```./pact/bin/pact-broker publish ./target/pacts -a <version> -h master -g -b $PACT_BROKER_URL -u $PACT_BROKER_USERNAME -p $PACT_BROKER_PASSWORD```
it works fine on my laptop, but it fails during gitlab build:
```PactBroker::Client::Hal::ErrorResponseReturned - Error making request to <url> status=503
...
<title>ERROR: The requested URL could not be retrieved</title>
...
<p id="sysmsg">The system returned: <i>(110) Connection timed out</i></p>
<p>The remote host or network may be down. Please try the request again.</p>```
also
```mvn pact:publish```
works on gitlub and I can establish connection using telnet from gitlub runner to pact broker
what is the difference between maven plugin and cli client and how to fix cli issue?
bethskurrie
2022-03-15 19:23
I can't help you with the maven publish. You'll need to ask in the pact-jvm channel
bethskurrie
2022-03-15 19:24
The 503 sounds like you might have a proxy issue. Do you have a corporate VPN or proxy?
bethskurrie
2022-03-15 19:29
@dchen the URL that comes from the webhook is actually a permalink to the content of the pact, and doesn't contain the consumer version. It includes the pact version.
bethskurrie
2022-03-15 19:30
I don't know if that's the right option - you'll need to ask in the pact-jvm channel, sorry.
pavlo.sprogis
2022-03-15 20:33
ok, thank you. Actually, maven plugin was working ok, I had 503 error with ruby cli tool, but I have tried different gitlab runner and now it works fine, pact was published
fabio.rodrigues
2022-03-16 11:09
Hello there. Is there any reason why pact-broker environment name can only have numbers and letters. For context our prod/test environments ( we have several of them) have geos and so on, so it's usual to have names like <regions>-<type>-<number>
fabio.rodrigues
2022-03-16 11:59
the funny thing is that broker create-environment allows us to create names with -
fabio.rodrigues
2022-03-16 13:49
is there any cli command to check what is registered as deployed in a environment?
bethskurrie
2022-03-16 21:52
@fabio.rodrigues are you trying to create environments in Pactflow or the OSS Pact Broker?
bethskurrie
2022-03-16 21:54
There's a bug in the UI validation logic then. I'll raise an issue for it. Can you use the API to create them in the meantime?
jgfarias42
2022-03-17 10:03
Hi folks,
I am trying to follow the bi-directional contracts tutorial, but I am having trouble on Step 10.
When I have to comment out the _price_ field, I am getting a 409 - Conflict error at publishing
the new OAS contract.
Basically what I did was to add a # before each _price:_ string + removing the whole entry on components.schemas.Product.properties.
Here is my OAS contract. Am I doing something wrong?
You can find my current contract here: https://thatsabug.pactflow.io/contracts/bi-directional/provider/pactflow-example-provider-dredd/version/8743ed-master%2B8743ed.SNAPSHOT.6c69b0f0743f/consumer/pactflow-example-consumer-mountebank/version/d1db1c-master%2Bd1db1c/provider-contract
```openapi: 3.0.1
info:
title: Product API
description: Pactflow Product API demo
version: 1.0.0
paths:
/products:
post:
summary: Create a product
description: Creates a new product
operationId: createProduct
requestBody:
description: Create a new Product
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/Product'
examples:
application/json:
value:
id: "1234"
type: "food"
# price: 42
responses:
"200":
description: successful operation
content:
"application/json; charset=utf-8":
schema:
oneOf:
- $ref: '#/components/schemas/Product'
examples:
application/json:
value:
id: "1234"
type: "food"
# price: 42
get:
summary: List all products
description: Returns all products
operationId: getAllProducts
responses:
"200":
description: successful operation
content:
"application/json; charset=utf-8":
schema:
type: "array"
items:
$ref: '#/components/schemas/Product'
examples:
application/json:
value:
- id: "1234"
type: "food"
# price: 42
# name: "pizza"
# version: "1.0.0"
# see https://github.com/apiaryio/dredd/issues/1430 for why
"400":
description: Invalid ID supplied
content: {}
/product/{id}:
get:
summary: Find product by ID
description: Returns a single product
operationId: getProductByID
parameters:
- name: id
in: path
description: ID of product to get
schema:
type: string
required: true
example: 10
responses:
"200":
description: successful operation
content:
"application/json; charset=utf-8":
schema:
$ref: '#/components/schemas/Product'
examples:
application/json:
value:
id: "1234"
type: "food"
# price: 42
# name: "pizza"
# version: "1.0.0"
# see https://github.com/apiaryio/dredd/issues/1430 for why
"400":
description: Invalid ID supplied
content: {}
"404":
description: Product not found
content: {}
components:
schemas:
Product:
type: object
required:
- id
- name
#- # price
additionalProperties: false # WARNING! without this, a consumer can add stuff that doesn't exist! See also https://bitbucket.org/atlassian/swagger-mock-validator/issues/84/test-incorrectly-passes-when-mock-expects
properties:
id:
type: string
type:
type: string
name:
type: string
version:
type: string
# price:
#type: number```
matt.fellows
2022-03-17 10:15
I think you?ll only get a `409` if you try publishing with the exact same version - are you bumping the version?
matt.fellows
2022-03-17 10:16
i.e. Pactflow (by default now) prevents you overriding a version of a contract, because it could invalidate a previously successful can-i-deploy result
jgfarias42
2022-03-17 11:10
Indeed.
I've changed the OAS version and I could upload. Thanks @matt.fellows
Probably it is obvious for people who understand OAS written-by-hand, but for a newbie like me, it wasn't :smile:
fabio.rodrigues
2022-03-17 13:51
that would be a good one, then in pact cli tools we should have a small call for that
paul.simms
2022-03-17 16:39
@bethskurrie Sorry for the tag, but any update in this.
The provider has other consumers, so I am not sure that the dry run is what we want in case there are problems there.
I guess we could use ignore option in can-i-deploy, but that would need a future code change to remove it (and our projects use a common can-i-deploy script that currently have this parameterised).
The other way I can think is to keep to deleting the integration from the broker until that consumer is going to be released across the enviornments.
Any other thoughts? Thanks
rawatankit90
2022-03-20 07:13
@matt.fellows
this is my understanding of bi-directional testing. Is this correct?
1.) Provider side upload the swagger file to pact broker which is called as provider contract. If the swagger file is generated by code, recommend writing test cases but if it is hand written then recommend to do functional testing using rest assured or some other functional testing tool.
2.) Consumer side we still need to publish the contract as in CDC
3.) Can-i-Deploy step then compares the consumer contract against the swagger file(aka producer file)
matt.fellows
2022-03-20 07:51
Yes Pretty close! If the contract is generated by code, from a contract testing standpoint we don't need any other validation. Of course, you should do other types of testing as required (e.g. functional)
matt.fellows
2022-03-20 07:52
If it's written by hand you can still test using the various methodologies mentioned - it only matters that you end up being confident your OAS is accurate/ correct and compatible with your code
bethskurrie
2022-03-21 02:50
@paul.simms I believe I've fixed this bug. Can you update to the latest version (2.95.1) and see if you are getting the expected results?
rawatankit90
2022-03-21 18:34
I was following this conversation, and it was pretty exciting to see how we can use can-i-deploy to manage.
However i do have a question, is there any diagram which can better illustrate the CI/CD Recommended process for Development from Pactflow
@matt.fellows @tjones
dimundo
2022-03-22 15:16
hi!
having this in logs (and some tests started to fail due to timeouts), any ideas ?
```2022-03-22T14:02:01.354538416Z stdout F /pact_broker/vendor/bundle/ruby/2.6.0/gems/sequel-5.49.0/lib/sequel/connection_pool/threaded.rb:264:in `raise_pool_timeout'
2022-03-22T14:02:01.354486796Z stdout F 2022-03-22 14:02:01.351645 E [8:puma server threadpool 005 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference YEkrNbMqTK -- Exception: Sequel::PoolTimeout: timeout: 5.0, elapsed: 5.000220500980504Show context```
rawatankit90
2022-03-22 19:41
also, can you explain how environments work ? or point me to a resource where it is documented @matt.fellows
rawatankit90
2022-03-22 23:26
@bethskurrie Do i need to use pact_cli to tag to Environment or i can use it as part of mvn pact:publish
bethskurrie
2022-03-22 23:35
are you having a lot of concurrent activity? often a mono-repo build will kick off a bunch of activity at once and hammer your database.
bethskurrie
2022-03-22 23:36
you can control the number of connections in the thread pool and the time out in the config settings.
david.vancouvering
2022-03-23 03:18
I wrote something up for eBay teams that helped me understand things better as well as others. I can de-ebayify it and submit a PR. I'll see when I can squeeze that in. I might do a very quick pass and send it out for draft review to see if it's even close to what you might find useful
rawatankit90
2022-03-23 04:58
thanks, i was able to record deployments and environment. How do i trigger provider verification when consumer published a new pact
david.vancouvering
2022-03-23 05:03
Here is the first doc - a conceptual overview. It might be merged in with "terminology" page but I am just getting it out there so you can get a sense of what I was getting at - https://github.com/pact-foundation/docs.pact.io/pull/125
david.vancouvering
2022-03-23 05:36
OK, here's the step-by-step guide to implementing a robust CI/CD pipeline. More work to be done around pending pacts, WIP pacts and feature toggles... Note it doesn't include any examples, as that varies from org to org, but just the general "how to get there" pathway... https://github.com/pact-foundation/docs.pact.io/pull/126/
matt.fellows
2022-03-23 07:02
I?d suggest having a quick search for ?webhooks? on the http://docs.pact.io site
mircea.ungureanu
2022-03-23 10:59
Good morning :wave: I have a working pact between an existing consumer and provider. I?m now trying to introduce a second consumer of the same provider/interaction but just different parts of the data. For some reason the pact doesn?t get recognised on the provider side. Could someone please help with this? All the existing pacts get verified fine and tagged appropriately, just this new one is not.
matt.fellows
2022-03-23 11:09
What does your provider verification setup look like?
Just in case it's not clear, the provider verification will need to run again if a new consumer is introduced (even if it has the same contract)
dimundo
2022-03-23 16:40
> how many connections does your database allow?
default one :slightly_smiling_face:
dimundo
2022-03-23 16:42
````PACT_BROKER_DATABASE_MAX_CONNECTIONS` - optional, defaults to 4. The maximum size of the connection pool.
`PACT_BROKER_DATABASE_POOL_TIMEOUT` - optional, 5 seconds by default. The number of seconds to wait if a connection cannot be acquired before raising an error.```
bethskurrie
2022-03-23 21:17
@mircea.ungureanu what configuration are you using to verify your pacts? Do you have WIP pacts turned on?
matt.fellows
2022-03-23 21:26
@bethskurrie I had a private DM with him last night. Enabling WIP did resolve the issue, but they need to look at the proper configuration goinsg forward (no tags/selectors currently being used)
mircea.ungureanu
2022-03-24 08:05
Sorting out the tags/selector is the next item on the agenda. Thanks for the support :+1:
pavlo.sprogis
2022-03-24 10:20
hi guys, I want to use pact cli docker in gitlub pipeline and I?m a little bit confused that there are 2 publish commands:
```pact broker publish PACT_DIRS_OR_FILES ... -a, --consumer-app-version=CONSUMER_APP_VERSION -b, --broker-base-url=BROKER_BASE_URL```
and
```pact publish PACT_DIRS_OR_FILES ... # Publish pacts to a Pact Broker.```
are there any differences? which one should be used to publish consumer contract to pact broker?
pavlo.sprogis
2022-03-24 10:23
hm, don?t know, maybe? https://hub.docker.com/r/pactfoundation/pact-cli
matt.fellows
2022-03-24 10:59
But I?d just use the as the docs suggest: https://github.com/pact-foundation/pact-ruby-cli#publish-pacts
madhulika.mitra
2022-03-24 16:43
Hi - No matter what I try what I do... on trying to get the pact file via uri or broker - I get starting SSL for http://truelayer.pactflow.io:443...
SSL established
Conn close because of connect error SSL_connect returned=1 errno=0 state=error: certificate verify failed ,
madhulika.mitra
2022-03-24 16:45
I have setup my pact broker using Pactflow trial. I am able to generate the pact from consumer side, but when I try to verify and update results from provider I get SSL error. I have tried to add the certificate to the ssl bundle, given the property but looks like pact is not even checking it
```.SetSslCaFilePath```
bethskurrie
2022-03-24 20:23
I'm not sure why there are two, but they will point to the same underlying code.
yousafn
2022-03-25 00:33
Hey @david.vancouvering, just about to sign off for the evening, but have your docs review / first merge into the path to nirvana - at the top of my list tomorrow!
simon.dicola
2022-03-25 10:27
Hi all, would like to ask if there are guides for best practises about how to clean up stale contracts in the broker.
matt.fellows
2022-03-25 10:28
Have a quick search of http://docs.pact.io. pretty sure there is a doc on running a cleanup job
ashok.pathak
2022-03-25 15:19
Hey, I want to publish provider open API schema. Could you please suggest me correct API for that ?
ashok.pathak
2022-03-25 15:22
I was trying to use endpoint from here, but it doesn't work as expected. When I publish contract for second pacticipant(provider) then it overrides the pact of the first pacticipant(provider) as well
yousafn
2022-03-25 15:36
Hi @ashok.pathak that is the correct script as per our docs, but used from our example repo. We aim to have these in the CLI soon
https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#publishing-the-provider-contract--results-to-pactflow
There is a https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#request-details which describes the payload
I assume your providers have distinct names?
jeffrey2011998
2022-03-25 16:15
Hi, I'm trying to configure a webhook in pactflow and have a question. In the Body of a POST message I would like to include some pact variables. I want to know what variables are available and found this documentation: https://pactflow.io/blog/webhooks/#:~:text=a%20number%20of-,variables,-%2C%20which%20are%20useful. The link to variables returns a 404? Anyone any idea where I can find the available variables for a web hook?
pavlo.sprogis
2022-03-25 18:05
speaking about webhooks, could somebody please share an example of whitelist to fix this error in the webhook logs:
```For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property.```
I have tried
```PACT_BROKER_WEBHOOK_HOST_WHITELIST="gitlab.<companyname>.com <companyname>.http://slack.com"```
yousafn
2022-03-25 20:29
And in each case, in your POST request, in the URL, are you providing a different name for the provider, shown as `${PACTICIPANT}` in the above snippet?
yousafn
2022-03-25 20:31
> When I publish contract for second pacticipant(provider) then it overrides the pact of the first pacticipant(provider) as well
I am actually not quite sure what you mean. could you list the explicit steps. it sounds like you are
1. Uploading an oas spec for provider 1
2. Uploading an oas spec for provider 2.
yousafn
2022-03-25 20:33
and you are seeing the Pact of the first provider being over-ridden? This is what I am not quite sure about
Do you mean the oas spec of provider 1 is being overwritten?
Pact files would be created on the consumer side, the provider would either read these pacts for verification in CDCT or the provider would upload an OAS spec and evidence (as a provider contract) for BDCT.
matt.fellows
2022-03-26 08:39
What are the examples of webhooks you have configured? If you look at your debug logs on the server you should be able to see more detail
bethskurrie
2022-03-28 02:39
@pavlo.sprogis have you seen these docs? https://docs.pact.io/pact_broker/configuration/settings#webhook_host_whitelist
bethskurrie
2022-03-28 02:40
when the app starts up, what is the configuration printed out for that setting?
matt.fellows
2022-03-28 03:31
One thing that was ambiguous to me looking at the doc Beth, was if the list of items should be comma delimited?
matt.fellows
2022-03-28 03:33
> A list of hosts, network ranges,?
should be
> A space delimited list of hosts, ?
abhi.nandan964
2022-03-28 05:06
posting a reference to the question here, as it is also related to pact-broker - https://pact-foundation.slack.com/archives/C9VECUP6E/p1648445167229899
pavlo.sprogis
2022-03-28 07:34
hi guys, thank you, space delimited whitelist works, I was thinking that if I update `PACT_BROKER_WEBHOOK_HOST_WHITELIST` variable inside pact-broker docker container (on the fly) it will re-read this setting. But looks like this configuration variable is read only during the start, so I restarted pact-broker and now I can see full logs with webhook fail reason in pact-broker UI
ashok.pathak
2022-03-28 12:25
And in each case, in your POST request, in the URL, are you providing a different name for the provider, shown as `${PACTICIPANT}` in the above snippet? (edited)
Yes, different provider and I am using PUT method
ashok.pathak
2022-03-28 12:27
Do you mean the oas spec of provider 1 is being overwritten?
Yes, OAS of spec1 is getting overwritten
ashok.pathak
2022-03-28 12:30
I am explaining the steps below:
1, Uploading OASSpec1 for provier 1
2, Uploading OASSpec1(With little in change in schema) for provier 2
3, OASSpec1 of provider2 overrides the OASSpec1 of provider1
yousafn
2022-03-28 12:44
So I have tested this out on my PF broker.
Here we have provider foo2 (version foo2) and provider foo3 (version foo3)
The swaggers are different in that fact, one have the name product2 and product3 respectively.
When viewed via the sidebar, the right hand pane isn't showing the correct content, here when selecting foo2, is displays foo3.
clicking on view contract in both cases displays the foo3 provider contract.
Note the foo2 provider contract does exist and hasn't been overwritten, I was able to navigate to it via the URL path https://you54f.pactflow.io/contracts/bi-directional/provider/foo2/version/foo2/provider-contract but the hyperlinking in the UI isn't correct.
Will raise this with the team. I believe you should be able to get your correct contract by using a URL structure similar to above with your 2nd provider name and version
yousafn
2022-03-28 12:45
I also noticed these docs mention a POST request, but it is PUT like you mentioned, so will get that updated
https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas/#request-details
I will get those examples on the public testdemo broker, and get a report raised :thumbsup:
yousafn
2022-03-28 13:45
I captured the issue against this pull request to demonstrate it
https://github.com/pactflow/example-provider-dredd/pull/1
and the contracts are uploaded to the testdemo broker https://testdemo.pactflow.io
I got the same message, when I had a mismatch in provider version in my URL (not going by what was displayed in the UI)
abhi.nandan964
2022-03-29 03:26
Hi, one more issue - we were using the Pact broker docker image version `2.84.0.0` , and we are currently trying to upgrade it to the latest version `2.96.0.0` . I changed the docker-compose file with the version and tried to spin up the pact broker and it throws error as it is unable to connect to the database instance, below is the error -
```pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/anyway_config-2.3.0/lib/anyway/type_casting.rb:111: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/anyway_config-2.3.0/lib/anyway/rbs.rb:40: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
pact-broker_1 | Puma starting in single mode...
pact-broker_1 | * Puma version: 5.6.2 (ruby 2.7.5-p203) ("Birdie's Version")
pact-broker_1 | * Min threads: 0
pact-broker_1 | * Max threads: 5
pact-broker_1 | * Environment: production
pact-broker_1 | * PID: 7
pact-broker_1 | 2022-03-29 03:08:07.303198 I [7:4640] pact-broker -- Connecting to database: -- "{:adapter=>\"postgres\", :user=>\"<username>\", :password=>\"*****\", :host=>\"xxxx.xxxx.xxxx\", :database=>\"pact_broker\", :port=>6432, :encoding=>\"utf8\", :sql_log_level=>:debug, :enable_caller_logging=>false, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>\"-c statement_timeout=15s\"}, :connect_max_retries=>5}"
pact-broker_1 | 2022-03-29 03:08:07.457332 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 5 tries to go.
pact-broker_1 | 2022-03-29 03:08:10.572607 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 4 tries to go.
pact-broker_1 | 2022-03-29 03:08:13.688064 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 3 tries to go.
pact-broker_1 | 2022-03-29 03:08:16.803917 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 2 tries to go.
pact-broker_1 | 2022-03-29 03:08:19.921639 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 1 tries to go.
pact-broker_1 | ! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: FATAL: unsupported startup parameter: options
pact-broker_1 | bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.7.0/bin/puma)
pact-broker_1 | Sequel::DatabaseConnectionError: PG::ConnectionBad: FATAL: unsupported startup parameter: options```
while reverting it to `2.84.0.0` starts the pact broker normally. Is there any known compatibility issues with upgrading?
abhi.nandan964
2022-03-29 03:40
```version: "3"
services:
pact-broker:
image: pactfoundation/pact-broker:2.84.0.0
ports:
- "9292:9292"
environment:
PACT_BROKER_PORT: '9292'
PACT_BROKER_DATABASE_URL: "xxxxxxxx"
PACT_BROKER_LOG_LEVEL: INFO
PACT_BROKER_SQL_LOG_LEVEL: DEBUG
# PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES is only needed for docker-compose
# because the database takes longer to start up than the puma process
# Should not be needed in production.
PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "5"
# The list of allowed base URLs (not setting this makes the app vulnerable to cache poisoning)
# This allows the app to be addressed from the host from within another docker container correctly
PACT_BROKER_BASE_URL: 'xxxxxxxx'
# Nginx is not necessary, but demonstrates how
# one might use a reverse proxy in front of the broker,
# and includes the use of a self-signed TLS certificate
nginx:
image: nginx:alpine
depends_on:
- pact-broker
volumes:
- ./ssl/nginx.conf:/etc/nginx/conf.d/default.conf:ro
- ./ssl:/etc/nginx/ssl
ports:
- "443:443"
- "80:80"
volumes:
postgres-volume:```
this is my `docker-compose.yml` , masked the `PACT_BROKER_DATABASE_URL` and `PACT_BROKER_BASE_URL`
abhi.nandan964
2022-03-29 03:41
yes, we have an external database, and 2.84.0.0 connects to it successfully
bethskurrie
2022-03-29 03:42
`Sequel::DatabaseConnectionError: PG::ConnectionBad: FATAL: unsupported startup parameter: options`
bethskurrie
2022-03-29 03:43
I tried to reproduce the issue locally by not starting up the postgres database, and I got a big long stracktrace.
bethskurrie
2022-03-29 03:44
```pact-broker_1 | ! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: could not translate host name "postgres" to address: Name does not resolve
pact-broker_1 | bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.7.0/bin/puma)
pact-broker_1 | Sequel::DatabaseConnectionError: PG::ConnectionBad: could not translate host name "postgres" to address: Name does not resolve
pact-broker_1 |
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.3.4/lib/pg/connection.rb:702:in `connect_start'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.3.4/lib/pg/connection.rb:702:in `new'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/adapters/postgres.rb:208:in `connect'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/connection_pool.rb:122:in `make_new'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/connection_pool/threaded.rb:209:in `assign_connection'
...```
abhi.nandan964
2022-03-29 03:45
```pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/anyway_config-2.3.0/lib/anyway/type_casting.rb:111: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/anyway_config-2.3.0/lib/anyway/rbs.rb:40: warning: Pattern matching is experimental, and the behavior may change in future versions of Ruby!
pact-broker_1 | Puma starting in single mode...
pact-broker_1 | * Puma version: 5.6.2 (ruby 2.7.5-p203) ("Birdie's Version")
pact-broker_1 | * Min threads: 0
pact-broker_1 | * Max threads: 5
pact-broker_1 | * Environment: production
pact-broker_1 | * PID: 7
pact-broker_1 | 2022-03-29 03:08:07.303198 I [7:4640] pact-broker -- Connecting to database: -- "{:adapter=>\"postgres\", :user=>\"<username>\", :password=>\"*****\", :host=>\"xxxx.xxxx.xxxx\", :database=>\"pact_broker\", :port=>6432, :encoding=>\"utf8\", :sql_log_level=>:debug, :enable_caller_logging=>false, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>\"-c statement_timeout=15s\"}, :connect_max_retries=>5}"
pact-broker_1 | 2022-03-29 03:08:07.457332 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 5 tries to go.
pact-broker_1 | 2022-03-29 03:08:10.572607 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 4 tries to go.
pact-broker_1 | 2022-03-29 03:08:13.688064 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 3 tries to go.
pact-broker_1 | 2022-03-29 03:08:16.803917 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 2 tries to go.
pact-broker_1 | 2022-03-29 03:08:19.921639 I [7:4640] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 1 tries to go.
pact-broker_1 | ! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: FATAL: unsupported startup parameter: options
pact-broker_1 | bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.7.0/bin/puma)
pact-broker_1 | Sequel::DatabaseConnectionError: PG::ConnectionBad: FATAL: unsupported startup parameter: options
pact-broker_1 |
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.3.4/lib/pg/connection.rb:637:in `async_connect_or_reset'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.3.4/lib/pg/connection.rb:707:in `new'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/adapters/postgres.rb:208:in `connect'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/connection_pool.rb:122:in `make_new'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/connection_pool/threaded.rb:209:in `assign_connection'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/connection_pool/threaded.rb:139:in `acquire'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/connection_pool/threaded.rb:91:in `hold'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/database/connecting.rb:269:in `synchronize'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/database/connecting.rb:278:in `test_connection'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/database/misc.rb:175:in `initialize'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/database/connecting.rb:57:in `new'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/database/connecting.rb:57:in `connect'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.54.0/lib/sequel/core.rb:124:in `connect'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.96.0/lib/pact_broker/initializers/database_connection.rb:17:in `block in create_database_connection'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.96.0/lib/pact_broker/initializers/database_connection.rb:31:in `with_retries'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.96.0/lib/pact_broker/initializers/database_connection.rb:16:in `create_database_connection'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.96.0/lib/pact_broker/app.rb:135:in `configure_database_connection'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.96.0/lib/pact_broker/app.rb:99:in `post_configure'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.96.0/lib/pact_broker/app.rb:50:in `initialize'
pact-broker_1 | http://config.ru:4:in `new'
pact-broker_1 | http://config.ru:4:in `block in <main>'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:116:in `eval'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:116:in `new_from_string'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:105:in `load_file'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:66:in `parse_file'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/lib/puma/configuration.rb:348:in `load_rackup'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/lib/puma/configuration.rb:270:in `app'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/lib/puma/runner.rb:150:in `load_and_bind'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/lib/puma/single.rb:44:in `run'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/lib/puma/launcher.rb:182:in `run'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/lib/puma/cli.rb:81:in `run'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.2/bin/puma:10:in `<top (required)>'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/bin/puma:23:in `load'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/bin/puma:23:in `<top (required)>'
pact-broker_1 exited with code 1```
bethskurrie
2022-03-29 03:49
can you try running postgres 13.5 in your docker compose and see what happens?
abhi.nandan964
2022-03-29 04:22
running with a fresh instance of postgres 13.5 in `docker-compose` spins up the pact broker successfully -
``` postgres:
image: postgres:13.5-bullseye
healthcheck:
test: psql postgres --command "select 1" -U postgres
volumes:
- postgres-volume:/var/lib/postgresql/data
environment:
POSTGRES_USER: xxxxxxx
POSTGRES_PASSWORD: xxxxxxxx
POSTGRES_DB: postgres```
abhi.nandan964
2022-03-29 05:02
@bethskurrie I have investigated further and seems to be some change in `2.87.1` is causing this issue, I am able to upgrade till `2.87.0`, but when I try with `2.87.1`, it starts throwing this error.
bethskurrie
2022-03-29 05:05
so, it seems like there's something slightly different about connecting to your external instance vs the local postgres instance
abhi.nandan964
2022-03-29 05:05
with `postgres:13.5-bullseye` image, I am able to start even the latest version `2.96.0.0`
bethskurrie
2022-03-29 05:06
So, I'm taking a wild guess at a fix, based on the error `unsupported startup parameter: options`
bethskurrie
2022-03-29 05:06
```"{:adapter=>\"postgres\", :user=>\"<username>\", :password=>\"*****\", :host=>\"xxxx.xxxx.xxxx\", :database=>\"pact_broker\", :port=>6432, :encoding=>\"utf8\", :sql_log_level=>:debug, :enable_caller_logging=>false, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>\"-c statement_timeout=15s\"}, :connect_max_retries=>5}"```
bethskurrie
2022-03-29 05:07
perhaps for some reason, that options statement doesn't work for your external database.
bethskurrie
2022-03-29 05:07
I'm just releasing a new version of the broker that will allow you to set that statement timeout to nil, and when it is nil, it won't set any options.
bethskurrie
2022-03-29 05:09
it's just building now. when it comes out, try setting `PACT_BROKER_DATABASE_STATEMENT_TIMEOUT: "nil"` in your docker compose.
bethskurrie
2022-03-29 05:09
then have a look at the logs and you should see that there is no `{:options=>\"-c statement_timeout=15s\"}` in there.
abhi.nandan964
2022-03-29 05:22
it's fixed, thanks a lot for your support, really appreciate it! :pray:
bethskurrie
2022-03-29 05:23
you're welcome. I don't understand why it didn't work, but good that it's fixed.
bethskurrie
2022-03-29 05:23
So, the risk is, if you get really long SQL queries, your queries won't time out (with the statement timeout set to nil)
abhi.nandan964
2022-03-29 05:24
got it, meanwhile I will also check why the options are not being supported by the DB instance that we are using
simon.dicola
2022-03-29 08:10
Morning all, our pact broker has a self signed certificate. When the consumer tries to publish the contract, the TLS handshake fails. In a maven project, there is it picking up the root certificate details so that it can validate the SSL certificate?
2022-03-29 08:10
Please see these instructions on running and accessing a Pact Broker over TLS https://docs.pact.io/pact_broker/advanced_topics/using-tls/
yousafn
2022-03-29 12:05
I've retested that and it appears to be working fine for me @ashok.pathak, so I have closed the reproduction PR.
Thanks for raising and trying out our new feature!
bethskurrie
2022-03-31 01:14
Environment variables aren't generally an "on the fly" thing. If you change an env var from outside the process, you typically have to restart the process that reads it.
bethskurrie
2022-03-31 01:15
it's only on the fly if you're inside the process - you can change your own env var, but not someone elses.
bethskurrie
2022-03-31 01:16
a "breaking change" in our docs means that you change the API in a way that is not backwards compatible with its consumers. It doesn't mean just that the pact fails.
paul.simms
2022-03-31 08:12
@bethskurrie We have got an upgrade to the latest version on our backlog at the moment. I'll try to push priority of it again, and let you know when available (its another thing on list to make a business case for moving across to pactflow).
bethskurrie
2022-04-03 21:07
@christoph.oswald sorry, I've been not checking slack very much recently, and missed this. Did you get it worked out?
jeroen.vandijk
2022-04-04 13:24
Hi, I'm doing the CI/CD workshop, but am stuck at trying to Configure the Provider Pipeline, https://docs.pactflow.io/docs/workshops/ci-cd/set-up-ci/configure-consumer-and-provider-pipelines get the following error:
jeroen.vandijk
2022-04-04 13:25
``` read 5745 bytes
Conn keep-alive
INFO: Fetching pacts for pactflow-example-provider from https://dojojeroen.pactflow.io with the selection criteria: latest for tag master, currently deployed
opening connection to http://dojojeroen.pactflow.io:443...
opened
starting SSL for http://dojojeroen.pactflow.io:443...
SSL established
<- "POST /pacts/provider/pactflow-example-provider/for-verification HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nAuthorization: [redacted]\r\n"
<- "{\"includePendingStatus\":false,\"consumerVersionSelectors\":[{\"tag\":\"master\",\"latest\":true},{\"deployed\":true}],\"providerVersionTags\":[\"master\"]}"
-> "HTTP/1.1 404 Not Found\r\n"
-> "Date: Mon, 04 Apr 2022 13:10:55 GMT\r\n"
-> "Content-Type: application/hal+json;charset=utf-8\r\n"
-> "Transfer-Encoding: chunked\r\n"
-> "Connection: keep-alive\r\n"
-> "Vary: Accept\r\n"
-> "X-Pact-Broker-Version: 2.96.0\r\n"
-> "X-Pact-Broker-Git-Sha: aecd69c6\r\n"
-> "X-Pactflow-Git-Sha: 07abda37c\r\n"
-> "X-Content-Type-Options: nosniff\r\n"
/home/runner/work/example-provider/example-provider/node_modules/@pact-foundation/pact-node/standalone/linux-x64-1.88.83/pact/lib/vendor/ruby/2.2.0/gems/pact-1.62.0/lib/pact/hal/entity.rb:102:in `assert_success!': Error retrieving https://dojojeroen.pactflow.io/pacts/provider/pactflow-example-provider/for-verification status=404 (Pact::Hal::ErrorResponseReturned)```
pavlo.sprogis
2022-04-04 15:21
also, as far as I remember, in scope of that CI workshop you should have the following fetching options:
```const fetchPactsDynamicallyOpts = {
provider: "pactflow-example-provider",
//consumerVersionTag: ['master', 'prod'], //the old way of specifying which pacts to verify
consumerVersionSelectors: [{ tag: 'master', latest: true }, { deployed: true } ], // the new way of specifying which pacts to verify
pactBrokerUrl: process.env.PACT_BROKER_BASE_URL,
enablePending: true,
includeWipPactsSince: "2020-01-01"
}```
yousafn
2022-04-04 15:27
Is your consumer pipeline running in master, but failing on the can-i-deploy step?
https://docs.pactflow.io/docs/workshops/ci-cd/set-up-ci/configure-consumer-and-provider-pipelines#configure-consumer-pipeline
@pavlo.sprogis is correct that is it looking for consumers marked with master that are deployed
> When the `$PACT_URL` is not set (ie. the build is running because the provider changed), the provider is configured to fetch all the pacts for the 'example-provider' provider which belong to the latest consumer versions tagged with `master` and those currently deployed to an environment. This ensures the provider is compatible with the latest changes that the consumer has made, and is also backwards compatible with the production/test versions of the consumer
> When the `$PACT_URL` is set (ie. the build is running because it was triggered by the 'contract content changed' webhook), we just verify the pact at the `$PACT_URL`
Taken from the provider readme https://github.com/pactflow/example-provider
yousafn
2022-04-04 15:30
I wonder if the provider is search for currently deployed, and the consumer currently isn't, so it's isn't finding a match, and should be verified by the webhook (which comes in the next step)
jeroen.vandijk
2022-04-04 15:39
> Is your consumer pipeline running in master, but failing on the can-i-deploy step?
jeroen.vandijk
2022-04-04 15:41
although when I juts tried it again, I got the following, I did delete all the pacts from Pactflow to see if that would make a difference
yousafn
2022-04-04 15:49
The first image was correct, failing on can-i-deploy. I would ask to see the provider pipeline next. If you can pass me your repo link I can take a look, I am going to test this out myself on a fork
yousafn
2022-04-04 16:25
So this is definitely my fault with the demo updates.
I had updated the GH actions pipeline to run against 2 consumer & 4 providers
https://github.com/YOU54F/example-consumer/blob/master/.github/workflows/build.yml#L19-L30
I had left the `pactflow-example-provider` commented out, so you wouldn't have been creating a contract for that, so there was contract to validate on the `example-provider` repo.
The failures you are seeing in can-i-deploy are correct, as there is no verified contracts between these three providers, note `pactflow-example-consumer`
Just testing now with this commit
https://github.com/YOU54F/example-consumer/commit/6b5b3989ab0973a8c405bd5acd1a25661222e4f4
Will find a way to support our multiple provider examples, in a way that doesn't cause issue for our ci/cd workshop.
Apologies!
mike.key
2022-04-04 16:33
Does the open source pact broker have a means to add secrets for things like a GitHub token to use for webhooks? If so, where am I missing its existence?
yousafn
2022-04-04 16:36
Hey @mike.key
You are able to store them with the creation of your webhook, but they are unencrypted in the pact broker database.
https://docs.pact.io/pact_broker/webhooks/debugging_webhooks#creating-webhooks
This is a feature offered in the Pactflow platform, there is a link in the above docs.
Hope that helps!
yousafn
2022-04-04 16:42
Yes I can confirm that was the issue.
Passing provider build - https://github.com/YOU54F/example-provider/actions/runs/2091210547
Passing consumer build - https://github.com/YOU54F/example-consumer/actions/runs/2091191082
Will get the main repo updated now to avoid confusion :thumbsup:
serghei.pogodin
2022-04-06 15:40
Hi,
I'm using Pactflow for CBT and found that on UI and in jvm plugin for provider consumer contracts' name is wrong.
My scenario is:
? Consumer creates a Pact with interaction name and state name
? Consumer publishes Pact to Pactflow
? In Pactflow, interaction name becomes a mix of interaction name + state name
? Same wrong name comes to provider when he executes contract validation with Maven/Gradle plugin
Is it possible to not add state name to the interaction name as it's consuming users?
serghei.pogodin
2022-04-06 15:43
``` "interactions": [
{
"_id": "0f45b9d0ec7cac44b590f56f5ef831aaa9122dde",
"description": "Get details of termsheet with Rabobank client",
"providerStates": [
{
"name": "Termsheet with Rabobank client exists"
}
],```
serghei.pogodin
2022-04-06 15:44
It results in this name in Pactflow: `Get details of termsheet with Rabobank client given termsheet with Rabobank client exists`
bethskurrie
2022-04-06 21:37
Hi @dalton.pinto I'm sorry, I was on holiday when you posted this, and I've only just seen it because I was scrolling down the Threads section in slack.
matt.fellows
2022-04-06 23:14
You might like to also watch the video here: https://docs.pact.io/consumer
matt.fellows
2022-04-06 23:15
The broker is designed to help you understand the scenarios you are testing, and frames it in a BDD style
serghei.pogodin
2022-04-07 07:07
Thanks guys for explanation! Will check what you advice in the video.
edouard.lopez
2022-04-07 12:54
Hello, after doing an upgrade of the broker, on the pacticipant page we got a `details` tab. But I would like to know how to populate the fields?
? `Main branch`
? `Repository URL`
matt.fellows
2022-04-07 12:59
They are properties on the `pacticipant` resource. I think you can `PUT` to `/pacticipants/:pacticipant` with the following:
? `name`
? `repositoryUrl`
? `mainBranch`
bethskurrie
2022-04-07 21:45
@edouard.lopez use the cli https://docs.pact.io/pact_broker/client_cli/readme#create-or-update-pacticipant
pavlo.sprogis
2022-04-08 13:29
hi guys, when I publish consumer tests results I use `--build-url $CI_JOB_URL` with the url to Gitlab build. If I understand correctly when I open some pact or the matrix it should display also this build_url, so you can go to CI results from Pact broker. But I cannot find the build_url in Pact broker UI. Could somebody please provide more info about `build-url`?
fabio.rodrigues
2022-04-08 16:45
Hey there, i'm using the pact cli tools docker image, and i'm getting the following error:
```bundler: failed to load command: /pact/bin/pact (/pact/bin/pact)
/usr/lib/ruby/2.7.0/net/http.rb:960:in `initialize': execution expired (Net::OpenTimeout)
from /usr/lib/ruby/2.7.0/net/http.rb:960:in `open'
from /usr/lib/ruby/2.7.0/net/http.rb:960:in `block in connect'
from /usr/lib/ruby/2.7.0/timeout.rb:105:in `timeout'
from /usr/lib/ruby/2.7.0/net/http.rb:958:in `connect'
from /usr/lib/ruby/2.7.0/net/http.rb:943:in `do_start'
from /usr/lib/ruby/2.7.0/net/http.rb:932:in `start'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal/http_client.rb:93:in `until_truthy_or_max_times'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal/http_client.rb:64:in `perform_request'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal/http_client.rb:25:in `get'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal/link.rb:41:in `get'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal/link.rb:45:in `get!'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/hal_client_methods.rb:20:in `index_resource'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/publish_pacts.rb:31:in `call'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/publish_pacts.rb:14:in `call'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/cli/broker.rb:157:in `publish_pacts'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/cli/broker.rb:42:in `publish'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
from /usr/lib/ruby/gems/2.7.0/gems/pact_broker-client-1.59.0/lib/pact_broker/client/cli/custom_thor.rb:15:in `start'
from /pact/lib/pact/cli.rb:40:in `broker'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
from /usr/lib/ruby/gems/2.7.0/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
from /pact/bin/pact:15:in `<top (required)>'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/cli/exec.rb:63:in `load'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/cli/exec.rb:63:in `kernel_load'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/cli/exec.rb:28:in `run'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/cli.rb:474:in `exec'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/vendor/thor/lib/thor/command.rb:27:in `run'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/vendor/thor/lib/thor/invocation.rb:127:in `invoke_command'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/vendor/thor/lib/thor.rb:392:in `dispatch'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/cli.rb:30:in `dispatch'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/vendor/thor/lib/thor/base.rb:485:in `start'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/cli.rb:24:in `start'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/exe/bundle:49:in `block in <top (required)>'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/lib/bundler/friendly_errors.rb:128:in `with_friendly_errors'
from /usr/lib/ruby/gems/2.7.0/gems/bundler-2.2.20/exe/bundle:37:in `<top (required)>'
from /usr/bin/bundle:25:in `load'
from /usr/bin/bundle:25:in `<main>'```
using the following command on linux:
```docker run --rm -w ${PWD} -v ${PWD}:${PWD} -e PACT_BROKER_BASE_URL -e PACT_BROKER_TOKEN pactfoundation/pact-cli:latest broker publish ${PWD} --consumer-app-version "POC1" c:\pacts\*.json --broker-base-url PACT_BROKER_BASE_URL --broker-token PACT_BROKER_TOKEN```
For context, this is a poc for other team that is trying to do the initial consumer tests.
fabio.rodrigues
2022-04-08 16:46
the c:\ is because altough the docker is running on linux under wsl called in windows
fabio.rodrigues
2022-04-08 16:46
it's the same behaviour when calling directly on linux with \mnt\c\pacts
fabio.rodrigues
2022-04-11 11:22
problem solved. it was just a problem between windows and wsl communication. we were using docker inside wsl
robert.strehli
2022-04-11 14:29
Hey, I have a question for publishing pacts to the pact broker (with JVM). There is one point in the documentation which puzzles me `All of the Pact client libraries should have an API to allow you to publish pacts directly through that API. If your implementation is missing this feature, please raise an issue.` Is there somewhere an example for that?
I only know the methods with using the `CLI Tool` , `maven plugin` or `gradle plugin`.
justin
2022-04-11 15:29
You may want to check the channel for the language you're using. But I think they're moving away from using the embedded upload approach since it's hard to add new features to libraries for every language vs just updating the CLI
jeroen.vandijk
2022-04-11 19:14
hello :slightly_smiling_face: Question, should the Provider publish the results of a verification to the Broker, where there will be a Pact verification for each individual commit as part of a PR? Tagging if with the name of the PR? I think yes?
bethskurrie
2022-04-12 03:03
@robert.strehli we've changed our policy on that. We now recommend everyone publishes with the Pact CLI.
jeroen.vandijk
2022-04-12 07:23
My initial thoughts were you should only verify the new Provider code against a Pact once the code was ready to be merged. But it may also be useful for others to see (via the Broker) how a potential new version of the Provider is behaving against a Pact?
brendan.j.donegan
2022-04-12 19:24
Hey, looks like this link is broken? https://docs.pactflow.io/docs/bi-directional-contract-testing/provider/contracts/pact/#publishing-the-provider-contract--results-to-pactflow
yousafn
2022-04-12 23:32
Hey, this is the correct link https://docs.pactflow.io/docs/bi-directional-contract-testing/provider/#step-4-publish-your-provider-contract-and-verification-results
will check now
yousafn
2022-04-12 23:33
ah that anchor has the broken link which I think should be pointing to https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#publishing-the-provider-contract--results-to-pactflow
yousafn
2022-04-12 23:37
Updated link should be live in the next 10 minutes, whenever the build is finished!
r.muthukumar136
2022-04-19 17:06
Hi, how to modify the request endpoint in the provider side? I?m using the junit5spring ?
r.muthukumar136
2022-04-19 19:08
Hi @yousafn@yousafn@yousafn@Yousaf Nabi (http://pactflow.io)@Yousaf Nabi (http://pactflow.io) this document is for adding/modifying the headers only..for me i want to modify the request endpoint url?
r.muthukumar136
2022-04-19 19:09
problem: my consumer test using api gateway url for their contract test. But my provider using the internal url for their contract test.
Example: consumer using /user/v2 and api gateway redirect this url to /customer/v1/details ..but request body and headers are same.
My question: how can i modify the request endpoint url in the provider side before executing pact test in the provider side?
yousafn
2022-04-19 21:45
Can you not set the request path, to your new path in that method? the example just shows a header, but the table below shows you the objects that you have available to you in the test template.
yousafn
2022-04-19 21:48
Here was some guidance we mentioned on testing pass throughs, with non http pacts
https://docs.pact.io/getting_started/what_is_pact_good_for#why-pact-may-not-be-the-best-tool-for-testing-pass-through-apis-like-bffs
If I wanted a quick method and it wasn't available to me via the Pact library (Pact-Js was always my go to), I would just modify the paths in the pact file, before providing the file to my verifier.
do you have a contract between the api gateway and your provider? if your provider changes the internal URL, how is the api gateway kept in sync? is that tied to the providers deployment infra?
rafael.espillaque
2022-04-22 14:35
hi, has anyone else seen this when triggering pactflow webhooks?
```Pact successfully republished for asd version 0.2.44-SNAPSHOT-8b5c0274 and provider qwe with no content changes.
View the published pact at https://...
Events detected: contract_published, contract_requiring_verification_published
Webhook "git-pact-webhook-qwe" triggered for event contract_requiring_verification_published.
View logs at https://...
Webhook "git-pact-webhook-qwe" triggered for event contract_requiring_verification_published.
View logs at https://...```
the event `contract_requiring_verification_published` triggered 2 runs!
thanks
paul.simms
2022-04-22 15:50
@bethskurrie Sorry for the delay in this, but we have just upgraded the PACT broker to 2.98.0 and re-tested this scenario (adding a new PACT integration to already deployed services) and I can confirm that it is working. Many thanks again.
akke.luukkonen
2022-04-25 05:24
Probably for 2 different contracts? It fires for each contract requiring verifiction, per the name.
For me it triggers twice because it tests the latest in my `prod` and `dev` environments that I have setup
akke.luukkonen
2022-04-25 05:26
I have it setup so that in the body I pass the URL of the specific contract it wants to test as well as the Git hash. In my case this data travels through an Azure Function (serverless app), which then starts the correct pipeline in Azure DevOps.
bethskurrie
2022-04-26 01:14
It will trigger a webhook for the main branch and all the deployed versions.
edouard.lopez
2022-04-26 13:24
Hello, is it possible to use the Pact broker to serve stub similar like the https://github.com/pact-foundation/pact-stub-server or do we need a dedicated server?
yousafn
2022-04-26 13:29
it doesn?t support it OOB, you would need to use another like you?ve shown.
There are a couple of flavours, I believe that is the preferred. note it may be v3 only atm looking at the docs.
There is a ruby flavour aswell as part of the standalone
yousafn
2022-04-26 13:30
https://github.com/pact-foundation/pact-ruby-standalone
or as a cli which is basically the above but in docker
https://github.com/pact-foundation/pact-ruby-cli
matt.fellows
2022-04-26 14:10
The last two are the same thing just different distributions. The one you linked is a better one to use as it supports newer pact formats
yousafn
2022-04-26 14:23
As said in my original message, the cli is the same as the above link but wrapped in docker, so there are two.
The older ruby version, which we are moving away from towards a rust shared core, and thus a rust based stub server was produced :thumbsup:
yousafn
2022-04-26 14:46
check out the Docker instructions for the pact-stub-server, you could easily run it in ECS in AWS :slightly_smiling_face: https://github.com/pact-foundation/pact-stub-server#running-with-docker
edouard.lopez
2022-04-27 08:35
Yep, we started to look at it, but as we already have a Broker deployed I was wondering if we could avoid deploying another one
edouard.lopez
2022-04-27 10:50
I'm having the following issue:
``` make publish-contract
docker run \
--rm \
--workdir=${PWD} \
--volume=${PWD}:${PWD} \
--env=PACT_BROKER_BASE_URL \
pactfoundation/pact-cli:latest \
publish \
${PWD}/contracts \
--consumer-app-version da970bb \
--tag-with-git-branch \
--repository-url="https://git.foo.tech/qraft/contract-testing/pact-consumer-example-for-go" \
--main-branch=main
ERROR: pact-broker publish was called with invalid arguments ["--repository-url"]
make: *** [Makefile:133: publish-contract] Error 1```
edouard.lopez
2022-04-27 10:58
Having some trouble pusing the `--repository-url` with the CLI https://github.com/pact-foundation/pact_broker-client/issues/106
matt.fellows
2022-04-27 11:01
you?re calling the `publish` command, I think you meant to use `create-or-update-pacticipant`
edouard.lopez
2022-04-27 11:39
Manage to make it work with the docker image, but not `curl` despite a `200`
```curl \
--verbose \
--location \
--request PUT \
--header "Content-Type:application/json" \
--data '{"name": "ms.pact-consumer-example-for-go.b2b", "repositoryUrl": "https://git.manomano.tech/qraft/contract-testing/pact-consumer-example-for-gofoo", "mainBranch": "main"}' \
${PACT_BROKER_BASE_URL}/pacticipants/ms.pact-consumer-example-for-go.b2b
* Trying 10.192.103.176:80...
* TCP_NODELAY set
* Connected to http://infra-pact-broker-web.support.manomano.com (10.192.103.176) port 80 (#0)
> PUT /pacticipants/ms.pact-consumer-example-for-go.b2b HTTP/1.1
> Host: http://infra-pact-broker-web.support.manomano.com
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Type:application/json
> Content-Length: 170
>
* upload completely sent off: 170 out of 170 bytes
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Wed, 27 Apr 2022 11:32:35 GMT
< Content-Type: application/hal+json;charset=utf-8
< Content-Length: 1588
< Connection: keep-alive
< Vary: Accept
< X-Pact-Broker-Version: 2.93.2
< X-Content-Type-Options: nosniff
< ```
Response:
```{
"repositoryUrl": "https://git.manomano.tech/qraft/contract-testing/pact-consumer-example-for-gofoo",
"mainBranch": "main",
"createdAt": "2022-04-27T11:32:35+00:00",
"_embedded": { "labels": [] },
"_links": {
"self": {
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants/"
},
"pb:versions": {
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants//versions"
},
"pb:version": {
"title": "Get, create or delete a pacticipant version",
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants//versions/{version}",
"templated": true
},
"pb:version-tag": {
"title": "Get, create or delete a tag for a version of ",
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants//versions/{version}/tags/{tag}",
"templated": true
},
"pb:branch-version": {
"title": "Get or add/create a version for a branch of ",
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants//branches/{branch}/versions/{version}",
"templated": true
},
"pb:label": {
"title": "Get, create or delete a label for ",
"href": "http:/* Connection #0 to host http://infra-pact-broker-web.support.manomano.com left intact /infra-pact-broker-web.support.manomano.com/pacticipants//labels/{label}",
"templated": true
},
"versions": {
"title": "Deprecated - use pb:versions",
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants//versions"
},
"pb:can-i-deploy-badge": {
"title": "Can I Deploy badge",
"href": "http://infra-pact-broker-web.support.manomano.com/pacticipants//latest-version/{tag}/can-i-deploy/to/{environmentTag}/badge",
"templated": true
},
"curies": [
{
"name": "pb",
"href": "http://infra-pact-broker-web.support.manomano.com/doc/{rel}?context=pacticipant",
"templated": true
}
]
}
}```
matt.fellows
2022-04-27 11:42
if you add `--verbose` to the CLI, you can see what it actually sent over the wire to compare
matt.fellows
2022-04-27 11:49
looking at the code, it might also support a `POST` and will do the smarts to update if it exists
yousafn
2022-04-27 13:10
No problem my friend. You certainly could avoid having to deploy anything, hehe, by using Pactflow's broker, however for the open source community we provide plentiful options and the end user is welcome to utilise them in whichever environment suits.
Best of luck with the journey to Pact Nirvana
matt.fellows
2022-04-27 23:23
But I think `PATCH` worked for him, because the pacticipant was created and then he needed to update it
matt.fellows
2022-04-27 23:24
It also looks like `PATCH` would ultimately create the pacticipant anyway from my memory of looking at the code last night. There was a comment there to the effect of ?this was a bad idea / I wish I hadn?t supported this? :laughing:
bethskurrie
2022-04-27 23:25
I initially supported POST for create and PATCH for create/update, and that's what the CLI has to use because I never make a breaking change to the CLI.
bethskurrie
2022-04-27 23:27
If there is a pacticipant with an empty name, there's definitely a bug in one of them, but the CLI works fine as far as I can tell.
yeseniavega411
2022-05-02 18:49
Hello. I am on the quest to find the ideal contract test, and I have a question about the collaboration in the pact broker. I took the following notes word for word(mostly) from https://www.youtube.com/watch?v=IetyhDr48RI&t=356s
_Step one, test the consumer by having it talk to a mock of the provider. We send a http request, we get an http response_
_Pack mock checks:_
1. _Consumer makes the correct call to API_
2. _Consumer code can handle the response_
_Step two, at the end of the test session, all the the request are going to go into the pact broker (like pact flow) and that?s we?re we are going to share the version and collaborate in the contract_
What did he mean by ?collaborate on the contract??
matt.fellows
2022-05-02 22:13
I meant that it?s where the contract is stored and managed. Think of it a bit like Git and Github.
You use Git locally (Pact) and you push your code to Github (Pactflow), where it is versioned, managed etc.
matt.fellows
2022-05-02 22:13
It?s the point of collaboration, because the provider side will use Pactflow to pull down the contracts to verify, and publish the results of the verification to
jbecker
2022-05-06 21:11
Hey! I have a docker container than I'm using as a jenkins agent which I'd like to run the pact cli in order to tag pacts in our pact broker. When I tried installing the pact-cli ruby standalone to the docker container, I see that `pact-publish --help` returns:
```ERROR: The `pact-publish` command has been moved to `pact-broker publish`. We apologise for any inconvenience caused.```
but `pact-broker publish --help` now returns:
```/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.61.0/lib/pact_broker/client/cli/broker.rb:8:in `require': /pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.61.0/lib/pact_broker/client/cli/version_commands.rb:51: syntax error, unexpected '.' (SyntaxError)
branch_name: options.branch&.strip,
^
/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.61.0/lib/pact_broker/client/cli/version_commands.rb:52: syntax error, unexpected '.'
tags: options.tag&.collect(&:strip)
^
/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.61.0/lib/pact_broker/client/cli/version_commands.rb:53: syntax error, unexpected '}', expecting keyword_end
from /pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.61.0/lib/pact_broker/client/cli/broker.rb:8:in `<top (required)>'
from /pact/lib/app/pact-broker.rb:1:in `require'
from /pact/lib/app/pact-broker.rb:1:in `<main>'```
So it seems to me like maybe this standalone cli is not maintained or something? Can anyone suggest an alternative?
jbecker
2022-05-06 21:14
I see that there is a pact-cli docker image as well, but I'm not sure exactly how to incorporate that into my own dockerfile. My instinct is to do a multi-stage dockerfile, where I pull the pact-cli image just to copy the pact-cli script, but when I try and run `docker run -it --entrypoint bash pactfoundation/pact-cli` to browse around inside the docker container and locate the script, I get an error that says it does not have bash installed, :man-shrugging:
yousafn
2022-05-06 22:01
Hey @jbecker
This was reported earlier today,
https://github.com/pact-foundation/pact-ruby-standalone/issues/72
you could downgrade to https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.83 and you should get sorted, and we will address this address you raised asap.
matt.fellows
2022-05-06 22:01
> I get an error that says it does not have bash installed, :man-shrugging:
>
That's because bash isn't installed. Just use `sh`
yousafn
2022-05-06 22:02
> I see that there is a pact-cli docker image as well, but I'm not sure exactly how to incorporate that into my own dockerfile.
ideally you would just use it as is, as a CLI tool, rather than incorporating into your Dockerfile, but as said you can use Dockerfiles extend syntax to build from an existing image.
yousafn
2022-05-06 22:42
Here is an example I did a while back, based on `debian:stretch` https://github.com/YOU54F/pact-standalone-docker-slim/blob/master/debian_base/Dockerfile where I load the ruby cli into an image, might be useful.
Let us know how you get on buddy
yousafn
2022-05-09 13:05
jbecker
2022-05-09 14:09
Another question though: how would I go about adding a new tag to an existing contract in the pact broker? The `pact-broker publish` command doesn't look right because it seems to expect you to upload a new contract when you call it.
jbecker
2022-05-09 14:22
Maybe I want to use "https://github.com/pact-foundation/pact_broker-client/blob/master/README.md#environments"? Can anyone link me to more information about how these are meant to be used? I don't recall reading anything about "environments" when I was learning pact, so it seems like maybe it's a pact-broker feature?
yousafn
2022-05-09 15:03
Try reading https://docs.pact.io/pact_broker/recording_deployments_and_releases#environments :thumbsup: may help
thomas.cederholm
2022-05-09 15:12
I think there is an issue with this: https://docs.pact.io/pact_broker/client_cli/readme#create-or-update-version ?
It is in the docs, but not in the cli.
yousafn
2022-05-09 15:17
```? docker pull pactfoundation/pact-cli
? docker run --rm pactfoundation/pact-cli:latest broker create-or-update-version
No value provided for required options '--pacticipant', '--version', '--broker-base-url'```
yousafn
2022-05-09 15:18
```? curl -LO https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v1.88.85/pact-1.88.85-osx.tar.gz
tar xzf pact-1.88.85-osx.tar.gz
cd pact/bin
./pact-broker create-or-update-version
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 7517k 100 7517k 0 0 2771k 0 0:00:02 0:00:02 --:--:-- 3710k
No value provided for required options '--pacticipant', '--version', '--broker-base-url'```
jbecker
2022-05-09 15:22
omg, I swear that wasn't there a minute ago, haha. I even did a ctrl+f on that help for the word "tag" and somehow skipped over that one. Thank you!
yousafn
2022-05-09 16:02
no problem my friend, I would like to be able to add to the docs, at which version a command came in from, to help users understand if they need to upgrade or not to get the latest feature (obviously we should all ideally upgrade, but I know realistically it doesn't always happen)
thomas.cederholm
2022-05-10 05:35
@bethskurrie Yeah, I figured it was new. This was the reason for my question :slightly_smiling_face:
rakesh.arrepu
2022-05-10 09:23
Hey All,
I am looking into the official documentation of *pactbroker* setup as in below.
https://docs.pact.io/pact_broker/docker_images/pactfoundation
But I could not find proper steps to setup the PactBroker.
PS: I don't want to setup *pactflow* as I have done setting it up. I need to know the setup/installation of PactBroker for a new account so that I can configure the same in my project.
yousafn
2022-05-10 09:41
The detail is on the page you are viewing
https://docs.pact.io/pact_broker/docker_images/pactfoundation#getting-started
matt.fellows
2022-05-10 09:58
Hi Rakesh I'm confused by your question. Pactflow is a hosted version of the pact broker. That is you would only use Pactflow OR your own hosted pact broker but not both.
What is it that you are wanting to configure?
rakesh.arrepu
2022-05-10 10:08
I am looking to host Own Pact broker but not pactflow.
I am missing some details in setting up the own pact broker from the doc. I am looking for any other source or video tutorials to setup the Pact Broker(own)
matt.fellows
2022-05-10 10:14
The link Yousaf provided is the right one. We recommend running our docker version so then it can be deployed like any other docker container
rakesh.arrepu
2022-05-10 10:23
Thanks Matt. I will go through them once and will come up if any queries.
thomas.cederholm
2022-05-10 14:48
The Pact broker matrix view, the `Pact verified` column -- what does it actually show?
yousafn
2022-05-10 14:58
yes, well you asked what does it show.
? A link to the verification results (failures would be shown here, in your case, it's not too exciting) but you can see the full payload
? colour of the Pact verified column based on the success flag
I'm not sure what else you are looking for?
yousafn
2022-05-10 14:59
There must be pictures of the original pact broker UI with some explanations, I'll see if I can find some and get that into the doc rework
yousafn
2022-05-10 15:00
I'm also not sure of the value of the pactflow link, going to the homepage, rather than going to the relevant UI section for the hosted Pactflow broker. Save someone another several hops
thomas.cederholm
2022-05-10 21:31
Thanks! I didn't really know if I could trust the green color of the matrix, ~since all mine turn out green~.. but pipeline seems to be behaving correctly.
yousafn
2022-05-11 00:19
Try introducing a breaking change, via a pull request and then you will see the magic of Pact and can-i-deploy
yousafn
2022-05-11 00:23
I'd love to understand the rational / psychology behind that, do we not trust a colour without seeing detail, or does it come from the pain of the integration testing hell we are seeking to free people from. I'll add it to the many things to ponder :slightly_smiling_face:
abubics
2022-05-11 01:19
forgot to red-green-refactor? Or Pact is obviating that workflow? :see_no_evil:
thomas.cederholm
2022-05-11 06:01
Haha, it has only to do with my lack of understanding yet. I think there is perfect sense in this. I am pioneering this at my company and have made it this far. Not without grief. But I think I might have just reached the goal now.
josh.kilazoglou
2022-05-12 05:07
Hi, I'm trying to view a v3 spec message pact in pact-broker (2.98.0.0), the pact is correctly viewable when uploaded to pactflow, however in pactbroker I see the message _`Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.`_ and see the raw json for the pact rather than the nicely rendered version. Is it the case that v3 pacts cannot be rendered in pact-broker?
josh.kilazoglou
2022-05-12 05:19
thanks, but otherwise the actual verification of v3 pacts will work as expected?
matt.fellows
2022-05-12 05:20
We added the view to Pactflow but just haven't made it a top priority for the OSS version. Most people use the automation features of OSS and so hasn't been a big issue
marcello.rigan335
2022-05-12 12:13
Hey, are there fallbacks in case the pactbroker connection can't be established for whatever reasons.
marcello.rigan335
2022-05-12 13:05
I don't know exactly. I am currently in a situation where our pactbroker isnt reliable right now because of maintenance. Builds are breaking because the tests are failing. I have disabled them now so the build doesn't break. Its unlucky timing right now.
marcello.rigan335
2022-05-12 13:06
I wanted to know if there are any solutions besides not maintaining the machine during critical times.
harwin1494
2022-05-12 14:56
Hi, I am getting this error while setting up the PACT broker, please assist.
``` Error: Database is uninitialized and superuser password is not specified.
You must specify POSTGRES_PASSWORD to a non-empty value for the
superuser. For example, "-e POSTGRES_PASSWORD=password" on "docker run".
You may also use "POSTGRES_HOST_AUTH_METHOD=trust" to allow all
connections without a password. This is *not* recommended.
See PostgreSQL documentation about "trust":
https://www.postgresql.org/docs/current/auth-trust.html```
matt.fellows
2022-05-12 21:07
perhaps you can describe a bit more about what you?re done so far, and what you have tried to fix it, and when that error has occurred?
harwin1494
2022-05-13 06:28
Hi Matt, we ran this command `docker logs <container id> --details.`
on the following container to see what error has it logged !
```d88204f1f9d8 postgres "docker-entrypoint.s?" 21 seconds ago Exited (1) 20 seconds ago peaceful_mendel```
harwin1494
2022-05-13 06:45
Any help on this would be great, since we are unable to access the hosted pact-broker.
matt.fellows
2022-05-13 06:46
OK thanks.
This is not a Pact question though, this is a question about how to run Postgres on Docker. Best to consult the postgres and/or docker logs.
matt.fellows
2022-05-13 06:46
the error above is pretty clear - my guess is you haven?t set the environment variable
aliboztemir
2022-05-13 07:55
Hello everyone, I have a question about document management with pact-brocker. In traditional schema driven testing, we first create the swagger api document and then write tests according to the schema. I couldn?t quite understand at what stage the document should be in pact flow. Is it possible for me to create a swagger document and perform cdc(consumer driven contract testing) first?
yousafn
2022-05-13 09:17
@harwin1494 with the greatest respect, this is not a very good bug report.
The error is quite verbose, and is clearly giving you a pointer
Have you set a password and what instructions/steps have you followed.
harwin1494
2022-05-13 14:45
Just an update , we are trying to run the following command :- `sudo docker run -d pactfoundation/pact-broker` with the latest pact-broker version `2.98.0`
and now encountering this issue
`2022-05-13 14:35:52.560039 I [9:4600] pact-broker -- Connecting to database: -- "{:adapter=>\"postgres\", :encoding=>\"utf8\", :sql_log_level=>:debug, :enable_caller_logging=>false, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>\"-c statement_timeout=15s\"}, :connect_max_retries=>0, :password=>\"*****\"}"`
`! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: could not connect to server: No such file or directory`
`Is the server running locally and accepting`
`connections on Unix domain socket "/tmp/.s.PGSQL.5432"?`
yousafn
2022-05-13 14:58
This is all in the docs btw https://github.com/pact-foundation/pact-broker-docker#configure-the-connection-details
```docker run --rm \
-e PACT_BROKER_DATABASE_URL=<url> \
pactfoundation/pact-broker```
harwin1494
2022-05-13 15:02
looks like we previously were using Pact broker version 2.78.0 and it had default credentials
yousafn
2022-05-13 15:33
fyi the exposed port is `9292`
```docker run --rm \ ??
-e PACT_BROKER_DATABASE_URL=$PACT_BROKER_DATABASE_URL \
-p 9292:9292 \
pactfoundation/pact-broker```
shiva.idc
2022-05-17 10:03
Hi, I've deployment the pact-broker images to AKS, it seems to erroring out with the message "Password Authentication failed for user account ruby", I'm using the pact-foundation docker image.
matt.fellows
2022-05-17 10:19
Hi PrasDev, unfortunately this isn?t a very helpful bug report. Could you please provide a bit more information. See howtoask
2022-05-17 10:19
Please see this page for some tips on how to ask for help to get the best response from the community https://docs.pact.io/help/how_to_ask_for_help
matt.fellows
2022-05-17 10:19
To my knowledge, we don?t have a user ?ruby? in our image, nor do we do any password based authentication
ben.pilgrim
2022-05-17 12:27
Hey, I don?t understand why this pact is still in a pending state when it has been verified for the `refs/heads/feature/testing` branch. Any help would be greatly appreciated.
matt.fellows
2022-05-17 12:40
Actually, can you please share the notices in that response? They should explain why the pact is pending
paul.simms
2022-05-17 12:56
Hi,
We are trying to integrate different workflows into the OSS pact broker.
One of these is to create a pipeline that has a can-i-deploy check for the provider. Now no consumers have used PACT before on any of its interfaces. Thus the provider isn't available as a pacticipant in the broker.
We are looking at adding in the provider tests, doing a can-i-deploy and then deploy. At a later date the consumers will then generate their PACTs as they implement PACT - start publishing, and then checking that they can deploy, having provider verify etc.
However the initial call to can-i-deploy fails as the pacticipant isn't known in the broker
""error": "No provider with name 'example-provider' found"".
Is this an invalid workflow in PACT? Do we need to / can we, just create the pacticipant (even without integrations) if it doesn't exists? so other stages will work.
I realise it is consumer driven - so is it actually valid to have a provider without consumer interactions?
It would be nice to fully complete the provider's pipeline as their 'test' is quite generic, so it would just work until and when consumers start using it (or implementing their tests), without then returning to update the provider unless any initial state is required.
Thanks
matt.fellows
2022-05-17 12:58
a dummy consumer contract might be the way to go, to get the systems up and going. When you get a ?real? consumer, you can kill off the dummy app
matt.fellows
2022-05-17 12:59
If you are generally provider driven as a group, and use OAS as a specification, you may also like to look at Pactflow?s bi-directional contract testing https://pactflow.io/bi-directional-contract-testing/.
ben.pilgrim
2022-05-17 13:06
The provider branches and tags are the same value, but I had to use providerVersionTags as the JVM libraries don?t support providerVersionBranches as far as I can see
ben.pilgrim
2022-05-17 13:10
Oops, mixed up consumer and provider when I masked out the sensitive info:
```"notices": [
{
"when": "before_verification",
"text": "The pact at https://pact-broker/pacts/provider/PROVIDER-SERVICE/consumer/CONSUMER-SERVICE/pact-version/784335ccca070ed0a4fec7cd3667e24ac57b4c06/metadata/d2lwPXRydWU is being verified because it is a 'work in progress' pact (ie. it is the pact for the latest version of CONSUMER-SERVICE from branch 'refs/pull/122141/merge' and is still in pending state). Read more at https://docs.pact.io/go/wip"
},
{
"when": "before_verification",
"text": "This pact is in pending state for this version of PROVIDER-SERVICE because a successful verification result for a version of PROVIDER-SERVICE with tag 'refs/heads/feature/testing' has not yet been published. If this verification fails, it will not cause the overall build to fail. Read more at https://docs.pact.io/go/pending"
},
{
"when": "after_verification:success_true_published_false",
"text": "This pact is still in pending state for any version of PROVIDER-SERVICE with tag 'refs/heads/feature/testing' as the successful verification results with this tag have not yet been published."
},
{
"when": "after_verification:success_false_published_false",
"text": "This pact is still in pending state for any version of PROVIDER-SERVICE with tag 'refs/heads/feature/testing' as a successful verification result with this tag has not yet been published"
},
{
"when": "after_verification:success_true_published_true",
"text": "This pact is no longer in pending state for any version of PROVIDER-SERVICE with tag 'refs/heads/feature/testing', as a successful verification result with this tag has been published. If a verification for a version of PROVIDER-SERVICE with this tag fails in the future, it will fail the build. Read more at https://docs.pact.io/go/pending"
},
{
"when": "after_verification:success_false_published_true",
"text": "This pact is still in pending state for any version of PROVIDER-SERVICE with tag 'refs/heads/feature/testing' as a successful verification result with this tag has not yet been published"
}
]```
paul.simms
2022-05-17 13:13
Thanks @matt.fellows we are certainly considering switching to PACTFlow, partly for the SaaS as we have found upgrading our hosted OSS time consuming, partly for user access, and also the option of bi-directional.
I did see a table in your documentation that compared bi-directional against pure PACT, and you gain some things for ease of use, but lose some level of confidence if process isn't fully followed (like keeping OAS updated).
We are re-platforming our solution soon - so need more information from our API team to decide on there working processes.
Dummy example would be a potential solution (that we had tried - but can cause problems).
Another we are considering is using a check if the pacticipant exists in broker before trying a verify or can-i-deploy (and not running these if it doesn't).
ben.pilgrim
2022-05-17 13:33
Changing the query to providerVersionBranches instead of providerVersionTags with the same value returns the same result.
ben.pilgrim
2022-05-17 13:40
The `This pact is still in pending state for any version of PROVIDER-SERVICE with tag 'refs/heads/feature/testing' as a successful verification result with this tag has not yet been published` claim seems to be false based on what I?m seeing in the UI. Not sure if I?m missing something though.
r.muthukumar136
2022-05-17 17:05
Issue: In the provider end, pact tests is failing with below error:-
Request to provider failed with an exception: ?/? is not allowed in an identifier in path expression ?$.data[0].relationships.user/shippingAddress.data.id? at index 28 (http://au.com.dius.pact.core.model.InvalidPathExpression)
My Request (POST):
?relationships?: {
?user/shippingAddress?: {
?data?: {
?id?: ?12345?,
?type?: ?user/shipping-address?
}
}
We are using junit5spring version 4.3.7. Is this a known issue in the pact ? Is there any way to fix this issue? Thanks.
bethskurrie
2022-05-18 00:56
@ben.pilgrim that doesn't seem right to me either. I would need to be able to debug your data locally to work out exactly why it's going wrong however.
bethskurrie
2022-05-18 00:57
You can try and reproduce the issue using this https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
bethskurrie
2022-05-18 00:58
Or you can give me a redacted dump of your database using this script https://github.com/pact-foundation/pact_broker/blob/master/script/prod/redact-data.sql (you'll need to leave enough data unredacted to still perform the correct query or work out how to recreate the issue with the redacted data)
bethskurrie
2022-05-18 01:00
@paul.simms you can register an empty pacticipant version in the pact broker so that you can call can i deploy on it and it won't error
matt.fellows
2022-05-18 01:02
ah awesome, I remember that was updated but hadn?t seen that section yet :white_check_mark:
bethskurrie
2022-05-18 01:06
Hi @aliboztemir. You can publish the OAS to Pactflow (not the OSS Pact Broker - this is a Pactflow only feature) at any time, as soon as you have it. This will allow the consumer to start writing their Pact tests and getting feedback on whether their calls match the expected OAS. What you can't do until you have implemented the provider is publish the provider self verification results. Only once there is a successful self verification from the provider will can-i-deploy return a successful result for either consumer/provider.
ben.pilgrim
2022-05-18 09:13
``` td.delete_pacticipant("foo-consumer-1")
.delete_pacticipant("bar-provider-1")
.publish_pact(consumer: "foo-consumer-1", consumer_version: "1", provider: "bar-provider-1", content_id: "111", branch: "feat/x")
.get_pacts_for_verification(
enable_pending: true,
provider_version_tag: "feat/y",
include_wip_pacts_since: "2020-01-01",
consumer_version_selectors: [{ branch: "main" }]
)
.verify_pact(
index: 0,
provider_version_tag: "feat/y",
provider_version: "1",
success: true
)
.get_pacts_for_verification(
enable_pending: true,
provider_version_tag: "feat/y",
include_wip_pacts_since: "2020-01-01",
consumer_version_selectors: [{ branch: "main" }]
)```
ben.pilgrim
2022-05-18 09:25
Looks like it works as I would expect if the consumer_version_selectors match the consumer branch the pact is published too, but not if they differ
marcello.rigan335
2022-05-18 09:54
Hello, im getting my contract from the pactbroker and it verifies correctly. But on the Pact broker itself, the last verified colum isnt updated. Consumer Version is 7.0 , Provider Version 2.50-SNAPSHOT with tag:test. I tried different consumerVersionSelectors like, tag test, consumer = consumername, and latest etc. The provider verification works so it has to get the right contract right?
```@PactBroker(url = "https://pact-broker-url",
authentication = @PactBrokerAuth(username = "XXXXXXe", password = "XXXXXX"),
consumerVersionSelectors = { @VersionSelector(consumer = "mint") }
)```
marcello.rigan335
2022-05-18 09:56
In the last verfified colum it says "https://pact-broker.dev.whint.at/hal-browser/browser.html#https://pact-broker.dev.whint.at/webhooks/provider/P2PPayment/consumer/mintd 21 days ago
Pact with tag feature/TAAS-branchname has changed since last successful verification by ProviderName(2.50-SNAPSHOT...)"
matt.fellows
2022-05-18 10:04
Also, be sure that you are always updated the version of the provider (the version should change if the code changes)
matt.fellows
2022-05-18 10:05
ben.pilgrim
2022-05-18 10:34
Now that tags are being deprecated, what?s the best way to handle pr merge pipeline can-i-deploy checks? Previously it made sense to can-i-deploy -to=master, but master isn?t an environment? Would adding a can-i-deploy method to pact-broker to deploy to a branch make sense? Should we continue using tags for that use case?
ben.pilgrim
2022-05-18 10:54
So would you recommend creating an environment to represent the main branch?
matt.fellows
2022-05-18 10:57
But there is an option to check if you?re compatible with a branch:
```[--branch=BRANCH] # The branch of the version for which you want to check the verification results```
matt.fellows
2022-05-18 10:57
so that might be useful for merge checks, where the `--to-environment` for deploy checks
ben.pilgrim
2022-05-18 11:45
Looks like that branch parameter specifies the source consumer branch rather than the target consumer/provider branches?
matt.fellows
2022-05-18 12:09
What are you trying to compare it to? I guess what you?re probably looking for is the equivalent of `can-i-merge --branch feat/xyz --with main` of the target _provider_. This does of course assume the providers all use the same branch name.
matt.fellows
2022-05-18 12:10
Usually, it?s the `environment` that matters here. i.e. once something has been merged it would be deployed to e.g. `staging` , so that would be the target
ben.pilgrim
2022-05-18 13:04
Yeah, that?s correct. We don?t have automatic deployment from master branches to our dev environments.
ben.pilgrim
2022-05-18 13:06
I suppose the assumption of all providers using the same branch name could be circumvented by allowing it to check the mainBranch of providers
bethskurrie
2022-05-18 21:49
@ben.pilgrim I know exactly what you are asking for and the underlying code supports it, but it's not currently exposed. It will be straightforward to add.
bethskurrie
2022-05-18 21:50
I'd been considering this yesterday actually because of the work on the new can-I-deploy page we're working on.
bethskurrie
2022-05-19 06:12
See point 5 in this section https://docs.pact.io/pact_broker/advanced_topics/wip_pacts#technical-details
bethskurrie
2022-05-19 06:13
Ideally, the messaging would indicate that it has successfully been verified, but is still WIP because it has not been verified when explicitly selected yet.
bethskurrie
2022-05-19 06:15
We went backwards and forwards about whether it should remain pending after a successful WIP verification, and for reasons I cannot recall off the top of my head right now, it was decided it was best to leave it as pending.
bethskurrie
2022-05-19 06:17
Basically, a pact will stay WIP and pending until it has been merged into the main branch.
bethskurrie
2022-05-19 06:50
```The pact at http://pact is being verified because it is a 'work in progress' pact (ie. it is the pact for the latest versions of Foo from branch 'feat-x' and it has not yet been successfully verified by a version of Bar from branch 'feat/z' when the pact's application version was explicitly specified in the consumer version selectors). Read more at https://docs.pact.io/go/wip```
uladzislau_danilchyk
2022-05-19 10:42
Hi all! URGENT. It's blocking our release right now...
We're facing the issue with tagging pacticipant with tag, e.g. prod.
Pact Broker version: 2.88.0.0
We have multiple versions of a pacticipant. For example latest version was 5.0.0 which has prod tag (it is marked with blue color). We're pushed new version 6.0.0 and trying to tag that version as we did it multiple times previously. But in Pact Broker i see that new version (6.0.0) was tagged as prod but not marked with clue color and when we doing request to retrieve latest version by tag for that pacticipant it returns 5.0.0.
In other words "latest" flag is not switched to a newest version despite of the newest (6.0.0 version) was tagged as prod.
Could anyone help us with that ASAP?
uladzislau_danilchyk
2022-05-19 10:51
Additional information: we did the following https://docs.pact.io/pact_broker/docker_images/pactfoundation#automatic-data-clean-up before getting the problem above. But we didn't add `{ "tag" : " production" }` to `PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS` property.
Does it can be the root cause?
If yes, is there any way to rollback clean-up or make a hotfix without rollback?
bethskurrie
2022-05-19 23:57
You may have lost production data if you didn't keep the production tags, but it depends how long your keep age was set to.
bethskurrie
2022-05-19 23:59
Tagging has some behaviours that don't match the behaviour you'd expect, which may be the reason you're having issues.
bethskurrie
2022-05-20 08:44
gustavs.slutins
2022-05-20 08:44
Hi. Are there any plans to get the pact-broker docker image official? We wanted to use it in our project, but it was rejected by our security team, due to the reason that it is not official. Any thoughts on this?
bethskurrie
2022-05-20 08:53
you post it to github and a little person puts it in a machine for you :envelope:
ben.pilgrim
2022-05-20 09:19
Deployed to our test environment and it seems to be working! Thanks @bethskurrie
bethskurrie
2022-05-20 09:26
BTW, there's an environment variable for can I deploy that you can set to ignore the results if you have to do a break-glass deployment.
bethskurrie
2022-05-20 09:29
Would the Pactflow image pass their requirements? It's the commercial version of the Pact Broker.
ben.pilgrim
2022-05-20 10:08
Our security teams policy is that docker images have to be docker official images, so we?d be out of luck on the pactflow image too. We?ve requested an exemption from the policy for our use case, so hopefully we can get the OSS image approved internally, but it would be ideal if it was possible to get an official image merged to the docker standard library.
gustavs.slutins
2022-05-23 10:26
Hey, @bethskurrie. Did you get a chance to look into it? Is this something you are willing to do?
yousafn
2022-05-23 17:20
Hi @gustavs.slutins,
With respect, your request was made on Friday, and we have a weekend, so I would imagine Beth hasn?t had time to look into it.
I would suggest raising the want on our Canny feature request board https://pact.canny.io/
If you are able to provide any of the ground work in either making the necessary steps, or providing a skeleton of any tasks that would be required, it would greatly aid us in being able to make this happen.
Outside of that, we would need to prioritise and juggle accordingly. Will have a chat to the team.
@ben.pilgrim re the following
> Our security teams policy is that docker images have to be docker official images
How does this work for your own images created internally?
How does this work for other projects you wish to use but don?t have official repos? Are you just unable to use them?
I also note that
> Docker Official Images are an intellectual property of Docker.
Sounds gnarly
ben.pilgrim
2022-05-24 08:07
@yousafn
> How does this work for your own images created internally?
Internally maintained images are allowed but have to be based off docker official images.
> How does this work for other projects you wish to use but don?t have official repos? Are you just unable to use them?
Pretty much. We?re going through the process internally of requesting an exception to the policy for the pact broker OSS image, so we will see how that turns out.
kyle.craviotto
2022-05-24 17:19
I was hoping to get a bit of guidance on making changes to existing pacts. We?ve had our pact process setup for quite a while and have mostly followed the CI/CD pact process.
This has been working well, on the provider we?ve enabled pending pacts and WipPactsSince?
However, we recently needed to make a breaking change on our schema for our provider. (changing a property type from string to number) - js.
This didn?t cause any breaking changes on our consumer side, but we ran into issues when trying to ?deploy? the changes because of the can-i-deploy didn?t have a deployed version of the provider that had that change. However, I can?t deploy it to the provider because it?s considered a ?breaking change? and tells me there is no verified pact between the version that is currently deployed or released to test.
I know there?s a ?right-way? to handle this, but I can?t seem to figure it out based on the documentation here: https://docs.pact.io/pact_nirvana/step_7 I?ve got everything in place (minus the webhooks)
The error I get when trying to ?deploy? the provider is there is no verified pact between the version of the ?consumer? current deployed or released to test and version ?provider_version? of ?provider?
kyle.craviotto
2022-05-24 20:28
I guess the real trick here is the fact that we made a ?breaking change? and we should have provided backword compatibility. Since we didn?t we just have to disable the can-i-deploy checks for the provider for now to get a valid build out there?
yousafn
2022-05-24 21:03
Yeah I think that is the trick, you make it backwards compatible and then can remove once consumers have updated and deployed using the new property.
I believe I saw there is an escape hatch via an env bar, Beth mentioned it the other day, will have a quick look in the docs when I am at the keyboard
yousafn
2022-05-24 21:13
> ? ?Dry run? mode, where the results can be viewed, but the exit code is always successful, so that you can check that your pipeline working as expected before enabling the `can-i-deploy` check fully.
From https://docs.pact.io/pact_broker/can_i_deploy#further-reading
Documented in the readme, which is propagated to the docs site
https://docs.pact.io/pact_broker/client_cli/readme#can-i-deploy
Maybe the word breakglass or something would be a good keyword to add, to aid searching.
``` [--dry-run], [--no-dry-run]
# When dry-run is enabled, always exit process with a success
code. Can also be enabled by setting the environment variable PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true.```
I am assuming this will do the trick, as it will return a success code
yousafn
2022-05-24 21:14
This was the thread, https://pact-foundation.slack.com/archives/C9VPNUJR2/p1653038819299419?thread_ts=1652956946.152589&cid=C9VPNUJR2
I am going to link back, and the above post may be useful to that OP
yousafn
2022-05-24 21:14
Not sure if this is helpful @uladzislau_danilchyk re the above env var
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1653426793243039?thread_ts=1653412787.937529&cid=C9VPNUJR2
yousafn
2022-05-24 21:20
> I know there?s a ?right-way? to handle this, but I can?t seem to figure it out based on the documentation here: https://docs.pact.io/pact_nirvana/step_7 I?ve got everything in place (minus the webhooks)
You can verify in a webhookless flow https://docs.pact.io/pact_nirvana/step_6#alternative-webhookless-workflow
Example repo here https://github.com/pactflow/example-consumer-webhookless
matt.fellows
2022-05-24 22:14
> I guess the real trick here is the fact that we made a ?breaking change? and we should have provided backword compatibility. Since we didn?t we just have to disable the can-i-deploy checks for the provider for now to get a valid build out there?
You can definitely make a ?breaking change? (breaking in the traditional sense) to an API, provided that no consumers would be impacted by the change.
At the time of deployment, the provider must be compatible with the consumer in the target environment (e.g. environment= `prod`) and probably with the current mainline (e.g. branch= `main`)
matt.fellows
2022-05-24 22:15
> The error I get when trying to ?deploy? the provider is there is no verified pact between the version of the ?consumer? current deployed or released to test and version ?provider_version? of ?provider?
This tells me that you?re not verifying against the environment `test`, so it can?t determine if it?s safe to deploy to `test`
bethskurrie
2022-05-24 22:40
Ok, I can see a couple of unrelated issues here. 1. is that Pact will not let you make the change you just described. You will have to ignore the failing results if you want to get that change into prod and 2. I don't think the error you're seeing is because you're making a breaking change, I think it's because there is something not set up properly, so you're missing a verification result.
In regards to the can-i-deploy failure: in the can-i-deploy error message, does it tell you that there is no consumer version deployed to test, or does it give you the version number that is missing the verification? What are the consumer version selectors you have configured to be verified in the provider verification?
In regards to the breaking change. Pact will never let you make this change in one deployment if the consumer is actually using that field, because it will force you to be backwards compatible with the consumer in prod, and if you update the pact in development, the field can't be both an integer for dev and a string for prod at the same time. The only way you can transition from a string to a number would be to add a new number field, deploy provider, switch all the consumers to use that new field, deploy consumers, change the old field type (because by this stage, none of the consumers are using it, so none of the pacts will fail) then deploy the provider, then update all the consumers to use the original field again. This is the "expand and contract" pattern https://docs.pact.io/faq#how-can-i-make-a-breaking-change-to-a-provider
bethskurrie
2022-05-24 22:41
The other alternative is to knowingly deploy the broken change, as Yousaf mentioned by disabling can-i-deploy using the --dry-run flag.
bethskurrie
2022-05-24 22:48
@yousafn how's this
``` [--dry-run], [--no-dry-run] # When dry-run is enabled, always exit process with a success code. Can also be enabled by setting the environment variable PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true. This mode is useful when setting up your CI/CD pipeline for the first time, or in a 'break glass' situation where you need to knowingly deploy what Pact considers a breaking change. For the second scenario, it is recommended to use the environment variable and just set it for the build required to deploy that particular version, so you don't accidentally leave the dry run mode enabled.```
yousafn
2022-05-24 23:10
Nice, we can probably expand on that, in the FAQ on the docs site (plus we get the chance to get two tv/movie references) - I am definitely too much of a fan of Spaced
> what if I _need_ to deploy, but Can-I-Deploy (computer) says no?
>
> Buckle your seat belt, Dorothy, 'cause Kansas is going bye-bye. Set x flag.
kyle.craviotto
2022-05-24 23:12
thank you all, this is really great clarification!
In our case passing in the --dry-run flag was what we needed for the can-i-deploy. We had the new pact verified on the main branch, but when we did the deploy check it would fail as the change was ?technically? breaking our consumer (even though it wasn?t) - because js doesn?t care much about types
kyle.craviotto
2022-05-24 23:17
One thing that was a little confusing was in a lot of your documentation you still have ?tags? mentioned, even though the preferred approach is to use branch and deploys/releases. (especially the CI/CD docs)
bethskurrie
2022-05-24 23:20
yes, this is really annoying! unfortuantely, we're still waiting for the last of the main clients to be updated so that we can do a wholesale update on the site.
yousafn
2022-05-24 23:21
if you catch any you've found, you can add it to the snagging list https://github.com/pact-foundation/docs.pact.io/issues/136 on the GitHub docs, appreciate the feedback on the docs Kyle
kyle.craviotto
2022-05-24 23:52
> In regards to the can-i-deploy failure: in the can-i-deploy error message, does it tell you that there is no consumer version deployed to test, or does it give you the version number that is missing the verification? What are the consumer version selectors you have configured to be verified in the provider verification?
What it was showing was
```There is no verified pact between version 1.0.0-CONSUMER-203 of consumer-ui and the version of provider currently deployed or released to test (1.1.3-1653402689-main-249)```
on the consumer can-i-deploy check
bethskurrie
2022-05-25 05:27
That tells me that you're missing the webhook, as you mentioned earlier, that triggers your missing verifications https://docs.pact.io/blog/2021/10/11/contract-requiring-verification-published-webhook-event
kyle.craviotto
2022-05-25 14:36
we are migrating to github, so once that?s fully complete and we are using actions, we can probably make that happen
uladzislau_danilchyk
2022-05-27 08:11
The problem was related to created at date for the version. We found that previously (one year before) when we tested Pact Broker versioning, we left some test versions which are equal to our currently newest versions and as you understand `order` field in `versions` table was too small to be able to override latest version for the same tag.
bethskurrie
2022-05-31 04:50
@uladzislau_danilchyk the new environments and deployments feature will not have this issue
edouard.lopez
2022-05-31 14:08
Hello, while publishing contracts from a project, 1 contract is published with success while the 5 others trigger a `500`:
```> Task :pactPublish
PUT JSON request failed with status HTTP/1.1 500 Internal Server Error
Publishing 'ms.customer-order-computation-ms.product-order.json' with tags git-tag-missing, HEAD ... Failed - Request failed with HTTP/1.1 500 Internal Server Error
{"error":{"message":"An error has occurred. The details have been logged with the reference ITHepmbWaB","reference":"ITHepmbWaB"}}```
? Did you met this issue already?
? Can I access those log from the UI?
gianni.araco
2022-05-31 15:39
Uhm.. I do not recognize the error.
From the UI I don't think you can see the logs, but I believe there should be a file somewhere
bethskurrie
2022-05-31 22:17
@edouard.lopez you need to find out where the logs are being shipped to. The person who deployed your broker will have set that up.
bethskurrie
2022-05-31 22:18
The logs go to stdout of the docker container, which will likely be captured and/or forwarded by your docker container management service (eg. kubernetes)
bethskurrie
2022-05-31 22:21
Are these new contracts, or has it just started occurring after an upgrade?
bethskurrie
2022-05-31 22:23
There was an issue that I fixed recently where invalid UTF-8 characters in the body of a request were causing an error to be raised when generating the 400 response because the error message itself contained the UTF-8 character, which then could not be serialized to JSON, causing a 500 error to be returned instead.
edouard.lopez
2022-06-01 07:41
That's new contracts we try to publish, I updated last week to `2.99.0`
edouard.lopez
2022-06-01 09:19
I found those log through our datadog:
> 2022-05-30 15:39:05.691665 E [33:puma srv tp 002 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference eCqKAhYxok -- Exception: NoMethodError: undefined method `gsub' for nil:NilClass
marcello.rigan335
2022-06-01 11:54
Hello, i got a quick question. Does this not work with gradle?
```@PactBroker(
enablePendingPacts = "false",
url = "https://pact-broker.dev.whint.at",
authentication = PactBrokerAuth(
username = "XXXX",
password = "XXXX"
)
)```
username and password cant be resolved somehow
edouard.lopez
2022-06-01 12:56
fabio.rodrigues
2022-06-01 16:01
Hey there, is there anyway to in GET request API get a specific contract for a given branch
fabio.rodrigues
2022-06-01 16:01
for example, before with tags we could get a specific contract by tag with
fabio.rodrigues
2022-06-01 16:02
```$"pacts/provider/{ProviderName}/consumer/{ConsumerName}/tag/{ConsumerTag}"```
jbecker
2022-06-01 19:46
I posted this question about the broker cli to the general channel, but it just occurred to me that maybe this would be a better channel to ask it in:
jbecker
2022-06-01 20:50
Another (unrelated) question: I'm trying to use https://github.com/pact-foundation/pact_broker-client#publish to publish a directory containing pact files. Since the first option is called `PACT_DIRS_OR_FILES` I assume that means it's possible to point at a directory and the pact-broker cli will simply upload all the pact files it finds. However, when I try and run it this way, I get:
```docker run --network host pactfoundation/pact-cli broker publish ./tests/ --consumer-app-version=ca3abdc
Specified pact file './tests/' does not exist. This sometimes indicates one of the arguments has been specified with the wrong name and has been incorrectly identified as a file path.```
Am I missing something? Do I need to format my argument differently? Or is there a flag to enable directory mode or something?
jbecker
2022-06-01 20:55
Okay, this is very strange, but when I use a wildcard, it looks like it's finding the file and filling it out, but it's still failing with the same error :exploding_head:
```docker run --network host pactfoundation/pact-cli broker publish ./tests/*.json --consumer-app-version=ca3abdc
Specified pact file './tests/test-consumer-test-service.json' does not exist. This sometimes indicates one of the arguments has been specified with the wrong name and has been incorrectly identified as a file path.```
jbecker
2022-06-01 20:55
So the path is obviously correct because the wildcard is getting expanded, but the error says the file doesn't exist. Very confusing
jbecker
2022-06-01 21:02
oh damn, this one might actually be because I'm using the docker executable. I tried just running the same command from the pact-broker stand-alone CLI instead and it worked. Maybe I need to like, volume the file into the container?
bethskurrie
2022-06-01 21:29
Not yet, no. There hasn't been a reason to do it. What is your usecase @fabio.rodrigues?
bethskurrie
2022-06-01 21:30
@edouard.lopez you'll need to provide the full backtrace for me to identify what the problem is.
matt.fellows
2022-06-01 22:17
The list is being expanded in your _shell_ but the file is not volume mapped into the container,
christoph.oswald
2022-06-02 07:31
Hi,
we are still running in the issue I mentioned a few months ago.
We have set up the (open-source) pact-broker and a postgresDB in kubernetes.
We are receiving status 500 for some calls and then the next will return normally. In the logs I see something like. Is there some obvious issue I am missing?
```2022-06-02 06:10:26.905288 E [6:puma server threadpool 001 log_quietener.rb:18] pact-broker -- PG::UnableToSend: server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.: SELECT NULL
2022-06-02 06:34:23 +0000 Rack app ("POST /pacts/provider/xyz/for-verification" - (10.249.112.192)): #<Sequel::DatabaseDisconnectError: PG::ConnectionBad: PQconsumeInput() server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
>
2022-06-02 06:34:23.894050 E [6:puma server threadpool 001 log_quietener.rb:18] pact-broker -- PG::ConnectionBad: PQconsumeInput() server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.: BEGIN
2022-06-02 06:34:23.896197 E [6:puma server threadpool 001 log_quietener.rb:18] pact-broker -- PG::UnableToSend: no connection to the server: ROLLBACK```
prerit.jain
2022-06-02 08:01
Hello,
We are implementing contract testing for mobile apps. To perform the record release & record support ended for multiple supported versions for mobile apps. How do we get the list of production versions from pact broker for a specific participant. In our case there are multiple active versions on production but we want to keep n-3 versions for the contract validation.
As per our finding we can use below APIs to get the supported versions from pact broker but it will require some custom code to be written to get from the APIs.
*To get environment ID:*
http://localhost/environments/
*To get the currently supported version:*
http://localhost/environments/{envIdFromAboveAPIResponse}/released-versions/currently-supported
christoph.oswald
2022-06-02 09:22
Can also happen when trying to access the HAL-Browser (using latest pact-broker version), stacktrace:
bethskurrie
2022-06-02 22:24
There's no endpoint currently to get only the versions for a specific pacticipant. You'll need to call the endpoint you mentioned, and then filter in code.
bethskurrie
2022-06-02 22:24
Your use case of supporting a fixed number of versions is one I had considered supporting properly. Could you raise a feature request at http://pact.canny.io please?
robert.strehli
2022-06-03 12:01
Hey, I have question to branch names. Is it possible to delete a branch name like the tags? E.g. I have a consumer version were mistakenly set 2 different branch names. I want to delete one of them.
wng
2022-06-03 20:09
So we've been playing around with the CI aspect of Pact and saw after a branch gets merged to main, we noticed that the consumer pact for the merged branch still exists as one of the contracts for the integration. Is there a way to have those be deleted once the PR is closed or do we have to manually prune (and if so how)? We seem to have a lot of them because of things like renovatebot for github actions so it quickly is cluttering up Pactflow and makes it hard to see the contract (on main) that we care about. Or is there another feature/implementation route we missed in configuring the CI?
a. i.e. we see a main <--> main contract but also still the original BRANCH/123 <---> main contract
matt.fellows
2022-06-05 06:23
Looking at `api.rb` in the code base, issuing a DELETE to the following will delete all pacts for a given branch
```/pacts/provider/:provider_name/consumer/:consumer_name/branch/:branch_name```
bethskurrie
2022-06-05 21:52
@robert.strehli it's not implemented, but I almost picked that card up on Friday. I'll see if I can get it out today.
bethskurrie
2022-06-05 21:53
@prerit.jain thanks. I actually meant to raise a feature to automatically limit the number of currently supported versions.
bethskurrie
2022-06-05 21:54
You're just asking for this api as a means to an end. Better to solve the underlying problem.
bethskurrie
2022-06-06 05:09
Really good question. I?ve had branch clean up on my mental todo list for a while, but I don?t think we?ve got it in our backlog. Can you raise a feature request in http://pact.canny.io?
bethskurrie
2022-06-06 05:11
There?s a batch ?clean up? feature, but it is based on version age, so it can?t tell if a git branch has been deleted or not. https://docs.pact.io/pact_broker/administration/maintenance
wng
2022-06-06 15:12
Thanks, I wrote up this one: https://pact.canny.io/feature-requests/p/branch-cleanup
christoph.oswald
2022-06-07 09:38
The setting seems to have helped, so far the error has not occurred anymore. Thank you!
bethskurrie
2022-06-08 04:10
@wng it?s not the most convenient way to do it, but you can always clear up the pacts via the API https://docs.pact.io/pact_broker/administration/deleting_resources#deleting-multiple-pacts
robert.strehli
2022-06-08 06:41
Sorry for the late answer. I'm using the OSS Pact Broker @bethskurrie. Will the function also be there?
robert.strehli
2022-06-08 12:58
Hi, I have another question for the OSS pact broker regarding webhooks. I created a webhook for gitlab with url `"url": "https://gitlab.com/api/v4/projects/123/ref/master/trigger/pipeline?token=asdasd1231asd"` In this case the token itself is not disguised and you can see it over the HAL Browser. Is there a way to disguise the token, like using a separate variable somehow?
edouard.lopez
2022-06-13 13:22
They manage to workaround using the CLI to create the pacticipants, we are investigating
edouard.lopez
2022-06-13 14:02
I got more log:
```2022-06-13 13:58:31.326225 D [34:puma srv tp 004] pact-broker -- (0.000503s) SELECT "name" FROM "pacticipants" ORDER BY "name"
2022-06-13 13:58:31.326814 D [34:puma srv tp 004] pact-broker -- (0.000388s) SELECT "name" FROM "pacticipants" ORDER BY "name"
2022-06-13 13:58:31.327723 E [34:puma srv tp 004 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference ueeXehYZSi -- Exception: NoMethodError: undefined method `gsub' for nil:NilClass
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/find_potential_duplicate_pacticipant_names.rb:30:in `split'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/find_potential_duplicate_pacticipant_names.rb:26:in `clean'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/find_potential_duplicate_pacticipant_names.rb:21:in `block in call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/find_potential_duplicate_pacticipant_names.rb:20:in `select'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/find_potential_duplicate_pacticipant_names.rb:20:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/find_potential_duplicate_pacticipant_names.rb:14:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/service.rb:27:in `find_potential_duplicate_pacticipants'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/service.rb:17:in `block in messages_for_potential_duplicate_pacticipants'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/service.rb:16:in `each'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/pacticipants/service.rb:16:in `messages_for_potential_duplicate_pacticipants'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/api/resources/pacticipant_resource_methods.rb:9:in `potential_duplicate_pacticipants?'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/api/resources/pact.rb:42:in `is_conflict?'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/flow.rb:500:in `p3'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:31:in `block (2 levels) in run'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:51:in `handle_exceptions'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:31:in `block in run'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:29:in `loop'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:29:in `run'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/dispatcher.rb:46:in `block in dispatch'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/as-notifications-1.0.2/lib/as/notifications.rb:161:in `instrument'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/events.rb:75:in `instrument'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/dispatcher.rb:45:in `dispatch'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/adapters/rack.rb:68:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/cascade.rb:47:in `block in call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `each'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/database_transaction.rb:46:in `block in call_with_transaction'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.56.0/lib/sequel/database/transactions.rb:258:in `_transaction'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.56.0/lib/sequel/database/transactions.rb:233:in `block in transaction'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.56.0/lib/sequel/connection_pool/threaded.rb:92:in `hold'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.56.0/lib/sequel/database/connecting.rb:269:in `synchronize'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.56.0/lib/sequel/database/transactions.rb:195:in `transaction'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/database_transaction.rb:45:in `call_with_transaction'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/database_transaction.rb:24:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/convert_404_to_hal.rb:10:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/no_auth.rb:9:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:244:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/cascade.rb:47:in `block in call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `each'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/cascade.rb:38:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/urlmap.rb:74:in `block in call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/urlmap.rb:58:in `each'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/urlmap.rb:58:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/static.rb:161:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/hal_browser/redirect.rb:20:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/set_base_url.rb:15:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/convert_file_extension_to_accept_header.rb:28:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/static.rb:161:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/static.rb:161:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/add_vary_header.rb:34:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/add_pact_broker_version_header.rb:14:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/reset_thread_data.rb:13:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/invalid_uri_protection.rb:24:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/use_when.rb:30:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-protection-2.2.0/lib/rack/protection/content_security_policy.rb:72:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/rack/pact_broker/use_when.rb:28:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-protection-2.2.0/lib/rack/protection/xss_header.rb:18:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-protection-2.2.0/lib/rack/protection/json_csrf.rb:26:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-protection-2.2.0/lib/rack/protection/base.rb:50:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-protection-2.2.0/lib/rack/protection/frame_options.rb:31:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/rack-2.2.3/lib/rack/builder.rb:244:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.99.0/lib/pact_broker/app.rb:91:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.4/lib/puma/configuration.rb:252:in `call'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.4/lib/puma/request.rb:77:in `block in handle_request'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.4/lib/puma/thread_pool.rb:340:in `with_force_shutdown'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.4/lib/puma/request.rb:76:in `handle_request'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.4/lib/puma/server.rb:441:in `process_client'
/pact_broker/vendor/bundle/ruby/2.7.0/gems/puma-5.6.4/lib/puma/thread_pool.rb:147:in `block in spawn_thread'
2022-06-13 13:58:31.327844 I [34:puma srv tp 004] PactBroker::Errors::ErrorLogger --```
andrefcsousa
2022-06-13 15:22
Hi everyone. I have some questions regarding Pact broker:
1. Its possible for Pact Broker to create a diff between consumer contract revisions? For example to compare what changed between revisions published by consumers?
2. What is the max ammount of entries on the matrix? To assess the risk of out of space on the postgre database
3. its there any example of CI/CD integration between a consumer and a provider with github actions instead of the pact broker webhook?
bethskurrie
2022-06-14 00:14
@robert.strehli this is not supported in the OSS Pact Broker. In Pactflow you get secrets support.
bethskurrie
2022-06-14 00:16
2. There is no max. However, it is good practice to set up the clean function so that you don?t get performance issues from having 2 year old data hanging around.
bethskurrie
2022-06-14 00:17
3. You can set up a webhookless workflow as documented here https://docs.pact.io/pact_nirvana/step_6#alternative-webhookless-workflow
cody
2022-06-14 21:21
Hiya - I see the webhook templates library: https://docs.pact.io/pact_broker/webhooks/template_library
Does anyone have experience with triggering a webhook on http://semaphoreci.com ? I can?t find any docs on their site about it, but hoping it?s possible somehow. :fingerscrossed:
bethskurrie
2022-06-15 00:39
@edouard.lopez can you see if you can get the debug logs from the failed request, so we can work out what?s missing?
sclaros
2022-06-15 20:40
Hi !
I'm trying to run pact-broker-docker in Heroku. I think my issue is configuring PACT_BROKER_PORT in the Config Vars. The running port is set dynamically.
Notice the log is throwing "*Web process failed to bind to $PORT within 60 seconds of launch*"
```2022-06-15T20:30:22.926091+00:00 app[web.1]: Use Ctrl-C to stop
2022-06-15T20:30:52.074325+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2022-06-15T20:30:52.125437+00:00 heroku[web.1]: Stopping process with SIGKILL
2022-06-15T20:30:52.267145+00:00 heroku[web.1]: Process exited with status 137
2022-06-15T20:31:04.337872+00:00 heroku[web.1]: Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch
2022-06-15T20:31:04.380315+00:00 heroku[web.1]: Stopping process with SIGKILL
2022-06-15T20:31:04.558860+00:00 heroku[web.1]: Process exited with status 137
2022-06-15T20:31:05.540549+00:00 heroku[web.1]: State changed from starting to crashed ```
Thanks on advance :slightly_smiling_face:
yousafn
2022-06-15 21:11
I have a working example without docker here
https://github.com/YOU54F/pact-broker-heroku
Are you passing the dynamic port into your docker config. Have you got an example of how you are running it
yousafn
2022-06-15 22:35
Spot on, I didn't look in the search this time round, so will have found that with a search under heroku I am sure
sclaros
2022-06-15 22:56
Thank you, yes, it was super simple, the first time i read it I did the database variable but missed the port.
Setting PACT_BROKER_PORT_ENVIRONMENT_VARIABLE_NAME = PORT works super !
Thank you very much @bethskurrie & @yousafn!!
agarwal.akash333
2022-06-17 03:47
Hey peeps! We have a pact-broker (image: `dius/pact-broker:2.100.0.1`) running on a k8s cluster reachable via an A record on a domain with a wildcard CA certificate. For some reason, our JVM provider verification is failing with the following error despite the https://docs.pact.io/pact_broker/advanced_topics/using-tls#with-a-ca-signed-certificate. Thoughts? Error:
```au.com.dius.pact.core.pactbroker.InvalidNavigationRequest: Failed to fetch the root HAL document
Caused by: javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target```
JVM provider dependency:
```testImplementation "au.com.dius.pact.provider:junit5spring:4.3.8"```
A python consumer also fails to publish the pacts in CI because of a 400 error (I?m guessing it?s the same cause), though it works locally. Dependency: `pact-python==1.5.2`.
matt.fellows
2022-06-17 04:34
you wouldn?t get a `400` for an invalid certificate. You wouldn?t get a valid HTTP response at all
agarwal.akash333
2022-06-17 04:41
Hey Matt!
`Issued by: Sectigo RSA Domain Validation Secure Server CA`
I?m aware of a `400` being a bad request. Not sure why publishing the same pacts fails in CI but works locally against the same broker (the env variables are ~similar~ *identical* in both environments) :slightly_smiling_face: Relevant logs from CI:
```...
publish_process = Popen(command)
publish_process.wait()
if publish_process.returncode != 0:
url = self._get_broker_base_url()
> raise RuntimeError(
f"There was an error while publishing to the pact broker at {url}.")
E RuntimeError: There was an error while publishing to the pact broker at https://dev-broker.example.app.
/root/.local/lib/python3.8/site-packages/pact/broker.py:94: RuntimeError
--------------------------- Captured stdout teardown ---------------------------
INFO going to shutdown ...
INFO WEBrick::HTTPServer#start done.
--------------------------- Captured stderr teardown ---------------------------
PactBroker::Client::Hal::ErrorResponseReturned - Error making request to https://dev-broker.example.app status=400
=========================== short test summary info ============================
ERROR tests/consumer/test_experiment_service_consumer.py::test_get_available_interventions
========================== 6 passed, 1 error in 1.95s ==========================
PactBroker::Client::Hal::ErrorResponseReturned - Error making request to https://dev-broker.example.app status=400
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/root/.local/lib/python3.8/site-packages/pact/pact.py", line 243, in stop_service
self.publish(
File "/root/.local/lib/python3.8/site-packages/pact/broker.py", line 94, in publish
raise RuntimeError(
RuntimeError: There was an error while publishing to the pact broker at https://dev-broker.example.app.```
matt.fellows
2022-06-17 04:46
This is going to require a good understanding of how certificates are stored and used on your system. Usually, each language / OS has a place that stores certificate bundles and uses them at runtime. You?re going to need to check those to ensure the Sectigo RSA CA is in them
matt.fellows
2022-06-17 04:46
I can?t say for Python, it might just use the standard OS certificate chain (which will obviously differ across OS?s)
agarwal.akash333
2022-06-17 04:46
I didn?t realise that either until you just pointed that out! :smile:. And thanks, down the rabbit hole I go.. I?m on macOS :slightly_smiling_face:
matt.fellows
2022-06-17 04:47
In the case of Python - assuming it is the problem - I?d first get some verbose/debug level logs so we can ensure it is the problem
matt.fellows
2022-06-17 04:47
then we need to check the bundled certificates in the Ruby standalone that?s packaged in there
agarwal.akash333
2022-06-17 04:49
Ah. Didn?t know there were certificates bundled. That explains why things worked fine using http://pactflow.io. Both Java and Python are problematic atm! Java for provider verifications (locally), and Python for publishing pacts (in CI). It?s a fun matrix haha
matt.fellows
2022-06-17 04:51
> Didn?t know there were certificates bundled
For clarification. We don?t bundle any Pactflow specific certs, but Java and other libs/browsers/tools often bundle well known certs together (e.g. https://curl.se/docs/caextract.html)
agarwal.akash333
2022-06-17 04:52
The more I learn about computers, the more I realise how much I don?t know :sob:
bethskurrie
2022-06-17 08:23
If you set the env var DEBUG=true then you should get the response body that tells you what the 400 error is for. I'm surprised it's not included in the output already.
agarwal.akash333
2022-06-20 03:06
Hey @bethskurrie! Thanks for the reply. We?re using pytest module to run the test files, and setting `DEBUG=true` didn?t make a difference unfortunately.
agarwal.akash333
2022-06-20 03:08
My current execution script is:
```export DEBUG=true # and other pact variables
ls tests/consumer/ | grep 'test_experiment' | \
xargs -n 1 -I '{}' python3 -m pytest -vv --log-level=DEBUG --log-cli-level=DEBUG tests/consumer/'{}'```
agarwal.akash333
2022-06-20 04:10
A little update on this: publishing the same pacts in CI using https://hub.docker.com/r/pactfoundation/pact-cli fails with the 400 error too. Makes me believe this is a ruby issue! Any suggestions for logging the request body here except `DEBUG=true`?
matt.fellows
2022-06-20 05:56
there should be a way to pass the environment variable / flags to the underlying process. `--verbose` should do that I believe
agarwal.akash333
2022-06-20 05:57
Jinx! Finally figured out how to log the request. Turns out, it was `VERBOSE=true` flag. After setting that, I see this:
```Reading environment variable exporting file contents.
Reading environment variable exporting file contents.
-> "HTTP/1.1 400 Bad Request\r\n"
-> "Content-Type: text/plain\r\n"
-> "Content-Length: 0\r\n"
-> "Status: 400 Bad Request\r\n"
-> "Date: Mon, 20 Jun 2022 05:54:56 GMT\r\n"
-> "X-Powered-By: Phusion Passenger(R) 6.0.12\r\n"
-> "Server: nginx/1.18.0 + Phusion Passenger(R) 6.0.12\r\n"
-> "Via: 1.1 google\r\n"
-> "Alt-Svc: h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000\r\n"
-> "\r\n"
reading 0 bytes...
-> "" ```
Despite the json files existing with correct read privileges..
agarwal.akash333
2022-06-20 05:58
I?ve tried both specifying the directory approach and individual pact files too. NADA
agarwal.akash333
2022-06-20 06:05
Local:
```> docker run --rm pactfoundation/pact-cli:latest version
0.39.0```
In CI, it?s `0.50.0`. Trying out `0.39.0.0` now in CI :fingerscrossed:
matt.fellows
2022-06-20 06:24
Could you please send the full verbose output here? (pls redact any credentials)
agarwal.akash333
2022-06-20 06:29
Yessir! As before, I stopped publishing the pacts from the python library, dunno how to enable verbosity there (maybe the same flag). Here?s the output from pact-cli directly:
```Executing command: export VERBOSE=true
------------------------------
Executing command: ls -lah myapp/src/tests/pacts
total 16K
drwxr-xr-x 2 root root 108 Jun 20 00:03 .
drwxr-xr-x 5 root root 132 Jun 20 01:54 ..
-rw-r--r-- 1 root root 3.5K Jun 20 06:02 myapp-provider1.json
-rw-r--r-- 1 root root 10.4K Jun 20 06:02 myapp-provider2.json
------------------------------
Executing command: /pact/entrypoint.sh version
0.50.0
------------------------------
Executing command: /pact/entrypoint.sh publish myapp/src/tests/pacts/myapp-provider1.json --consumer-app-version fake-git-sha-for-demo-1234567 --tag-with-git-branch
opening connection to http://blah.example.app:443...
opened
starting SSL for http://blah.example.app:443...
SSL established, protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384
<- "GET /? HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nAuthorization: [redacted]\r\n"
-> "HTTP/1.1 400 Bad Request\r\n"
-> "Content-Type: text/plain\r\n"
-> "Content-Length: 0\r\n"
-> "Status: 400 Bad Request\r\n"
-> "Date: Mon, 20 Jun 2022 06:02:37 GMT\r\n"
-> "X-Powered-By: Phusion Passenger(R) 6.0.12\r\n"
-> "Server: nginx/1.18.0 + Phusion Passenger(R) 6.0.12\r\n"
-> "Via: 1.1 google\r\n"
-> "Alt-Svc: h3=\":443\"; ma=2592000,h3-29=\":443\"; ma=2592000\r\n"
-> "\r\n"
reading 0 bytes...
-> ""
read 0 bytes
Conn keep-alive
PactBroker::Client::Hal::ErrorResponseReturned - Error making request to https://blah.example.app status=400
Reading environment variable exporting file contents.
Reading environment variable exporting file contents.
Failed with exit code: 1```
matt.fellows
2022-06-20 06:36
You should also get a log entry in your broker (or if it?s Pactflow?s - our logs) that you can see why it was a 400
agarwal.akash333
2022-06-20 07:24
So for the successful run:
```Tagged version fake-git-sha-for-demo-1234567 of myapp as "new/feature-branch"
Publishing myapp/provider1 pact to pact broker at https://blah.example.app```
Regarding logs on broker, that was my first guess too, but I haven?t spotted any :slightly_smiling_face: The env variables we?re using on our deployment of image `dius/pact-broker:2.100.0.1`:
```- name: PACT_BROKER_LOG_LEVEL
value: DEBUG
- name: PACT_BROKER_ALLOW_DANGEROUS_CONTRACT_MODIFICATION
value: 'false'
- name: PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES
value: '10'
- name: PACT_BROKER_ALLOW_MISSING_MIGRATION_FILES
value: 'false'
- name: PACT_BROKER_DATABASE_MAX_CONNECTIONS
value: '1'
- name: PACT_BROKER_BASIC_AUTH_ENABLED
value: 'true'
- name: PACT_BROKER_PUBLIC_HEARTBEAT
value: 'true'```
Also worth mentioning, I don?t think that specifying the SSL file/dir to the CLI tool has any effects. I tried specifying a SSL file and changed a character in it, and I didn?t receive any issues related to SSL connection establishment failure (this was using the local version `0.39.0`).
bethskurrie
2022-06-22 04:22
My bad @agarwal.akash333, I should have known it was `VERBOSE` not `DEBUG`, sorry for the bum steer.
bethskurrie
2022-06-22 04:22
ok, that should not be possible! Every 400 should return error text, so there?s a bug there somewhere.
bethskurrie
2022-06-22 04:24
Ok, what?s even more confusing is that?s a GET request to the index resource. There is no validation on a get to the index resource!
bethskurrie
2022-06-22 04:26
I?m not seeing any headers in that response that tell me the request ever reached the Pact Broker Ruby application. I think that response is coming from Passenger/Ngnix.
bethskurrie
2022-06-22 04:30
This is what you get if you curl the vanilla ruby application:
```$ curl -v http://localhost:9292
* Trying ::1:9292...
* Connected to localhost (::1) port 9292 (#0)
> GET / HTTP/1.1
> Host: localhost:9292
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Vary: Accept
< Content-Type: application/hal+json;charset=utf-8
< Content-Length: 4300
< Date: Wed, 22 Jun 2022 04:30:10 GMT
< Server: Webmachine-Ruby/1.6.0 Rack/1.3
< X-Pact-Broker-Version: 2.101.0
< X-Content-Type-Options: nosniff
< Connection: Keep-Alive```
bethskurrie
2022-06-22 04:31
The Server header may get overridden by the nginx value, but the X-Pact-Broker-Version header should be in there, and it?s not.
bethskurrie
2022-06-22 04:32
Can you try running a curl request against your broker as I have shown above, and share the output please?
ben.pilgrim
2022-06-22 09:10
Does the provider_verification_published webhook trigger for automatic verifications?
bethskurrie
2022-06-23 00:56
It triggers for publication of any pact verification, regardless of whether it was a provider change or via a consumer change webhook triggered build.
agarwal.akash333
2022-06-23 03:05
Hi @bethskurrie, no worries regarding the confusion between the flag names!
Since my last message here?I ended up decoupling the responsibility of publishing from the Python library `pact-python==1.5.2` and hence, downgrading the `pactfoundation/pact-cli:latest` image version to `0.39.0.0`. The problem is resolved since.
Regarding your query, we?re on version `dius/pact-broker:2.100.0.1` and I curled both ports 9292 and 80. Results:
```root@160b72d08493:/home/app/pact_broker# curl -v http://localhost:9292
* Trying 127.0.0.1:9292...
* TCP_NODELAY set
* connect to 127.0.0.1 port 9292 failed: Connection refused
* Trying ::1:9292...
* TCP_NODELAY set
* Immediate connect fail for ::1: Cannot assign requested address
* Trying ::1:9292...
* TCP_NODELAY set
* Immediate connect fail for ::1: Cannot assign requested address
* Failed to connect to localhost port 9292: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 9292: Connection refused
root@160b72d08493:/home/app/pact_broker#
root@160b72d08493:/home/app/pact_broker#
root@160b72d08493:/home/app/pact_broker# curl -v http://localhost:80
* Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
> GET / HTTP/1.1
> Host: localhost
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Content-Type: text/plain
< Content-Length: 0
< Connection: keep-alive
< Status: 401 Unauthorized
< WWW-Authenticate: Basic realm="Restricted area"
< Date: Thu, 23 Jun 2022 03:03:30 GMT
< X-Powered-By: Phusion Passenger(R) 6.0.12
< Server: nginx/1.18.0 + Phusion Passenger(R) 6.0.12
<
* Connection #0 to host localhost left intact
root@160b72d08493:/home/app/pact_broker#```
matt.fellows
2022-06-23 03:11
you might need to get through the basic auth layer - could you please add the user/password to your curl, try again and share (redacting the values)?
agarwal.akash333
2022-06-23 03:15
Ah yep. These are local dev credentials so it?s fine:
```root@160b72d08493:/home/app/pact_broker# curl -v http://localhost:9292 -u "user2:password"
* Trying 127.0.0.1:9292...
* TCP_NODELAY set
* connect to 127.0.0.1 port 9292 failed: Connection refused
* Trying ::1:9292...
* TCP_NODELAY set
* Immediate connect fail for ::1: Cannot assign requested address
* Trying ::1:9292...
* TCP_NODELAY set
* Immediate connect fail for ::1: Cannot assign requested address
* Failed to connect to localhost port 9292: Connection refused
* Closing connection 0
curl: (7) Failed to connect to localhost port 9292: Connection refused
root@160b72d08493:/home/app/pact_broker#
root@160b72d08493:/home/app/pact_broker# curl -v http://localhost:80 -u "user2:password"
* Trying 127.0.0.1:80...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 80 (#0)
* Server auth using Basic with user 'user2'
> GET / HTTP/1.1
> Host: localhost
> Authorization: Basic dXNlcjI6cGFzc3dvcmQ=
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: application/hal+json;charset=utf-8
< Content-Length: 4160
< Connection: keep-alive
< Status: 200 OK
< Date: Thu, 23 Jun 2022 03:13:10 GMT
< Vary: Accept
< X-Content-Type-Options: nosniff
< Server: Webmachine-Ruby/1.6.0 Rack/1.3
< X-Pact-Broker-Version: 2.100.0
< X-Powered-By: Phusion Passenger(R) 6.0.12
<
{"_links":{"self":{"href":"http://localhost","title":"Index","templated":false},"pb:publish-pact":{"href":"http://localhost/pacts/provider/{provider}/consumer/{consumer}/version/{consumerApplicationVersion}","title":"Publish a pact","templated":true},"pb:publish-contracts":{"href":"http://localhost/contracts/publish","title":"Publish contracts","templated":false},"pb:latest-pact-versions":{"href":"http://localhost/pacts/latest","title":"Latest pact versions","templated":false},"pb:tagged-pact-versions":{"href":"http://localhost/pacts/provider/{provider}/consumer/{consumer}/tag/{tag}","title":"All versions of a pact for a given consumer, provider and consumer version tag","templated":false},"pb:pacticipants":{"href":"http://localhost/pacticipants","title":"Pacticipants","templated":false},"pb:pacticipant":{"href":"http://localhost/pacticipants/{pacticipant}","title":"Fetch pacticipant by name","templated":true},"pb:latest-provider-pacts":{"href":"http://localhost/pacts/provider/{provider}/latest","title":"Latest pacts by provider","templated":true},"pb:latest-provider-pacts-with-tag":{"href":"http://localhost/pacts/provider/{provider}/latest/{tag}","title":"Latest pacts for provider with the specified tag","templated":true},"pb:provider-pacts-with-tag":{"href":"http://localhost/pacts/provider/{provider}/tag/{tag}","title":"All pact versions for the provider with the specified consumer version tag","templated":true},"pb:provider-pacts":{"href":"http://localhost/pacts/provider/{provider}","title":"All pact versions for the specified provider","templated":true},"pb:latest-version":{"href":"http://localhost/pacticipants/{pacticipant}/latest-version","title":"Latest pacticipant version","templated":true},"pb:latest-tagged-version":{"href":"http://localhost/pacticipants/{pacticipant}/latest-version/{tag}","title":"Latest pacticipant version with the specified tag","templated":true},"pb:webhooks":{"href":"http://localhost/webhooks","title":"Webhooks","templated":false},"pb:webhook":{"href":"http://localhost/webhooks/{uuid}","title":"Webhook","templated":true},"pb:integrations":{"href":"http://localhost/integrations","title":"Integrations","templated":false},"pb:pacticipant-version-tag":{"href":"http://localhost/pacticipants/{pacticipant}/versions/{version}/tags/{tag}","title":"Get, create or delete a tag for a pacticipant version","templated":true},"pb:pacticipant-branch-version":{"href":"http://localhost/pacticipants/{pacticipant}/branches/{branch}/versions/{version}","title":"Get or add/create a pacticipant version for a branch","templated":true},"pb:pacticipant-version":{"href":"http://localhost/pacticipants/{pacticipant}/versions/{version}","title":"Get, create or delete a pacticipant version","templated":true},"pb:metrics":{"href":"http://localhost/metrics","title":"Get Pact Broker metrics"},"pb:can-i-deploy-pacticipant-version-to-tag":{"href":"http://localhost/can-i-deploy?pacticipant={pacticipant}&version={version}&to={tag}","title":"Determine if an application version can be safely deployed to an environment identified by the given tag","templated":true},"pb:can-i-deploy-pacticipant-version-to-environment":{"href":"http://localhost/can-i-deploy?pacticipant={pacticipant}&version={version}&environment={environment}","title":"Determine if an application version can be safely deployed to an environment","templated":true},"pb:provider-pacts-for-verification":{"href":"http://localhost/pacts/provider/{provider}/for-verification","title":"Pact versions to be verified for the specified provider","templated":true},"beta:provider-pacts-for-verification":{"name":"beta","href":"http://localhost/pacts/provider/{provider}/for-verification","title":"DEPRECATED - please use pb:provider-pacts-for-verification","templated":true},"curies":[{"name":"pb","href":"http://localhost/doc/{rel}?context=index","templated":true},{"name":"beta","href":"http://localhost/doc/{rel}?context=index","templated":true}],"pb:environments":{"title":"Environments","href":"http://localhost/environments","templated":false},"pb:environment":{"title":"Environment","* Connection #0 to host localhost left intact
root@160b72d08493:/home/app/pact_broker# ```
bethskurrie
2022-06-23 03:16
OK, you can see that got through to the ruby app because of the headers
```< Server: Webmachine-Ruby/1.6.0 Rack/1.3
< X-Pact-Broker-Version: 2.100.0```
agarwal.akash333
2022-06-23 03:18
Without being any close to your levels of insights in the repos, I don?t think it?s the broker that?s the problem?it was the publisher failing to read the Pact json files.
bethskurrie
2022-06-23 03:19
And you still have the same error with the `0.50.0.29` tag of the pact docker cli?
agarwal.akash333
2022-06-23 03:47
I can?t say for sure which patch version `latest` was previously pointing to in CI, since we don?t have access to the docker daemon. Here are my results from a quick few tests:
agarwal.akash333
2022-06-23 03:48
The k8s dev deployment is on a public facing URL backed by a wildcard cert. Didn?t see any SSL issues :smile:
bethskurrie
2022-06-23 03:50
and what happens if you try to publish to your real broker from your local dev machine using the 0.50.0.29 image?
agarwal.akash333
2022-06-23 03:50
I forgot to add that row, it passes :slightly_smiling_face:/:disappointed:
agarwal.akash333
2022-06-23 03:52
Good question! My local ?latest? was previously pointing to `0.39.0` (dunno which patch version) when publishing was failing for the Python and pact-cli (`0.59.0`) on CI
agarwal.akash333
2022-06-23 03:54
In fact, we were able to publish from the python library `pact-python==1.5.2` locally to k8s dev too.
bethskurrie
2022-06-23 03:56
My next thought is for you to run 0.39.0.0 with VERBOSE=true on, and then run 0.50.0.29 with VERBOSE=true on, and compare the output, character for character.
bethskurrie
2022-06-23 03:57
I cannot for the life of me think of anything that could be different about a ?GET /? request that could be different, but weird things happen.
Yes, in CI, seeing as that?s the only place it?s reproducible.
bethskurrie
2022-06-23 03:57
You didn?t redact any paths out of the logs when you pasted them did you?
bethskurrie
2022-06-23 03:59
There?s not a lot that can go wrong with this request!
```<- "GET /? HTTP/1.1\r\nAccept-Encoding: gzip;q=1.0,deflate;q=0.6,identity;q=0.3\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nAuthorization: [redacted]\r\n"```
agarwal.akash333
2022-06-23 04:06
Yeah, I can?t think of something either unfortunately. Long shot but is it a PATCH request perhaps?
I just tried publishing with both versions again in CI, *same error* as in the https://pact-foundation.slack.com/archives/C9VPNUJR2/p1655706584367349?thread_ts=1655437631.249989&cid=C9VPNUJR2, except that we aren?t using `--tag-with-git-branch` anymore.
bethskurrie
2022-06-23 04:07
Ok, now the logs for the working one. And then we can put them side by side.
agarwal.akash333
2022-06-23 04:08
Yeah, I?m not sure if the underlaying library (since it?s trying to include a body) is actually making a PATCH/PUT request but reporting the request method as GET. Like I said, long shot.
agarwal.akash333
2022-06-23 04:10
Already done a diff compare with the working one, logs:
```Executing command: export VERBOSE=true
------------------------------
Executing command: ls -lah myapp/src/tests/pacts
total 16K
drwxr-xr-x 2 root root 108 Jun 23 01:39 .
drwxr-xr-x 5 root root 132 Jun 23 01:39 ..
-rw-r--r-- 1 root root 3.5K Jun 23 03:24 myapp-provider1.json
-rw-r--r-- 1 root root 10.4K Jun 23 03:24 myapp-provider2.json
------------------------------
Executing command: /pact/entrypoint.sh version
0.39.0
------------------------------
Executing command: /pact/entrypoint.sh publish myapp/src/tests/pacts --consumer-app-version $PACT_CONSUMER_VERSION
Publishing myapp/provider1 pact to pact broker at https://blah.example.app
The latest version of this pact can be accessed at the following URL:
https://blah.example.app/pacts/provider/provider1/consumer/myapp/latest
Publishing myapp/provider2 pact to pact broker at https://blah.example.app
The latest version of this pact can be accessed at the following URL:
https://blah.example.app/pacts/provider/provider2/consumer/myapp/latest
Successfully ran freestyle step: Publish Python pacts
Reading environment variable exporting file contents.
Reading environment variable exporting file contents.```
ben.pilgrim
2022-06-23 09:35
I meant pre-verifications, but I figured out that the contract_published webhook includes the status, so can solve it that way
alanbos
2022-06-23 16:43
The `can-i-deploy` command takes an `--ignore` parameter that allows me to specify multiple pacticipants to ignore for the purposes of the deploy check.
Is it possible I can tell this command to treat absence of _any_ pacticipant from the target environment as ignorable? The reason for this is twofold:
? Its not necessarily an error that a given peer pacticipant isn't in the deployment environment; I have different environments that require different mixes of pacticipants.
? Its very brittle to have to state what must be ignored because this might change over time as new components are added; I have to go through each environment figuring out whether new component X is expected for environment E and if not add it to the ignore list.
bmeyres
2022-06-23 18:58
Im a little lost with the `publish` command and the matrix that is maintained in the pact-broker. From the docs I've read, provided the pacts have already been tested on the provider and have not been changed by the Consumer then the matrix should show that when I publish new Consumer results they have already been verified on the Producer side. However, what im seeing is that whenever a new Consumer verification result is published to the pact-broker my Matrix shows it has not been verified by the Producer even though there has been no change to the contract itself.
Am i missing something? Can someone help explain what im doing wrong here? Thanks
matt.fellows
2022-06-23 22:24
My guess is that the contracts are differing slightly. In the HAL browser you can navigate to the pact and do a diff on the previous version to see why they are different
matt.fellows
2022-06-23 22:25
do you use Pact JVM by any chance? If so, and you use matchers without specifying the example, I believe it will generate a random value. If so, this could explain why the pacts differ
matt.fellows
2022-06-23 22:26
I don?t believe `can-i-deploy` will fail for a provider, if there are no consumers in a target environment
bmeyres
2022-06-23 22:26
I tried the distinct-diff api, all it showed was the schema version had changed?
bmeyres
2022-06-23 22:28
``` {
"response": {
"body": {
- "schema_version": "4.0"
+ "schema_version": "8111.65"
}
}
},```
matt.fellows
2022-06-23 22:29
I?m confused about what you mean. The above diff clearly shows it has changed.
bmeyres
2022-06-23 22:30
But i dont know what has changed, In my mind as i see it i have made no change
matt.fellows
2022-06-23 22:31
My guess is that you are using a matcher for the `schema_version` property in your consumer test. If you can share that part of the test I can give some pointers
bmeyres
2022-06-23 22:32
ohhh wait ive got it now! Sorry i thought `schema_version` was something controlled by pact, but its the `schema_version` in my API :facepalm: oh dear!
bmeyres
2022-06-23 22:33
you are exactly right
```.stringMatcher("schema_version", "[0-9]+\\.[0-9]+")```
matt.fellows
2022-06-23 22:33
nice one, so yes, if you just pop a canned number in there (I think the 3rd argument) that should stop it from generating random values
matt.fellows
2022-06-23 22:34
@uglyog I?m wondering if we should mark those methods that don?t take examples as either deprecated on not best practice, as it essentially it works against our guidance of the pre-validation in the broker. Thoughts?
cc: @bethskurrie
bethskurrie
2022-06-24 03:04
How are you going with this @agarwal.akash333? I can?t see anything in the output there that hints at what the problem is.
matt.fellows
2022-06-24 03:53
Hmm. My concern is now you?ve pinned your CLI to an old version and at some point in the future you?ll have to deal with it. i.e. you?re just putting off a problem that future Akash (or worse, somebody without the context) will have to solve.
agarwal.akash333
2022-06-24 07:15
True. We're aware of that and prefer locking down software versions to avoid unforeseen breakages regardless :)
alanbos
2022-06-24 08:08
That's the case (consumer fail if provider not deployed) that I'm having the issues with; if the consumer is e.g. an API gateway with a configurable set of backends (the providers), each deployment may have a different mix of "required" providers.
Having to do this by exclusion (i.e. the `--ignored` switch) is pessimal because every time a new provider appears we have to go through all deployments adjusting the ignore list. If we had a global "ignore missing" switch or even the opposite `--dontIgnore` that would be much less brittle.
edouard.lopez
2022-06-24 08:14
Other teams have the same issue when trying to publish new contracts :S
edouard.lopez
2022-06-24 08:22
This happens on the Broker version `2.101.0.0` , we have a message that is a bit different
```> Configure project :
fatal: No annotated tags can describe 'c7c37886f8cc68b75cdfee3c4404b22b7bfd9d37'.
However, there were unannotated tags: try --tags.
> Task :pactPublish FAILED
Publishing 'ms.customer-delivery-ms.carrier.json' with tags git-tag-missing, HEAD ...
Got an invalid notices value from the Pact Broker: Expected an array, got Null
Failed - Request to path 'http://infra-pact-broker-web.support.manomano.com/contracts/publish' failed with response 500
{"error":{"message":"An error has occurred. The details have been logged with the reference MngWRRZpRk","reference":"MngWRRZpRk"}}
FAILURE: Build failed with an exception.
* What went wrong:
One or more of the pact files were rejected by the pact broker```
matt.fellows
2022-06-24 08:32
I'm confused about why the gateway would be deployed with a contract to a non existent provider?
alanbos
2022-06-24 08:33
Think of the gateway as being deployment-time configurable in terms of what providers it will need; not all providers are needed in all deployments.
matt.fellows
2022-06-24 08:37
So I wonder if that can be delt with using other means (e.g. tags or environments)
matt.fellows
2022-06-24 08:38
I'm not saying the feature isn't doable or even desirable, but I worry about the use of it
matt.fellows
2022-06-24 08:39
In your case, how will you differentiate between a situation where a provider should be there but isn't, and a valid situation where a provider isn't there and isn't needed
alanbos
2022-06-24 08:43
The way I'm dealing with it at the moment is to associate different ignore lists with different environment (tags), but as I say its brittle.
So I'm making that judgement already via the `ignore` flag (i.e. don't worry about this provider for this deployment).
I think in practice this approach would be more tractable in my particular use case if I were able to use `dontIgnore` because as the number of environments grows it becomes harder to manage the arrival of new providers.
But I understand your concerns around inadvertently missing a provider where it's needed; however I wouldn't suggest this kind of behaviour were the default - as with `ignore` its a case of _caveat developer_.
edouard.lopez
2022-06-24 09:14
When publish a new contract between non-existing pacticipants, isn't the broker supposed to create them?
edouard.lopez
2022-06-24 10:05
I use a repo with working contract and publication to just change the name of consumer and provider to something that was not in the broker, and it fails. So sound like a Broker regression.
matt.fellows
2022-06-24 10:28
If you?re using Pactflow though, and don?t have appropriate permissions, it won?t however
edouard.lopez
2022-06-24 13:36
After rolling back to the broker `2.99.0.0` , I'm able to publish a contract for new pacticipant, so there is probably a bug that have been introduce in later version (cf. https://pact-foundation.slack.com/archives/C9VPNUJR2/p1654006134133589)
bethskurrie
2022-06-24 21:08
I?ve taken your exact body and sent it with a curl, and this is what I get.
bethskurrie
2022-06-24 21:08
```+ curl -v -XPOST -H 'Content-Type: application/json' -d@/var/folders/9_/0ck5csjn64d78ttbzh9_n_mc0000gp/T/tmp.oEan8Hf1 http://127.0.0.1:9292/contracts/publish
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 127.0.0.1:9292...
* Connected to 127.0.0.1 (127.0.0.1) port 9292 (#0)
> POST /contracts/publish HTTP/1.1
> Host: 127.0.0.1:9292
> User-Agent: curl/7.77.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 15257
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Vary: Accept
< Content-Type: application/hal+json;charset=utf-8
< Content-Length: 3813
< Date: Fri, 24 Jun 2022 21:06:15 GMT
< Server: Webmachine-Ruby/1.6.0 Rack/1.3
< X-Pact-Broker-Version: 2.101.0
< X-Content-Type-Options: nosniff
< Connection: Keep-Alive
<
* Connection #0 to host 127.0.0.1 left intact
{"logs":[{"level":"debug","message":"Created ms.customer-delivery version unspecified with tags v0.20.2, dx-4628-pact","deprecationWarning":"Replaced by notices"},{"level":"prompt","message":" Next steps:\n Configure the version branch to be the value of your repository branch.","deprecationWarning":"Replaced by notices"},{"level":"success","message":"Pact successfully published for ms.customer-delivery version unspecified and provider ms.carrier.","deprecationWarning":"Replaced by notices"},{"level":"debug","message":" View the published pact at http://localhost:9292/pacts/provider/ms.carrier/consumer/ms.customer-delivery/version/unspecified","deprecationWarning":"Replaced by notices"},{"level":"debug","message":" Events detected: contract_published, contract_content_changed (first time any pact published for this consumer with consumer version tagged v0.20.2, first time any pact published for this consumer with consumer version tagged dx-4628-pact)","deprecationWarning":"Replaced by notices"},{"level":"prompt","message":" Next steps:","deprecationWarning":"Replaced by notices"},{"level":"prompt","message":" * Add Pact verification tests to the ms.carrier build. See https://docs.pact.io/go/provider_verification","deprecationWarning":"Replaced by notices"},{"level":"prompt","message":" * Configure separate ms.carrier pact verification build and webhook to trigger it when the pact content changes. See https://docs.pact.io/go/webhooks","deprecationWarning":"Replaced by notices"}],"notices":[{"type":"debug","text":"Created ms.customer-delivery version unspecified with tags v0.20.2, dx-4628-pact"},{"type":"prompt","text":" Next steps:\n Configure the version branch to be the value of your repository branch."},{"type":"success","text":"Pact successfully published for ms.customer-delivery version unspecified and provider ms.carrier."},{"type":"debug","text":" View the published pact at http://localhost:9292/pacts/provider/ms.carrier/consumer/ms.customer-delivery/version/unspecified"},{"type":"debug","text":" Events detected: contract_published, contract_content_changed (first time any pact published for this consumer with consumer version tagged v0.20.2, first time any pact published for this consumer with consumer version tagged dx-4628-pact)"},{"type":"prompt","text":" Next steps:"},{"type":"prompt","text":" * Add Pact verification tests to the ms.carrier build. See https://docs.pact.io/go/provider_verification"},{"type":"prompt","text":" * Configure separate ms.carrier pact verification build and webhook to trigger it when the pact content changes. See https://docs.pact.io/go/webhooks"}],"_embedded":{"pacticipant":{"name":"ms.customer-delivery","_links":{"self":{"href":"http://localhost:9292/pacticipants/ms.customer-delivery"}}},"version":{"number":"unspecified","_links":{"self":{"title":"Version","name":"unspecified","href":"http://localhost:9292/pacticipants/ms.customer-delivery/versions/unspecified"}}}},"_links":{"pb:pacticipant":{"title":"Pacticipant","name":"ms.customer-delivery","href":"http://localhost:9292/pacticipants/ms.customer-delivery"},"pb:pacticipant-version":{"title":"Pacticipant version","name":"unspecified","href":"http://localhost:9292/pacticipants/ms.customer-delivery/versions/unspecified"},"pb:pacticipant-version-tags":[{"title":"Tag","name":"v0.20.2","href":"http://localhost:9292/pacticipants/ms.customer-delivery/versions/unspecified/tags/v0.20.2"},{"title":"Tag","name":"dx-4628-pact","href":"http://localhost:9292/pacticipants/ms.customer-delivery/versions/unspecified/tags/dx-4628-pact"}],"pb:contracts":[{"title":"Pact","name":"Pact between ms.customer-delivery (unspecified) and ms.carrier","href":"http://localhost:9292/pacts/provider/ms.carrier/consumer/ms.customer-delivery/version/unspecified"}]}}```
bethskurrie
2022-06-24 21:53
Ok, something is not right. The error stack you have shared comes from the resource for publishing pacts using the old endpoint (/pacts/provider/PROVIDER/consumer/CONSUMER/version/VERSION). `pact_broker/api/resources/pact.rb:4` However, the request body you have shared is for the new endpoint at /contracts/publish, and which is in `pact_broker/api/resources/publish_contracts.rb`
bethskurrie
2022-06-24 21:58
There was a bug where if you tried to update a pacticipant in a particular way, it created a duplicate pacticipant with a null name. I?ve recently fixed that.
bethskurrie
2022-06-24 21:59
You?ll need to go into your database and run `delete from pacticipants where name is null`
bethskurrie
2022-06-24 22:04
Ok, I?ve worked out why you had the issue, and why rolling back helped. I recently added the ?check for duplicate pacticipants? feature into the new publish contracts endpoint. That meant that the pacticipant that was in your database with a null name was now causing an issue, where as before, it had no side effects.
edouard.lopez
2022-06-27 09:50
I see some weird entries, if you look for the item after `"name": "web-pro-product-page"` , I have no `name` nor `displayName` but `repositoryUrl` and `mainBranch`.
edouard.lopez
2022-06-27 09:51
Under the `_links` object I have items like:
``` {
"href": "http://pact.broker.foo/pacticipants/",
"title": "Pacticipant",
"name": null
},```
edouard.lopez
2022-06-27 09:53
The one with the `repositoryUrl` probably come from this curl request I use:
```# Fish Shell function
function pact-set-repo-metadata --description 'Set repo URL and Main branch to a repo' --argument consumer_name
set PACT_REPO_URL https://(git remote get-url origin | sed -e 's/git@//' -e 's/:/\//' -e 's/.git//')
set PACT_REPO_MAIN_BRANCH (git rev-parse --abbrev-ref origin/HEAD | cut -c8-)
curl \
--verbose \
--location \
--request PATCH \
--header "Content-Type:application/json" \
--data '{"repositoryUrl": "'$PACT_REPO_URL'", "mainBranch": "'$PACT_REPO_MAIN_BRANCH'"}' \
$PACT_BROKER_BASE_URL/pacticipants/$consumer_name
end```
edouard.lopez
2022-06-27 10:24
I will see to this with one of our SRE. Please be sure to check the related messages
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1656323446314029?thread_ts=1656077762.613129&cid=C9VPNUJR2
bethskurrie
2022-06-27 23:02
Yes, there was a bug where an update done in a particular way was causing a duplicate pacticipant with a null name to be created. I?ve fixed that, but the bad data is still there. I?ve written some migrations to clean up the bad data, but I?d like to test it on the saas platform before I put it out in oss.
bethskurrie
2022-06-27 23:02
Ideally you can lock it to a version that?s less than 1 year old though @agarwal.akash333!
bethskurrie
2022-06-28 02:17
:alert: *SUPPORT NOTICE - DOCKER 19 NO LONGER SUPPORTED*
I have updated the base image of the `pactfoundation/pact-broker` Docker image from `alpine3.13` to `alpine3.15` This means that *Docker 19 is no longer supported* for the `pactfoundation/pact-broker` Docker image, as alpine3.14+ requires Docker 20 or later. There were too many vulnerabilities in alpine3.13 to continue using it, and it was well overdue for an upgrade.
bethskurrie
2022-06-28 04:48
As rightly pointed out by @tjones this is a theoretical breaking change without bumping the major version number. Unfortunately, past Beth made the decision to tie the docker tag to the underlying broker gem version, which means that the situation where we?ve made a potentially breaking change to the *packaging*, rather than the API, is hard to express in our current tag format.
Current Beth apologises for Past Beth?s versioning strategy decision!
Hopefully, in practical terms, this is not an ACTUAL breaking change for anyone, as Docker 19 has been out of support for quite some time.
harwin1494
2022-07-01 15:20
Hello, the Can-i-deploy command is returning that its safe to deploy, even though the pact is not verified(failed) on the pact broker. Thoughts?
matt.fellows
2022-07-02 01:46
You might need to back this statement up with some data! Very hard to answer.
For a start:
1. What arguments are you passing to can-i-deploy?
2. What is the output of that command?
3. The command should have links to verification results to show you why it thinks it?s safe - follow those links
ruben.perezg
2022-07-04 13:11
Hi :slightly_smiling_face:
I wanted to share with you what I'm seeing in my Pact Broker, and see if anyone can help me understand what's happening.
We have set our _Pact Broker image_ and our Webhook (reacting to the `contract_content_changed` event), and I was working on a consumer & provider sample repos.
What is happening right now is that once the contract changes, the Webhook gets executed and makes a request to our internal CI tool, which runs the provider verification.
Once that happens, the provider contract tests pass and the verification result is published. The issue I have is that, even the verification passed and the UI shows it `green` , we still see `red` on the _Webhook_ status column (screenshot attached). If I go in to try to see what happened, I see that shows two webhook executions: one from a few days ago (that failed) and one from today (that succeeded). I have also attached an screenshot showing it.
To me it looks like somehow it keeps showing an earlier webhook execution that failed, and I can't get "rid of it". Could you help me understand what's happening?
bethskurrie
2022-07-04 23:49
See if you can delete the failing triggered webhook through the HAL browser
bethskurrie
2022-07-04 23:59
@harwin1494 is it the provider that is being reported as safe to deploy? The provider does not need the consumer for it to be deployed the first time.
ruben.perezg
2022-07-05 06:17
How could I do that?
The thing is that when I try to see the webhooks cerated in the Broker, I only see 1:
bethskurrie
2022-07-05 06:17
there?s 1 webhook, it?s been triggered multiple times for different events.
bethskurrie
2022-07-05 06:18
go to the webhook, and see if you can navigate to the triggered webhooks for that webhook.
bethskurrie
2022-07-05 06:19
just checked. there?s no hal relation for it, but you can just put ?/triggered-webhooks? on the end of the webhook URL.
ruben.perezg
2022-07-05 06:20
if you mean `...../webhooks/{webhookId}/triggered-webhooks` , I get a 404
bethskurrie
2022-07-05 06:21
the reason you?ve got a failure there is that it groups the triggered webhooks by the event type
bethskurrie
2022-07-05 06:22
so you?ve probably got multiple event types that have triggered it, and it failed for the most recent triggering of one event type, but not the other.
ruben.perezg
2022-07-05 06:23
but if you check the screenshoot in my main message, the event that triggered both was the same as far as I can see
bethskurrie
2022-07-05 06:23
in the HAL browser, on the webhook status resource, you should have a link of triggered webhooks in the resources section
bethskurrie
2022-07-05 06:24
you could see if one of htem was failed and delete that, but then the triggered webhook from before that would be used in the calculation, and if that one is failed, then it won?t help!
ruben.perezg
2022-07-05 06:26
What I don't understand is why I got that first execution (`triggeredWebhooks[0]`) that doesn't look like my created webhook... I guess I created a "bad" webhook at some point, and I'm paying the prize now :sweat_smile: :laughing:
ruben.perezg
2022-07-05 06:27
I will try to clean them and start again, and see if that solves this :slightly_smiling_face:
bethskurrie
2022-07-05 06:28
working out how to summarise all the webhook data into one status was tricky, and while I?m not convinced there?s a bug there, it might be showing data in an unexpected way.
ruben.perezg
2022-07-05 06:30
Probably I messed something up while trying to create the webhook, I'm not sure there's a bug either.
I was just trying to understand what could be going on, because I could mess it up again in a similar way in the future :sweat_smile:
ruben.perezg
2022-07-05 07:22
it hasn't worked :sweat_smile:
I tried to remove the webhook using a DELETE to `..../webhooks/{id}` , and it looked like it was deleted looking at the Broker UI.
But then I created it again (2 times, the fist one I created it wrong and then I did it well), and it showed all the previous data, and all the previous executions are still there.
Hence, I can't get a "green" status in the Broker UI because it still takes into account executions with deleted webhooks
bethskurrie
2022-07-05 07:23
oh, I wonder if there?s some logic in there that was too smart for this sitaution.
ruben.perezg
2022-07-05 07:23
Only the last one has been executed with the existing version of the webhook
bethskurrie
2022-07-05 07:23
now I think about it, I think that the triggered webhooks are kept around when the webhook is deleted to ensure that a status can be calculated. sigh.
bethskurrie
2022-07-05 07:24
you might need to clear the triggered webhooks table, if it?s important to you.
ruben.perezg
2022-07-05 07:24
I was going to ask if there was any API endpoint to remove that data, or if I had to look at the DB directly
bethskurrie
2022-07-05 07:25
if you can?t identify the triggered webhook that?s failed, then you?ll need to go to the db.
ruben.perezg
2022-07-05 07:30
I'm getting `404`, I'm not sure I'm sending the DELETE request to the proper path.
I'm trying to do this:
`http://my-broker/triggered-webhooks/fd6ecab9-bc36-4a06-a035-801bba7c6bd1`
That's what I get when navigating through the HAL Browser to get the status of the webhook executions for my applications. I mean, it points me to that path + /logs to check the execution logs:
`http://my-broker/pacts/provider/ms-common--pact-provider-sample/consumer/ms-common--pact-consumer-sample/webhooks/status`
ruben.perezg
2022-07-05 07:34
no worries, I'll try to do it and see it that does the trick :slightly_smiling_face:
ruben.perezg
2022-07-05 07:36
so, one final question.
As far as I understand, once a webhook execution fails, we will have a "red" state in the broker UI until we have a newer one that succeeds.
But if we at some point need to create a new version of the webhook, we will face this same issue if we had the previous version's last execution state as not-successful (either failed or retrying)
bethskurrie
2022-07-05 07:37
I think I need to update the logic for the webhook status so it only takes into consideration the current webhooks
bethskurrie
2022-07-05 07:37
you can raise an issue in the pact-broker repository describing the problem if you like.
ruben.perezg
2022-07-05 07:38
sounds good to me, but I don't know what side-effects that may have :sweat_smile:
And yeah, I will create an issue there :slightly_smiling_face:
Thank you very much for all the help!
ruben.perezg
2022-07-05 14:36
I have opened this issue:
https://github.com/pact-foundation/pact_broker/issues/568
Please, let me know if you want me to add any further information that might be useful :slightly_smiling_face:
ben.pilgrim
2022-07-06 16:26
Is providerVersionBranch missing from the contract_published and provider_verification_published webhooks?
bethskurrie
2022-07-06 23:26
You?re absolutely right @ben.pilgrim. I?ve fixed it and will push out a release today. Thanks for raising it.
bethskurrie
2022-07-07 05:49
@ben.pilgrim i?ve just hit the release button, so the new docker image should be out in a few minutes with the fix
ben.pilgrim
2022-07-07 08:32
@bethskurrie The release happened but no new docker image has been published
billal.patel
2022-07-12 13:01
Hello. When running the verify job, I am getting this error: `No pacts were found for the consumer versions selected` - This is totally fine however, the job still passes. Is there a way to make it fail in such cases?
tjones
2022-07-13 07:57
By default, the Ruby verifier (which pact-js uses) passes if there are no pacts. There is an option to fail if there are no pacts found, but I don't think it's exposed to pact-js
tjones
2022-07-13 07:58
Update: It is not. It's a straightforward change to get this supported, though.
billal.patel
2022-07-13 08:01
That would be very handy as I think teams are getting a false positive with the current set up
tjones
2022-07-13 08:10
You're welcome. Just to make sure there isn't any misunderstanding, I don't have the time to make the change - (which is part of the reason I stopped maintaining pact-js). However, I can happily point you at the right place to do it though - this is the arg mapper that would need to be extended to support `--fail-if-no-pacts-found` https://github.com/pact-foundation/pact-js-core/blob/pact-node/src/verifier.ts#L25 - notes that it is on the `pact-node` branch, not the master branch.
tjones
2022-07-13 08:10
This is the source that I used to check what the argument is called: https://github.com/pact-foundation/pact-ruby-standalone/releases
tjones
2022-07-13 08:12
> teams are getting a false positive with the current set up
Note that can-i-deploy will still fail, so the recommended setup of using can-i-deploy to gate deployments will be ok even if teams incorrectly think they're passing verification.
jeroen.lamain
2022-07-13 08:50
Hello, for me its not clear which version of the pact broker supports which version of the pact contracts . For example, which broker version supports https://github.com/pact-foundation/pact-specification/tree/version-4 ?
jeroen.lamain
2022-07-13 08:52
We now use 2.93.3 from docker hub. Does it support v4 of the pact specification?
tjones
2022-07-13 09:28
The broker is contract agnostic, it's the client libraries for verification and testing that support different pact specs
bethskurrie
2022-07-13 15:33
The API supports all versions @jeroen.lamain it?s just the UI rendering that?s not supported.
bethskurrie
2022-07-13 15:35
It should though. Can you have a look in http://pact.canny.io and add a request if it doesn?t already exist?
lorenz.ammon
2022-07-14 09:01
Hi everybody. Can it be that there are still some "blank?" problems left in 2.102.1, e.g. when a consumer version selector contains {"mainBranch":true}?
When running pact-broker-docker/blob/master/docker-compose.yml with pactfoundation/pact-broker:2.102.1.0
with an empty database
a POST to
http://localhost:9292/pacts/provider/bit-jme-cdc-provider-service-test-pact/for-verification
with body
{"consumerVersionSelectors":[{"mainBranch":true}],"providerVersionBranch":"feature/test-pact"}
results in
HTTP 500
{"error":{"message":"An error has occurred. The details have been logged with the reference JVbxfuyZqD","reference":"JVbxfuyZqD"}}
with the error log
pact-broker_1 | 2022-07-14 08:41:34.430032 E [7:puma srv tp 001 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference JVbxfuyZqD -- Exception: NoMethodError: undefined method `blank?' for true:TrueClass
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:79:in `not_provided?'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:97:in `validate_consumer_version_selector'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:69:in `block in add_cross_field_validation_errors'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:68:in `each'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:68:in `each_with_index'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:68:in `each'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:68:in `flat_map'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:68:in `add_cross_field_validation_errors'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/contracts/pacts_for_verification_json_query_schema.rb:61:in `call'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/resources/provider_pacts_for_verification.rb:100:in `schema_validation_errors?'
pact-broker_1 | /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.1/lib/pact_broker/api/resources/provider_pacts_for_verification.rb:23:in `malformed_request?'
When running pactfoundation/pact-broker:2.101.0.1 the same request results in { "error": "No provider with name 'bit-jme-cdc-provider-service-test-pact' found" } which is OK.
bethskurrie
2022-07-14 14:57
Ugh, this has been driving me nuts! At some stage there must have been a dependency that monkey patched the `blank?` method on to a heap of classes (cough active-effing-support cough) that has recently been removed.
bethskurrie
2022-07-14 14:57
I thought I?d caught all of them, but that one must have slipped through. I?ll put out a fix asap.
abudi.hijazi.01
2022-07-14 15:46
How is the can-i-deploy triggered by the consumer, and when does the consumer know when the provider has finished verifying the pacts, to then run can-i-deploy
bethskurrie
2022-07-14 18:27
You can trigger it with a webhook that fires when the provider has published a successful verification.
bethskurrie
2022-07-14 18:27
But generally, you want to do your feature work on a branch, and wait until that pact is verified before you merge into master.
bethskurrie
2022-07-14 18:28
By that stage, the pact is pre-verified, so can-i-deploy will pass immediately on master, and you can just deploy.
bethskurrie
2022-07-14 18:28
If you do the CI/CD workshop, it will explain the workflow https://docs.pactflow.io/docs/workshops/ci-cd
lorenz.ammon
2022-07-15 07:44
@bethskurrie Thanks for the quick fixing, Beth! Version 2.102.2.0 works for me now with requests containing a {"mainBranch":true} version selector. :+1:
bethskurrie
2022-07-15 12:21
The downside of non compiled languages that give people enough rope to hang themselves...
abudi.hijazi.01
2022-07-18 11:15
So is the whole new pact process being ran on every commit (in another branch)?
abudi.hijazi.01
2022-07-18 11:15
If that is the case, wouldn't that be a bit overkill, especially if you have a limit on GH actions minutes
abudi.hijazi.01
2022-07-18 11:24
The way I understand it is, on every commit a new pact is made and published to pact flow.
Then when there is a PR, can_i_deploy is ran
bethskurrie
2022-07-18 13:47
if a new pact is generated, then yes, a webhook would trigger a build of the provider. Otherwise, you would need to wait for the provider to run their build for other reasons, and it makes the feedback slower.
bethskurrie
2022-07-18 13:49
> If we already have schema and integration tests in our CI pipelines and are tested as a part of each PR to master, do I still benefit from using Pact?
Can/do your integration tests run on your local development machine, or do they need to be deployed to an environment to run?
bethskurrie
2022-07-18 13:49
If they need to be deployed, the advantage with contract tests is that they can be run BEFORE you commit (on the provider side), and before you deploy on the consumer side, so you know as soon as possible whether or not you?re compatible.
scott.riley111
2022-07-18 13:52
> If we already have schema and integration tests in our CI pipelines and are tested as a part of each PR to master, do I still benefit from using Pact?
Also - pact can give you convince which specific versions work with each other, rather than just "the version I tested against when the integration tests ran" (which can be hard to determine)
edouard.lopez
2022-07-22 07:38
Hello, is there a way to get all interactions between all consumers/providers?
je.alvinez
2022-07-25 02:53
hi pact-broker team! i didn't set any consumer version selectors in my provider test. when i run the said test, i saw it makes a POST request to *pb:provider-pacts-for-verification* (path: `/pacts/provider/{provider}/for-verification`) with this body
```{"consumerVersionSelectors":[],"includePendingStatus":false}```
what default consumer version selectors does the pact broker use in this scenario if i didn't set it? is it below based on what i can deduce from the pacts it fetched for verification? thanks for your help! :pray:
```{
"consumerVersionSelectors": [
{ "mainBranch": true },
{ "deployedOrReleased": true }
]
}```
tried looking at the https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors#recommended but could only find the recommended values for consumer version selectors. tried looking at the https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/api/decorators/pacts_for_verification_query_decorator.rb too but couldn't find my answer (or i'm just a ruby noob) :sweat_smile:
je.alvinez
2022-07-25 03:02
hey Matt! thanks for replying!
ah we didn't set it since we can run our provider test without it. we're still tweaking our implementation though.
we seem to be okay with whatever is the default behaviour based on the pacts it fetches for verification. however, we want to confirm exactly what are the default consumer version selectors used... :sweat_smile:
matt.fellows
2022-07-25 03:26
I think it should tell you in the output notices what has been selected and why
je.alvinez
2022-07-25 03:34
yep, i saw the criteria why a pact was fetched in the logs. normally, i would see these two:
? consumer version(s) currently deployed to some-env-dev (some-commit-hash) and some-env-test (some-commit-hash)
? latest version of some-consumer from the main branch 'main' (some-commit-hash)
which would mean the default consumer version selector has below
```{
"consumerVersionSelectors": [
{ "mainBranch": true },
{ "deployedOrReleased": true }
]
}```
however, sometimes i would see below too.
```latest version of some-consumer that has a pact with some-provider (some-commit-hash)```
i don't know what setting that corresponds to.
so i wanted to confirm what exactly are the default consumer version selectors since i can't rely on the logs to deduce it since i might miss a setting or two depending on the pacts stored in the broker :sweat_smile:
matt.fellows
2022-07-25 03:36
The core maintainer is off sick at the moment, so you might need to wait a few days for a response i?m afraid!
je.alvinez
2022-07-25 03:38
if you could point me to a doc or code for the default consumer version selectors, that would be great. :pleading_face:
oh no, hope he/she gets well quickly :pray:
tjones
2022-07-25 04:12
I _think_ the default is just the latest. But I wouldn't want to stake my reputation on that answer
je.alvinez
2022-07-26 00:14
hi Matt and Timothy! think i found my answer in the `pact-broker`https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/pacts/pacts_for_verification_repository.rb#L138-L141. thanks for your replies! :sweat_smile::pray:
1. if `branch` is set when publishing pacts, then criteria are: latest with `branch` = main, deployed, released
2. if `tag` (deprecated) is set instead of `branch`, then criteria are: latest with `tag` = main, deployed, released
3. if neither `branch` or `tag` is set, then criteria are: latest (overall), deployed, released
tjones
2022-07-26 00:28
Awesome, thanks for tracking that down! If you have a moment to make a PR adding this info to the documentation, that would be extra great
ruben.perezg
2022-07-26 06:57
Hi Pact team :slightly_smiling_face:
We have recently integrated our CI/CD flows with Pact, and we are seeing a behaviour that is being challenging to explain :sweat_smile:
What we see is that the webhook (`contract_content_changed` event) gets executed way too many times from what we would expect. I was trying to _debug_ what is going on looking at https://docs.pact.io/pact_broker/webhooks/debugging_webhooks#identifying-why-a-webhook-did-or-did-not-get-triggered, and what we see is that this is the message that I see constantly: `"Scheduling job for webhook with uuid ap7c1tk-AdEYyphWBVieIg"` . But it looks like the contract should have not changed, so I'm clearly missing something.
Is there any way to actually see what are the 2 versions of the contract the Broker is comparing to understand what is going on?
Also, as far as I've seen in the documentation, this could also explain what is happening:
> If the relevant consumer version has any tags, then for each tag, check if the content is different from the previous latest version for that tag. It is 'changed' if any of the checks are true. One side effect of this is that brand new tags will trigger a pact changed event, even if the content is the same as a previous version.
But all the versions published are tagging with `master`, so I'm not sure if there is anything else I should be looking at...
ruben.perezg
2022-07-26 07:02
Extra information: We are using _branches_ and _environments_, but we are still also creating _tags_ even though we are trying to avoid the use of _tags_ for all CI/CD flows
tjones
2022-07-27 05:19
Usually this happens when changing data is included in the contract every time.
ruben.perezg
2022-07-27 09:53
Thank you Timothy!
Could you help me find that endpoint? Can I get there using the HAL Browser? Or can I find it somewhere in the documentation?e
matt.fellows
2022-07-27 10:14
If you navigate to the pact in the HAL browser, there should be a relation to discover previous versions of the integration
ruben.perezg
2022-07-27 10:21
I think I have seen it now, but is there a way to get that content in a "plain json" format?
What I'm getting is the Pact itself but visualized using the Pact Broker browser, which is good, but not very diff-friendly :sweat_smile:
ruben.perezg
2022-07-27 10:22
For anyone interested:
`http://my-pact-broker.com/pacts/provider/myProvider/consumer/myConsumer/versions`
ruben.perezg
2022-07-27 10:30
ohhh, now I see that :the_horns: :the_horns: :the_horns: :the_horns: :the_horns:
ruben.perezg
2022-07-27 10:31
I tried to search for previous questions/answers here in slack, but clearly my searching skills in slack are not as good as yours :laughing:
Thank you very much to both of you Timothy and Matt!!
tjones
2022-07-27 10:32
You're welcome. If it helps, I didn't actually find what I was looking for either.
thanuxxxx
2022-07-27 20:35
Hi there,
I am trying to execute `describe-pacticipant` to double check if the main branch is configured but getting a "`Could not find command 'describe-pacticipant'`" . When I do a describe-version with similar parameters I works perfectly! Any thoughts?
```docker run --rm \
pactfoundation/pact-cli:latest \
broker describe-pacticipant \
--name my-pacticipant \
--broker-base-url https://my_broker_base_url.com \
--broker-username my_user \
--broker-password my_password
Resulting -> Could not find command "describe-pacticipant".```
tjones
2022-07-28 00:53
is it listed if you do a `broker help` ? What do you get with `broker version`?
thanuxxxx
2022-07-28 02:17
`docker run --rm \`
`pactfoundation/pact-cli:latest \`
`broker help`
`Commands:`
`broker can-i-deploy -a, --pacticipant=PACTICIPANT -b, --broker-base-url=BRO...`
`broker create-or-update-pacticipant --name=NAME -b, --broker-base-url=BROKE...`
`broker create-or-update-webhook URL --uuid=UUID -X, --request=METHOD -b, --...`
`broker create-version-tag -a, --pacticipant=PACTICIPANT -b, --broker-base-u...`
`broker create-webhook URL -X, --request=METHOD -b, --broker-base-url=BROKER...`
`broker describe-version -a, --pacticipant=PACTICIPANT -b, --broker-base-url...`
`broker generate-uuid ...`
`broker help [COMMAND] ...`
`broker list-latest-pact-versions -b, --broker-base-url=BROKER_BASE_URL ...`
`broker publish PACT_DIRS_OR_FILES ... -a, --consumer-app-version=CONSUMER_A...`
`broker test-webhook --uuid=UUID -b, --broker-base-url=BROKER_BASE_URL ...`
`broker version`
thanuxxxx
2022-07-28 02:18
bethskurrie
2022-07-28 23:18
@ruben.perezg you should be seeing output during the publishing step that tells you why the webhook has been triggered.
bethskurrie
2022-07-28 23:19
bethskurrie
2022-07-28 23:20
@ruben.perezg also, you would be better to use the new webhook ?contract requiring verification published? https://docs.pact.io/blog/2021/10/11/contract-requiring-verification-published-webhook-event
thanuxxxx
2022-07-29 05:09
Hi there,
I need some more clarification about `contract_requiring_verification_published` event. The http://A%20webhook%20using%20the%20contract_requiring_verification_published%20should%20be%20configured%20to%20pass%20through%20the%20${pactbroker.pactUrl}%20and%20${pactbroker.providerVersionNumber}%20and%20${pactbroker.providerVersionBranch}%20to%20the%20provider%20verification%20build., stated that
"A webhook using the `contract_requiring_verification_published` should be configured to pass through the `${pactbroker.pactUrl}` and `${pactbroker.providerVersionNumber}` and `${pactbroker.providerVersionBranch}` to the provider verification build."
I assume we need to pass version number (assume it is git SHA) so that we can checkout that GIT version before verifying the pact
My questions is why do we need to pass `pactUrl` and `providerVersionBranch` & and how that can be useful?
matt.fellows
2022-07-29 06:34
The `pactUrl` is the thing that is being verified. It?s the pact that needs to be verified
matt.fellows
2022-07-29 06:34
the branch may not be required, if you can derive what version to checkout from the version number (e.g. it?s a git SHA)
bethskurrie
2022-07-29 07:27
This is because a commit can belong to multiple branches, and to populate the branch build properties correctly, it needs to know the branch.
ruben.perezg
2022-07-29 07:30
Thank you Beth :slightly_smiling_face:
I saw in the logs that the webhook was triggered, but I didn't see why. I saw one of the options in the logs:
> Scheduling job for webhook with uuid ap7c1tk-AdEYyphWBVieIg
Which looks like just a "contract change" to me. But the consumer team told me that they didn't change anything for some time, but still the provider tests got triggered between 10 and 20 times per day. I just needed some help to try to see how the contract was actually changing...
And you all helped me. For the record, I was able to see the changes and understand what was happening. In this case, the consumer tests were using `form-data`, which uses a `boundary` field internally. That field was created randomly for every test execution, and that was the "change" introduced in every single CI consumer build.
matt.fellows
2022-07-29 07:31
> And you all helped me. For the record, I was able to see the changes and understand what was happening. In this case, the consumer tests were using `form-data`, which uses a `boundary` field internally. That field was created randomly for every test execution, and that was the ?change? introduced in every single CI consumer build.
good pickup! That?ll do it
ruben.perezg
2022-07-29 07:31
> also, you would be better to use the new webhook ?contract requiring verification published?
I know, but I have not been able to get into it yet :sweat_smile:
ruben.perezg
2022-07-29 07:37
Thank you for all the help folks, you are awesome :slightly_smiling_face:
thanuxxxx
2022-07-29 16:59
@matt.fellows So instead of `consumerVersionTags`, we should use `pactUrl` to get the correct contract from `pact broker` right?
jbecker
2022-07-29 17:45
Hey, are there any known issues with the webhook hitting jenkins? My webhook is triggering my jenkins job, but the values I have in the "body" are _not_ populating the parameters in my job. I'm not sure what I'm doing wrong
jbecker
2022-07-29 17:48
```[2022-07-29T17:36:59Z] DEBUG: Webhook context {"base_url":"http://pact-broker-url.com","consumer_version_branch":null,"build_url":null,"consumer_version_tags":[],"event_name":"contract_requiring_verification_published","provider_version_number":"9d89cb0","provider_version_branch":null,"provider_version_descriptions":["deployed in master"]}
[2022-07-29T17:36:59Z] INFO: HTTP/1.1 POST http://jenkins-base-url.com/job/pact_verify_provider/buildWithParameters
[2022-07-29T17:36:59Z] INFO: accept: */*
[2022-07-29T17:36:59Z] INFO: user-agent: Pact Broker v2.98.0
[2022-07-29T17:36:59Z] INFO: content-type: application/json
[2022-07-29T17:36:59Z] INFO: authorization: **********
[2022-07-29T17:36:59Z] INFO: host: http://jenkins-base-url.com
[2022-07-29T17:36:59Z] INFO: content-length: 251
[2022-07-29T17:36:59Z] INFO: {"project":"rating-service","version":"9d89cb0","pactfile_url":"http://pact-broker-url.com/pacts/provider/rating-service/consumer/rating-gateway/pact-version/2b4d7a5857da9e1f41ff3c5c259086e63f608663/metadata/Y3ZuPTk3MDUxMjUmdz10cnVl"}
[2022-07-29T17:36:59Z] INFO: HTTP/1.1 201 Created
[2022-07-29T17:36:59Z] INFO: date: Fri, 29 Jul 2022 17:36:59 GMT
[2022-07-29T17:36:59Z] INFO: content-length: 0
[2022-07-29T17:36:59Z] INFO: connection: keep-alive
[2022-07-29T17:36:59Z] INFO: x-content-type-options: nosniff
[2022-07-29T17:36:59Z] INFO: location: http://jenkins-base-url.com/queue/item/9154391/
[2022-07-29T17:36:59Z] INFO: server: Jetty(9.4.27.v20200227)
[2022-07-29T17:36:59Z] INFO:
[2022-07-29T17:36:59Z] INFO: Successfully executed webhook```
jbecker
2022-07-29 18:00
I'm trying to compare to this template for triggering a jenkins job with parameters, but this example doesn't look like it actually has any parameters? :grimacing:
https://docs.pact.io/pact_broker/webhooks/template_library#jenkins---trigger-build
thanuxxxx
2022-07-30 00:35
Great :+1:. So what about the main build pipeline? Keep using consumerVersionTags?
thanuxxxx
2022-07-30 01:41
Just one more question, let's say I have the master branch , test and prod environment. If a contract changes then does it trigger 3 builds?
matt.fellows
2022-07-30 01:49
If the provider versions that need to be verified are all different then yes, if they are the same then it will de-duplicate them
mike.geeves064
2022-07-30 14:06
Can you do it with just query string params?
The other examples have e.g.
`"url": "https://<DRONE_HOST>/api/repos/<NAMESPACE>/<REPO_NAME>/builds?branch=${pactbroker.providerVersionBranch}&commit=${pactbroker.providerVersionNumber}&PACT_URL=${pactbroker.pactUrl}"`
So can just add on following the `buildWithParameters?os_authType=basic`
dimundo
2022-08-01 19:24
hi!
any ideas - are those numbers from cleanup logs ok ? :slightly_smiling_face:
> {:deleted=>{:pact_publications=>0, :verification_results=>28, :pact_versions=>0, :triggered_webhooks=>0}, :kept=>{:pact_publications=>11244, :verification_results=>25401, :pact_versions=>31, :triggered_webhooks=>0}}
bethskurrie
2022-08-01 23:48
Yeah, it just means that since the previous clean up, the only thing it?s found to delete is 28 verification results.
bethskurrie
2022-08-01 23:50
These API docs indicate that the body is a form post, not a JSON post https://www.jenkins.io/doc/book/using/remote-access-api/#RemoteaccessAPI-Submittingjobs
bethskurrie
2022-08-01 23:55
You?ll need to put the parameters in the body in the format that you usually use for query parameters. https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/POST
bethskurrie
2022-08-01 23:57
it looks like you may need to define the parameter on the job https://stackoverflow.com/questions/20359810/how-to-trigger-jenkins-builds-remotely-and-to-pass-parameters
dimundo
2022-08-02 11:02
i meant more about `verification_results=>25401`
are there any `10500 is ok` , but `100500 is no-no` ?
or one just adds cpu/ram for bigger amounts ?
bethskurrie
2022-08-02 23:17
It deletes the pacticipant versions as per the selectors you provide to it. Any associated verification results/pacts get deleted along with the pacticipant versions.
edouard.lopez
2022-08-03 12:54
Hello, is there a page that display the network graph for all contract?
thanuxxxx
2022-08-03 19:20
Another quick question regarding to `contract_requiring_verification_published` webhook event.
In my provider's main pipeline I used tags to pull contracts like `-Ppactbroker.tags='master, dev, prod'`, since I changed to `contract_requiring_verification_published`, do I still have to use same approach to pull contracts? What is the recommended approach?
tjones
2022-08-04 06:45
Yes. You can click on your service to see the network diagram - See here: https://docs.pact.io/pact_broker#network-diagram
Also, if your network is complex, it can be very slow. See here for some advice on how to deal with that: https://docs.pact.io/pact_broker/network_graph
tjones
2022-08-04 06:47
You would pass the pact URL to the webhook and read the URL in your build and then pass the URL to pact. See here: https://docs.pact.io/pact_broker/webhooks#template-parameters
adam.witko
2022-08-04 08:04
Hey hey, I?m struggling with our hosted pact broker to be able to find any logs. for-verification is failing when the provider test has the exact same setup as another and has no consumer pacts to verify. I?m getting a 500 with `{"error":{"message":"An error has occurred. The details have been logged with the reference DrCxVPsPSd","reference":"DrCxVPsPSd"}}` but I can?t seem to find how I get to these via the API. Can anyone help?
adam.witko
2022-08-04 08:14
I have noticed this since upgrading our broker to 2.102.1.
Here is the request extracted from the ?debug? logs from the verifier execution:
```curl --location --request POST 'https://pact-broker.internal.io/pacts/provider/test-service/for-verification' \
--header 'Content-Type: application/json' \
--data-raw '{
"providerVersionTags": [
"DP-2086"
],
"includePendingStatus": true,
"consumerVersionSelectors": [
{
"mainBranch": true
},
{
"deployedOrReleased": true
},
{
"matchingBranch": true
}
],
"providerVersionBranch": "DP-2086"
}'
> {"error":{"message":"An error has occurred. The details have been logged with the reference XmWvwEMTCw","reference":"XmWvwEMTCw"}}```
matt.fellows
2022-08-04 13:39
You still use webhooks because these are used to verify new consumer contracts proactively.
But when your provider code changes you still need to make sure they don't break existing consumers.
In this case, your main build should continue to use tags (or environments/branches/releases as appropriate)
2022-08-04 13:39
See this page on the steps to creating an effective contract-testing setup https://docs.pact.io/pact_nirvana. (This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/)
matt.fellows
2022-08-04 13:43
I don't believe you can retrieve your errors via the API (they are designed to be secure I think but I don't think they are persisted). Who manages your broker that can get them for you?
adam.witko
2022-08-04 13:43
I thought that may be the answer. I shall pester those people with that lucrative AWS access :smile: thanks
bethskurrie
2022-08-05 00:33
@thanuxxxx you need to use branches and environments with the `contract_requiring_verification_published` event. You can?t use tags.
bethskurrie
2022-08-05 00:50
@adam.witko are you on the very latest version of the broker docker image? I have some memory of fixing a bug in this area recently.
bethskurrie
2022-08-05 00:54
Yep, I reckon it?s this one: https://pact-foundation.slack.com/archives/C9VPNUJR2/p1657789301853659
thanuxxxx
2022-08-05 04:22
Hello, I am trying to understand `master`, `deployed` and `released` for `consumer_version_selectors`.
Am I getting all right here?
`{"branch": "master"}` ->assume we configure master as our main branch then we pull the latest version of master
assume there is only one dev environment for testing, and for a given application instance,
`{"deployed":true}` -> this will pull the the pact from dev environments and we don't have to worry about latest because the `record-deployment` command automatically marks any application version that was deployed to the same application instance as undeployed, which guarantees that we will have just *one version of the pact*.
For a given application instance,
`{"released":true}` -> this will fetch all pacts which is in prod it can be more than one version.
edouard.lopez
2022-08-05 08:01
Thanks, but that's the graph for the pacticipant only. I would like to see all existing graph even if they are not connected
adam.witko
2022-08-05 08:38
Yeah that?s how we fixed it @bethskurrie. Bumped to 2.102.2 and all the things worked again :slightly_smiling_face:
bethskurrie
2022-08-09 04:16
that is mostly correct, but deployed is not just for dev, and released is not just for prod.
bethskurrie
2022-08-09 04:17
you can deploy to any environment, and you could release to any environment (thought generally, you?d only release to prod).
bethskurrie
2022-08-09 04:17
You can read about deployments and releases here https://docs.pact.io/pact_broker/recording_deployments_and_releases
thanuxxxx
2022-08-09 16:59
Do I have to prevent a consumer `feature branch` to merge to `master` if pre-verification fails?
Because `can-i-deploy` command is to check whether a code can be deployed to a specific env (`dev, test, prod and etc`..) or not. Which means a `non-verified contract` can be merged to `master` there is no check to enforce that. Should we check with `can-i-deploy` command before the code get merged to `master`?
lucka
2022-08-09 17:09
You'd get most safety this way, yes. Consider reading CI/CD Integration guide about Step "Platinum" pact nirvana
thanuxxxx
2022-08-09 17:14
That is great but `tags` are deprecated in that case do we have to create an `environment` to represent `master/any stable branch`. `can-i-deploy` requires an environment isn't it?
lucka
2022-08-09 17:48
It's not bound to working with `environment` only, consider readme: https://docs.pact.io/pact_broker/client_cli/readme#can-i-deploy
lucka
2022-08-09 17:49
Would anyhow recommend using `environment` and `branch` now, as its more readable and tends to confuse people less compared to `tag`s that get confused with the GIT concept.
thanuxxxx
2022-08-09 17:56
No, I am trying to switch to `contract requiring verification published` web-hook event from `contract content changed` event. From their https://docs.pact.io/pact_broker/webhooks#the-contract-requiring-verification-published-event they recommend use `main branch` and `environment`. Thank you for your guidance I should have read the docs properly :lol:
lucka
2022-08-09 17:57
it depends how much safety you want, you could also setup the `can-i-deploy` to check your other environments for sure, e.g. `prod` sounds reasonable
thanuxxxx
2022-08-09 18:02
I already have `can-i-deploy` checks for `dev environments` and `prod` but I didn't have a check (`can-i-deploy`) for `feature branch` to `master` for consumers.
alison.stuart.contrac
2022-08-09 20:47
Hi team, I work at Macmillan Learning on a team called "writing tools" and I'm encountering an issue I believe might be related to https://www.npmjs.com/package/@pact-foundation/pact/v/9.18.1 and state handlers (which as far as I know we aren't using). I would love any advice that you can offer. My error previously mentioned "no null state handler present" prior to failing, and my new error occurs at nearly the same point in our Jenkins build and publish process, and looks as follows:
Verifying writing 0.0.0-8477ca993
[2022-08-09 14:12:40.376 +0000] INFO (29 on d53225d7acfa): pact@9.18.1: Verifying provider
[2022-08-09 14:12:40.389 +0000] INFO (29 on d53225d7acfa): pact-node@10.17.6: Verifying Pacts.
[2022-08-09 14:12:40.391 +0000] INFO (29 on d53225d7acfa): pact-node@10.17.6: Verifying Pact Files
*Error: connect EINVAL 0.0.11.184:80 - Local (0.0.0.0:0)*
at internalConnect (node:net:953:16)
at defaultTriggerAsyncIdScope (node:internal/async_hooks:465:18)
at GetAddrInfoReqWrap.emitLookup [as callback] (node:net:1097:9)
at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:73:8) {
errno: -22,
code: 'EINVAL',
syscall: 'connect',
address: '0.0.11.184',
port: 80
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
matt.fellows
2022-08-09 21:23
Hi Alison, this looks like a JS issue.
Does it work on your local machines and only fail on CI? We?ll need a bit more info in addition to this to see what?s happening
2022-08-09 21:24
To help assist with debugging your issue, please provide: your pact test setup (code), the generated pact file and terminal output/relevant log files. Please note: statements such as "I cannot share in public because it's commercially sensitive" are not helpful. See this link on how to produce a minimal reproducible example that we can use to help you: https://stackoverflow.com/help/minimal-reproducible-example
matt.fellows
2022-08-09 21:27
please see the tips above. What makes you believe it?s a provider states issue and not something else? The logs shown don?t point to that. It looks like the verifier is trying to connect to port `80` on `00.0.11.184`. That looks to be a non-local IP address, and the verifier is unable to reach it. You might find that instead of pointing to `localhost` , pointing to `127.0.0.1` (or the correct local IP) might work
bethskurrie
2022-08-10 02:08
if you run can-i-deploy for every branch, it acts as a can-i-merge by default.
bethskurrie
2022-08-10 02:09
it?s saying ?could this feature branch be deployed to your test environment?
bethskurrie
2022-08-10 02:10
It depends if you want to hold off merging until your code can be deployed, or if you just want to merge as soon as your feature branch is compatible with the main branches of the integrated services.
thanuxxxx
2022-08-10 04:37
Our pipeline defined such a away that every `PR branches` will be merged into `master branch` then we deploy the `master` to `dev environment`. I think I can validate a new contract `can-i-deploy` with `--branch PR BRANCH` before it gets merged with `master`
thanuxxxx
2022-08-10 04:42
@bethskurrie Is `can-i-merge` command available? Looks like it is still in progress right? https://pact.canny.io/feature-requests/p/add-can-i-merge-functionality
thanuxxxx
2022-08-10 04:46
Do we have to do a similar check for provider CI/CD (`can-i-deploy` `--branch PR-PROVIDER`) ? I think we don't need that
bethskurrie
2022-08-10 06:35
I?ve made an endpoint for can-i-merge, but I still need to add the CLI for it.
bethskurrie
2022-08-10 06:35
you should still use the version number for can-i-deploy, not the branch name.
bethskurrie
2022-08-10 06:36
branch builds can run concurrently, so that makes using the branch name unreliable.
bethskurrie
2022-08-10 06:36
can you let me know if you want to merge
1. when your feature branch is compatible with the main branch of the provider OR
2. when the feature is supported in the dev environment
bethskurrie
2022-08-10 06:37
If you go with 1 (merge when consumer is compatible with provider?s main branch) but the provider has not deployed the main branch to dev, then your consumer main branch will be blocked from deployment until the provider has deployed.
bethskurrie
2022-08-10 06:38
This is why I suggest to use exactly the same can-i-deploy command, regardless of whether it?s the feature branch or main branch.
bethskurrie
2022-08-10 06:40
`can-i-deploy --pacticipant $APP_NAME --version $GIT_SHA --to-environment dev` will tell you when it?s safe to deploy from main into dev when you?re on main, and will tell you when it?s safe to merge feature branch into main when it?s on a feature branch.
alison.stuart.contrac
2022-08-10 13:45
Hi Matt, thanks for the suggestion! I thought it was related to provider states because it started showing up at the same time as the message "pact@9.18.1: No state handler found for "null", ignoring", which caused me to add
```stateHandlers: {
[null]: () => {
// This is the "default" state handler, when no state is given
console.log('hit null state, handling')
}
},```
to my Verifier.
alison.stuart.contrac
2022-08-10 13:47
Everything was working perfectly in CI pipeline and then out of the blue on a fresh rebuild we started hitting this error. I'm still trying to locate what changed or the source of the issue is.
alison.stuart.contrac
2022-08-10 13:48
Locally verify completes its execution without issue.
```Finished verifying writing
Reading json outputfile ...writing/api/app/tests/pact-tests/pact-verify-result.json
6 examples, 2 failures
Verification Failed...```
alison.stuart.contrac
2022-08-10 13:50
One known issue (that I doubt is related to this error) is that we are generating a new random uuid on the consumer side and republishing the pact any time we want verify to pass, since we can't get around a no-duplicate-creation issue in our POST requests to the actual writing DB in our testing. We are not mocking the server. So that's why there are 2 failures. But that is fixed each time we recreate the pact and re-run verify.
matt.fellows
2022-08-10 14:01
> We are not mocking the server.
do you mean, you?re hitting a live service or that you aren?t mocking dependencies? In case it?s not clear, you should definitely not mock the provider that you?re verifying
alison.stuart.contrac
2022-08-10 14:02
Right, we are NOT mocking the provider, we are hitting the actual provider API and modifying the real DB. This was a point of debate on the team, but in the end we agreed to hit the real provider API since that's the only way (imo) Pact really serves its purpose.
alison.stuart.contrac
2022-08-10 14:02
So we are indeed hitting a live service but I'm fairly unclear on what this connection is that's failing, I have no idea what lives on that port 80 at that IP addr, I'm very new to this side of things as I'm mostly a front end dev XD
alison.stuart.contrac
2022-08-10 14:19
Is there something else I can put in the Null State handler now that I know I am getting into that block (my console.log has come out from there just prior to the error) that would perform the default behavior? We don't have any different possible states in this context on the Consumer side, and I wasn't sure what was meant in the https://www.npmjs.com/package/@pact-foundation/pact/v/9.18.1 by the Promise.resolve that was the example here:
```"Has no animals": () => {
animalRepository.clear()
return Promise.resolve(`Animals removed from the db`)
},```
Is the Promise being referred to some hypothetical animalRepository.clear() function that wouldn't exist in my context? Or is this a default behavior inside the Pact stateHandler where I could put Promise.resolve(`'Completed Pact Verify'`)?
adam.witko
2022-08-10 14:34
Heya heya :wave:
A question non the broker + webhooks if anyone can enlighten me with knowledge.
Is there a setup of a webhook where it could pass multiple pact urls to the HTTP request to the providers pipeline trigger? I can't find any documentation that mentions this as a possibility, only that you will have 1 webhook per 1 pact that requires verification.
alison.stuart.contrac
2022-08-10 15:02
This issue has been resolved. I was pointed to localhost where I should have been pointed to the live Provider API due to a brief test I forgot I did and then never changed it back. I was fixating on the broker url but the one that was off was the provider url in verify.js. Thanks for the advice Matt! Your URL check suggestion was on point.
matt.fellows
2022-08-10 22:03
I will say, it's not best practice to point to a live provider, we recommend testing against a locally running provider with third party dependencies stubbed out. Live servers will be hard to manage as state becomes more important, and you're likely to get flakey and unreliable tests as a result
matt.fellows
2022-08-10 22:04
For the same reason the e2e tests can be painful, running tests against a live server is a step in that direction.
bethskurrie
2022-08-10 23:09
You can?t have multiple pact URLs because the event fires once per pact publication.
bethskurrie
2022-08-10 23:33
I?ve just added a FAQ for that, as it?s come up a few times recently https://docs.pact.io/faq#can-i-verify-my-pacts-against-a-deployed-instance-of-a-provider
matt.fellows
2022-08-11 00:10
The other practical reason is that using provider states is very hard to do this way.
je.alvinez
2022-08-11 10:22
hi pact-broker team! i've got a question related to the default consumer version selectors again. i'm trying to understand why a certain pact is not being fetched by the provider. it's the first and only pact for that consumer and that pact's branch, tag or environments fields are not set (all N/A).
when does this line of code evaluate to true? btw, confirmed the `mainBranch` for that consumer is set to `main` :pray:
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/pacts/pacts_for_verification_repository.rb#L151-L152
i was expecting that would return false so this line of code is executed instead which would fetch the latest pact for that consumer, but i guess i was wrong. :sweat_smile:
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/pacts/pacts_for_verification_repository.rb#L156
bethskurrie
2022-08-11 23:23
Is there anything stopping the branch or tag being set? You could spend a lot of time trying to work out why it?s happening, or you could do the recommended best practise and set the branch name.
sandy.mechie
2022-08-12 17:04
Hello,
I am trying to connect Pactbroker to postgres using kerberos . Getting this error when starting the container. I am using docker image 2.100.0.1
`PG:: Connection Bad: GSSAPI Authentication not supported` . Is GSSAPI not supported?
zhoutianli1234
2022-08-12 21:18
Hi, I am trying to create a webhook using the cli, however following your documentation (see first image), I end up with an incorrect format for the "body" (see image 2). The correct result should not contains the extra double quotes (see image 3). Is there another way/syntax to properly create my webhook using the cli ? Is this a bug ?
thanuxxxx
2022-08-15 19:05
Regarding to `pact broker` or `pactflow` failures (down for maintenance) what would happen when someone publishes, verifies or executes can-i-deploy commands? Does that build fail?
matt.fellows
2022-08-15 20:50
Are you asking, what is the behaviour of the CLI if they are down? They would fail, that would be my expectation
matt.fellows
2022-08-15 22:06
IMO you always need a way to build an escape hatch for CI in case a system is down.
tjones
2022-08-16 00:44
I've never seen this happen in all of my years of using pact.
I have seen Jenkins go down many many times :sweat_smile:
thanuxxxx
2022-08-16 01:48
Actually our `devOps` are responsible for the pact broker hosting. We upgraded the docker version to one of the latest versions and we started getting message like `The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.` I think this is because of some config issue from `devOps` side
I was curious how that impact our CI/CD pipeline and it seems consumers pipeline did not break even though pact publish stage throw error/exception but provider build/pipeline failed due to pact broker connectivity issue
matt.fellows
2022-08-16 03:16
> I was curious how that impact our CI/CD pipeline and it seems consumers pipeline did not break even though pact publish stage throw error/exception
Interesting. I?d expect my consumer pipeline to fail if that happened, worth checking to avoid future logic issues with your pipelines (e.g. if your build doesn?t fail but the publish wasn?t successful, you might get strange results further down the deployment pipeline that might be hard to reason about)
bethskurrie
2022-08-16 22:41
The ?break glass? in the can-i-deploy situation is to run a one off build with the env var `PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true`
bethskurrie
2022-08-16 22:43
> consumers pipeline did not break even though pact publish stage throw error/exception
This is surprising. There are retries in there, so maybe it eventually got through? Which tool are you using to publish?
bethskurrie
2022-08-16 22:45
Having said that, can-i-deploy also has retries built in. So maybe it just hit the limit when can-i-deploy ran.
bethskurrie
2022-08-16 22:46
> if your build doesn?t fail but the publish wasn?t successful, you might get strange results further down the deployment pipeline that might be hard to reason about
This is one of the reasons why a git sha should be used in the can-i-deploy commands, and not ?--latest?
thanuxxxx
2022-08-16 22:48
Actually the `can-I-deploy` stage also failed in the consumer `CI CD` but the `publish contract stage` did not.
bethskurrie
2022-08-16 22:49
Can you share the exact code that you?re using to create the webhook @zhoutianli1234?
thanuxxxx
2022-08-16 22:51
```const { Publisher } = require('@pact-foundation/pact');
const path = require('path');
const childProcess = require('child_process');
const exec = (command) => childProcess.execSync(command).toString().trim();
const gitSha = process.env.GIT_COMMIT || exec('git rev-parse HEAD');
const branch =
process.env.GIT_BRANCH || exec('git rev-parse --abbrev-ref HEAD');
const opts = {
pactFilesOrDirs: [path.resolve(process.cwd(), 'pact/pacts')],
pactBroker: process.env.PACT_BROKER_URL,
pactBrokerUsername: process.env.PACT_BROKER_BASIC_CREDENTIALS_USR,
pactBrokerPassword: process.env.PACT_BROKER_BASIC_CREDENTIALS_PSW,
consumerVersion: gitSha,
tags: [branch],
};
const publisher = new Publisher(opts)
.publishPacts()
.then(() => {
console.log('Pact contract publishing complete!');
console.log(
`Head over to ${process.env.PACT_BROKER_URL} to see your published contracts.`
);
})
.catch((e) => {
console.log('Pact contract publishing failed: ', e);
});```
bethskurrie
2022-08-16 22:51
Have you seen anything in the docs that would make you think that kerberos authentication is supported?
bethskurrie
2022-08-16 22:52
```.catch((e) => {
console.log('Pact contract publishing failed: ', e);
});```
bethskurrie
2022-08-16 22:52
By the way, we recommend people use the pact-cli to publish pacts now, rather than wrapping it with javascript. This is one of the reasons why!
tjones
2022-08-16 22:53
Possibly. We removed them at some point because it's much better to use the CLI (which is also included)
bethskurrie
2022-08-16 22:54
These are the database configuration environment variables https://docs.pact.io/pact_broker/configuration/settings#database
thanuxxxx
2022-08-16 22:56
So I use maven provider to publish contract to broker. Are you still recommending to use CLI for Java or other languages as well?
bethskurrie
2022-08-16 22:56
we?d rather people did, so we could stop having to support maven :laughing:
bethskurrie
2022-08-16 22:57
here?s how we recommend to publish with js https://github.com/pact-foundation/pact-js/blob/master/examples/graphql/package.json#L11
tjones
2022-08-16 22:58
My view (although I'm not a maintainer) is that it would be best to support whatever is idiomatic in the language you're using. In node, it's idiomatic to call CLI commands, so pact-js exposes the CLI for you to use
sandy.mechie
2022-08-17 10:17
Sure. Thanks for the update. I know nothing is mentioned in docs. But since postgres supports Kerb I thought will give it a try. Is there any plan of supporting kerb in near future?
athaper
2022-08-17 10:31
Hey , I was setting up pact broker on local and was wondering where the pacts are being stored and the role of postgres db that we set up
I couldn?t find any tables in the pact_broker database
matt.fellows
2022-08-17 11:02
I can assure you a proper setup stores pacts in the PG database. My guess is that either you're looking at the wrong schema in the database or you've configured the data to go elsewhere (e.g. sqlite)
bethskurrie
2022-08-17 23:16
You can run this docker compose and then inspect the database https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose.yml
bethskurrie
2022-08-17 23:18
`docker compose up` then
```$ docker exec -it pact-broker-docker-postgres-1 psql -U postgres
psql (14.3 (Debian 14.3-1.pgdg110+1))
Type "help" for help.
postgres=# select * from pacticipants;
id | name | repository_url | created_at | updated_at | display_name | repositor
y_name | repository_namespace | main_development_branches | main_branch
----+-------------+-----------------------------------------------------+----------------------------+----------------------------+--------------+----------
-------+----------------------+---------------------------+-------------
1 | Example App | https://github.com/example-organization/Example App | 2022-08-01 23:16:42.900855 | 2022-08-17 23:16:42.960083 | Example App |
| | | main
2 | Example API | https://github.com/example-organization/Example API | 2022-08-01 23:16:42.907195 | 2022-08-17 23:16:43.124324 | Example API |
| | | main
(2 rows)```
bethskurrie
2022-08-17 23:19
I did a quick google of ?pg gem kerberos? and there were no promising results, so I?d say that the pg gem does not support it. Without pg gem support, we can?t do anything.
msiyaj1
2022-08-18 22:10
Hi, is there a way to configure what header is read for basic authorization? We would love if there is an environment variable for this? We are behind a gateway that is renaming our `Authorization` header. We are using the pact-broker https://hub.docker.com/r/pactfoundation/pact-broker.
matt.fellows
2022-08-18 22:13
No, basic auth is an RFC standard. if you have auth on the gateway, why not do auth there?
gustavs.slutins
2022-08-19 10:58
Hey :smile: . I'm implementing Contract Based Tests for a project im working on. We are using our self hosted pact-broker (also considering switching to pactflow). Im wondering if anyone knows ways to gather some metrics. The /metrics endpoint gives some general data, but i was wondering if its possible to separate them per service or per integration? We are looking for failure rate.
zhoutianli1234
2022-08-19 12:58
```docker run --rm -e PACT_BROKER_BASE_URL -e PACT_BROKER_USERNAME -e PACT_BROKER_PASSWORD pactfoundation/pact-cli:latest pact-broker create-webhook https://dev.azure.com/MYORGANIZATION/_apis/pipelines/1496/runs?api-version=6.0-preview.1 --request=POST --header="Content-Type: application/json" "Accept: application/json" "Authorization: Basic TOKEN" --data='{"resources":{"repositories":{"self":{"refName":"refs/heads/PactWebhookTest"}}},"variables":{}}' --provider=MYPROVIDER --description='Testing Webhook' --contract-requiring-verification-published```
matt.fellows
2022-08-19 14:58
I guess I'm saying, if you're adding another auth layer how will all of the pact client tooling know how to send two different authentication headers?
matt.fellows
2022-08-19 14:59
Is basic with required if you have gateway auth?
You could implement a custom auth layer that has basic rules in place, and then just disable basic auth on the broker?
matt.fellows
2022-08-19 15:00
If security like this is important, you might want to look at Pactflow which has proper security, user management and RBAC. We have a cloud and on prem version
matt.fellows
2022-08-19 15:00
Not at this stage sorry Gustav, but we are looking into it (see the other thread in general the other day)
matt.fellows
2022-08-19 15:00
I'd love to know more about the use cases you're thinking about, why they matter and who would be consuming them
gustavs.slutins
2022-08-22 07:06
We are trying to measure success for the CBTs that we already created, to see if they are helping at all, before we scale our operation.
We already have detailed metrics for our FE and BE e2e tests that we measure per service daily. We combine them with the amount of bugs found per team. Then they are compared to teams which don't have those tests. The results are presented to the management mostly. We map the data over time to see if the tests make any difference at all in preventing bugs in the higher environments.
We were thinking of doing something similar for Contract Based Tests. Maybe compare CBT failure rate against the amount of bugs found per service?
gustavs.slutins
2022-08-22 07:12
I saw the thread in General. Actually Ben is part of our team as well.
matt.fellows
2022-08-22 08:09
Number of failing/passing tests might be hard to correlate, but would be interesting to note. Adoption rate at the application level will probably be a good starting point - which I think is what you?re asking
gustavs.slutins
2022-08-22 08:19
Yes. We have different teams for development and test automation. Then we have a different team for CBT testing. I have sent out a survey to the developers in the teams where we implemented the CBTs, but its been hard getting any results back. Its been 2 months since we added the first batch of CBTs. Maybe its too soon?
matt.fellows
2022-08-22 08:25
Interesting. Usually the Devs would write the contract tests. Who's writing them now? Are you using Pact or Pactflows bidirectional testing approach?
gustavs.slutins
2022-08-22 08:32
We are using both. Between internal services we use pact. With external services we intend to use pactflow with bidirectional (though its still in the Proof of concept phase).
We created the CBT team to lay down some initial tests and infrastructure in our pipelines to make it work.
The initial plan was for the devs to pick it up eventually, which is slowly happening now as well. Certain teams are more interested than others, depending on what type of services they own.
We have quite a few internal and external integrations to cover, and just thinking if its worth scaling the CBT team to make it happen quicker.
matt.fellows
2022-08-22 10:13
> We created the CBT team to lay down some initial tests and infrastructure in our pipelines to make it work.
that?s :chefkiss: , it?s a great way to help set good patterns/practices/habits (pact aside, any tool/practice etc.)
manel_ben_yahia
2022-08-22 13:37
Hello all !! i have a problem with my pact broker :disappointed: i have searched all the internet and didn't found a solution :
manel_ben_yahia
2022-08-22 13:39
`http://au.com.dius.pact.core.pactbroker.InvalidNavigationRequest: Failed to fetch the root HAL document`
manel_ben_yahia
2022-08-22 13:39
`at http://au.com.dius.pact.core.pactbroker.HalClient.navigate(HalClient.kt:240)`
at http://au.com.dius.pact.core.pactbroker.PactBrokerClient$fetchConsumersWithSelectors$halClient$navigateResult$1.invoke(PactBrokerClient.kt:311)
at http://au.com.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:39)
at http://au.com.dius.pact.core.pactbroker.PactBrokerClient.fetchConsumersWithSelectors(PactBrokerClient.kt:311)
at http://au.com.dius.pact.provider.junitsupport.loader.PactBrokerLoader.loadPactsForProvider(PactBrokerLoader.kt:233)
at http://au.com.dius.pact.provider.junitsupport.loader.PactBrokerLoader.load(PactBrokerLoader.kt:120)
at http://au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider$resolvePactSources$pactSources$1$pacts$1.invoke(PactJUnit5VerificationProvider.kt:83)
at http://au.com.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:39)
at http://au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.resolvePactSources(PactJUnit5VerificationProvider.kt:83)
at http://au.com.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.provideTestTemplateInvocationContexts(PactJUnit5VerificationProvider.kt:44)
at http://au.com.dius.pact.provider.spring.junit5.PactVerificationSpringProvider.provideTestTemplateInvocationContexts(PactVerificationSpringProvider.kt:24)
at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$0(TestTemplateTestDescriptor.java:103)
at java.base/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:271)
at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1621)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:107)
at org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:42)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1507)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1507)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:35)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:54)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:86)
at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:86)
at org.junit.platform.launcher.core.SessionPerRequestLauncher.execute(SessionPerRequestLauncher.java:53)
at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:71)
at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs(IdeaTestRunner.java:33)
at com.intellij.rt.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:220)
at com.intellij.rt.junit.JUnitStarter.main(JUnitStarter.java:53)
Caused by: http://javax.net.ssl.SSLException: Read timed out
at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:127)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:324)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:267)
at java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:262)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:137)
at java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1460)
at java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1368)
at java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:437)
at org.apache.hc.client5.http.ssl.SSLConnectionSocketFactory.createLayeredSocket(SSLConnectionSocketFactory.java:273)
at org.apache.hc.client5.http.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:241)
at http://org.apache.hc.client5.http.impl.io.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:148)
at http://org.apache.hc.client5.http.impl.io.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:396)
at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:158)
at org.apache.hc.client5.http.impl.classic.InternalExecRuntime.connectEndpoint(InternalExecRuntime.java:168)
at org.apache.hc.client5.http.impl.classic.ConnectExec.execute(ConnectExec.java:136)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
at org.apache.hc.client5.http.impl.classic.ProtocolExec.execute(ProtocolExec.java:175)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
at org.apache.hc.client5.http.impl.classic.HttpRequestRetryExec.execute(HttpRequestRetryExec.java:96)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
at org.apache.hc.client5.http.impl.classic.ContentCompressionExec.execute(ContentCompressionExec.java:133)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.ExecChainElement$1.proceed(ExecChainElement.java:57)
at org.apache.hc.client5.http.impl.classic.RedirectExec.execute(RedirectExec.java:115)
at org.apache.hc.client5.http.impl.classic.ExecChainElement.execute(ExecChainElement.java:51)
at org.apache.hc.client5.http.impl.classic.InternalHttpClient.doExecute(InternalHttpClient.java:170)
at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:67)
at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:200)
at org.apache.hc.client5.http.impl.classic.CloseableHttpClient.execute(CloseableHttpClient.java:143)
at http://au.com.dius.pact.core.pactbroker.HalClient$getJson$1.invoke(HalClient.kt:300)
at http://au.com.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:39)
at http://au.com.dius.pact.core.pactbroker.HalClient.getJson(HalClient.kt:295)
at http://au.com.dius.pact.core.pactbroker.HalClient.fetch(HalClient.kt:259)
at http://au.com.dius.pact.core.pactbroker.HalClient.fetch(HalClient.kt:254)
at http://au.com.dius.pact.core.pactbroker.HalClient.navigate(HalClient.kt:236)
... 65 more
Caused by: java.net.SocketTimeoutException: Read timed out
at java.base/sun.nio.ch.NioSocketImpl.timedRead(NioSocketImpl.java:284)
at java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:310)
at java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:351)
at java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
at java.base/java.net.Socket$SocketInputStream.read(Socket.java:937)
at java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:450)
at java.base/sun.security.ssl.SSLSocketInputRecord.decode(SSLSocketInputRecord.java:165)
at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:108)
... 98 more
matt.fellows
2022-08-22 13:41
Set to debug level logs and see what requests it makes. One possible explanation is proxies/network firewalls getting in the way
manel_ben_yahia
2022-08-22 13:41
Can you please help me on this ? i am blocked for two days didn't find a solution :disappointed:
matt.fellows
2022-08-22 13:42
Looks like an SSL exception too. Have you got a custom certificate installed and have you checked the certificate is properly installed in the trust store?
matt.fellows
2022-08-22 22:06
Does it work on your personal or work machine? Sometimes corporate machines have other network firewalls or proxies that interfere with the certificate chain
Can you curl it e.g. `curl https://pct-borker` or do you need to add the `-k` flag? That indicates the setup is incorrect
matt.fellows
2022-08-22 22:07
Where is the broker running - locally on your laptop or on another environment?
bethskurrie
2022-08-22 23:28
My guess is that because the command is running via docker, the behaviour of the brackets is different to running the command directly. You could try putting the webhook body in a file and using the format `--data @name-of-your-file.json`Like this https://github.com/pactflow/example-consumer/blob/master/Makefile#L100
manel_ben_yahia
2022-08-23 08:06
hello i think our time zone is not the same but thank you so much for your answers
matt.fellows
2022-08-23 08:10
they will know what should be setup on your client environment to properly access. The addition of the VPN won?t help the situation, because it will no doubt involve corporate firewalling and intermediate certs
manel_ben_yahia
2022-08-23 08:39
the certificate in the JVM already configured Java/JavaVirtualMachines/adopt-openjdk-11.0.9.1/Contents/Home/lib/security/cacerts
matt.fellows
2022-08-23 09:52
Or better yet, write a java script that calls the API and take pact out of the equation altogether
adam.witko
2022-08-23 11:02
Quick one for people. How do you logout of the Pact Broker OSS? I see no option in the UI or any clear indication if your auth creds are stored in cookies/local storage/ session storage, etc
adam.witko
2022-08-23 11:06
Is the clearing of this down to the browser on exit and/or if you specify your basic auth creds in the url when visiting the broker??
matt.fellows
2022-08-23 11:22
It?s basic auth, so it?s whenever your browser decides to re-authenticate you
manel_ben_yahia
2022-08-23 13:49
i would say, pact is on tests so i can disable SSL handshake when the test pact is calling the broker
thanuxxxx
2022-08-23 16:02
Hello everyone!
How to make Pact broker web-hook status green again? I had to change content changed web-hook build URL due to our Jenkins migration. So web-hook did not trigger and web-hook status was in red state. Now I updated the correct URL and web-hook triggers successfully but I still see web-hook status as red instead of green. Anyone experienced this?
matt.fellows
2022-08-24 02:02
> with java spring webClient i have ssl handshake timeout
So there must be a reason your team has setup SSL on the broker - presumably they care about security. Disabling SSL doesn?t seem the right thing to do
matt.fellows
2022-08-24 02:03
bethskurrie
2022-08-24 06:28
it groups the webhooks by webhook uuid, consumer id, provider id and event name.
bethskurrie
2022-08-24 06:28
I think the problem is that the triggered webhooks were deliberately not being removed when the webhook was removed.
manel_ben_yahia
2022-08-24 08:47
"For providers that are running on SSL with self-signed certificates" it is not talking about the broker
manel_ben_yahia
2022-08-24 09:00
```<plugin>
<groupId>au.com.dius.pact.provider</groupId>
<artifactId>maven</artifactId>
<version>${pact.version}</version>
<configuration>
<pactBrokerUrl>https://pact-feat.noprd.com</pactBrokerUrl>
<trimSnapshot>true</trimSnapshot>
<serviceProviders>
<serviceProvider>
<name>provider1</name>
<pactBrokerUrl>https://pact-feat.noprd.com</pactBrokerUrl>
<insecure>true</insecure>
</serviceProvider>
</serviceProviders>
</configuration>
</plugin>```
manel_ben_yahia
2022-08-24 09:01
but not sure that it will enable insecure SSL when calling the broker
matt.fellows
2022-08-24 09:32
Yep you might be right. I don't know the answer but was trying to see for you
manel_ben_yahia
2022-08-24 09:39
i didn't find in the docs how to enable insecure SSL or how to add certificate before verifying pacts on a self signed broker
edouard.lopez
2022-08-24 14:32
Is the _branch_ feature support documentation still accurate, i.e. only Ruby and dockerized support?
thanuxxxx
2022-08-24 22:37
I updated the web-hook, red status
I deleted the previous one and created a new one, still see red status
matt.fellows
2022-08-24 22:46
We're currently working on this at Pactflow now. I think almost all support them now, python support was submitted as a PR overnight. We'll look at the docs in the next few weeks and workshops to ensure it's all up to scratch
harwin1494
2022-08-26 14:32
Hi Team, when running the can-i-deploy command, its trying to find a verified pact for a particular provider, with a consumer whose pact does not exist on the broker anymore. How to resolve this?
thanuxxxx
2022-08-29 18:10
When `PACT_BROKER_CAN_I_DEPLOY_DRY_RUN` is set to `true` do `[--retry-interval=SECONDS]` and `[--retry-while-unknown=TIMES]` have any affect?
bethskurrie
2022-08-30 22:21
Is the problem that the pact doesn?t exist, and you don?t know why, or is the problem that you want can-i-deploy to ignore the missing pact?
bethskurrie
2022-08-30 22:22
It will still retry while there are unknown results. The dry run only changes the exit status at the end.
harwin1494
2022-09-01 07:37
The pact between a consumer A and Provider B doesnt exist anymore (its expected) and a pact between Provider B and consumer C does. But the can-i-deploy is expecting a verified pact between Consumer A and Provider B, and hence its failing. I resolved it by deleting the integrations from the broker.
fabio.rodrigues
2022-09-01 08:57
Hello All :wave:
I got a problem with pact broker
We have a list of pacts for a provider to be verified, the name of the provider is 'application-versioning-service' and the consumer service is 'publish-service'
The pactnet nugget attempts to retrieve the contract to be verified by using the following call:
```[10h26] 2022-08-31T07:31:01.8906579Z [DEBUG][pact_verifier::pact_broker] Sending JSON to https://outsystems.pactflow.io/pacts/provider/application-versioning-service/for-verification using POST: {"providerVersionTags":[],"includePendingStatus":true,"consumerVersionSelectors":[{"consumer":"publish-service","mainBranch":true}]}```
For any other consumer it is working fine, we get the specific contract but for that one - 'publish-service' he doesn't give anything and it returns that pact couldn't find the contract.
When i checked out using the API browser using the following call (for the contracts to be verified endpoint that the url use)
``` {"providerVersionTags":[],"includePendingStatus":true,"consumerVersionSelectors":[{"consumer":"publish-service","mainBranch":true}]}```
i got the response where i got all contracts (but no publish-service one)
when `"consumer"` is, for example, another one (like alm-app) i get only that one (as expected)
fabio.rodrigues
2022-09-01 08:58
all contracts have main branch published, and in pactflow we can see that other times it gets verified
bethskurrie
2022-09-01 23:03
Hi @fabio.rodrigues. Can you share the pacticipant resource for the publish-service please.
ruben.perezg
2022-09-02 06:26
Hi team :slightly_smiling_face:
I have some doubts regarding the `Webhook` triggering. Reading the documentation https://docs.pact.io/pact_broker/webhooks#the-contract-content-changed-event, I can see this:
> If the relevant consumer version has any tags, then for each tag, check if the content is different from the previous latest version for that tag. It is 'changed' if any of the checks are true. *One side effect of this is that brand new tags will trigger a pact changed event, even if the content is the same as a previous version.*
Reading this, some questions come to my mind:
1. Does it work for `branches` that way? I mean, if we used _branches_ instead of _tags,_ it would still trigger an execution for every new _branch_ even if there are no changes to the contract? (Currently we are using *both* _branch_ and _tags)_
2. Would it happen that way too with the `contract_requiring_verification_published` event? We are still using the old `contract_content_changed` :slightly_smiling_face:
3. Is there a way to "disable" those "side-effect" executions? I would like to avoid them if the contract does not include actual changes.
4. I'm pretty sure there is a reason why every new branch triggers an execution, but I'm struggling at understanding it :sweat_smile:, because that new branch may or may not introduce actual contract changes. Could anyone help me understand that?
Thank you! :slightly_smiling_face:
bethskurrie
2022-09-02 06:40
@ruben.perezg the docs are about to be updated. Please use the contract_requiring_verification_published event instead of contract_content_changed.
bethskurrie
2022-09-02 06:40
> I?m pretty sure there is a reason why every new branch triggers an execution, but I?m struggling at understanding it
You may have random data in your pacts.
bethskurrie
2022-09-02 06:41
See the docs here for how to identify if you do https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact#two-arbitrary-pacts
bethskurrie
2022-09-02 06:42
If the pacts are the same, then it?s most likely just the undesirable behaviour of the old webhook, and it?s one of the reasons why there is a new one to replace it.
bethskurrie
2022-09-02 06:42
> ? It only triggers if there is a verification result missing for one of the critical provider versions, reducing the number of unnessary builds triggered.
>
ruben.perezg
2022-09-02 06:47
Hi Beth! :slightly_smiling_face:
I guess this answers one of my questiones directly:
> It only triggers if there is a verification result missing for one of the critical provider versions, reducing the number of unnessary builds triggered.
So moving to the newer event should solve our current "issue".
As far as your other comments, I checked the diff to see what changed and why the webhook triggered, but in this case what I saw was pretty confusing to me. I will try to explain it.
We have an issue with random data previously that we caught using that diff (you folks helped me with that previously :slightly_smiling_face: ), but in this case what I see in the diff doesn't make a lot of sense to me. It shows changes in the contract (real changes, no random data), but those changes are not between the code versions I'm trying to compare. It shows differences that are not actual differences in the code... so maybe I did the wrong comparison, or maybe the comparison doesn't work so smoothly when new branch/tags appear
bethskurrie
2022-09-02 06:49
the main diff is that you?ll need to pass in the git sha of the provider to the build.
ruben.perezg
2022-09-02 06:51
then maybe I just got wrong the versions to compare, and hence the weird result I saw :sweat_smile:
I will take a look at https://docs.pact.io/pact_broker/webhooks#migrating-from-the-contract_content_changed-event to the newer event and try to do it. I already had that in my to-do list, so it's a very good time to work on it :slightly_smiling_face:
bethskurrie
2022-09-02 06:52
we need to start building up the webhook library for the new webhook, so if you would be able to share the webhook if you get it working that would be :raised_hands::skin-tone-3:
ruben.perezg
2022-09-02 06:55
that was another things I had in my to-do list xD. I was interested in the `Github - publish commit status` and the slack notifications.
As I see, the `Travis - trigger build` is still documented using the old event... so I think now I see what you meant :slightly_smiling_face:
ruben.perezg
2022-09-02 06:56
Ok, I will get back to you if I get it working.
And if I have problems... I will probably get back to you too :sweat_smile: :laughing:
marxjo
2022-09-02 07:21
Hi pact team,
I'm currently trying to figure how to best integrate `Webhooks` with GitHub on the event "Contract published that requires verification" to trigger the GitHub action on the provider side.
My question is about the authorization. I was trying to use a GitHub App as a "system account" but I doesn't work be cause a multi-step auth is required (e.g. create installation access token that is valid for 1 hour).
Am I right that I basically need to create a "system user" in GitHub, create a PAT for that system user and simply use this to authenticate the webhook? Or am I missing something? I basically don't want to use a PAT of a "real" personal account within the organization.
Thanks in advance for your support :+1:
bethskurrie
2022-09-05 23:23
@marxjo I haven?t worked out a better way to invoke the github apis myself. Using the personal access tokens is really crap, I agree.
bethskurrie
2022-09-05 23:25
I think the way github works, you need to create an app https://docs.github.com/en/rest/guides/getting-started-with-the-rest-api#about-tokens
bethskurrie
2022-09-05 23:26
And we?ll need to add in JWT authentication for the webhooks https://docs.github.com/en/developers/apps/building-github-apps/authenticating-with-github-apps
bethskurrie
2022-09-05 23:26
Can you create a feature request in http://pact.canny.io for this please?
bethskurrie
2022-09-05 23:27
You may be able to generate a long lived JWT (eg 1 year) that you could hardcode in the webhook.
bethskurrie
2022-09-05 23:43
The pacticipant looks fine. And because it?s in Pactflow, I can actually have a look at it for you.
edouard.lopez
2022-09-06 09:06
Could you help me understand why there is no contract available for verification?
https://pact-foundation.slack.com/archives/C9UN99H24/p1662390872006659
edouard.lopez
2022-09-06 12:39
I'm on version `2.102.1.0` , it's related to https://pact-foundation.slack.com/archives/C9UN99H24/p1662113042797179
bethskurrie
2022-09-06 23:29
@fabio.rodrigues can you send a request to so I can look into this for you?
ruben.perezg
2022-09-07 06:47
Hi! :slightly_smiling_face:
I had to switch to another task, but today I am going to work back on it. I'll keep you posted :slightly_smiling_face:
snehasingh291506
2022-09-07 12:50
Could someone please help me with the step-by-step pact broker implementation? If anyone has any detailed documentation, it will be really helpful.
2022-09-07 13:41
See this page on the steps to creating an effective contract-testing setup https://docs.pact.io/pact_nirvana. (This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/)
2022-09-07 13:41
Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops
ruben.perezg
2022-09-07 13:55
I'm looking at it, but I don't really understand what I should do here.
Reading the https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event, I see this:
> Update the webhook body to pass in the `${pactbroker.providerVersionNumber}` as the commit and `${pactbroker.providerVersionBranch}` as the branch
Why do I need to send that information? I mean, what I understand is that we should check the new contract with our "main branch" version of the provider, and with the versions deployed in our defined environments (for example, _production_). But I'm not sure if those parameters will do the trick (not all of them are documented https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks#dynamic-variable-substitution)
ruben.perezg
2022-09-07 16:18
I kind of expected the webhook to "know" what is the latest version of the provider main branch, and the latest version deployed for each environment, so it would trigger the needed builds.
But I'm not really sure if I have understood this at all :sweat_smile:
bethskurrie
2022-09-07 23:28
The Pact broker does know what the latest versions are, and it is triggering the right builds. But you need to pass that information to your CI/CD application, which does not know. That?s why you need to pass it via parameters in the webhook.
bethskurrie
2022-09-07 23:29
You need to send the commit, so the build knows which version to build. you need to send the branch because a commit might be present on multiple branches, and some CI apps like to populate the correct branch. It also helps the verification results publish with the correct branch.
ruben.perezg
2022-09-08 07:01
So, let me put our scenario as an example to see if I got it right.
In our case, what we want is to trigger 2 different builds of the provider: one for our `master` _branch_ and one for our `production` _environment_ (we don't have any other defined environment at the moment, as we don't think we need it).
So the Pact Broker will trigger both builds (assuming both provider versions are different), and for each one it will replace those placeholders (`${pactbroker.providerVersionNumber}` and `${pactbroker.providerVersionBranch}`) for the value they should have for those 2 different cases.
Is that right?
ruben.perezg
2022-09-08 07:09
That would be awesome :awesome:. Let me know if I can help you with that, because sometimes "someone from outside the project" can help with those things
bethskurrie
2022-09-08 07:27
You just need to hit the edit button on that page, and github will do the rest.
tjones
2022-09-08 14:01
Is it still the case that the broker is contract-agnostic - as in, I can put any other json file in instead of the pact file?
matt.fellows
2022-09-08 14:04
calling it the Pact Broker might be the worst branding mistake :laughing:
yousafn
2022-09-08 14:06
I had seen that in the docs, but hadn?t tried it out, what you thinking Mr Jones
mike.geeves064
2022-09-08 15:16
:thinking_face: thinking pact message, on the oss pact broker you get the "idk what this JSON is, can't parse it, here's the raw" but puts it in the right place with links etc so would expect some level of agnostic with some required fields? :thinking_face:
mike.geeves064
2022-09-08 15:19
I got no sympathy trying to explain The Martian was basically like my every day with things on fire, exploding, trying to come up with crazy solutions involving duct tape code and so on :thinking_face:
sashaavramchik
2022-09-09 11:05
Hi folks! Is there any way to get a version of the provider that deployed in different environments? I'm trying to get rid of tags. And previously I used 'describe the version' to do this. But I don't see any option for 'environments'. Or is there any other way to verify the new pact with different versions of provider?
matt.fellows
2022-09-09 11:19
May I ask why you need the info? I think it?s doable via APIs, but just wondering why you want to get the provider version from the environment?
sashaavramchik
2022-09-09 11:26
We have different version deployed. And when new pact uploaded -> webhook triggered -> getting deployed versions -> checkout to these versions -> do verification to satisfy can-i-deploy
matt.fellows
2022-09-09 11:28
usually, this would map to a branch (e.g. `main` ) but I?m guessing you can?t always be sure so it?s a fair point
matt.fellows
2022-09-09 11:28
A feature request at https://pact.canny.io/ would be great (if it?s not already there)
matt.fellows
2022-09-09 11:29
In the meantime, hit the `/` path of the API and then follow the environments resource. I believe you can get to the deployed resource via those relations
tjones
2022-09-12 01:57
At least, I keep telling people that one of the nice side benefits of Pact is now you know what is deployed everywhere. Have I been lying to them?
matt.fellows
2022-09-12 02:04
Yes the matrix definitely does, but that?s not super helpful for automation. You could obviously call the API but I think alexsandr is wanting a CLI command to get it (which I think is reasonable)
snehasingh291506
2022-09-12 10:52
Hey guys, I am trying to publish the contracts to pact-broker in the consumer repo. I have added PACT_BROKER_BASE_URL and PACT_BROKER_TOKEN in the.env file, but when I run the command on the terminal to publish it, it throws an error.
```pact-broker publish --consumer-app-version 1.0.0 --broker-base-url=${PACT_BROKER_BASE_URL} --broker-token=${PACT_BROKER_TOKEN} pacts/webapp-pact-js-v3-engine-service.json```
matt.fellows
2022-09-12 10:53
The CLI is not aware of any `.env` file. You will need to properly export the shell variables
jordan.nazemi
2022-09-12 20:52
Hi, small issue with the Pactflow pact broker I've come across during bi-directional contract testing. We have a provider that has a server URL defined in the OAS, see first attached screenshots of provider contract in Pactflow.
jordan.nazemi
2022-09-12 20:52
When uploading the consumer contract using the Cypress adapter, it catches the ENTIRE path of the request including that server URL as seen in the attached screenshot.
jordan.nazemi
2022-09-12 20:53
As you can see, the consumer contract is comparing the FULL path of the request to the partial path in the provider contract (the full path being made up of that server url + the endpoint). Is there something I should change to how I'm uploading the pact on either the provider or consumer side to resolve this?
bethskurrie
2022-09-12 23:25
Best to ask in the #pactflow channel, as the Pact Broker doesn?t support bi-directional contracts.
bethskurrie
2022-09-12 23:27
@snehasingh291506 you may have seen the .env file used in the workshops. That works because the makefile is loading the .env file at the start of the task, but the pact CLI doesn?t know about that.
bethskurrie
2022-09-12 23:29
There is a feature request for this already. https://pact.canny.io/feature-requests/p/cli-for-getting-supported-version-for-specific-participant
bethskurrie
2022-09-12 23:34
it?s just because i?ve never been able to con someone in to doing the message pact UI.
matt.fellows
2022-09-13 00:12
It?s possible the server URL is not taken into consideration during the matching. We could potentially look to do this, albeit it?s possible to have multiple server URLs defined so that would have other impacts for consideration
matt.fellows
2022-09-13 00:13
I would suggest for now to pre-process your pact file to strip those paths out (or update the OAS, but I?m guessing that is less preferable).
We could potentially also allow the Cypress adapter to do that (e.g. define a base URL that is removed from the serialisation)
cgoodison
2022-09-13 00:24
yeah that is exactly what I am thinking too matt, the server urls may not be being taken into consideration
bethskurrie
2022-09-13 00:40
the endpoints are `/environments/:environment_uuid/deployed-versions/currently-deployed` and `/environments/:environment_uuid/released-versions/currently-supported`
tjones
2022-09-13 00:42
If this is using the swagger-mock-validator, I believe it just directly compares the paths :confused:
bethskurrie
2022-09-13 00:42
Oh, I understand the problem. When it?s deployed, you put an extra path at the start of the API path.
bethskurrie
2022-09-13 00:42
So the consumer contract has a contract for the deployed path, while the provider contract only knows about its pre-deployment path.
tjones
2022-09-13 00:43
That's my understanding too. I think in the Pact, the full path is there, but in the OAS, it isn't (because OAS has a "server base url" concept)
tjones
2022-09-13 00:43
> the provider contract only knows about its pre-deployment path.
I _think_ the provider contract knows `{some_base}/path`
tjones
2022-09-13 00:44
I agree. I don't like the idea of `{some_base}` because it doesn't give you deployment confidence. So, I feel like ideally it should be an input into the validation
bethskurrie
2022-09-13 00:45
I?ve only ever seen servers defined with a host, not with a path, but it makes sense that it?s a Thing.
matt.fellows
2022-09-13 00:45
Yes. The issue is the provider contract (for an OAS) can have multiple servers and each server may have a differ base URL. The results for these could be different of course so that would be another set of rules we'd need to think about
tjones
2022-09-13 00:45
It's common with an API gateway consuming a bunch of services that are defined by OAS
bethskurrie
2022-09-13 00:47
yes, definitely worth hashing it out and thinking through the implications.
matt.fellows
2022-09-13 00:47
I'll pop an item in the backlog. For now though stripping the base URL before publication is your best bet Jordan
sashaavramchik
2022-09-13 07:07
How can I contribute to pactfoundation/pact-cli? Is there only https://github.com/pact-foundation/pact_broker-client to add new features?
bethskurrie
2022-09-13 07:08
if everything you need is in the endpoints i?ve listed, it?s just a matter of adding the CLI commands to call them
bethskurrie
2022-09-13 07:08
if you?d like to raise an issue in that repo, we can discuss how it could be implemented there.
tjones
2022-09-13 07:15
:taco: for @sashaavramchik for "so we don't have this, let me contribute it" :raised_hands: Very much appreciated!
marxjo
2022-09-14 07:01
Hi @bethskurrie,
thanks for your response.
In my humble opinion adding just JWT authentication for the webhooks is
no enough.
Besides creating a GitHub app the following steps are required to
use the API using an installation token as far as I understand it.
As the token lifetime is quite restricted this needs to be done
regularly:
1.
Generate a sign a JWT token using the app's private key:
https://docs.github.com/en/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-a-github-app
This token is valid for maximum 10 minutes.
2.
Use the JWT token from step 1 and create an installation token:
https://docs.github.com/en/developers/apps/building-github-apps/authenticating-with-github-apps#authenticating-as-an-installation
```$ curl -i -X POST \
-H "Authorization: Bearer YOUR_JWT" \
-H "Accept: application/vnd.github+json" \
https://api.github.com/app/installations/:installation_id/access_tokens```
This Bearer Token is valid for 60 minutes
3.
Call the webhook/GitHub API with the Bearer Token from step 2.
Thanks
Johannes
ruben.perezg
2022-09-14 07:18
Hi :slightly_smiling_face:
Update: I'm struggling with an Authentication issue in our Travis, that it's being hard to debug. That's why I have been a bit blocked lately. But it definitely looks like the webhook triggers the expected Travis executions as you Beth said, so as soon as I get that authentication issue fixed, I will share it so it can be included in the documentation if you want :slightly_smiling_face:
matt.fellows
2022-09-14 11:59
Thanks Johannes. See also https://github.com/pactflow/roadmap/issues/45 Beth and team
ruben.perezg
2022-09-15 14:08
```{
"events": [{
"name": "contract_requiring_verification_published"
}],
"request": {
"method": "POST",
"url": "https://api.travis-ci.org/repo/<organization>%2F${pactbroker.providerName}/requests",
"headers": {
"Content-Type": "application/json",
"Travis-API-Version": "3",
"Authorization": "token TOKEN"
},
"body": {
"request": {
"message": "Triggered by changed pact for ${pactbroker.consumerName} version ${pactbroker.consumerVersionNumber}",
"branch": "\${pactbroker.providerVersionBranch}",
"sha": "\${pactbroker.providerVersionNumber}",
"config": {
"env": {
"global": [
"PACT_URL=\${pactbroker.pactUrl}"
]
}
}
}
}
}
}```
ruben.perezg
2022-09-15 14:25
also, I have created this PR: https://github.com/pact-foundation/docs.pact.io/pull/167
Not sure it helps too much, but I didn't come up with something better... Feel free to let me know if you want me to improve it
tjones
2022-09-16 03:13
If you need more users, the pactflow hosted broker might be for you. See https://pactflow.io/
senchu.pampoorickal
2022-09-18 19:16
Hi There,
I am writing the pact provider test on the application running with Spring and Junit 4. I am using the http://au.com.dius.pact.provider dependenc and came across 2 questions and it will be really appreciated anyone can guide on this
1. What I understand from the documentation is while doing provider testing we need to test against the actual server in test. And I am using a docker container hosted with application and hitting the pact provider test against the application in testing container. The situation I came across is the base url("127.0.0.1"), port (443) and protocol (https) can vary and I need this values to be passed from some environment variables in the CI pipeline. Can anyone guide on this
```@TestTarget
public final Target target = new HttpTarget("https", "127.0.0.1", 443, "api", true);```
2. I have a job in the pipeline which build the application by running the "mvn clean install" command . The provider test also runs in this scenario and as the environment is not ready it will fail the test and build will not succeed. I want to control the running of pact provider test only when invoked individually in a job for pact provider testing. In all the other cases if anyone invoke the command "mvn clean install" pact provider test cases should not run. How to handle this situation.
Thanks in advance for the help and guidance (edited)
uglyog
2022-09-18 23:21
These are JUnit and Maven questions, not really Pact ones. Junit supports ways of tagging tests, so you can exclude them based on certain conditions. I would also suggest upgrading to JUnit 5, it will help with your first question.
senchu.pampoorickal
2022-09-19 00:04
Thanks, @uglyog for the answer. The reason I need to use Junit 4 is that the current application is a heavy monolithic application and has many test cases. Migrating it to junit 5 involves lots of effort. Is there a way we can achieve Question 1 using Junit 4 @testtarget
uglyog
2022-09-19 00:08
You can run JUnit 4 and Junit 5 together, you don't have to migrate all your tests
uglyog
2022-09-19 00:10
You can try initialise the parameters using `System.getenv`, but there is no direct support for doing that
edouard.lopez
2022-09-19 10:43
Building the latest `2.104.0.0` I got this error:
``` > [linux/arm64 stage-2 2/5] RUN apk add --no-cache bash=5.1.16-r0:
#22 0.193 .buildkit_qemu_emulator: /bin/sh: Invalid ELF image for this architecture```
Does it ring a bell?
lnthai2002
2022-09-19 14:45
Thanks, i'll check with my supervisor to see if we can switch over to pactflow
purushothamv02
2022-09-19 14:53
Hi Team, I am new here and need a quick help. My Provider tests are running but the test results are not being updated in PactBroker. It shows `VERIFIED AT - never`.. Is there anything I am missing here to show the latest results.
tomknee1
2022-09-22 15:32
hello, question around pact-broker-basic-auth user and password, should it only ever be one account that all services share and use in CI ? should we or can we have different accounts for different services/teams ? (read only OR read/write) ?
david.hvilava
2022-09-26 18:50
Hi @bethskurrie. Your suggestion about using can-i-deploy looks logical. In my company we're just adopting contracting testing and haven't reached the point of using 'environments'. But do want to prevent Consumer PR from merging to 'main' without validation against Provider's 'main'.
That's why I'm curious are you planning to roll out the update to CLI related to 'can-i-merge' in the nearest future? Thank you in advance
bethskurrie
2022-09-27 00:58
You can use can-i-deploy for this purpose now, but you?ll need to state all the dependencies explicitly.
edouard.lopez
2022-09-27 09:47
Why doest pact provider verification fails the test with `initializationError` and `http://au.com.dius.pact.provider.junitsupport.loader.NoPactsFoundException: No Pact files were found to verify` when there are no contracts available? I was expecting a non-blocking behaviour in this kind of case.
To it's simplest form, my consumer version selectors is:
``` @PactBrokerConsumerVersionSelectors
public static SelectorBuilder consumerVersionSelectors() {
return new SelectorBuilder()
.mainBranch();
// .branch("abmm-5295"); // work fine
}```
bethskurrie
2022-09-28 01:29
@tomknee1 the CI should have the write user, and the devs should use the read only user.
edouard.lopez
2022-09-28 13:30
Thanks, saw you recommendation on https://pact-foundation.slack.com/archives/C9UN99H24/p1664328119520049?thread_ts=1662113042.797179&cid=C9UN99H24
edouard.lopez
2022-09-29 12:54
Thanks @yousafn
The Go issue is closed? oh that's just the feature request issue, I was a bit confused as some languages are not supported yet
edouard.lopez
2022-09-29 12:56
Maybe replace ~_issue_~ by _feedback_ for the language that are supported
edouard.lopez
2022-09-29 12:58
What are your recommendation for the `providerBranch` settings when working on merge request pipeline? Should it be the branch name of that MR?
tjones
2022-09-29 13:43
Ideally (irrespective of whether you?re using pact) branches are short lived, so it probably won?t make much difference. If you expect it to make a difference (eg for high numbers of merges over a few days) then probably I would not do pact on non-MR branch pipelines
yousafn
2022-10-04 19:41
Feedback is probably best raised via new issues, it was for traceability from the docs to the originating feature request or pull request, some are complete, some are outstanding. The version number over the TBC shows support is available
Will be reworking the support guide to show support for the consumer version selectors and ensure there is relevant documentation in each language implementation to support so will take feedback on board
marek.czerwinski
2022-10-05 22:47
Hello, team!
I'm implementing contract testing in my company and I have one question.
Why generally pact URL is used instead of pact consumer selectors
for builds triggered by a 'contract content changed' webhook?
Is it better?
For me, both approaches seem to work.
Reference:
https://github.com/pactflow/example-provider/blob/master/src/product/product.pact.test.js#L32
bethskurrie
2022-10-06 00:43
Because the provider build won?t know the name of the new branch that triggered the provider build
bethskurrie
2022-10-06 00:43
Also, there is some information in the URL of the pact that helps all the verification results match up to the consumer versions properly.
bethskurrie
2022-10-06 00:44
this is especially important when you have multiple builds running at the same time and they start inverleaving.
thanuxxxx
2022-10-06 21:35
What is the different between `pactbroker.providerBranch` and `pactbroker.providerTags`?
bethskurrie
2022-10-06 22:15
You don?t pass in those variables in the webhook -the webhook fills the variables in for you from values you have previously provided.
bethskurrie
2022-10-06 22:16
Here are the docs for branches and tags https://docs.pact.io/pact_broker/branches
https://docs.pact.io/pact_broker/tags
bethskurrie
2022-10-06 22:17
If you?re using one of the libraries that supports branches, you should be populating the branch with the git branch. Guide here: https://docs.pact.io/provider/recommended_configuration
thanuxxxx
2022-10-06 22:34
In that case what is the value that gets assigned to it. PR branch or Master branch
yousafn
2022-10-06 22:53
It depends on the webhook used, there is a new one, which supercedes the previous and checks against the latest on your mainBranch and any deployedOrReleased
This table shows the difference in coverage
https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event
yousafn
2022-10-06 22:55
Tags traditionally represented pseudo-branches in 99% of peoples workflows, whilst also representing environments.
so branches became a first-class property of the Pact Broker, along with a new concept of environments, and the notion of recording deployments (or releases) to them.
Tags whilst still supported, are being phased out from our recommended configuration, and you should see some docs changes over the next couple of weeks to support this
bethskurrie
2022-10-06 22:57
> We use providersbranch and providertag for pending pact verification right
The branch name is used for lots of things.
bethskurrie
2022-10-06 22:57
Calculating pending, working out what the WIP pacts are, triggering the right builds for the webhooks.
thanuxxxx
2022-10-07 02:32
So having a stages like this is enough to cover `contract_requiring_verification_published` and `pending` and `WIP pact?`
Pact verification build template:
``` stage('Contract Tests: Provider Verify') {
steps {
sh """mvn test -Pcontract-tests-provider-verify \
-Dpact.verifier.publishResults=true \
-Dpact.provider.version=${GIT_COMMIT} \
-Dpact.provider.branch=${BRANCH_NAME} \
-Dpact.filter.pacturl=${params.pactUrl}"""
}
}```
In main build template:
``` stage('Contract Tests: Provider Verify') {
when {
expression { PACT_PROVIDER == true }
}
steps {
sh """mvn test -Pcontract-tests-provider-verify \
-Dpact.verifier.publishResults=true \
-Dpact.provider.version=${GIT_COMMIT} \
-Dpact.provider.branch=${GIT_BRANCH} \
-Dpactbroker.providerBranch=${GIT_BRANCH}\
-Dpact.broker.consumerversionselectors.rawjson=[{"mainBranch":true},{"deployed":true}]"""
}
}```
bethskurrie
2022-10-07 02:34
Not sure why you need these both:
```Dpact.provider.branch=${GIT_BRANCH}
Dpactbroker.providerBranch=${GIT_BRANCH}```
bethskurrie
2022-10-07 02:34
I have never used pact jvm, so you?d be best to check in the pact-jvm channel.
thanuxxxx
2022-10-07 03:10
```Dpact.provider.branch=${GIT_BRANCH}
Dpactbroker.providerBranch=${GIT_BRANCH}```
Are they the same?
thanuxxxx
2022-10-07 03:11
From my understanding,
```Dpact.provider.branch=${GIT_BRANCH} --> this is for registering provider's branch name
Dpactbroker.providerBranch=${GIT_BRANCH} --> this is for enabling pending pact??```
bethskurrie
2022-10-07 03:11
Please ask in the #pact-jvm channel. I cannot help you. I have never used pact-jvm.
marek.czerwinski
2022-10-11 12:26
Thanks for the response @bethskurrie it was really helpful :slightly_smiling_face:
mitchell.l.cooper
2022-10-11 13:48
Hi all. New to pact-broker; working on setting it up for my team in AWS (Fargate). Does the https://hub.docker.com/r/pactfoundation/pact-broker/ have a web UI for end users and if so, does it require a login? I have not been able to really find definitive documentation on this. Thanks!
And if there's a UI and requires a login, does it support SAML?
yousafn
2022-10-11 14:01
Hey,
Yes to a UI,
See https://docs.pact.io/pact_broker#screenshots
You can use auth, or choose not too, see the section titled `Using basic auth` in the link you provided above :+1:
It should be this README for the `pactfoundation/pact-broker` image :point_down:
https://docs.pact.io/pact_broker/docker_images/pactfoundation#authentication
The readme linked is for the ``dius/pact-broker` but the mechanism is the same
yousafn
2022-10-11 14:09
I would advise spinning up a copy of the image locally and having a look around at the UI first, and basic auth, before trying to run in AWS :slightly_smiling_face:
mitchell.l.cooper
2022-10-11 14:10
If I ran it in AWS I would have to connect my VPC to my corp network and only expose the pact-broker internally
yousafn
2022-10-11 14:15
We have a hosted Pact Broker (Pactflow) which has the option to support SAML which may help in organisational adoption. There are options with the open-source broker, but involve rolling your own auth mechanism dependant on your organisations security setup
https://docs.pactflow.io/docs/user-interface/settings/authentication/#saml-support
May be worth having a peek whilst you are exploring options :+1:
mitchell.l.cooper
2022-10-11 14:16
Yes - we did see that - we were investigating the OSS version, but we saw that Pactflow does offer it :slightly_smiling_face:
olsen.lee.r
2022-10-11 18:28
Wondering if this is expected behavior or if we are doing something wrong.
1. Service A is deployed
2. Client B creates Pact via test
3. Client B goes through build pipeline
a. pipeline calls verifier
b. verifier creates matrix record for client B / service A
c. verifier fails because service A gets pact but pact check fails
4. Client B build fails and does not deploy due to failing pact check
5. Service A is not deployable unless it satisfies the contract of client B even though it's not deployed
If Client B had successfully deployed in the past so there is an older version of the contract in a verified state, then service A can still deploy even though it doesn't satisfy the new version. I'd expect this behavior even in the scenario above.
olsen.lee.r
2022-10-13 04:25
In case anyone sees this in the future, I believe this is the answer to my question. I'll report back definitively after we validate that.
https://docs.pact.io/pact_broker/advanced_topics/pending_pacts
olsen.lee.r
2022-10-13 05:20
I looked at my co-workers repo and he is setting enable pending to true. So I'm back to wondering why this situation fails.
olsen.lee.r
2022-10-13 05:24
Ah...the https://github.com/pact-foundation/pact_broker/issues/576 that was created is likely why. He is setting a branch in the config.
gustavs.slutins
2022-10-13 11:28
Hey, we are getting a strange message when trying to upload the consumer pact. This seems to happen when master has the same hash as a release branch.
[ERROR] Got an invalid notices value from the Pact Broker: Expected an array, got Null
Failed - Request to path 'https://*redacted*/contracts/publish' failed with response 500
{"error":{"message":"source sequence is illegal/malformed utf-8","reference":"ysJCZaBRKy"}}
bethskurrie
2022-10-14 04:00
@olsen.lee.r this will be out soon. for the time being, set a tag as well
gustavs.slutins
2022-10-14 06:27
is this what it would look like?
```"includes": [
"\u493B\u62B5\uC318\u6BE1"
],```
gustavs.slutins
2022-10-14 08:47
Resolved the issue. So basically, the matchQuery regexp was generating a random example that contained some non-UTF-8 characters.
ksawery.karwacki
2022-10-18 13:16
I know that pact is best suited for Continuous Deployment where each service deployed independent. But is there any flow for deploying services as part of batch? E.g. I have application that contains five services (A, B, C, D, E). I want to upgrade two services (A,B). How to run "Can I deploy" so I can verify that set of versions is compatible with specific env? My best idea is to tag new versions of A & B with tag (as A & B may have contract) containing my env name and check "Can I deploy" for each of them if any of them fails remove tags from their version and fail promotion, otherwise proceed. Any other ideas?
Before anyone asks: We have pretty long security procedure before deployment so it is much easier to promote periodically as batch rather than delay each service before previous finish security checks.
jackbwheatley
2022-10-18 15:19
would anyone be able to share their `Dockerfile` for running `pactfoundation/pact-broker` in Kubernetes? I?m a massive noob at this stuff
matt.fellows
2022-10-18 23:08
The dockerfile probably doesn?t need changing. It will mostly be in the helm charts (assuming you go that path)
matt.fellows
2022-10-18 23:09
Somebody has created an example here: https://github.com/hmcts/chart-pact-broker
bethskurrie
2022-10-19 02:42
Assuming you have something like a mono-repo:
can-i-deploy --pacticipant SubApp1 --version 1 --pacticipant SubApp2 --version 1 --pacticipant SubApp3 --version 1 --to-environment prod
bethskurrie
2022-10-19 02:46
make sure you give hardcoded examples each time, or it will look like your pact has changed every time you publish, and you?ll be running a lot of unnecessary verification builds.
ksawery.karwacki
2022-10-19 09:22
@bethskurrie if I have contract between SubApp1 and SubApp2 it will use versions provided as parameter to verify rather than already deployed?
I don't have strictly monorepo but my upgrade job have list of services with versions (all of them are versioned independently) so I can build call like the above (just each SubApp will have it's own different version rather than common version 1)
ankit.jain
2022-10-19 10:43
Hi Guys,
I was following the below guide:
https://github.com/pact-foundation/pact-workshop-js/tree/step11#step-11---using-a-pact-broker
But got stuck in npm run pact:publish step.
```~/Contract-Testing-POC/pact-consumer:~ $ npm run pact:publish
> pact-consumer@1.0.0 pact:publish
> pact-broker publish ./pacts --consumer-app-version='1.0.0' --auto-detect-version-properties --broker-base-url=http://localhost:8000 --broker-username pact_workshop --broker-password pact_workshop
node:internal/modules/cjs/loader:988
throw err;
^
Error: Cannot find module '../src/pact-standalone'
Require stack:
- /Users/ankitjain/Contract-Testing-POC/pact-consumer/node_modules/.bin/pact-broker
at Module._resolveFilename (node:internal/modules/cjs/loader:985:15)
at Module._load (node:internal/modules/cjs/loader:833:27)
at Module.require (node:internal/modules/cjs/loader:1051:19)
at require (node:internal/modules/cjs/helpers:103:18)
at Object.<anonymous> (/Users/ankitjain/Contract-Testing-POC/pact-consumer/node_modules/.bin/pact-broker:7:43)
at Module._compile (node:internal/modules/cjs/loader:1149:14)
at Module._extensions..js (node:internal/modules/cjs/loader:1203:10)
at Module.load (node:internal/modules/cjs/loader:1027:32)
at Module._load (node:internal/modules/cjs/loader:868:12)
at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12) {
code: 'MODULE_NOT_FOUND',
requireStack: [
'/Users/ankitjain/Contract-Testing-POC/pact-consumer/node_modules/.bin/pact-broker'
]
}
Node.js v18.10.0```
ankit.jain
2022-10-19 10:48
For Pact broker installation, i run the command docker-compose up which set up postgres and pact-broker
yousafn
2022-10-19 11:08
can you show the output of `consumer/node_modules/.bin` there should be a `pact-broker` stub
```./node_modules/.bin/pact-broker```
If it is there it probably hasn't downloaded the standalone binaries, are you on a corp proxy by chance?
Were there any errors in the console when running your npm install command?
Some other ways you can get at the CLI tool :+1:
https://github.com/pact-foundation/pact_broker-client#installation
ankit.jain
2022-10-19 11:41
There is pact-broker inside .bin folder, but as you can see, pact-broker file requires pact-standalone module which is not present. In fact whole src folder is not present.
ankit.jain
2022-10-19 11:43
We can run broker on localhost:8000 via docker-compose up command but to make pact-broker command work, do we have to install pact-broker cli separately from https://github.com/pact-foundation/pact_broker-client#installation ??
yousafn
2022-10-19 11:45
it pulls them down as a post install script, there will probably errors in your npm install log showing they can't be installed.
This is from the old pact-node readme, I can't seem to find it in the pact-js-core
https://www.npmjs.com/package/@pact-foundation/pact-node#pact-download-location
ankit.jain
2022-10-19 11:47
Sure @yousafn, will try specifying download location. When I am trying installing the cli, it looks like it is not supported in Mac M1 OS:
yousafn
2022-10-19 11:49
I run on an m1 mac and it's grand, that message in your terminal output is because it wasn't build on an arm platform, as we don't have build runners for them, they will work but take a performance hit
yousafn
2022-10-19 11:50
that is running, you can call the pact-broker command, but will need to mount your volume so the container has access to your pacts, and any env vars. instructions in the pact cli readme
https://hub.docker.com/r/pactfoundation/pact-cli
you can also install as a ruby gem
yousafn
2022-10-19 11:50
Best place I currently have it documented is here for the different ways is here
https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas#installation
I need to pull this onto the http://docs.pact.io site too
ankit.jain
2022-10-19 12:07
Hi @yousafn its a bad day for me i guess, Tried both methods, the cli is not available. Can you please tell what am i doing wrong
matt.fellows
2022-10-19 12:09
oh sorry, I didn?t see the above context. Looks like that thread is taknig care of this
matt.fellows
2022-10-19 12:09
Usually, I?d recommend https://docs.pact.io/implementation_guides/cli. But in the case of Pact JS, that gets bundled in
yousafn
2022-10-19 12:11
if you are trying to run the docker image, you pass your command in via docker run
```docker run --rm \
-w ${PWD} \
-v ${PWD}:${PWD} \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_USERNAME \
-e PACT_BROKER_PASSWORD \
pactfoundation/pact-cli:latest \
publish \
${PWD}/example/pacts \
--consumer-app-version fake-git-sha-for-demo-$(date +%s) \
--tag-with-git-branch```
it won't make it available on your command line.
To do that you need to install the gem, or download the standalone.
yousafn
2022-10-19 12:15
it ran the pactflow command because it has downloaded and extracted the standalone to `./pact/bin/`
so `./pact/bin/pact-broker` will work
yousafn
2022-10-19 12:15
its not automagically available on your system path, you would need to set that if required
ankit.jain
2022-10-19 12:39
Broker is running on 8000 port on localhost (via docker-compose up), same i have provided in broker base url variable, why it is showing this error.
bethskurrie
2022-10-19 23:04
I?d recommend doing this one first https://docs.pactflow.io/docs/workshops/ci-cd
bethskurrie
2022-10-19 23:05
> if I have contract between SubApp1 and SubApp2 it will use versions provided as parameter to verify rather than already deployed?
Yes
bethskurrie
2022-10-20 05:35
@olsen.lee.r update to the latest version and let me know if you?re still having issues
dyptorden
2022-10-20 10:37
Hi guys!
I am facing a problem publishing results to the broker. To give some context:
1. Broker is deployed in AWS (dockers with compose)
2. Jenkins is hosted in the company domain
3. Two jobs are set in Jenkins:
a. one for the consumer
b. one for the provider
4. jenkins is added in the broker's whitelist
```2022-10-20 10:02:31.347940 I [7:4360] pact-broker -- webhook_host_whitelist=["http://jenkins.secretcompanyname.com", "http://github.com", "http://secretcompanyname.slack.com"] source={:type=>:env, :key=>"PACT_BROKER_WEBHOOK_HOST_WHITELIST"}```
*Issue:*
? Consumer:
? if I run it from Local machine (IntelliJ) -> Contract gets published to the broker :white_check_mark:
? If I run it from Jenkins -> Contract also gets published to the broker :white_check_mark:
? Provider
? if I run it from Local machine (IntelliJ) -> Result gets published to the broker :white_check_mark:
? If I run it from Jenkins -> Result does NOT get published to the broker as the connection can't be established :x:
```org.apache.http.conn.ConnectTimeoutException: Connect to my.secret.ip:9292 [/my.secret.ip] failed: Connection timed out
at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:157)```
Any ideas as why only the provider can't connect to the Broker from Jenkins but the consumer can (from the same Jenkins) ?
tanyaryzhova93
2022-10-24 18:47
Hi All! Could you please help me with contract publishing to a Pact Broker?
I was able to run Pact Broker locally, I used docker image with my local DB, and now I can see UI in my browser. I followed https://github.com/pact-foundation/pact-broker-docker#getting-started. And I don?t use pactflow, just pact broker.
Now I?d like to try to publish a contract to my Pact Broker and I am confused here, what I should do next? I see that I can use a CLI client with https://hub.docker.com/r/pactfoundation/pact-cli. But I don?t understand all parameters here :disappointed: and from what directory I should run the command.
For example, I am trying to run the following command from my home directory:
```docker run --rm \
-e PACT_BROKER_BASE_URL=http://localhost:9292 \
pactfoundation/pact-cli:latest \
publish \
/Users/tatiana/projects/project_name/contract-tests/pacts \
--consumer-app-version fake-git-sha-for-demo-$(date +%s)```
and I am getting the error:
```Specified pact file '/Users/tatiana/projects/project_name/contract-tests/pacts' does not exist. This sometimes indicates one of the arguments has been specified with the wrong name and has been incorrectly identified as a file path.```
So, my questions:
1. Where should I run the docker command from?
2. `PACT_BROKER_USERNAME` and `PACT_BROKER_PASSWORD` are mandatory or they can be ignored? I didn?t set up these env variables when I was running `pactfoundation/pact-broker` image.
Please point a right direction for me :pray:
tanyaryzhova93
2022-10-24 19:05
Also, I see that I can use pact-broker such as
```pact-broker publish /path/to/pacts/consumer-provider.json --consumer-app-version 1.0.0 --branch main --broker-base-url https://test.pactflow.io --broker-token SomeToken```
But in this case I can?t get how to run/setup `pact-broker`, I tried just to run docker image as
`docker run pactfoundation/pact-cli` but it didn?t work
yousafn
2022-10-24 19:46
You need to volume mount your drive into the docker container as per the instructions in the linked docker readme.
yousafn
2022-10-27 20:37
Your docker cli run via docker run cannot talk to the host machine, so you need to set ?network=host
https://github.com/YOU54F/path-to-pact-nirvana/blob/45550fa9ddb2c56bfa9b5d09c9193d06f99a9ec8/Step_04_PublishYourFirstPactLocally/Makefile#L14
If you are running on a Mac or windows machine, the broker endpoint will be different
https://github.com/YOU54F/path-to-pact-nirvana/blob/45550fa9ddb2c56bfa9b5d09c9193d06f99a9ec8/Step_04_PublishYourFirstPactLocally/Makefile#L37
yousafn
2022-10-27 20:41
If trying to connect to a local broker, you need to tell your docker run command to connect to the host network, and volume mount the drive where your pacts reside
https://github.com/YOU54F/path-to-pact-nirvana/blob/45550fa9ddb2c56bfa9b5d09c9193d06f99a9ec8/Step_04_PublishYourFirstPactLocally/Makefile#L14
Example here which publishes to a local broker stood up with docker compose.
The endpoint needs to changed from localhost if on a Mac/windows machine, you can see it at the bottom of the file
tanyaryzhova93
2022-10-27 20:57
Thank you very much. I was able to publish and verify the contract locally with pact broker :+1:
mattandaey
2022-11-02 18:07
Hi Everyone,
I was trying to find out if there is an open issue to patch OpenSSL vulnerability. Particularly the Pact-Broker Dockerfile using Alpine 3.15 below. Please let me know if this is not the right forum to post this question and direct me to the right direction.
Thank you,
Matthew
https://github.com/pact-foundation/pact_broker/blob/88b7df42ea593c20315d06a0206795ccaaf752a3/Dockerfile#L1
docker image vulnerability page: https://dso.docker.com/cve/DSA-2022-0001
CVE https://dso.docker.com/cve/CVE-2022-3602
yousafn
2022-11-02 18:18
Hey,
have you checked the repo? that is where issues would be tend to be reported for visibility and action.
You can also fork the repository and provide a patch easily once tested.
mattandaey
2022-11-02 18:27
Gotcha. Yes I was looking through the repo->issues and I didn?t see any issue related to the OpenSSL vulnerability.
mattandaey
2022-11-02 18:28
Would the best thing to do is to report the issue in the repo and try forking it to see if I can patch it?
bethskurrie
2022-11-03 02:22
I can see that here was a push to `2.7.6-alpine3.15` 8 days ago, so it?s possible that it?s been fixed in the base image already.
bethskurrie
2022-11-03 02:22
I?ve kicked off the release workflow - that may just be all we need to do.
bethskurrie
2022-11-03 02:36
https://hub.docker.com/layers/pactfoundation/pact-broker/2.105.0.1/images/sha256-37ddf51838eabb5ca4b435e91d002737b7dca98c5bf7c9190848a7f173a81938?context=repo is out now. It passed trivy scan, so I assume it has the ssl fix in it
mattandaey
2022-11-03 21:26
mattandaey
2022-11-03 21:28
And I pull in the latest image https://hub.docker.com/layers/pactfoundation/pact-broker/2.105.0.1/images/sha256-37ddf51838eabb5ca4b435e91d002737b7dca98c5bf7c9190848a7f173a81938?context=repo and see that alpine version was 3.16.2 so I think it?s fixed.
`/ # cat /etc/os-release`
`NAME="Alpine Linux"`
`ID=alpine`
`VERSION_ID=3.16.2`
`PRETTY_NAME="Alpine Linux v3.16"`
yousafn
2022-11-04 13:24
Thanks for checking this @mattandaey
I noted the pact-broker-docker repo doesn't have a security readme. https://github.com/pact-foundation/pact-broker-docker
do you think that would have helped you for guidance in how go about reporting, and potentially resolving
https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository
> Would the best thing to do is to report the issue in the repo and try forking it to see if I can patch it?
Also to echo @tjones encouragement, this is the literally the dream for any open source project/maintainers
mattandaey
2022-11-04 17:12
Yes, I think that would help in guiding me how to approach this. I did the usual search in the repo and issues to find anything related to the vulnerability and also a lot googling. I just didn?t know what the next after that so I post the question here.
james.perepiczka
2022-11-07 11:31
Hi all, I?ve been using an older version of the Pact broker for months and noticed a difference in the sort ordering that I wanted to query. When using the older version and clicking the grid icon next to a consumer/provider, it would give me a list of contracts ordered by publish date desc. I would get to see all the contracts we had published on different branches. Now on the later version I get all of the contracts that have been published for the latest version only. Is there a reason for this? It?s a bit frustrating that I have to keep clearing the version number filter every time when I havent selected a specific contract number
tomasz.sosnowski
2022-11-07 14:10
Hi Everyone, I'm facing issue with the broker data purge feature, trying to apply given version selector:
`"[{\"max_age\": 15}, {\"max_age\": 30, \"branch\": \"main\"}]"`
but as a result in broker logs I got: `ERROR: each UNION query must have the same number of columns.`
I used tags before and this selector worked fine, it looks like it stopped after changing to branches, any ideas what to do with it?
tomasz.sosnowski
2022-11-07 14:10
query
```pack_broker.public> SELECT * FROM "versions" WHERE ("id" NOT IN (SELECT * FROM (SELECT * FROM (SELECT * FROM (SELECT "id" FROM "versions" WHERE ("versions"."created_at" >= '2022-10-23') UNION (SELECT "id", "branch_name" FROM "versions" INNER JOIN (SELECT "version_id", "branch_name" FROM "branch_versions" WHERE ("branch_id" IN (SELECT "id" FROM "branches" WHERE ("name" = 'main')))) AS "bv" ON ("versions"."id" = "bv"."version_id") WHERE ("versions"."created_at" >= '2022-10-08'))) AS "t1" UNION (SELECT "id" FROM "versions" WHERE ("id" IN (SELECT "version_id" FROM "deployed_versions" WHERE ("id" IN (SELECT "deployed_version_id" FROM "currently_deployed_version_ids")))))) AS "t1" UNION (SELECT "id" FROM "versions" WHERE ("id" IN (SELECT "version_id" FROM "released_versions" WHERE ("support_ended_at" IS NULL))))) AS "t1")) ORDER BY "id" ASC LIMIT 50```
error:
```[2022-11-07 14:32:19] [42601] ERROR: each UNION query must have the same number of columns
[2022-11-07 14:32:19] Position: 181```
bethskurrie
2022-11-07 22:26
@tomasz.sosnowski can you raise an issue in the pact broker codebase with a reproducible example please?
bethskurrie
2022-11-07 22:28
That was meant to be a usability enhancement, but I can see it wasn?t for you! Is it just from the main menu that you?d like this behaviour?
james.perepiczka
2022-11-08 16:04
I have a question about the webhooks, if can-i-deploy runs and triggers a pipeline webhook due to a missing verification and the provider version to validate is not the latest version, how will the provider know which version of itself to validate against? The scenario being that if you had a dev (v3), preprod (v2), prod (v1) environment and a consuming service was checking if it can deploy to preprod (after a successful dev (v3) validation and it did not have a verification against v2) then how would the payload to the provider pipeline be aware of the version it needed to use to validate with?
bethskurrie
2022-11-08 22:23
The provider version is passed in as a webhook parameter, which you will then need to map to the correct field in the request that triggers the build in your CI system.
bethskurrie
2022-11-08 22:23
james.perepiczka
2022-11-14 14:05
When the documentation mentions labels such as `${pactbroker.consumerLabels}` , what is it referring to? There are details about tags but can?t see what the usecase is?
james.perepiczka
2022-11-14 14:32
Also is there anything to pass the environment in the webhook? I?ve got logic for the provider to use environments but it doesn?t seem like I can pass environment in the webhook
bethskurrie
2022-11-14 23:28
There?s a property for the version description (it says whether it?s from a branch, and/or an environment) but there?s no specific field for environments. There may be multiple.
bethskurrie
2022-11-14 23:28
The labels is a little known feature where you can apply string labels to a pacticipant for the purposes of metadata or grouping.
bethskurrie
2022-11-14 23:29
I?ve made an issue for this on our internal jira so it gets done as part of the commercial work.
2022-11-14 23:44
This message was deleted.
kellie.persson
2022-11-14 23:50
I am using ruby. I plan on going through the pact-broker so I was unsure where to post. Will move it over there.
robert.strehli
2022-11-15 13:21
Hi, I'm not sure if this is the right channel. But I have an issue with two pacts that always trigger the "Contract Content Changed" event, even the contract didn't change. If I check the most recent changes on the pact broker for that pact.
I got as response header `200 parseerror`
and in the response body there is the line that something changed, but underneath it's just empty lines
```The following changes were made about 2 hours ago (Tue 15 Nov 2022, 11:15am +00:00)```
yousafn
2022-11-15 13:35
are the pacts being created with non-deterministic data, a timestamp perhaps? can you provide the content of the old and new pact, that is causing the event trigger.
Where are these pacts being generated? In CI?
> I got as response header `200 parseerror`
> and in the response body there is the line that something changed, but underneath it's just empty lines
Where are seeing this, directly in the broker?
robert.strehli
2022-11-15 14:28
There a no non-deterministic data used. I can't share the content and the pact is also pretty big.
Yes the pact is generated in CI.
> Where are seeing this, directly in the broker?
Yeah, I'm calling the *`pb:diff-previous-distinct`* in the HAL Browser and I see that. It's the same if I call the api over e.g. postman
Anyway I'm trying to reproduce this locally, but I wonder why there no changes shown on the pact broker or if I can check somewhere else
robert.strehli
2022-11-15 15:05
I just compared now the pacts on the pact broker and I just can see that the interaction ids are sometimes differing. That can't be the problem right?
```"interactions": [
{
"_id": "2367036c61b56ea3a005eec90da7b26be755928b",
"description": "GET some request",```
robert.strehli
2022-11-15 15:52
Ok after local testing I found the problem. There are matching rules sometimes added and than again removed from the pact. Therefore the pact really changed
```[2022-11-15 14:04:20.344 +0000] DEBUG (609 on runner-19-concurrent-0): pact-node@10.17.6: WARN: Ignoring unsupported matching rules {"match"=>"type"} for path $['body']['data']['detail']['items'][*]@['id']```
bethskurrie
2022-11-22 22:26
Thanks to the wonderful @chrisjburnscg there is now a Pact Broker Helm Chart available for use in the Pact Foundation org. Go nuts people! https://github.com/pact-foundation/pact-broker-chart
werner.lauterfeld
2022-11-23 13:38
Hi,
I recently read that it is advised to change from tags to branches & deployed/released.
Regarding Pact Nirvana I wonder what impact it has.
I assume we now use the branch to publish pacts or validations on feature branches and mark the environment with the record-feature after successful deployment.
Does it still hold true that we publish pacts only on PR validation and once they passed the verification and can-i-deploy (to environments) check we merge and instead of tagging main we set the stable branch (e.g. main) on the pact that was published during PR build?
yousafn
2022-11-23 14:00
Correct,
depending on your PR merge setup, you may publish pacts from the main branch build as well, that would have a new version number but the same content, and would be pre-verified from the PR branch. (assuming the provider has verified the changed content pact on the feature branch, by way of webhook, or using WIP progress pacts on the providers regular CI build)
Once is it deployed into an environment, you would record that version as deployed to x environment.
werner.lauterfeld
2022-11-23 14:04
Hey Yousaf, thanks a lot :+1: - that answers a second question I had as well.
One followup regarding the "pending-pact"-feature. I read that it is used in conjunction with tags. Is there a way to use it with maven JVM-plugin and branches?
A colleague of mine pointed out an example where a change in a Consumer contract e.g. name of interaction state would cause the provider to need to change it and this would be a backwards incompatible change. We figured from reading the docs that a pending pact might help us here - however we are unsure on how to use it without tags.
yousafn
2022-11-23 14:12
pending pacts should work with branches without anything, bar adding enable pending into your provider lang.
let me find some doccos
yousafn
2022-11-23 14:14
I've got some pending updates which should provide more clairity
https://github.com/pact-foundation/docs.pact.io/pull/178
which updates the pending pacts essentially replacing tags with branches. (tags were used as psuedo branches before)
https://deploy-preview-178--docs-pact-io.netlify.app/pact_broker/advanced_topics/pending_pacts
yousafn
2022-11-23 14:18
Have been waiting for reviews from the team before putting these live,
> name of interaction state would cause the provider to need to change it and this would be a backwards incompatible change
changing interaction state yeah will cause issues on provider side if they are looking for that, we could do better at being able to make those states more visible to both parties, so its easier to sync up or grok for providers with multiple consumers. Not sure of the right solution there but think it is a problem
werner.lauterfeld
2022-11-23 14:18
Much appreciated Yousaf :slightly_smiling_face: Thanks a lot!
Guess you are making my day today!
yousafn
2022-11-23 14:19
Awww well if you can test it out and be my guinea pig, it would be much appreciated
jpullifrone
2022-11-23 16:33
Am I use the --ignore option correctly? I want to ignore an existing pacticipant but it still verifies against it. `can-i-deploy --pacticipant $(pactClientGatewayConsumerName) --version $(Build.SourceVersion) --ignore ClientSpendAuthority --broker-base-url $(pact-broker-url) --broker-token $(pact-publish-token) --to=prod`
bethskurrie
2022-11-24 00:15
Also, is this a bi-directional contract? (Pact/OAS) Ignore is not yet supported for that query.
bethskurrie
2022-11-24 00:23
Have you deleted some contracts since raising the issue? I can?t reproduce your error. I get a different one, but not the one you?re getting.
bethskurrie
2022-11-24 00:25
I need to know the exact can-i-deploy query you?re running, and that wasn?t included in the ticket.
bethskurrie
2022-11-24 05:29
Ok, I managed to reverse engineer the query from your screenshot and I?ve fixed the bug. It?s being deployed as we speak.
bethskurrie
2022-11-24 05:30
There was a recent performance optimisation that introduced a bug. Sorry about that.
werner.lauterfeld
2022-11-24 11:28
we are having a look at pending pacts and I wonder:
Pact-Nirvana states that during PR-validation we would verify against the stable branch of the Consumer and also check with the can-i-deploy whether we are still compatible to production as versions between stable branch and production might drift with time.
My question to the pending pacts:
Do we still need the can-i-deploy step or is this actually incorporated in the verification when using pending pact as suggested in your documentation where we use the selectors mainBranch: true and isDeployedOrReleased: true?
Right now I would assume if we run the can-i-deploy still it would fail.
yousafn
2022-11-24 11:36
the selectors pick pacts to verify and the provider build publishes results.
you still want the can-i-deploy check to check the application, and specifically the application version, is compatible to be deployed into an environment, which will query the results performed by the provider verification
werner.lauterfeld
2022-11-24 11:43
Ok, then I got it wrong. Thanks for clarification :slightly_smiling_face:
yousafn
2022-11-24 11:45
I think I am following though, if a provider was to deploy that version of code, directly after doing a provider verification on their main build, they have verified all their pacts, the verification task will only fail if the provider made a regression (as enable pending is on)
as there is a usually a delay even small in deploying services after running the verification build, we always advise running can-i-deploy directly before your deploy task, and record-deployment after.
These might be different pipelines so best advising always use can-i-deploy :slightly_smiling_face:
werner.lauterfeld
2022-11-24 16:27
Hey Yousaf,
sorry for bothering again. The following scenario:
Consumer is changing an already existing PACT and changes the "given"-scenario on a feature branch. This would trigger provider verification on its stable version (we do not use web hooks) against the feature/branch and verification would fail.
Now we look at the provider - in order to comply with the change a feature branch would be opened and the state would be renamed according to consumer requirements.
This would mean we have a change that is no longer backwards compatible with consumer versions being on the stable branch e.g. master or the deployed version in production, but only the one on the feature branch of said consumer.
In our case we would have a valid verification for both versions consumer and provider that are deployed in prod, we would have a failed verification of the feature branch of the consumer and the stable branch of the provider and we would have a successful verification of the feature of the consumer and the provider.
Now this is where my question from earlier comes in: In the PR of the provider we would besides the verification also check whether we can deploy to production. In our case however, we do not have an entry in the matrix that would successfully verify production version of consumer to the new changed provider as the contract of production version and the verification (state was renamed) are no longer compatible and the PR would be blocked.
Likewise the consumer can not merge his PR as the provider can not go ahead.
From my understanding the pending-pact feature would allow to have the verification exit with a status code 0 and not fail the PR, however the can-i-deploy check would still block it?
Now I wonder, did I get something wrong with pending pacts, is this scenario likely and are there ways around it?
werner.lauterfeld
2022-11-24 17:39
Regarding your documentation that you linked earlier - we played the guinea pig and we were able to introduce a pending pact that would not break the verification step of the provider of our pipeline (exit code 0), but mark the run as failed in the pact broker.
chrisjburnscg
2022-11-27 17:11
@bethskurrie Hi, ive noticed I'm unable to merge things without having approvals. not sure if this is because of an overarching org policy. i dont think im able to change it on the repo level either
https://github.com/pact-foundation/pact-broker-chart/pull/16
tomknee1
2022-11-28 14:51
Hello :wave: just sharing a feature request I have raised as was forced to add legacy tagging as a workaround to get what i need (provider version number in a specific environment) https://pact.canny.io/feature-requests/p/get-latest-provider-version-for-a-specific-environment
sanmicad
2022-11-28 18:05
Hello. I would appreciate some help with the errors below. I am new to pact and I am trying to publish my consumer test pact to the broker but `win32-1.89.02-rc1\pact\bin\pact-broker.bat` is missing from `node_modules\@pact-foundation\pact-node\standalone\` . I am using pact-node -v `^10.17.6`
```personal-media@0.1.0 test:publish
node publish.js
[2022-11-28 17:55:35.334 +0000] INFO (13664 on DESKTOP-1H0P31U): pact-node@10.17.6: Publishing Pacts to Broker
[2022-11-28 17:55:35.336 +0000] INFO (13664 on DESKTOP-1H0P31U): pact-node@10.17.6: Publishing pacts to broker at: https://cloudmargin.pactflow.io
[2022-11-28 17:55:35.368 +0000] ERROR (13664 on DESKTOP-1H0P31U): pact-node@10.17.6: spawn C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\@pact-foundation\pact-node\standalone\win32-1.89.02-rc1\pact\bin\pact-broker.bat ENOENT
Error: spawn C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\@pact-foundation\pact-node\standalone\win32-1.89.02-rc1\pact\bin\pact-broker.bat ENOENT
at notFoundError (C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\cross-spawn\lib\enoent.js:6:26)
at verifyENOENT (C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\cross-spawn\lib\enoent.js:40:16)
at ChildProcess.cp.emit (C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\cross-spawn\lib\enoent.js:27:25)
at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12)
[2022-11-28 17:55:35.369 +0000] WARN (13664 on DESKTOP-1H0P31U): pact-node@10.17.6: Pact exited with code 1.
[2022-11-28 17:55:35.370 +0000] ERROR (13664 on DESKTOP-1H0P31U): pact-node@10.17.6: Pact publication failed with non-zero exit code. Full output was:
The system cannot find the path specified.
Pact contract publishing failed: Error: Pact publication failed with non-zero exit code. Full output was:
The system cannot find the path specified.
at ChildProcess.<anonymous> (C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\@pact-foundation\pact-node\src\publisher.js:79:40)
at Object.onceWrapper (node:events:510:26)
at ChildProcess.emit (node:events:402:35)
at ChildProcess.cp.emit (C:\Users\sanmi\OneDrive\Desktop\New folder\personal-media\node_modules\cross-spawn\lib\enoent.js:34:29)
at maybeClose (node:internal/child_process:1064:16)
at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5)
* Terminal will be reused by tasks, press any key to close it. ```
matt.fellows
2022-11-28 22:55
You?ll need to bring the CLI closer to `c:\` or consider using the docker image
matt.fellows
2022-11-28 22:55
(search long path issue in Pact JS and you should find some other workarounds also)
sanmicad
2022-11-28 23:33
@matt.fellows Thanks for your reply. I was able to resolve it by downgrading to `@pact-foundation/pact-node@10.17.2`
tjones
2022-11-29 08:43
The version of the standalone in 10.17.3 is a rc, which means it has a longer path name.
yousafn
2022-11-29 13:05
Hey @chrisjburnscg are you sorted on this dude? If not drop me a message and we can get you perms. I think the deal was you were happy to be admin / maintain the repo. We've had a historic policy of keeping the original authors as admins of their project on transfer to the pact-foundation org, so it may just be some mixed perms.
We still warrant a full audit and review of the policies at some point but that is some yak shaving for another day
chrisjburnscg
2022-11-29 18:58
Hi @yousafn as far as I can see, I still think I've got problems merging without approvals on the repo
yousafn
2022-11-29 19:09
np, will get you sorted tomorrow, just clocking off the eve now. thanks again buddy
bethskurrie
2022-11-29 22:39
I?ll have a look. I didn?t add any rules, but maybe there are some by default.
bethskurrie
2022-11-29 22:43
Ok, I?ve added ?helm chart maintainers? as able to override the PR approval process.
sanmicad
2022-11-29 22:55
Hi, Can someone please help me identify what the issue is, I have published my consumer contract to the broker, but when i try to verify the provider i get the following. I have also attached a copy of my provider.js file
`22:42:05.290] INFO (26840): pact@10.1.4: Verifying provider`
`[22:42:05.297] INFO (26840): pact-core@13.12.2: Verifying Pacts.`
`RUNS __tests__/provider.js`
`RUNS __tests__/provider.js`
`2022-11-29T22:42:11.622800Z ERROR ThreadId(12) pact_verifier: Failed to load pact - Failed to load pact 'https://cloudmargin.pactflow.io/pacts/provider/Provider-Backend/consumer/Consumer-Personal-Media/latest' - Request failed with status - 401 Unauthorized`
`2022-11-29T22:42:11.624057Z ERROR ThreadId(12) pact_verifier: Failed to load pact - Could not load pacts from the pact broker 'https://cloudmargin.pactflow.io'`
`2022-11-29T22:42:11.625595Z WARN ThreadId(12) pact_matching::metrics:`
`Please note:`
`We are tracking events anonymously to gather important usage statistics like Pact version and operating system. To disable tracking, set the 'PACT_DO_NOT_TRACK' environment variable to 'true'.`
`Failures:`
`1) Failed to load pact - Failed to load pact 'https://cloudmargin.pactflow.io/pacts/provider/Provider-Backend/consumer/Consumer-Personal-Media/latest' - Request failed with status - 401 Unauthorized`
`2) Failed to load pact - Could not load pacts from the pact broker 'https://cloudmargin.pactflow.io'`
`FAIL __tests__/provider.js (7.98 s)`
`Backend Personal Media verification`
`× validates the expectations of personal media (6414 ms)`
`? Backend Personal Media verification ? validates the expectations of personal media`
`Verfication failed`
`at node_modules/@pact-foundation/pact-core/src/verifier/nativeVerifier.ts:50:20`
matt.fellows
2022-11-29 23:30
sure, but how is it being passed into that job? My guess is that the environment variable is not set
matt.fellows
2022-11-29 23:34
Above line `13` if you print out `console.log(`Token ${process.env.PACT_BROKER_TOKEN}`)` does the correct token value print out?
matt.fellows
2022-11-29 23:36
If it does
1. Check the token has the correct permissions (pretty sure you?d get a `403` if it were the case, but just to be sure)
2. Set log level to `debug` and see what the verifier is sending to the Broker
sanmicad
2022-11-29 23:49
Done that. The logs weren't quite helpful. maybe you might get it. The tokeni is a read write permission
```> web-server@1.0.0 test:provider
> rimraf pacts && jest __tests__/ --runInBand --force-exit
RUNS __tests__/provider.js
2022-11-29T23:44:01.756550Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_new_for_application FFI function invoked
2022-11-29T23:44:01.757169Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_provider_info FFI function invoked
2022-11-29T23:44:01.757509Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_provider_state FFI function invoked
2022-11-29T23:44:01.757666Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_verification_options FFI function invoked
2022-11-29T23:44:01.757832Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_publish_options FFI function invoked
2022-11-29T23:44:01.759765Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_url_source FFI function invoked
2022-11-29T23:44:01.760059Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_broker_source_with_selectors FFI function invoked
2022-11-29T23:44:01.760329Z DEBUG ThreadId(02) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_execute FFI function invoked
2022-11-29T23:44:01.760466Z DEBUG ThreadId(02) pact_ffi::verifier::handle: Pact source to verify = URL(https://cloudmargin.pactflow.io/pacts/provider/Provide
RUNS __tests__/provider.js
2022-11-29T23:44:01.761410Z DEBUG ThreadId(02) pact_ffi::verifier::handle: Pact source to verify = PactBrokerWithDynamicConfiguration(https://cloudmargin.pactflow.io, provider_name='Provider-Backend', enable_pending=false, include_wip_since=None, provider_tags=["main"], provider_branch=Some(""), consumer_version_selectors='[ConsumerVersionSelector { consumer: None, tag: Some("main"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }], auth=User(, Mich***********)')
2022-11-29T23:44:01.766107Z DEBUG ThreadId(02) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/content-generator/binary
core/content-generator/json
core/content-matcher/json
core/content-matcher/multipart-form-data
core/content-matcher/text
core/content-matcher/xml
2022-11-29T23:44:01.767351Z DEBUG ThreadId(02) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/matcher/v1-equality
core/matcher/v2-max-type
core/matcher/v2-min-type
core/matcher/v2-minmax-type
core/matcher/v2-regex
core/matcher/v2-type
core/matcher/v3-content-type
core/matcher/v3-date
core/matcher/v3-datetime
core/matcher/v3-decimal-type
core/matcher/v3-includes
core/matcher/v3-integer-type
core/matcher/v3-null
core/matcher/v3-number-type
core/matcher/v3-time
core/matcher/v4-array-contains
core/matcher/v4-equals-ignore-order
core/matcher/v4-max-equals-ignore-order
core/matcher/v4-min-equals-ignore-order
core/matcher/v4-minmax-equals-ignore-order
core/matcher/v4-not-empty
core/matcher/v4-semver
2022-11-29T23:44:01.780808Z DEBUG tokio-runtime-worker hyper::client::connect::dns: resolving host="http://cloudmargin.pactflow.io"
RUNS __tests__/provider.js
2022-11-29T23:44:02.058380Z DEBUG reqwest-internal-sync-runtime hyper::client::connect::http: connected to 3.105.11.81:443
[23:44:01.746] INFO (27772): pact@10.1.4: Verifying provider
[23:44:01.757] DEBUG (27772): pact-core@13.12.2: the optional ffi function 'pactffiVerifierSetFilterInfo' was not executed as it had non-fatal validation errors: None of PACT_DESCRIPTION, PACT_PROVIDER_STATE or PACT_PROVIDER_NO_STATE were set in the environment
[23:44:01.753] INFO (27772): pact-core@13.12.2: Verifying Pacts.
[23:44:01.754] INFO (27772): pact-core@13.12.2: Verifying Pact Files
[23:44:01.754] DEBUG (27772): pact-core@13.12.2: Initalising native core at log level 'DEBUG'
[23:44:01.757] DEBUG (27772): pact-core@13.12.2: the optional ffi function 'pactffiVerifierSetConsumerFilters' was not executed as it had non-fatal validation errors: Either no consumerFilters option provided, or the array was empty
[23:44:01.758] DEBUG (27772): pact-core@13.12.2: the optional ffi function 'pactffiVerifierSetFailIfNoPactsFound' was not executed as it had non-fatal validation errors: No failIfNoPactsFound option provided
[23:44:01.758] DEBUG (27772): pact-core@13.12.2: the optional ffi function 'pactffiVerifierAddCustomHeader' was not executed as it had non-fatal validation errors: No customProviderHeaders option provided
[23:44:01.758] DEBUG (27772): pact-core@13.12.2: checking source type of given pactUrl: https://cloudmargin.pactflow.io/pacts/provider/Provider-Backend/consumer/Consumer-Personal-Media/latest
[23:44:01.759] DEBUG (27772): pact-core@13.12.2: adding https://cloudmargin.pactflow.io/pacts/provider/Provider-Backend/consumer/Consumer-Personal-Media/latest as a Url source
[23:44:01.760] DEBUG (27772): pact-core@13.12.2: the optional ffi function 'pactffiVerifierAddProviderTransport' was not executed as it had non-fatal validation errors: No additional provider transports provided
2022-11-29T23:44:02.601006Z DEBUG reqwest-internal-sync-runtime h2::client: binding client connection
2022-11-29T23:44:02.601521Z DEBUG reqwest-internal-sync-runtime h2::client: client connection bound
2022-11-29T23:44:02.601821Z DEBUG reqwest-internal-sync-runtime h2::codec::framed_write: send frame=Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
2022-11-29T23:44:02.605944Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_read: received frame=Settings { flags: (0x0), max_concurrent_streams: 128, initial_window_size: 65536, max_frame_size: 16777215 }
2022-11-29T23:44:02.606854Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_write: send frame=Settings { flags: (0x1: ACK) }
2022-11-29T23:44:02.607103Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_read: received frame=WindowUpdate { stream_id: StreamId(0), size_increment: 2147418112 }
2022-11-29T23:44:02.607584Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_write: send frame=WindowUpdate { stream_id: StreamId(0), size_increment: 5177345 }
2022-11-29T23:44:02.608675Z DEBUG reqwest-internal-sync-runtime hyper::client::pool: pooling idle connection for ("https", http://cloudmargin.pactflow.io)
2022-11-29T23:44:02.609937Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_write: send frame=Headers { stream_id: StreamId(1)
RUNS __tests__/provider.js
2022-11-29T23:44:03.175136Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_read: received frame=Settings { flags: (0x1: ACK) }
2022-11-29T23:44:03.176250Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::proto::settings: received settings ACK; applying Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
2022-11-29T23:44:03.232264Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_read: received frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
2022-11-29T23:44:03.232688Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(1) }
2022-11-29T23:44:03.240502Z DEBUG reqwest-internal-sync-runtime Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(1), flags: (0x1: END_STREAM) }
2022-11-29T23:44:03.247294Z INFO ThreadId(02) pact_verifier::pact_broker: Fetching path '/' from pact broker
2022-11-29T23:44:03.247746Z DEBUG tokio-runtime-worker hyper::client::connect::dns: resolving host="http://cloudmargin.pactflow.io"
2022-11-29T23:44:03.248371Z DEBUG ThreadId(02) hyper::client::connect::http: connecting to 3.105.11.81:443
RUNS __tests__/provider.js
2022-11-29T23:44:04.045581Z DEBUG ThreadId(02) h2::client: binding client connection
2022-11-29T23:44:04.046611Z DEBUG ThreadId(02) h2::client: client connection bound
2022-11-29T23:44:04.047334Z DEBUG ThreadId(02) h2::codec::framed_write: send frame=Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
2022-11-29T23:44:04.048536Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Settings { flags: (0x0), max_concurrent_streams: 128, initial_window_size: 65536, max_frame_size: 16777215 }
2022-11-29T23:44:04.049461Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=Settings { flags: (0x1: ACK) }
2022-11-29T23:44:04.050268Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=WindowUpdate { stream_id: StreamId(0), size_increment: 2147418112 }
2022-11-29T23:44:04.051294Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=WindowUpdate { stream_id: StreamId(0), size_increment: 5177345 }
2022-11-29T23:44:04.048574Z DEBUG ThreadId(02) hyper::client::pool: pooling idle connection for ("https", http://cloudmargin.pactflow.io)
2022-11-29T23:44:04.053296Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=Headers { stream_id: StreamId(1), flags: (0x5: END_HEADERS | END_STREAM) }
2022-11-29T23:44:04.615780Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Settings { flags: (0x1: ACK) }
2022-11-29T23:44:04.617523Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::proto::settings: received settings ACK; applying Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
2022-11-29T23:44:04.650339Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
2022-11-29T23:44:04.651488Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(1) }
2022-11-29T23:44:04.652628Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(1), flags: (0x1: END_STREAM) }
2022-11-29T23:44:04.654178Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
2022-11-29T23:44:04.654210Z ERROR ThreadId(02) pact_verifier: Failed to load pact - Failed to load pact 'https://cloudmargin.pactflow.io/pacts/provider/Provider-Backend/consumer/Consumer-Personal-Media/latest' - Request failed with status - 401 Unauthorized```
matt.fellows
2022-11-29 23:56
```auth=User(, Mich***********)```
:point_up: have you got other credentials in your environment?
matt.fellows
2022-11-29 23:57
in your shell, do you see other variables prefixed with `PACT_` (e.g. `env | grep PACT`)
sanmicad
2022-11-30 00:05
no i don't, i was a bit skeptical about the token not working so i tried switching from token to username and password
sanmicad
2022-11-30 00:19
My guess is I shouldn't be passing the authentication as a verifier option, but all of the examples i have seen doesn't specify or state that authentication is required to verify a pact
matt.fellows
2022-11-30 07:01
> My guess is I shouldn?t be passing the authentication as a verifier option, but all of the examples i have seen doesn?t specify or state that authentication is required to verify a pact
where does it say this?
matt.fellows
2022-11-30 07:01
> no i don?t, i was a bit skeptical about the token not working so i tried switching from token to username and password
you can?t use username/passwords for Pactflow API usage
matt.fellows
2022-11-30 07:01
If you?re pulling contracts from the broker (which you are) you will need authentication
tjones
2022-11-30 07:59
That would address this, but it?s more ergonomic in node to use the CLI directly.
I don?t know if pact-node is still being released, but I?ve made https://github.com/pact-foundation/pact-js-core/pull/419 , which would fix the regression of an extra three characters in the path introduced in 10.17.3 by updating the standalone to 1.91.0
tjones
2022-11-30 08:35
Awesome! I should add - I haven?t tested that at all - and of course CI doesn?t run on PRs to pact-node?s branch
sanmicad
2022-11-30 15:22
I moved my code folder closer to C:/ and that fixed the earlier problem I was having with the latest version. So all good on this. Thanks Guys and @matt.fellows
sanmicad
2022-12-01 00:38
@matt.fellows Thanks for the help. some of your suggestions were quite insightful. I managed to publish and verify my consumer and provider pact.
One of the issues was the long path, the second issue was
I was using
```const { Verifier } = require('@pact-foundation/pact');```
but pact was expecting
```const { Verifier } = require('@pact-foundation/pact-node');```
also
```return new Verifier(opts).verifyProvider().then((output) => ```
but pact was expecting
```return new Verifier(opts).verify().then((output) => ```
lastly, in my dotenv file i had my token and my basic auth credentials defined but was only calling the token to be used for the verifier pact file but it would not let me until i deleted the username and password from my dotenv file and left just the token.
matt.fellows
2022-12-01 00:50
yes, any `PACT_` environment variables are read in by the tooling automatically. This is so you can export them in CI etc. and it just passes through
francislainy.campos
2022-12-01 04:42
Hi, how to do a tag a contract with the PR branch from the mvn command when publishing it? Can?t find the right syntax for that. Not sure if something like this?
```./mvnw -Dpactbroker.auth.token=${pactBrokerToken} -Dpactbroker.tags=${getTag(testEnvt)} -Dtest=com.hmhco.lti.ags.tool.infrastructure.pact.*IT \
-Dpact.consumer.version=${ReleaseVersion} integration-test```
elluru.kri.mohan
2022-12-01 17:48
I am interested in adding pact-plugins to my broker server. just copying the pact_plugins to the broker is enough? Does anyone have some steps followed for the broker to run the plugins (especially mockServer capable) ones? it would be great help to interact and learn from you.
yousafn
2022-12-01 17:56
pact plugins help you with generating and verifying pacts, you can publish those generated pacts to any broker
matt.fellows
2022-12-01 21:18
Yep. Basically you don't need to add plugins to the broker, they get installed on your client projects where the tests run
matt.fellows
2022-12-01 21:19
Remember - the broker doesn't run any tests. It is the collaboration point and repository for storing them and all of the verification data etc.
elluru.kri.mohan
2022-12-02 00:58
Yousuf and Matt, given we can?t migrate to http://pactflow.io, for bi-directional contract testing, we want broker to be the _*https://www.google.com/search?rlz=1C5CHFA_enIN962IN962&sxsrf=ALiCzsbtvtF-XzII-xVgO0qSPeV2XilAJA:1669942605699&q=intermediary&spell=1&sa=X&ved=2ahUKEwjog7v-3Nn7AhVpHTQIHQNoCCEQkeECKAB6BAgFEAE*_ to between the providers and consumers. by having the plugins installed on the broker server, the mock server can be run through Broker ip itself, than local machine fetching the pacts and running locally. Intention is use it for Asynchronous communication. Am I being crazy/stupid here ? :)
matt.fellows
2022-12-02 01:00
> Am I being crazy/stupid here ? :slightly_smiling_face:
Well, I?m not a qualified psychiatrist, so you might want to seek proper medical advice an that one :wink:
matt.fellows
2022-12-02 01:00
But plugins have nothing to do with the broker, it doesn?t work that way
matt.fellows
2022-12-02 01:01
Pact tests are unit tests, and the mocks always run as part of the unit test where those tests are running (i.e. not remote). That?s just how Pact works
matt.fellows
2022-12-02 01:02
I?m not sure I properly follow your other points, but the Pact Broker is not designed to be a remote mock server.
elluru.kri.mohan
2022-12-02 01:08
Matt, I have started recently(3 weeks), but I believe I have some misunderstanding here. Let me re-iterate our use-case clearly
1. we want to use protobuf for our contracts testing.
2. we want the broker to house all the pacts created by our different consumers
3. our providers are similar to open API model, and bi-directional contract testing seems more appropriate for us, than consumer-driven contract testing for needs and suggestion was to rely on http://pactflow.io saas services
4. given, we have services already using an existing broker server, I am trying to mimic what http://pactflow.io does in reality with BDCT
matt.fellows
2022-12-02 01:16
Right. So plugins currently work with Pact in a consumer-driven model. You could look to create a plugin that mimics BDCT but at the moment the plugin is very much consumer driven.
BDCT currently only supports OAS as the provider contract, albeit we would like to extend this to others over time.
matt.fellows
2022-12-02 01:17
> given, we have services already using an existing broker server, I am trying to mimic what http://pactflow.io does in reality with BDCT
what do you mean by ?using an existing broker server? - do you mean the Pact Broker or something else?
dyptorden
2022-12-05 15:01
Hi guys. Please enighten me on how should I instruct the provider to run the test against a specific version of the contract and not against the newest contract published in the broker.
My Pact broker initially had a contract version that was successfully passing the tests. But then, the team that owns the consumer pushed from their branch a new version of the contract, and the provider tests are failing now, because they run against the latest contract in the Matrix list (contracts in the Matrix are sorted by database id I assume). How can I make the provider tests run against the latest "prod" version of the contract and not against versions published by dev branches? (against c.v.1-PROD according to the screenshot instead of c.v.2.-WorkInProgress)
Thank you!
dyptorden
2022-12-05 15:03
P..S.: to make it clear, I don't want to block provider releases as long as consumer's new version is not in master yet
james.perepiczka
2022-12-05 15:34
Hi, I had a question about whether there is an override for this behaviour. For a provider, I have been running can-i-deploy as a way of checking if verifications exist between my current branch and ?main? branch consumers and then through the deployment lifecycle checking if there are verifications between environments. I recently cleared down contracts to test what would happen with custom webhooks when the consumer runs can-i-deploy to trigger the provider (it worked fine). The problem I had was when the provider was deployed to a later environment than the consumer, where no contracts existed between them. I can understand the usecase of failing can-i-deploy if the contracts were unverified as interactions would be required but what about where the are no consumers in the environment for a provider. is that a breaking case? So my question is?is there a flag to say ?don?t fail if there are no consumers of this tag/environment? so it only fails if the contract has changed and there has previously been a verification for the tag and/or environment but not for this latest version
dyptorden
2022-12-05 15:41
@james.perepiczka take a look at the IgnoreNoPactsToVerify annotation - could probably be what you need
dyptorden
2022-12-05 15:41
still...I am learning about pact framework now, so I may not be the right person to answer
james.perepiczka
2022-12-05 15:42
If you are using java it would be something like:
``` @PactBrokerConsumerVersionSelectors
public static SelectorBuilder consumerVersionSelectors() {
return new SelectorBuilder().latestTag("your tag")
}```
james.perepiczka
2022-12-05 15:43
It doesn?t look like you are using tags from that screenshot however, it looks like your tags are in the version field
dyptorden
2022-12-05 15:44
I am not using tags (yet). So then if I will tag a contract version with "PROD", I could instruct the provider to run against the latest "PROD" version instead of the latest from the list?
dyptorden
2022-12-05 15:47
and the method that you gave as an example ( @PactBrokerConsumerVersionSelectors ) should be part of the provider contract test?
james.perepiczka
2022-12-05 15:52
Thanks Basu, I?ve tried the IgnoreNoPactsToVerify in the past for provider verification but it doesn?t seem to affect the can-i-deploy pact broker cli
bethskurrie
2022-12-07 07:37
Do keep the main branch pact in your selectors. But by turning on pending, it won't break your build.
bethskurrie
2022-12-07 07:39
Can I deploy does not require the consumer to be present to deploy the provider. It should work fine.
bethskurrie
2022-12-07 07:41
Have you seen a failure that indicates otherwise? Or are you just considering a hypothetical situation?
github2
2022-12-07 20:21
The GitHub user https://github.com/bethesque has signed out.
Use the following command/s to recreate subscriptions
/github subscribe pact-foundation/pact_broker
/github subscribe DiUS/pact_broker-docker
2022-12-08 00:33
:white_check_mark: Subscribed to https://github.com/pact-foundation/pact_broker. This channel will receive notifications for `issues`, `pulls`, `commits`, `releases`, `deployments`
2022-12-08 00:33
:white_check_mark: Subscribed to https://github.com/pact-foundation/pact-broker-docker. This channel will receive notifications for `issues`, `pulls`, `commits`, `releases`, `deployments`
2022-12-08 06:10
Unsubscribed from https://github.com/pact-foundation/pact_broker
bethskurrie
2022-12-08 06:11
/github subscribe pact-foundation/pact_broker issues pulls releases deployments
2022-12-08 06:11
:white_check_mark: Subscribed to https://github.com/pact-foundation/pact_broker. This channel will receive notifications for `issues`, `pulls`, `commits`, `releases`, `deployments`
2022-12-08 06:12
This channel will receive notifications from https://github.com/pact-foundation/pact_broker for: `issues`, `pulls`, `releases`, `deployments`
2022-12-08 06:12
This channel will receive notifications from https://github.com/pact-foundation/pact-broker-docker for: `issues`, `pulls`, `releases`, `deployments`
dyptorden
2022-12-13 08:57
Hi guys!
Running a `pact-broker help` returns the entire list of commands that can be executed, which is useful. But for some commands in the list, the parameters are truncated (due to space maybe).
E.g.: `pact-broker publish PACT_DIRS_OR_FILES ... -a, --consumer-app-version=CONSUMER_APP_VERSION -b, --broker-base-url=BROKER_BASE_URL`
Also, on the https://github.com/pact-foundation/pact-ruby-standalone/releases in github I can only see the *Usage* for `pact-mock-service`, `pact-stub-service` and `pact-provider-verifier`
Can we get an implementation for the entire list of attributes when running for example `pact-broker publish help` ? - (which at the moment returns No value provided for required options '--consumer-app-version')
Thank you,
matt.fellows
2022-12-14 11:09
but, it IS consistently quirky, which is actually what matters with CLIs
sam774
2022-12-14 21:56
Hey folks, I'm experiencing some problems with pact provider verification via the new ``contract_requiring_verification_published`` webhook. My pact broker is hosted on http://sh1989.pactflow.io
The error I receive is:
> pact_1 | bundler: failed to load command: /pact/bin/pact (/pact/bin/pact)
> pact_1 | /usr/lib/ruby/gems/3.0.0/gems/pact-1.63.0/lib/pact/hal/entity.rb:53:in `_link!': Could not find relation 'pb:latest-provider-pacts' in resource at https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ (Pact:hal:RelationNotFoundError)
sam774
2022-12-14 21:57
This is what comes back from `GET /pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ`:
```"{\"consumer\":{\"name\":\"pact-consumer\"},\"interactions\":[{\"_id\":\"f0f5cbd6bdb420b5c2bc3fbf4ec719ea5304fe11\",\"description\":\"A request for quotes\",\"providerStates\":[{\"name\":\"a comedy-loving user\"}],\"request\":{\"method\":\"GET\",\"path\":\"/quotes\"},\"response\":{\"body\":[{\"author\":\"Rick Sanchez\",\"quote\":\"I'm Pickle Rick!\",\"source\":\"https://www.imdb.com/title/tt5218268/\"}],\"headers\":{\"Content-Type\":\"application/json\"},\"matchingRules\":{\"body\":{\"$\":{\"combine\":\"AND\",\"matchers\":[{\"match\":\"type\",\"min\":1}]},\"$[*].source\":{\"combine\":\"AND\",\"matchers\":[{\"match\":\"regex\",\"regex\":\"http(s)?://([^?#]*)\"}]}}},\"status\":200}},{\"_id\":\"10bbe0048033bcb9069f50ec34714735737e7508\",\"description\":\"A request for quotes\",\"providerStates\":[{\"name\":\"no user\"}],\"request\":{\"method\":\"GET\",\"path\":\"/quotes\"},\"response\":{\"status\":200}}],\"metadata\":{\"pact-js\":{\"version\":\"10.4.0\"},\"pactRust\":{\"ffi\":\"0.3.15\",\"models\":\"1.0.1\"},\"pactSpecification\":{\"version\":\"3.0.0\"}},\"provider\":{\"name\":\"pact-provider\"},\"createdAt\":\"2022-12-14T21:19:53+00:00\",\"_links\":{\"self\":{\"title\":\"Pact\",\"name\":\"Pact between pact-consumer (df1802b6) and pact-provider\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/version/df1802b6\"},\"pb:consumer\":{\"title\":\"Consumer\",\"name\":\"pact-consumer\",\"href\":\"https://sh1989.pactflow.io/pacticipants/pact-consumer\"},\"pb:consumer-version\":{\"title\":\"Consumer version\",\"name\":\"df1802b6\",\"href\":\"https://sh1989.pactflow.io/pacticipants/pact-consumer/versions/df1802b6\"},\"pb:consumer-versions\":[{\"title\":\"Consumer version\",\"name\":\"df1802b6\",\"href\":\"https://sh1989.pactflow.io/pacticipants/pact-consumer/versions/df1802b6\"}],\"pb:provider\":{\"title\":\"Provider\",\"name\":\"pact-provider\",\"href\":\"https://sh1989.pactflow.io/pacticipants/pact-provider\"},\"pb:pact-version\":{\"title\":\"Pact content version permalink\",\"name\":\"70a8e3b23699154f9342895ea8bac8e8d79396e3\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3\"},\"pb:latest-pact-version\":{\"title\":\"Latest version of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/latest\"},\"pb:all-pact-versions\":{\"title\":\"All versions of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/versions\"},\"pb:latest-untagged-pact-version\":{\"title\":\"Latest untagged version of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/latest-untagged\"},\"pb:latest-tagged-pact-version\":{\"title\":\"Latest tagged version of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/latest/{tag}\",\"templated\":true},\"pb:previous-distinct\":{\"title\":\"Previous distinct version of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/version/df1802b6/previous-distinct\"},\"pb:diff-previous-distinct\":{\"title\":\"Diff with previous distinct version of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/version/df1802b6/diff/previous-distinct\"},\"pb:diff\":{\"title\":\"Diff with another specified version of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/diff/pact-version/{pactVersion}\",\"templated\":true},\"pb:pact-webhooks\":{\"title\":\"Webhooks for the pact between pact-consumer and pact-provider\",\"href\":\"https://sh1989.pactflow.io/webhooks/provider/pact-provider/consumer/pact-consumer\"},\"pb:consumer-webhooks\":{\"title\":\"Webhooks for all pacts with provider pact-provider\",\"href\":\"https://sh1989.pactflow.io/webhooks/consumer/pact-provider\"},\"pb:tag-prod-version\":{\"title\":\"PUT to this resource to tag this consumer version as 'production'\",\"href\":\"https://sh1989.pactflow.io/pacticipants/pact-consumer/versions/df1802b6/tags/prod\"},\"pb:tag-version\":{\"title\":\"PUT to this resource to tag this consumer version\",\"href\":\"https://sh1989.pactflow.io/pacticipants/pact-consumer/versions/df1802b6/tags/{tag}\"},\"pb:publish-verification-results\":{\"title\":\"Publish verification results\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ/verification-results\"},\"pb:latest-verification-results\":{\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/verification-results/latest\"},\"pb:triggered-webhooks\":{\"title\":\"Webhooks triggered by the publication of this pact\",\"href\":\"https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/version/df1802b6/triggered-webhooks\"},\"pb:matrix-for-consumer-version\":{\"title\":\"View matrix rows for the consumer version to which this pact belongs\",\"href\":\"https://sh1989.pactflow.io/matrix?q[][pacticipant]=pact-consumer\\u0026q[][version]=df1802b6\\u0026latestby=cvpv\"},\"curies\":[{\"name\":\"pb\",\"href\":\"https://sh1989.pactflow.io/doc/{rel}?context=pact\",\"templated\":true}]}}"```
sam774
2022-12-14 21:59
And the command that the webhook triggers:
```pact verify https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ
--provider pact-provider
--provider-app-version 6a774a4
--provider-version-branch master
--provider_base_url http://app:8081
--provider-states-setup-url http://app:8081/provider-states
--pact-broker-base-url https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ
--broker-token <redacted>
--wait 10
--verbose true```
bethskurrie
2022-12-15 02:41
you either want to set your `--pact-broker-base-url ` and `--provider` OR you set the pact URL.
bethskurrie
2022-12-15 02:42
when you do a verification, either you?re verifying a changed pact at a specific URL, passed in via the webhook (so, just provide the pact URL parameter) OR you?re doing a verification of all the provider?s pacts because the provider has changed (in which case, you set the base URL and the provider name)
bethskurrie
2022-12-15 02:43
```pact verify https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ
--provider-app-version 6a774a4
--provider-version-branch master
--provider_base_url http://app:8081
--provider-states-setup-url http://app:8081/provider-states
--broker-token <redacted>
--wait 10
--verbose true```
bethskurrie
2022-12-15 02:43
```pact verify
--provider pact-provider
--pact-broker-base-url https://sh1989.pactflow.io
--provider-app-version 6a774a4
--provider-version-branch master
--provider_base_url http://app:8081
--provider-states-setup-url http://app:8081/provider-states
--broker-token <redacted>
--wait 10
--verbose true```
bethskurrie
2022-12-15 02:54
I?ve manually added ?pact-broker xxx help? commands in a few places, but I?ve clearly not got them all.
sam774
2022-12-15 09:29
Thanks Beth! If I run the first option, I get the error:
`No value provided for required option '--provider'`
But once I added that back in too it worked correctly :slightly_smiling_face: and glad it was something simple!
I was also a bit confused by the documentation here https://docs.pact.io/provider/recommended_configuration, which says that "When the pact URL is known, the `pactBrokerUrl`, `providerName`, `consumerVersionSelectors/consumerVersionTags`, `enablePending`, `includeWipPactsSince` fields should not be set" - but maybe that's specific to the JS/Ruby libs rather than via the CLI
alvaro.navarroiborra
2022-12-15 11:06
Hello team!, I'm new on Pact and I'm performing a PoC with Pact. I've created 3 dummy services with Java. I've also used the Pact broker docker image to set up a container in my local. Currently I've been able to generate contracts from the consumer side and publishing into the broker and also verify the providers and publish the verificarion into the broker. At this point I want to play with the Docker Pact CLI (pactfoundation/pact-cli). I couldn't execute any command at this point because a TCP connection error with the pact-broker is raised.
alvaro.navarroiborra
2022-12-15 11:06
Example command
```docker run --rm pactfoundation/pact-cli:latest \
pact-broker list-environments -b="http://localhost:9292"```
Error
```Error making request - Errno::EADDRNOTAVAIL Failed to open TCP connection to localhost:9292 (Address not available - connect(2) for "localhost" port 9292) /usr/lib/ruby/gems/3.0.0/gems/pact_broker-client-1.66.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 3 of 3
Error retrieving matrix. Errno::EADDRNOTAVAIL - Failed to open TCP connection to localhost:9292 (Address not available - connect(2) for "localhost" port 9292)```
alvaro.navarroiborra
2022-12-15 11:08
If I perform a curl
```http://localhost:9292```
works fine. Do you know If I need some kind of configuration or am I doing something wrong with the Pact CLI?
yousafn
2022-12-15 11:12
depending on your operating system you probably need to point to a docker internal address rather than localhost
yousafn
2022-12-15 11:31
a docker container cannot talk to another container bound on localhost on a mac/windows machine from my exp, and it is documented in Dockers documentation
https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host
yousafn
2022-12-15 11:32
If we were to point a link to that guide / workaround where do you think it would best be?
In the provider cli?
> Hey we couldn't connect to localhost, if you are on a mac/windows try host.docker.internal and see <link to docker docs>
Or somewhere in the docs site / repo readme?
alvaro.navarroiborra
2022-12-15 11:39
This would be very useful, thanks. And also a concrete docker run example using host.docker.internal would be great.
alvaro.navarroiborra
2022-12-15 11:44
If I try this
```docker run --rm pactfoundation/pact-cli:latest \
pact-broker list-environments -b=http://host.docker.internal:9292```
Errno::EADDRNOTAVAIL - Failed to open TCP connection to localhost:443 (Address not available - connect(2) for "localhost" port 443)
If I use https I need the credentials but on my docker-compose I'm not using https.
https://github.com/alvNa/contract-testing/blob/develop/pact-broker/docker-compose.yml
yousafn
2022-12-15 17:54
So if I comment that out it works fine locally with
```docker run --rm pactfoundation/pact-cli:latest \
pact-broker list-environments -b=http://host.docker.internal:9292```
bethskurrie
2022-12-15 22:05
@alvaro.navarroiborra it?s because it?s trying to make a request to the localhost inside the docker container.
bethskurrie
2022-12-15 22:09
You can use the hostname *`host.docker.internal`* to access localhost on your host machine.
bethskurrie
2022-12-15 22:11
This looks like its been ripped from the demo that shows how to use https https://github.com/alvNa/contract-testing/blob/c971b9a0a094fee2cb9380beaaf2767e09ebda86/pact-broker/docker-compose.yml
bethskurrie
2022-12-15 22:14
Can you send me the exact command and error stack for when you saw `No value provided for required option '--provider'`
alvaro.navarroiborra
2022-12-15 22:23
Thank you very much for the info. It's working now ! :smiley::raised_hands:
alvaro.navarroiborra
2022-12-15 22:25
I took this post as a reference https://blog.devgenius.io/how-to-verify-api-interfaces-using-automated-contract-test-7002cce5a306
I used the same docker-compose.
bethskurrie
2022-12-15 22:25
It?s worth learning all the different ways that docker containers are accessible to various hosts.
? docker container to docker container within the same docker-compose -> use the service name
? native docker host to docker container -> use localhost and the port it?s bound to
? independent docker container to another docker container bound to a localhost port -> use host.docker.internal and the port it is bound to
sam774
2022-12-16 14:12
Running `pactfoundation/pact-cli` docker container with digest `sha256:e0a783b0` (v0.51.0), here's the output from my terminal:
```docker run --rm pactfoundation/pact-cli:latest pact verify \
> https://sh1989.pactflow.io/pacts/provider/pact-provider/consumer/pact-consumer/pact-version/70a8e3b
23699154f9342895ea8bac8e8d79396e3/metadata/Y3ZuPWRmMTgwMmI2Jnc9dHJ1ZQ \
> --provider-app-version 6a77a4 \
> --provider-version-branch master \
> --provider_base_url http://host.docker.internal:8081 \
> --provider-states-setup-url http://host.docker.internal:8081/provider-states \
> --pact-broker-base-url https://sh1989.pactflow.io \
> --broker-token fake-token \
> --verbose true
No value provided for required option '--provider'```
Sadly there's no deeper error stack than that.
Simply adding the extra arg (`--provider pact-provider` - sorry about the poor provider name there :sweat:) makes that command work successfully.
edouard.lopez
2022-12-20 13:43
I don't find a clear list in the docs, is this the list of all native webhook events?
``` events << 'contract_content_changed' if options.contract_content_changed
events << 'contract_published' if options.contract_published
events << 'provider_verification_published' if options.provider_verification_published
events << 'provider_verification_succeeded' if options.provider_verification_succeeded
events << 'provider_verification_failed' if options.provider_verification_failed
events << 'contract_requiring_verification_published' if options.contract_requiring_verification_published```
https://github.com/pact-foundation/pact_broker-client/blob/bf58b5c6503bdf6a4e137430f12d83af3e049891/lib/pact_broker/client/cli/webhook_commands.rb#L62-L67
yousafn
2022-12-20 15:34
I believe the 2nd page is pulled from the docs from here
https://github.com/pact-foundation/pact_broker/blob/master/docs/api/WEBHOOKS.md
synced into the docs site here
https://github.com/pact-foundation/docs.pact.io/blob/8f88f8a7f5812b50db38bfa87d0764c274b381de/scripts/sync/pact_broker.rb#L10
kjayachandra2000
2022-12-21 21:31
Hi Team :wave:,
We are using postgressql v11.16 and want to upgrade the version to 14.6 is there anything which can break or any pointers to keep an eye on
thanks
matt.fellows
2022-12-22 07:16
FYI sorry for the delay, 10.17.7 of the core has been released - if you do an update of the dependencies in your Pact JS project, it should bump the patch version for the dependency that was taking up a few extra chars in your path :slightly_smiling_face:
dimundo
2022-12-23 09:38
hi!
in broker there are 2 labels for same `env:live1` :slightly_smiling_face: should `released` and `deployed` be a bit different ( in color ? )
broker 2.105
ksawery.karwacki
2022-12-27 11:30
What is the proper way to query can-I-deploy with multiple services? pact-jvm seems to only support checking single pacticipant, HAL browser also only shows request builder for only one pacticipant. I know it can be done with Pact CLI but most of my CI code is written in Java and I would much more prefer to just send raw REST request rather than add dependency on external CLI.
matt.fellows
2022-12-27 23:23
The simplest way is to use the CLI with the flags you want and verbose logging enabled, and look at the calls it makes
misterjkl
2023-01-03 13:06
Hi, Happy New Year! :slightly_smiling_face:
I am trying to setup webhooks. I have created a webhook using the docker-cli but when I test the webhook it fails due to `{"message":"Exception obtaining parameters","status-code":500}`
I have checked the logs for clues and searched the source code to trace the error message but to no avail.
Any help appreciated!
misterjkl
2023-01-03 16:00
In the end I found the issue myself. Content-type header was set to `application/json` when in fact the CI I am using returns xml.
edouard.lopez
2023-01-05 14:31
Hello, Happy New Year!
Is there way to link the broker to the pipeline/job that gave publish a result ?
dyptorden
2023-01-05 16:03
I only have small experience with Pact, but I would say yes. You need to have in the pipeline a stage where the Can-I-Deploy runs. You can configure a retry mechanism for the Can-I-Deploy (e.g.: --retry-while-unknown=60 --retry-interval=10) against the broker, to be sure that the results were published in the broker by the provider
yousafn
2023-01-06 12:58
You can set the `buildUrl` when posting verification results, which would store that property to the build
Could you clarify a little more on your use case?
I have used slack notifications and webhooks to report to a particular CI's build logs for publishing of pacts too
yousafn
2023-01-06 12:59
@dyptorden's method is very good for cases where the consumer publishes a pact which hasn't been verified by the provider.
? webhook fires which triggers provider ci build
? consumer polls for provider ci result
? consumer can deploy if result is successful or fails if no result or failed verification
Really neat way for CI/CD
matt.fellows
2023-01-09 01:37
Yeah, I read this as ?I?d like a link to the build job from the pact broker?.
> You can set the `buildUrl` when posting verification results, which would store that property to the build
This is the way to do it, albeit I can?t recall if it?s visible from the UI
edouard.lopez
2023-01-09 11:31
> Yeah, I read this as ?I?d like a link to the build job from the pact broker?.
That's what I want, so we can navigate from broker to our gitlab more easily
edouard.lopez
2023-01-09 11:40
For reference, one should search for either `buildUrl` but `--build-url` in the docs (e.g. https://github.com/pact-foundation/pact_broker-client)
``` [--build-url=BUILD_URL]
# The build URL that created the pact ```
harwin1494
2023-01-10 07:28
Hello all, I am trying out this nirvana pipeline approach, and trying to figure out how to implement the _'wait for results'_ for the can-i-deploy stage. Please provider your insights.
matt.fellows
2023-01-10 07:30
See the ?retry? flags:
``` pact-broker help can-i-deploy
Usage:
pact-broker can-i-deploy -a, --pacticipant=PACTICIPANT -b, --broker-base-url=BROKER_BASE_URL
Options:
-a, --pacticipant=PACTICIPANT # The pacticipant name. Use once for each pacticipant being checked.
-e, [--version=VERSION] # The pacticipant version. Must be entered after the --pacticipant that it relates to.
[--ignore=IGNORE] # The pacticipant name to ignore. Use once for each pacticipant being ignored. A specific version can be ignored by also specifying a --version after the pacticipant name option.
-l, [--latest=[TAG]] # Use the latest pacticipant version. Optionally specify a TAG to use the latest version with the specified tag.
[--to-environment=ENVIRONMENT] # The environment into which the pacticipant(s) are to be deployed
[--branch=BRANCH] # The branch of the version for which you want to check the verification results
[--to=TAG] # The tag that represents the branch or environment of the integrated applications for which you want to check the verification result status.
-o, [--output=OUTPUT] # json or table
# Default: table
[--retry-while-unknown=TIMES] # The number of times to retry while there is an unknown verification result (ie. the provider verification is likely still running)
# Default: 0
[--retry-interval=SECONDS] # The time between retries in seconds. Use in conjuction with --retry-while-unknown
# Default: 10
[--dry-run], [--no-dry-run] # When dry-run is enabled, always exit process with a success code. Can also be enabled by setting the environment variable PACT_BROKER_CAN_I_DEPLOY_DRY_RUN=true. This mode is useful when setting up your CI/CD pipeline for the first time, or in a 'break glass' situation where you need to knowingly deploy what Pact considers a breaking change. For the second scenario, it is recommended to use the environment variable and just set it for the build required to deploy that particular version, so you don't accidentally leave the dry run mode enabled.
-b, --broker-base-url=BROKER_BASE_URL # The base URL of the Pact Broker
-u, [--broker-username=BROKER_USERNAME] # Pact Broker basic auth username
-p, [--broker-password=BROKER_PASSWORD] # Pact Broker basic auth password
-k, [--broker-token=BROKER_TOKEN] # Pact Broker bearer token
-v, [--verbose], [--no-verbose] # Verbose output. Default: false
Description:
Returns exit code 0 or 1, indicating whether or not the specified application (pacticipant) has a successful verification result with each of the application versions that are already deployed to a
particular environment. Prints out the relevant pact/verification details, indicating any missing or failed verification results.
The can-i-deploy tool was originally written to support specifying versions and dependencies using tags. This usage has now been superseded by first class support for environments, deployments and releases.
For documentation on how to use can-i-deploy with tags, please see https://docs.pact.io/pact_broker/client_cli/can_i_deploy_usage_with_tags/
Before `can-i-deploy` can be used, the relevant environment resources must first be created in the Pact Broker using the `create-environment` command. The "test" and "production" environments will have been
seeded for you. You can check the existing environments by running `pact-broker list-environments`. See https://docs.pact.io/pact_broker/client_cli/readme#environments for more information.
$ pact-broker create-environment --name "uat" --display-name "UAT" --no-production
After an application is deployed or released, its deployment must be recorded using the `record-deployment` or `record-release` commands. See
https://docs.pact.io/pact_broker/recording_deployments_and_releases/ for more information.
$ pact-broker record-deployment --pacticipant Foo --version 173153ae0 --environment uat
Before an application is deployed or released to an environment, the can-i-deploy command must be run to check that the application version is safe to deploy with the versions of each integrated application
that are already in that environment.
$ pact-broker can-i-deploy --pacticipant PACTICIPANT --version VERSION --to-environment ENVIRONMENT
Example: can I deploy version 173153ae0 of application Foo to the test environment?
$ pact-broker can-i-deploy --pacticipant Foo --version 173153ae0 --to-environment test
Can-i-deploy can also be used to check if arbitrary versions have a successful verification. When asking "Can I deploy this application version with the latest version from the main branch of another
application" it functions as a "can I merge" check.
$ pact-broker can-i-deploy --pacticipant Foo 173153ae0 \ --pacticipant Bar --latest main```
harwin1494
2023-01-10 11:16
Is there any provision to send a consumer tag via the create-webhook command, to allow the provider-verification tests to run against the consumer with only that tag?
david.turner
2023-01-16 16:17
Hi All :wave: I have been working on creating and debugging some webhooks and in the process of that I have deleted a few of the webhooks! I have noticed that there seems to be some left over `triggeredWebhooks` embedded resources from some failed triggeres which leaves the webhook status as red on the Broker homepage even though they are now successfully being triggered. Is there an easy way to clean up these old logs?
bethskurrie
2023-01-16 21:47
But I cant remember if I finished it. Can you have a look at the CHANGELOG.md?
bethskurrie
2023-01-16 21:49
@shuying.lin could you add a card somewhere for displaying the build URL in the new UI designs please?
bethskurrie
2023-01-16 23:08
bethskurrie
2023-01-16 23:09
@harwin1494 you should be passing through the URL of the pact to be verified
david.turner
2023-01-17 09:11
Ah perfect, thank you :slightly_smiling_face: I will have to get our broker upgraded
kerrypmckeever
2023-01-18 03:31
Hey there! Hopefully this is the right channel. I'm piecing together my consumer/provider workflow, and I'm at a tricky intersection with `create-version-tag` for my pacticipant version.
For reference, we're using *GitHub Actions*. I'm using the commit short SHA for my versioning, and the environment name as the tag.
Our general development flow is:
1. Commit PR and run tests
2. Squash and merge
3. Deploy (This is handled in a separate GitHub Action file)
*My question is*: When we squash and merge the PR into the target branch, the only commit reference for that branch is then the merge commit SHA, which doesn't align with the commit SHA that the contract was verified for. So what is the appropriate way to then run the `create-version-tag` command and reference the correct version for that particular environment?
abubics
2023-01-18 05:07
I don't have the actual answer you want, but a couple of other things . . .
? The final PR commit and the squash-merge commit are definitely different, so you probably don't want to assume they're equivalent.
? If the contract is the same for both commits, the newer one will be pre-verified, so that doesn't sound like a major sticking point.
Is there a problem with creating lots of version tags? Sounds like you might want to only tag things on your main branch, if so.
matt.fellows
2023-01-18 06:45
Side not: I think you probably want to actually start using https://docs.pact.io/pact_broker/branches and https://docs.pact.io/pact_broker/recording_deployments_and_releases, not tags
matt.fellows
2023-01-18 06:48
> If the contract is the same for both commits, the newer one will be pre-verified, so that doesn?t sound like a major sticking point.
exactly. But to expand on this, the underlying assumption is that you _should_ run the consumer contract test + publish steps (thus producing a new consumer version) in every build (even post merge). The contract should be pre-verified, and so you can deploy.
If the second GitHub action doesn?t run the publish step, the version will be different and won?t have any published contracts to reference, to then determine compatibility with providers in the target environment.
kerrypmckeever
2023-01-18 14:23
Thanks for the clarification! That is definitely helpful. A follow up question on the flow, then, and apologies if I'm being a bit obtuse lol. I'm hopeful to get this right from the jump.
What it sounds like is we would likely want to do the following (but please correct me if this is incorrect):
*ON PR:*
1. Run the consumer test and publish on PR
2. Run `pact-can-i-deploy` using the `--to-environment=<environment>` flag and forget the `--to=<tag>` flag, post-test, pre-merge
3. Merge
*ON POST-MERGE/DEPLOY*
1. Run the consumer test and publish on post-merge, pre-deploy
2. Run `pact-can-i-deploy` on post-merge, pre-deploy
3. Deploy
4. Run the `record-deployment` script post deploy (and skip `create-version-tag` altogether)
And do something similarly on the provider side?
kerrypmckeever
2023-01-18 21:49
I'm a little unclear on the order by which pacticipants should be publishing their results when first setting up new consumers/providers.
Say I have a new consumer and provider and I set up my CI process to do the following:
*Consumer PR:*
1. Run consumer test
a. New contract should kick off the provider new contract verification task
2. Run `pact-can-i-deploy`
*Provider PR:*
1. Run provider verification test
2. Run `pact-can-i-deploy`
If I start the consumer test flow first, the provider new contract verification test will fail with `TypeError: providerVersion` because my provider is new and has not yet run.
If I start the provider test flow first, the provider verification will still fail because I have no consumer contracts to verify.
How do we avoid these types of race conditions? And will this be something to consider when we have multiple environments (dev, qa, prod, etc.) that the tests are running for the first time?
bethskurrie
2023-01-18 21:50
> the provider verification will still fail because I have no consumer contracts to verify.
kerrypmckeever
2023-01-18 21:52
Hey Beth! I'm actually in the middle of that right now after stumbling a bit in setting up my own applications' pact tests. I was testing the provider and consumer in the CI/CD workshop on "what if" scenarios, and this was one of them. I knew there was a switch for the consumer to not fail if the provider test wasn't yet executed, but wasn't aware the provider had a similar switch if the consumer wasn't yet published.
zhoutianli1234
2023-01-19 18:07
Hi,
For example I have App1 and App2. My App1 is the consumer and App2 is the provider. Now we are also having contracts the other way around where the App2 is the consumer and App1 is the provider. Keeping the same names, will it cause issues to the pact-broker?
Thank you
bethskurrie
2023-01-19 21:23
The Pact Broker will support it, but this kind of bi-directional relationship can cause problems
bethskurrie
2023-01-19 21:24
You can easily get into the situation where you can?t deploy either application because both apps are relying on a change from the other that is not yet deployed.
bethskurrie
2023-01-19 21:25
If you are going to do this, you have to be very careful to manage your release process so that you only ever have one changes for one dependency direction at a time.
tomknee1
2023-01-20 17:47
Hi there, we very occasionally (like 5% of the time or less) get this error during our `pactPublish` step in CI (which uses the pact broker CLI) and im unsure what is causing it or how to solve, hoping someone could give me some ideas / lead me in the right direction please? please see thread for the error output
tomknee1
2023-01-20 17:47
```
Status: Downloaded newer image for pactfoundation/pact-cli:latest
Cannot change the content of the pact for OtacProviderService version bab2e3650bef58ceae679ca4c8e31b5ba62b0fad and provider OtacProviderService, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see https://docs.pact.io/go/versioning
{
"response": {
"headers": {
- "Content-Type": "application/json; charset=UTF-8"
+ "Content-Type": "application/json;charset=UTF-8"
}
}
},
{
"response": {
"headers": {
- "Content-Type": "application/json;charset=UTF-8"
+ "Content-Type": "application/json; charset=UTF-8"
}
}
},
@@ -23,7 +23,7 @@
{
"response": {
"headers": {
- "Content-Type": "application/json; charset=UTF-8"
+ "Content-Type": "application/json;charset=UTF-8"
}
}
},```
tomknee1
2023-01-20 17:48
we follow git flow and this is on our PR / feature branches before being merged into `develop`
tomknee1
2023-01-20 17:49
the versioning on our consumer side follows the recommended git branch and short sha approach.
the provider side is trunk based development and follows the same on PR branches (and once merged into main uses image version tags)
chrisjburnscg
2023-01-21 16:02
Hello, Would someone with admin credentials to the `pact-foundation` be able to help me with regards to dependabots? I'm currently the maintainer for https://github.com/pact-foundation/pact-broker-chart and as an advocate of securing software supply chains, I wanted to do a couple of things over the next week or so around achieving this in mainly 2 areas.
1. Enable dependabot version and security updates https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuring-dependabot-version-updates - I can't enable it on the helm chart project itself, so this is why I might need someone with organisation priviledges to look into it - unless of course this would cause problems elsewhere
2. I want to push the OCI Helm Artifacts to the container registry that would come with github. So if folks wanted to install the Pact Broker onto Kubernetes using the Helm Chart, they can do so by using the new OCI format that is offered by `ghcr` (I can also sign these OCI artifacts using `cosign` which will give people the peace of mind that it's coming from the right place).
Both of the above queries I believe needs running by an admin to do, so thought I'd float it in this channel to get some traction.
matt.fellows
2023-01-23 00:58
I?ve enabled the other settings, I think you can set the dependabot file yourself now
matt.fellows
2023-01-23 01:00
I?ve also enabled the permission for members to create a public package - let me know if that works for you, I haven?t tried this myself.
matt.fellows
2023-01-23 01:00
In any case, just let us know what you need and we can get cracking for you
bethskurrie
2023-01-23 23:58
> the pacts havent changed so dont understand why that message appears
There?s a whitespace change in the headers.
bethskurrie
2023-01-23 23:59
While that is semantically identical, unfortunately, the tool that generates the SHA from the pact content does not know that, and hence, it generates a different SHA, and considers that the pact has been changed.
bethskurrie
2023-01-24 00:00
Why your pact tests are generating pacts with headers with a space 95% of the time, and without a space 5% of the time, I have no idea.
bethskurrie
2023-01-24 00:00
Is there a dependency that is not pinned exactly, and maybe you?re getting an unpredictable version installed?
bethskurrie
2023-01-24 00:01
I can see that you haven?t pinned the pact CLI (pactfoundation/pact-cli:latest) and that?s a bit dangerous. One day, there will be a major release, and things will Break.
bethskurrie
2023-01-24 03:12
You either give it a pact URL, OR you give it a base URL and a provider name.
matt.fellows
2023-01-24 03:12
Are you talking about packages? I might have to do a little more research. All the options are checked :man-shrugging:
tomknee1
2023-01-24 08:56
Thanks I will look to pin the pact cli. Not sure why the content type header changes as we dont set that explicitly in our tests, pact handles it
tomknee1
2023-01-24 09:15
i now this morning just got this error instead on pactPublish step...
```/usr/lib/ruby/gems/3.0.0/gems/json-2.6.2/lib/json/common.rb:216:in `parse': 859: unexpected token at 'gex": "application/json(;\\\\s?charset=[\\\\w\\\\-]+)?" (JSON::ParserError)
}
},
"status": 201
}
},
{
"description": "a request to reuse a Firebase token",
"providerState": "there is a valid, reusable terminal configuration",
"request": {
"body": {
"activation_code": "TK1474",
"serial_number": "0822382308"
},
"method": "POST",
"path": "/device/activate"
},
"response": {
"body": {
"token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ8.eyJpc3MiOiJhZy1zdGFnaW5nLW1vYmlsZUBhcHBzcG90LmdzZXJ2aWNlYWNjb3VudC5jb20iLCJhdWQiOiJodHRwczovL2lkZW50aXR5dG9vbGtpdC5nb29nbGVhcGlzLmNvbS9nb29nbGUuaWRlbnRpdHkuaWRlbnRpdHl0b29sa2l0LnYxLklkZW50aXR5VG9vbGtpdCIsImV4cCI6MTY0NjMxNjU5NiwiaWF0IjoxNjQ2MzEyOTk2LCJzdWIiOiJhZy1zdGFnaW5nLW1vYmlsZUBhcHBzcG90LmdzZXJ2aWNlYWNjb3VudC5jb20iLCJ1aWQiOiI0MTEwMDAzNyJ9.YQKzgFAmYGYi_ygkhBHVp6INGBsOuxGTwYFuwORovjx6uLM8Vs5m7DOa8BpLKfoZ9dSSm8XgsDeSsPH4c6C80eCm5kjJzhCYfI1_GL8uvkpWjqtT7jION7ybQZOoNMJ4rYTb4IyUOu06PG08VFBrt14uem-X_Kk_s-X_jnH2e81QHSvrM1ROCfDpkiDHic9S4op_zcaMPgKzC8vvJj5cY6Y11hPbhY2cb0z9BXIFql4S98rK96Hyw4JY2iWEt2dURtvYt-oyCWE4vP8uod3WEDZsrIc-3druPiZwbKp5Xx1S0MSuAwr8vs6mba5lkvreyoKNJAoxeHaJsnUigGl-Kg"
},
"headers": {
"Content-Type": "application/json; charset=UTF-8"
},
"matchingRules": {
"$.body.token": {
"match": "regex",
"regex": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ8.eyJpc3MiOiJhZy1zdGFnaW5nLW1vYmlsZUBhcHBzcG90LmdzZXJ2aWNlYWNjb3VudC5jb20iLCJhdWQiOiJodHRwczovL2lkZW50aXR5dG9vbGtpdC5nb29nbGVhcGlzLmNvbS9nb29nbGUuaWRlbnRpdHkuaWRlbnRpdHl0b29sa2l0LnYxLklkZW50aXR5VG9vbGtpdCIsImV4cCI6MTY0NjMxNjU5NiwiaWF0IjoxNjQ2MzEyOTk2LCJzdWIiOiJhZy1zdGFnaW5nLW1vYmlsZUBhcHBzcG90LmdzZXJ2aWNlYWNjb3VudC5jb20iLCJ1aWQiOiI0MTEwMDAzNyJ9.YQKzgFAmYGYi_ygkhBHVp6INGBsOuxGTwYFuwORovjx6uLM8Vs5m7DOa8BpLKfoZ9dSSm8XgsDeSsPH4c6C80eCm5kjJzhCYfI1_GL8uvkpWjqtT7jION7ybQZOoNMJ4rYTb4IyUOu06PG08VFBrt14uem-X_Kk_s-X_jnH2e81QHSvrM1ROCfDpkiDHic9S4op_zcaMPgKzC8vvJj5cY6Y11hPbhY2cb0z9BXIFql4S98rK96Hyw4JY2iWEt2dURtvYt-oyCWE4vP8uod3WEDZsrIc-3druPiZwbKp5Xx1S0MSuAwr8vs6mba5lkvreyoKNJAoxeHaJsnUigGl-Kg"
},
"$.headers.Content-Type": {
"match": "regex",
"regex": "application/json(;\\\\s?charset=[\\\\w\\\\-]+)?"
}
},
"status": 200
}
}
],
"metadata": {
"pact-jvm": {
"version": "4.3.5"
},
"pactSpecification": {
"version": "2.0.0"
}
},
"provider": {
"name": "OtacProviderService"
}
}
'```
chrisjburnscg
2023-01-24 10:33
I haven't tried packages yet, I only tried to see if the dependabot was available in the security settings for the repo
bethskurrie
2023-01-24 22:24
I?m guessing that something in `"application/json(;\\\\s?charset=[\\\\w\\\\-]+)?"` is not parsing properly.
bethskurrie
2023-01-24 22:26
> Not sure why the content type header changes as we dont set that explicitly in our tests
Could you be getting a different version of pact-jvm in some builds?
matt.fellows
2023-01-25 05:03
ah! Looks like I need to explicitly add you. Done. Could you please try again?
tomknee1
2023-01-25 08:51
looking at the generated pacts file i think maybe i already made a change that could potentially fix it?
tomknee1
2023-01-25 08:53
as i dont see the `"application/json(;\\\\s?charset=[\\\\w\\\\-]+)?"` in there anywhere :confused: will keep an eye out to see if this issue pops up again, its been pretty random and infrequent
tomknee1
2023-01-25 08:56
its possible the failed CI build that someone on my team shared with me probably needed rebasing or something to get latest pact changes that I made :thinking_face: and has looked to be fine after that fact
matt.fellows
2023-01-27 00:04
Yep! I?ve just made the group admin. I don?t know what else I can do if this doesn?t work!
chrisjburnscg
2023-01-27 17:28
Thanks @matt.fellows I'll give the dependabot and OCI images a go over the weekend :+1:
chrisjburnscg
2023-01-27 22:08
Well, that didn't take long :smile: Dependabot is configured and working well, and even got the signed OCI Charts for the pact broker too https://github.com/pact-foundation/pact-broker-chart/pkgs/container/pact-broker-chart%2Fpact-broker
Thanks again for your help :sunglasses:
jorgen.x.andersson
2023-01-30 07:42
Hi,
First time interacting here, so please forgive me if I'm in the wrong place and please point me to any documentation my question indicates I might have missed.
Since I'm really interested in issues https://github.com/pact-foundation/pact-broker-docker/issues/88, https://github.com/pact-foundation/pact-broker-docker/issues/92, https://github.com/pact-foundation/pact-broker-docker/issues/93 of the pact-broker-docker repo I've done the upgrades locally in any places of the repo where I could find the version numbers. I've also run the build and test commands described in https://github.com/pact-foundation/pact-broker-docker/blob/master/RELEASING.md. And I've tried to poke around a bit in the GUI after starting the Pact-Broker up. To me, it seems to work just fine, but since I'm totally new to the product that might not mean a whole lot.
The reason I want these issues fixed (and ideally also https://github.com/pact-foundation/pact-broker-docker/issues/94, which I still haven't had a look at) is that I need the security issues out of the way to be able to bring the Pact-Broker into my organisation for further testing and evaluation.
Now for my questions:
? Is there any other documentation to follow on how to contribute to the pact-broker-docker repo that I might have missed?
? Are there any other test suites that should/could be run against an upgraded docker image?
? Would it be helpful to you if I packaged my changes up into three pull-requests, one for each issue?
? The issues got comments about a Jira-ticket being created. However, I haven't been able to find any link or hint to where that Jira-instance might be located, hence not been able to read up on any ongoing discussions or work on the issues. Any hints on this would be appreciated.
Best Regards
Jörgen
matt.fellows
2023-01-30 11:27
Hello and thanks for raising the issues and your interest in helping - it?s much appreciated!
This label, and the corresponding ticket is just a reference to a Smartbear team?s backlog. Basically, it means that we will pick up the work and get it done. We are just toying around with the best ways to track work across OSS and within our organisation to create visibility, so our apologies whilst the process is not documented - perhaps we can have the bot put more information in the response, so the next steps are clearer (cc @ilia).
I?ll wait for a maintainer to respond with more info, but I can?t see why a PR that upgrades the dependencies and makes the security issues go away wouldn?t be helpful. I think it might need to be in upstream repositories though.
bethskurrie
2023-01-30 21:26
I'll accept any PRs that fix vulnerabilities. If they're not fixed, it's because I haven't had time to look at them. The tests that run in Github Actions are enough to ensure any changes are OK.
bethskurrie
2023-01-30 21:43
I'm glad it's working, but it is very annoying not to be able to work out why!
jorgen.x.andersson
2023-02-01 07:12
@bethskurrie It seems the build/test-flows for my three PR:s (#98, #99 and #100) failed due to not being able to login to DockerHub
`Run script/release-workflow/docker-login.sh`
`Error: Cannot perform an interactive login from a non TTY device`
`Error: Process completed with exit code 1.`
A temporary failure? Could they be easily restarted?
bhavyashree.r
2023-02-01 08:46
Hi.. Is it possible to host pact broker centrally without using pactflow ? If yes can someone please help me with the steps .
jorgen.x.andersson
2023-02-01 09:05
This seems to be a good place to start: https://hub.docker.com/r/pactfoundation/pact-broker
Haven't tried it myself yet though.
chrisjburnscg
2023-02-01 19:24
It is, we host it on Kubernetes like any other application and connect it to an external RDS database.
chrisjburnscg
2023-02-01 19:24
You can use the Helm Chart here https://github.com/pact-foundation/pact-broker-chart
Disclaimer, I'm the maintainer :slightly_smiling_face:
chrisjburnscg
2023-02-01 19:25
If you want to go another route like EC2 or any other variant in Azure or GCP, I'm pretty sure you can. The Docker image is available as normal, so the hosting possibilities are plentiful in that way
jorgen.x.andersson
2023-02-02 13:12
With regards to security issues with mariadb-dev package in AlpineLinux (https://github.com/pact-foundation/pact-broker-docker/issues/94), a solution that would remove many of the problems would be to upgrade to Alpine-3.17. However, there seem to be no Ruby-2.7.6-Alpine-image available after ruby:2.7.6-alpine3.16, Further upgrades would require migrating Pact-Broker to Ruby 3.0 or 3.1. I can't find any written information (issue or technical roadmap) describing such plans.
According to https://endoflife.date/ruby Ruby 2.7 is to be EOL at the end of March 2023. Is there a planned way forward for Pact-Broker that you can share?
matt.fellows
2023-02-03 06:32
TL;DR - yes there are plans. It?s on our PactFlow roadmap (which would necessitate the OSS broker also supporting it)
matt.fellows
2023-02-03 06:33
@bethskurrie should we created a V3 upgrade issue and link it to our Jira?
bethskurrie
2023-02-04 02:30
Peeps, due to some issues with the versioning scheme we're currently using for the docker image (it's impossible to convey breaking changes semantically for anything other than the pact_broker gem) I'm proposing a change to the way we do the versions. Would love thoughts here if you're someone who cares about that kind of thing :laughing: (cc @tjones) https://github.com/pact-foundation/pact-broker-docker/discussions/102
bethskurrie
2023-02-04 02:32
I know there were some other people concerned with the version number the last time we had to upgrade the alpine image, but I can't find the discussion due to the fact we're on the free Slack workspace.
tjones
2023-02-04 02:33
> Would love thoughts here if you?re someone who cares about that kind of thing :laughing: (cc @tjones)
Also, lol @ this
gazal.gafoor
2023-02-04 04:11
somewhat tangential to this discussion, how about alias tags like `0` (to pin to the major version) and `0.51` (to pint to the minor version) ?
Perhaps a variant of that to accomodate
```<Major>.<Minor>.<Patch>_with_pactbroker.v<pact_broker_gem_version>```
jorgen.x.andersson
2023-02-04 16:17
I created an issue for upgrading to Ruby 3.1.3 (or higher) which is needed to use Alpine Linux 3.17:https://github.com/pact-foundation/pact_broker/issues/599
gustavs.slutins
2023-02-06 16:27
Hello. Would appreciate a bit of a helping hand. We have some verification tests failing due to a 500 response from the broker. The url is: Request to path 'https://pact-broker.url/pacts/provider/provider-name/for-verification' failed with response 500 . There was no error message printed, so just wandering what could cause such a response?
This seems to only happen when a new branch is built, but master is always passing the build.
bethskurrie
2023-02-07 03:52
You?ll need to enable verbose logging for your client so you can see the full response.
gustavs.slutins
2023-02-07 11:59
@bethskurrie @matt.fellows We didnt see error logs from the broker. What is the way to enable verbose logging for pact? We are using java and maven goals to run our pact tests.
james.perepiczka
2023-02-08 09:40
Hi, I?ve got a question around the pact webhooks. Do they only get evaluated for use after a contract has been published? I was wondering what would happen in a scenario where for example there was a period of time where you were not publishing provider verification results and then started and implemented can i deploy, record deployments etc. If you ended rolling back to an older provider version, there might not be a contract verification so my question is, if a rollback doesn?t trigger a publish, is there no way to trigger a custom verification of the provider? Also, does can i deploy (consumer side) ever trigger a webhook? For background, we do not publish contracts post merging into trunk, we use can-i-deploy/record deployment from then on so curious what would happen in this scenario
matt.fellows
2023-02-08 10:17
In that scenario, I believe the answer is no. The events are triggered based on a publication, so it wouldn?t know to trigger
matt.fellows
2023-02-08 10:18
Is the concern that version A of the provider went to production, and then you started contract testing and version B of the provider was deployed which has passed all the contract testing checks.
Later on, you realised B needed to be rolled back, but `can-i-deploy` would fail, because A had never verified anything?
james.perepiczka
2023-02-08 10:31
I was hoping that maybe something would trigger an interaction at that point. I figured because you can configure a wait with can-i-deploy that it had the capability of triggering the interaction without a contract publish
james.perepiczka
2023-02-08 11:24
I have another related question to the above. If Provider Version A is the version in production (and has been ?deployed? to that environment using record deployment). If the contract expectation is changed by the consumer and the latest provider version B has validated the contract. How would the consumer find out if it is compatible or not with version A of the provider?
matt.fellows
2023-02-08 11:40
I don't think so. It feels a bit edge-casey. Is there a way you could just ensure the currently deployed version is also included in the initial pact rollout?
matt.fellows
2023-02-08 11:41
A can I deploy check from the new consumer version against the production target would yield a negative response
matt.fellows
2023-02-08 11:43
Which is what you'd expect. B needs to be deployed before the consumer can release
james.perepiczka
2023-02-08 11:57
Just to clarify in case I have misunderstood (reading this document - https://docs.pact.io/pact_broker/set_up_checklist). For the provider, when the verification takes place, should it validate all environments at once? so any test and production contracts from the consumer?
jeroenlamain
2023-02-08 12:11
Hi, is installing the pact broker (open source) using a prefix path supported or recommended? I have deployed the broker on aws using a name like http://blbla.aws.com/pact-broker. I can log in and do api calls. However, i have multiple problems using client libries. (1) the jvm @provider annotation does not support a path (I think) (2) using the pact-js libraries I could publish the consumer contract but could not verify as the native verifier could not download the consumer contract. Has anyone deployed the pact broker using a prefix path?
james.perepiczka
2023-02-08 12:11
And if that is the case, will it prevent the deploying of a provider to trunk or an environment because the prod consumer is not compatible?
jeroenlamain
2023-02-08 12:22
Well figured out that for JVM i could fix it by this annotation:
@PactBroker(
host = "http://blbla.aws.com/pact-broker",
scheme = "https",
)
tommy.chen
2023-02-10 00:41
Hey team, this is Tommy from Culture Amp and we are using pactflow. I got the ssl error as the screenshot when I tried to publish a pact while @vietanhtran.dev ran the same command I send to him and it?s working on his laptop. Does anyone have some ideas?
tjones
2023-02-10 00:55
For pactflow support try #pactflow - but generally -
? Do you have a VPN?
? Do you have custom SSL certificates (and are they set correctly on your machine?)
matt.fellows
2023-02-10 01:06
This is almost certainly a client language problem. What client are you using?
tjones
2023-02-10 01:06
Just checking my understanding - am I right that the broker can store arbitrary json contracts, but only one per service pair? like, if I have:
ServiceA (@ v1.0.0) -> ServiceB, and I publish a contract of one type, I can?t publish another contract between ServiceA (@ v1.0.0) with ServiceB without overwriting the first one?
tommy.chen
2023-02-10 01:06
Yeah, the vpn is a compulsory one - netskope. Every one at culture amp is using it. I dont think I have a custom SSL certificates? I am going to ask in #pactflow
matt.fellows
2023-02-10 01:07
yes that?s right. The contract can be any JSON, but the model is that it contains everything needed by that consumer version of a given provider.
matt.fellows
2023-02-10 01:07
I don?t think it?s a PactFlow issue. Our certs are standard public issue
vietanhtran.dev
2023-02-10 01:07
> What client are you using?
we are just using `pactfoundation/pact-cli:latest` docker image
matt.fellows
2023-02-10 01:07
This smells of corporate proxy that is intercepting your requests and breaking the certificate chain
tjones
2023-02-10 01:08
Right. That?s what I thought. It?s a shame, because all the merge-contract-file problems go away if you let multiple contract files be published for the same version
vietanhtran.dev
2023-02-10 01:08
hmm I am also working at the same company as Tommy but not getting this error :thinking2:
pryan
2023-02-10 03:17
Hello! I have been toying with the example ruby application and pact broker. I thought things were really starting to make sense, but I do not understand what the environments tab is showing me. It seems insistent that the provider version is always identical. It complains that the 'pact from main has changed', but I don't think it has?
pryan
2023-02-10 03:21
For example, I got back and try and verify the provider again against he main branch in QA, now the provider changes for both environments. Every other tab makes sense, more or less. Perhaps I am missing something fundamental here...
pryan
2023-02-10 03:27
I am referencing from here: https://docs.pact.io/pact_broker/recording_deployments_and_releases#environments
I am using the `pact-broker record-deployment` command. And so far the can-i-deploy tool seems to be consistent when my understanding as well.
pryan
2023-02-10 03:41
I'm guessing this has something to do with branches, versions, and the behavior of implicit/explicit 'latest'.
tjones
2023-02-10 04:55
I?m confused too. I would have thought that the second row should have both displaying `env: qa`
tjones
2023-02-10 04:57
I wonder if the last verified warning state is global (as in, there?s a change to the pact on the branch that this contract is from, but it?s not deployed to qa?)
tjones
2023-02-10 04:58
I?m not super familiar with the broker UI - I mostly use can-i-deploy and trust that
matt.fellows
2023-02-10 12:11
That might be a separate concern (publishing vs the relationship itself) but logically there is one contract. The broker does have a feature to merge a contract on upload, it's not well advertised/ used however
matt.fellows
2023-02-10 12:12
One problem I envisage would be knowing when you have all of the interactions covered in a verification or can-i- deploy scenario race condition.
matt.fellows
2023-02-10 12:17
Can you please add the verbose flag and share the results? This will help us see what is going on.
achuljyan
2023-02-10 16:11
Hello,
I'm running *can-i-deploy* for "*myservice*" application by providing a application version which doesn't exist in *pact-broker* and it returns "*No*" as expected:
`pact-broker can-i-deploy --pacticipant=myservice --broker-base-url=https://my.cool-pact-broker.com --version=f7a284be9046416fad7a577bb52737af571dd6d1 --to-environment=prod`
`Computer says no ¯_(?)_/¯`
`No pacts or verifications have been published for version f7a284be9046416fad7a577bb52737af571dd6d1 of myservice`
Then I'm running pact-broker *create-or-update-version* by providing that version:
`pact-broker create-or-update-version --pacticipant=myservice --broker-base-url=https://my.cool-pact-broker.com --version=f7a284be9046416fad7a577bb52737af571dd6d1`
And after that I'm running *pact-broker can-i-deploy* again
`pact-broker can-i-deploy --pacticipant=myservice --broker-base-urlhttps://my.cool-pact-broker.com --version=f7a284be9046416fad7a577bb52737af571dd6d1 --to-environment=prod`
`Computer says yes \o/`
`There are no missing dependencies`
And it returns "*yes*" for all the environments for that particular version.
Is this behavior expected?
tjones
2023-02-11 13:02
> The broker does have a feature to merge a contract on upload, it?s not well advertised/ used however
I don?t think you could do this without knowing the semantics of the contract, right?
matt.fellows
2023-02-12 23:49
I think it?s expected, because if there are no dependencies, none of the dependencies can be broken, so from an integration point of view it?s safe
matt.fellows
2023-02-13 01:22
I think it merges it remotely using the same business rules as if it were set to `merge` . e.g. it will continue to append interactions, until it sees a conflicting interaction (I believe by uniquely identifying them based on description, state and possibly http bits).
matt.fellows
2023-02-13 01:22
but yes, effectively it must know something about the type of contract - that is, a pact file
achuljyan
2023-02-13 09:00
Hey @matt.fellows.
Yes, it has. This microservice has multiple providers with published and validated contracts. In the CI flow we're building, we don't allow the pipeline to fail during the pact test stage and let can-i-deploy to control (to pass/fail) the pipeline. We run the create-or-update-version command to avoid other following Pact Broker commands failing due to a missing version in Pact Broker if the Pact test fails. But after the create-or-update-version command, can-i-deploy returns yes, although there are no published/verified pacts for this version, but there are existing dependencies for the previous versions in Pact Broker.
matt.fellows
2023-02-13 10:40
I think that?s probably the problem. That _version_ *doesn?t* have any dependencies - other versions might and they aren?t deployable.
@bethskurrie can probably clarify for me, but logically that?s how I would think of it.
matt.fellows
2023-02-13 10:41
> we don?t allow the pipeline to fail during the pact test stage and let can-i-deploy to control (to pass/fail) the pipeline
why?
That?s like saying ?if my unit tests fail, i?ll still deploy if my end-to-end tests pass?
achuljyan
2023-02-13 11:57
don't quite agree, deployment shouldn't happen due to a failure in the "can-I-deploy" stage
achuljyan
2023-02-13 12:00
> why?
Reason to do it this way:
Our release engineering team is currently not using webbooks for some reason and is triggering a pact verification pipeline based on GitLab dependencies on pact publishing stage. This approach avoids the failure of the pipeline at this stage for this type of contract testing pipeline configuration in case the downstream pact verification pipeline fails for any reason not related to the contract, but the published pact is not changed and previously successfully verified.
achuljyan
2023-02-13 12:23
> I think that?s probably the problem. That _version_ *doesn?t* have any dependencies - other versions might and they aren?t deployable.
my understanding is that dependencies are more about the Pacticipant and not the specific version. If a version exists in Pact Broker but has not been verified, "can-I-deploy" should answer "NO" with the reason "not verified for that version".
rbenbolton
2023-02-13 21:43
Hey all, after a couple years I'm back to setting up pact for a new employer. I've deployed a pact broker to our internal private network in AWS and we've successfully published consumer tests to it. However, we're getting a strange error when pulling down and executing tests on the provider side:
We created several new contract tests with matchers and pushed it to Pact BrokerWhen we execute the tests, the tests pass, but we're left with a failed test run overall.
```2023-02-10T14:02:52.604594Z INFO ThreadId(28) pact_verifier: Publishing verification results back to the Pact Broker
2023-02-10T14:02:54.102596Z INFO ThreadId(28) pact_verifier: Results published to Pact Broker
2023-02-10T14:02:54.102673Z ERROR ThreadId(28) pact_verifier: Failed to load pact - Could not load pacts from the pact broker 'https://pact.broker.io'
Verifying a pact between Open API and User Service
a request for an user
Given an user exists
returns a response which
has status code 200 (OK)
includes headers
has a matching body (OK)
a request for the second user
Given more than 1 user exists
returns a response which
has status code 200 (OK)
includes headers
has a matching body (OK)
a request for two users
Given at least 2 users exists
returns a response which
has status code 200 (OK)
includes headers
has a matching body (OK)
Failures:
1) Failed to load pact - Could not load pacts from the pact broker 'https://pact.broker.io'
There were 1 pact failures
[11:02:54.455] ERROR (74633): pact-core@13.13.3: Verification unsuccessful```
The provider side clearly downloaded and executed the tests, but for some reason says the pacts could not be loaded. Anyone seen this behavior?
bethskurrie
2023-02-13 21:44
?Failed to load pact? is a very unhelpful error, and I?ve been meaning to get it improved. It?s in the rust core. You will need to turn on the debug logging to find out what the issue is.
bethskurrie
2023-02-13 21:46
> my understanding is that dependencies are more about the Pacticipant and not the specific version
bethskurrie
2023-02-13 21:49
Imagine the scenario where a consumer microservices is deleted, and stops publishing pacts. If you calculated the dependencies at the application level, then this dependency would never go away.
bethskurrie
2023-02-13 21:53
> It complains that the ?pact from main has changed?, but I don?t think it has?
This logic may or may not be helpful. I wouldn?t pay too much attention to it if it?s not what you expect, and everything else is working fine.
bethskurrie
2023-02-13 21:54
> I don?t think you could do this without knowing the semantics of the contract, right? (edited)
bethskurrie
2023-02-13 21:56
Correct - merging pacts is one of the pact specific features. It was added to support the scenario where JVM tests were split across different nodes running in parallel. I don?t advertise it because it?s a pain to support and introduces all sorts of problems with webhooks.
bethskurrie
2023-02-13 21:57
I encourage people to merge them on the client - the pact publication CLI does the merging client side before it publishes them, if it finds pacts with the same consumer/provider/spec version.
bethskurrie
2023-02-13 21:58
You should be able to set the SSL_CERT_FILE or SSL_CERT_DIR environment variables to provide it with the correct certificate.
bethskurrie
2023-02-13 21:59
At one stage I was working on a design to allow multiple contract types per version, but ron decided it would be better to merge them into one pact file, and support that in the pact specification.
pryan
2023-02-13 22:05
I have the main branch/versions of the provider consumer deployed in QA , which makes sense in the 'no filter' tab.
But when I switch to the environment tab, it's showing a different consumer version from a different branch which was deployed to a different environment in the same row, and showing a verification warning.
pryan
2023-02-13 22:07
I guess I just don't understand why this is happening, or what the environment tab is trying to show me. It seems inconsistent to me?
I would expect each row to represent the latest versions deployed to that environment. I would not expect two different environments in the same row.
But I expect I am simply misunderstanding something.
bethskurrie
2023-02-13 22:08
If the same version is deployed to two environments, it bunches them together.
bethskurrie
2023-02-13 22:08
I?m afraid I don?t have the time right now to fully understand the problem.
bethskurrie
2023-02-13 22:09
If you?d like to raise an issue in the pact_broker repo, then please either share your database with me, or recreate the scenario using this tool https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
andrevdrodrigues
2023-02-13 22:15
Hello everyone!
Im trying to publish pact locally in windows using pact-cli image directly:
`docker run pactfoundation/pact-cli:latest publish C:\pacts\consumer-provider.json --consumer-app-version 0.0.1 --broker-base-url http://localhost:9292/`
However, the pact throws this error:
Specified pact file 'C:/pacts/consumer-provider.json' does not exist. This sometimes indicates one of the arguments has been specified with the wrong name and has been incorrectly identified as a file path.
The file exists and is properly stored in this folder in my windows.
Anyone can help me on that? Thanks a lot!
matt.fellows
2023-02-13 23:04
Strange. It looks like it has verified and published results. My guess is there are multiple arguments to the verifier - can you please share the args you are passing to it? Or if it?s a language, how you are configuring the verification?
rbenbolton
2023-02-13 23:05
Thanks Matt! I'll run it again with debug logging and share the arguments to the verifier.
matt.fellows
2023-02-13 23:37
They shouldn?t need to do that Beth, because it?s a PactFlow account. I suspect corporate proxy, so they should just need to skirt around it
matt.fellows
2023-02-14 06:01
> The dependencies are on that particular version.
If you think about it, it _has_ to be this way. One minute the application has 0 dependencies, and the next minute it has 1. When it has 0 it is always safe to release (as far as Pact is concerned). Once it has a dependency, we then have more information to check (is the dependency relationship satisfied) before we let it through
matt.fellows
2023-02-14 06:04
> don?t quite agree, deployment shouldn?t happen due to a failure in the ?can-I-deploy? stage
In case I wasn?t clear, I see a pipeline as a serious of stages that must be passed before moving on to the next.
If your unit tests fail, usually in a ?pipeline? you wouldn?t proceed to the next step (you might, to get additional feedback) but at th every least, the pipeline would still fail because an important check failed.
Pact tests should be thought of as (something like) a unit test that checks you can effectively collaborate with other applications. If these tests fail, it should be a clear warning sign that something is wrong.
andrevdrodrigues
2023-02-14 14:34
Hi @beth (http://pactflow.io/Pact Broker/pact-ruby), could you gimme some idea about what can be occurring here at this point?
Is stranged because by pactBrokerApi I could publish properly.
yousafn
2023-02-14 16:41
Hi @andrevdrodrigues,
Please don't directly tag maintainers, they will respond if/when they get time
yousafn
2023-02-14 16:41
Please see the readme, you need to volume mount your pacts into the docker container
yousafn
2023-02-14 16:44
https://github.com/pact-foundation/pact-ruby-cli#publish-pacts
you can see the `-v` command being using to mount the working directory, into the container.
The files are `$PWD/example/pacts` are being used to publish, assume you are running the docker command from the root of this repo
https://github.com/pact-foundation/pact-ruby-cli
so you would volume mount to pact directory, or file into the container with regular docker syntax, and then provide the path (to the file in the container) not on your root filesystem
yousafn
2023-02-14 16:49
np, also worth noting that you may need to change the hostname for your local broker, on mac/windows machines in the cli command
https://docs.docker.com/desktop/networking/#i-want-to-connect-from-a-container-to-a-service-on-the-host
achuljyan
2023-02-14 17:24
Agree @matt.fellows. But imagine you're not using Pact Broker webhooks and running pact validation by running a downstream pipeline based on GitLab dependencies. This means that you can't distinguish between cases where the contract is published unchanged, and there is no need to run a contract validation and your contract check will always run (which is actually not good). And now you want to avoid the consumer contract test failing if the contract validation pipeline fails for a reason unrelated to the contract test. So, for such type of configuration this could be a solution to avoid contract unrelated failures and would make the contract testing flow more stable. Of course assuming that "can-i-deploy" is completely reliable
achuljyan
2023-02-14 17:25
hi @bethskurrie
What if if we remove pacticopant in this case? I thought we had something like "pact-broker remove-pacticipant" for this purpose, but I think we can remove pacticipant with curl DELETE anyways.
achuljyan
2023-02-14 17:25
Let me ask another question,
in our flow, we would like to allow deployment to test environments in case if the contract test fails using some config flag(we would like to make this configurable for some cases). In this case, we'd like to record the deployed version of the microservice to Pact Broker despite of the contract test failure (so to keep the correct version about the deployed application). Therefore, we need to call "create-or-update-version" to avoid the "record-deployment" command failure. What do you think about it? What pitfalls can we face in this case? Surely excluding this particular deployment, given the obvious fact that we are deploying a microservice that has not passed the contract test.
andrevdrodrigues
2023-02-14 20:35
Hi Yousaf.
Just to leave it here for other people who eventually had the same question... The final command in windows:
```docker run --network="host" --rm -it -v ${PWD}/pacts:/example/pacts pactfoundation/pact-cli:latest publish /example/pacts --consumer-app-version 0.0.1 --broker-base-url http://localhost:9292```
rbenbolton
2023-02-14 21:57
Ok, @matt.fellows @bethskurrie Here's the full execution details for the tests.
carlos.lopez
2023-02-14 22:25
Hello guys!
I'm implementing BDCT using an OAS file provided by a banking platform. The file is in JSON file and it's working fine in Swagger editor. Based on https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas/keyword-support I've been reading, it's recommended to dereference the nodes of the file, and that's what I've done. However, I noticed I get errors like this when comparing pacts in Pactflow (see screenshot too):
```Unable to parse "oas": Swagger schema validation failed. Data does not match any schemas from 'oneOf' at #/paths//v1/plan-migrations:batchGet/get/responses/200 Data does not match any schemas from 'oneOf' at #/paths//v1/plan-migrations:batchGet/get/responses/200/content/application/json/schema Data does not match any schemas from 'oneOf' at #/content/application/json/schema/properties/plan_migrations Data does not match any schemas from 'oneOf' at #/properties/plan_migrations/additionalProperties Data does not match any schemas from 'oneOf' at #/additionalProperties/properties/supervisor_contract_version_migration Expected type array but found type boolean at #/properties/supervisor_contract_version_migration/required Missing required property: $ref at #/properties/supervisor_contract_version_migration Missing required property: $ref at #/additionalProperties Expected type boolean but found type object at #/additionalProperties Missing required property: $ref at #/properties/plan_migrations Missing required property: $ref at #/content/application/json/schema Missing required property: $ref at #/paths//v1/plan-migrations:batchGet/get/responses/200 JSON_OBJECT_VALIDATION_FAILED```
In particular, the original format of the node producing the error is as follows:
```"supervisor_contract_version_migration": {
"$ref": "#/components/schemas/plansSupervisorContractVersionMigration",
"required": true
}```
After dereference it, I get the following:
```"supervisor_contract_version_migration": {
"required": true,
"type": "object",
"properties": {
"from_supervisor_contract_version_ids": {
"type": "array",
"items": {
"type": "string"
},
"description": "The Supervisor Contract version IDs to migrate plans from.\n\nRequired.\nMin count: 1."
},
"to_supervisor_contract_version_id": {
"type": "string",
"description": "The Supervisor Contract version ID to migrate the plans to.\n\nRequired."
},
"schedule_migration_type": {
"description": "Specifies how existing schedules should be migrated.",
"x-release-info": {
"releaseVersion": {
"major": 2,
"minor": 4
},
"changeType": "ADD_FIELD"
},
"type": "string",
"enum": [
"SCHEDULE_MIGRATION_TYPE_RECREATE_ALL_SCHEDULES_AND_GROUPS",
"SCHEDULE_MIGRATION_TYPE_PRESERVE_SCHEDULES_IF_NO_GROUP_CHANGES"
],
"default": "SCHEDULE_MIGRATION_TYPE_RECREATE_ALL_SCHEDULES_AND_GROUPS",
"x-enum-value-descriptions": {
"SCHEDULE_MIGRATION_TYPE_PRESERVE_SCHEDULES_IF_NO_GROUP_CHANGES": "When updating the Supervisor Contract version of a plan, existing schedules are preserved if either: * They are not part of a group and a schedule of the same event type is defined in the new Supervisor Contract code; or * They are part of a group and a group of the same name, size and order is defined in the new Supervisor Contract code. New schedules are only created if they are defined in the new Supervisor Contract code.",
"SCHEDULE_MIGRATION_TYPE_RECREATE_ALL_SCHEDULES_AND_GROUPS": "When updating the Supervisor Contract version of a plan, all existing schedules will be deleted then recreated according to the Supervisor Contract code of the new product version. Any updates previously made to existing schedules will not be preserved. This is the default behaviour."
}
}
}
}```
It looks like the offending property is `"required": true` which comes from the original content. That property also shows a warning in Swagger editor (see screenshot). As stated in the https://swagger.io/docs/specification/using-ref/, the warning informs that "_Any sibling elements of a `$ref` are ignored. This is because `$ref` works by replacing itself and everything on its level with the definition it is pointing at._" However, the Pactflow validator fails ignoring those properties.
Is there chance this can be handled by Pactflow transparently instead of producing a validation error? Is there any other way to address this issue on my side?
Thanks.
matt.fellows
2023-02-15 00:03
Thanks Ben, that does look to be `INFO` level. The `logLevel` property should be all you need to set.
It?s strange that it can?t find the pacts, but is still verifying something. Are you specifying both a file and a pact broker? Perhaps it can verify the local pact, but can?t connect to the remote broker?
rbenbolton
2023-02-15 00:04
Oh shoot, I had a previous snippet with the log level but it was super long. I made some changes and included a new one that removed the log level. So sorry. Let me change that again.
matt.fellows
2023-02-15 00:06
If you know in advance to ignore the failed contract tests, you don?t need a flag on any of the pact CLI commands - you can guard against that in your script that calls it.
`record-deployment` doesn?t care about the result of the contract test, it is stating a fact - `version X of application Y has been deployed to environment Z`. So you can still call that.
I think what will happen eventually is that you?ll get stuck in some loop, where `can-i-deploy` won?t let you deploy to a certain environment because you?ve brute forced your way around the checks. This will then lead to a serious of guards in your scripts to ignore checks for certain applications under certain conditions, which I think will be a mess to maintain.
matt.fellows
2023-02-15 00:32
hello! Just an FYI, this is a #pactflow question (it?s not a feature in the open source pact broker, which is what this channel is for)
matt.fellows
2023-02-15 00:33
It might be possible. If you remove the `required` property, do things work?
matt.fellows
2023-02-15 00:36
hmm that was marginally more helpful :laughing:
I?m so sorry, could you please try again with `trace` :grimacing:
matt.fellows
2023-02-15 01:12
hmm thanks. Something isn?t right with the logging, it looks like the core is not spitting out trace/debug logs. The JS library is, so I might need to dig into why we aren?t getting that visibility.
bethskurrie
2023-02-15 02:22
How is this for an improved error message?
```"Specified pact file '#{path}' does not exist. This sometimes indicates one of the arguments has been specified with the wrong name and has been incorrectly identified as a file path. If you are using Docker, check that you have mounted the pact file or directory into the container correctly using `-v`, and have specified the location of the pact file or directory in the *Docker container*, not the *host*."```
bethskurrie
2023-02-15 02:31
I?ve also added: https://github.com/pact-foundation/pact-ruby-cli#docker-gotchas
carlos.lopez
2023-02-15 12:42
It works if I remove the `required: true` attribute. Wondering if there is a way Pactflow validator can ignore it. The problem I have is that the OAS document I got is huge and it would be nice if the Pactflow validator were more flexible.
achuljyan
2023-02-15 14:02
Thank you Matt, I agree with you that this is not a good practice, but from time to time we have to deal with this.
And with regards to deployment recording.. if the pacticipant version does not exist in Pact Broker, then record-deployment for that version fails: `service-X, version Z not found (error requesting https://pact-broker... status=404)`
So, to record a consumer version deployment that has not published a pact file, you must call create-or-update-version on that version of the consumer.
rbenbolton
2023-02-15 15:37
My apologies, I misunderstood, thinking there was some kind of verification token I was missing. Here's the Verifier code:
```import { Verifier, VerifierOptions } from '@pact-foundation/pact';
// import path from 'path';
describe('Pact Verification', () => {
const opts: VerifierOptions = {
provider: 'api.open',
pactBrokerUrl: 'https://pact.broker.io',
pactBrokerUsername: 'pact',
pactBrokerPassword: 'broker',
// // publishVerificationResult: http://process.env.CI === 'true',
publishVerificationResult: true,
providerVersion: '1',
providerBaseUrl: `http://localhost:4003`,
pactUrls: [
'https://pact.broker.io/pacts/provider/User%20Service/consumer/Open%20API/latest',
],
// stateHandlers: {
// 'an user exists': () => {
// return Promise.resolve(`User already seeded`);
// },
// },
logLevel: 'trace',
};
it('validates the expectations of Matching Service', () => {
return new Verifier(opts).verifyProvider().then(() => {
// console.log('Pact Verification Complete!');
});
});
});```
rbenbolton
2023-02-15 15:38
On a side note, I'm also getting a Typescript error trying to use that `stateHandler` I'm having trouble with, if anyone has seen something similar.
carlos.lopez
2023-02-15 17:21
@matt.fellows, after a lot of trial & error, I managed to address my issue and now Pactflow can read & parse the entire OAS file successfully.
Looks like Pactflow validator crashes/complains when it runs into a node having `"$ref"` and `"required"` sibling attributes together. Per the OAS standard, "_Any sibling elements of a `$ref` are ignored. This is because `$ref` works by replacing itself and everything on its level with the definition it is pointing at._" More info this https://swagger.io/docs/specification/using-ref/ .
This is the sort of changes I have to do manually:
file:///tmp/image.png
Is there a chance of the Pactflow validator ignoring all `"required"` attributes whenever a sibling `"$ref"` attribute is present?
bethskurrie
2023-02-15 20:37
This is the channel for the Pact Broker. That's a problem with the Pact js library, which I can't help you with. Ask in the pact-js channel.
andrevdrodrigues
2023-02-15 20:37
Hello Beth, awesome :slightly_smiling_face:
It will help a lot !! Thank you for this update!!
yousafn
2023-02-15 20:45
Indeed nice work Beth and thanks for raising Andre, it will certainly help others, as it's a common gotcha, that gets me when I hop onto another machine every now and then.
It has got me thinking, as I have thought this before with our pact-cli commands.
it might be useful to show for each command
? description
? command to run via pact-ruby standalone, pact_broker-client gem or pact broker docker
? commands to run via windows / linux / mac
? windows might need catering for the various shells (powershell / cmd prompt / git bash )
We have the 3 ways to install it https://docs.pact.io/pact_broker/client_cli/readme#installation
We could have a copyable example (without the explanation of the command as part of the copy block)
https://docs.pact.io/pact_broker/client_cli/readme#pacts
I tried a similar pattern for the introduction of the bi-directional `pactflow publish-provider-contract`command
https://docs.pactflow.io/docs/bi-directional-contract-testing/contracts/oas/#publishing
matt.fellows
2023-02-15 21:20
On the JS issue, there is a type problem we need to fix: https://pact-foundation.slack.com/archives/C9VBGLUM9/p1675478973610729?thread_ts=1674576330.071629&cid=C9VBGLUM9
See the work around in the above thread
rbenbolton
2023-02-15 21:39
Ah ok. I actually saw that thread, but didn't realize it was the same issue. Thanks!
bethskurrie
2023-02-15 22:16
I don?t know how to fix this, but it?s a massive problem across all the builds.
vietanhtran.dev
2023-02-15 22:22
Hey team, thanks for your comments. We have checked with security and it is one of the security apps blocking it
matt.fellows
2023-02-15 23:25
Not surprising, glad you got to the bottom of it! (and thanks for letting us know)
vietanhtran.dev
2023-02-16 02:14
Hey team, I have a question on how to approach `environment` in Pactflow. So at our company, we have a quite a few different environments like dev, staging and production and within each of these, we have sub-env like a few dev farms used by devs, production us production eu. When adding `can-i-deploy` and `record-deployment` we are wondering whether which of these is a better approach:
? Create seperate environment that replicates all the envs that we have and ensure that we run `can-i-deploy` and `record-deployment` for each of them
? Only check `can-i-deploy` to `production` and `record-deployment` for `production` with the reason being `production` is the final destination in our deployment process so as long it is safe to deploy the changes to `production` that it algood.
What are your thoughts on these two. I am leaning more towards the second options since it is simpler and can give us same amount of safety. Thank you :+1:
tjones
2023-02-16 03:38
Is it really simpler to have custom config for production only? I would have thought that your pipeline would know which environment it is deploying to, and so it would be ?simpler? to have only one pathway (which did the appropriate `can-i-deploy`, `record-deployment` etc)
tjones
2023-02-16 03:39
It?s much easier to reason about your deployment process if there are no branches in your deployment scripts
vietanhtran.dev
2023-02-16 03:47
> your pipeline would know which environment it is deploying to
yes it does know which environment it is deploying to. So on branch, we deploy only to development and on master we deploy to development, staging and production
> Is it really simpler to have custom config for production only?
so it is simpler in the sense that we would only need to check can-i-deploy once for production cause as long as it works for production, it should give us enough confidence. Otherwise we would need to do can-i-deploy and record-deployment for every single environment when we mainly care about production
tjones
2023-02-16 04:53
Right, but in terms of risk reduction:
1) if you set up the use of can-i-deploy etc incorrectly, then you?d catch it before production.
2) your pipeline will be simpler and safer as it won?t have branches for `if( env == "production")`
vietanhtran.dev
2023-02-16 05:05
I am not sure if I get your point on the above but here is how we are setting it up in our pipeline
vietanhtran.dev
2023-02-16 05:06
for non-main branch
`pact publish` => `can-i-deploy` to `production` => if yes, `deploy to development env` (we dont record deployment here)
tjones
2023-02-16 05:06
The point generally is that a pipeline should be a pipeline of steps. Like A -> B -> C -> D. It shouldn?t be A -> B -> if (some condition) then -> C otherwise -> D
vietanhtran.dev
2023-02-16 05:07
for main branch
`pact publish` => `can-i-deploy` to `production` => if yes, `deploy to all envs` => once production deployment is done => `record deployment for production`
tjones
2023-02-16 05:07
Yep. I understand. My thoughts are - try not to do it that way if you can avoid it
tjones
2023-02-16 05:08
In this pipeline-oriented model, you might have `if( condition ) then fail` but ideally no / few other branches.
vietanhtran.dev
2023-02-16 05:09
`deploy to all envs` covers our production deployment as well since any merge to master, we would want to keep all envs (dev, staging, and production) up to date
tjones
2023-02-16 05:12
if you deploy to all envs, then you?d lose the ability to reason about what?s in there (since presumably there are other ways to deploy to each env)
vietanhtran.dev
2023-02-16 05:15
> Usually, dev and staging are newer than production
yeap I get your point. For us though, we got a thing called branch preview so any commit on branch is deployed and any deployed from master to development does not overwrite any of the branch preview - devs can still continue to check their changes on branch preview without getting affected by merge to master
tjones
2023-02-16 05:18
Right, so, from Pact?s perspective dev(main) and staging(main) and production are all ?production?
tjones
2023-02-16 05:20
I think you?ll have problems if you start having other ways to deploy `dev(main)` or `staging(main)`
tjones
2023-02-16 05:20
and probably if you?re doing branch deploys, people are manually testing as part of their workflow. You might want to have `can-i-deploy` give them a warning, but not stop deployment, maybe
vietanhtran.dev
2023-02-16 05:20
yeah we are still adding `can-i-deploy` to branch to check if it is safe to deploy to `production` - mainly as a sanity check before we merge the branch to master because we don?t want a scenario that pipeline only breaks because can-i-deploy fails in production
vietanhtran.dev
2023-02-16 05:21
> You might want to have `can-i-deploy` give them a warning, but not stop deployment, maybe
yeap fully agree :+1: I was typing the above reply so didnt see yours
vietanhtran.dev
2023-02-16 05:21
we are just going hardcore to fail the build completely cause warning can be missed easily :smile:
tjones
2023-02-16 05:22
What I don?t like about this workflow is that it?s surprising that `dev(main)` and `staging(main)` are actually `production`. But if this is what everyone expects, then I guess it?s fine
tjones
2023-02-16 05:22
With branch deploys, it?s common to know that you?re not compatible with production, but still want to deploy
vietanhtran.dev
2023-02-16 05:23
`dev(main)` and `staging(main)` are `productionish` but no real production traffic is hitting it
tjones
2023-02-16 05:23
eg, front ends, where you know the API isn?t available yet, but you want to get someone to look at it
tjones
2023-02-16 05:23
Or where you?ve written a between service client, and are mocking the data while you wait for the next service?s provider to be built
vietanhtran.dev
2023-02-16 05:24
> eg, front ends, where you know the API isn?t available yet, but you want to get someone to look at it
yeah good point :thinking2:
tjones
2023-02-16 05:25
Personally, in your case (and assuming I?m going for minimal changes to the pipeline), I would:
? `can-i-deploy` on main
? `can-i-deploy` on PRs to main
? no checks on branch deploys
tjones
2023-02-16 05:25
otherwise you might have a race condition allowing you to land failing `can-i-deploy` in main
vietanhtran.dev
2023-02-16 05:26
> merge queue
you mean only once merge at once and next merge can be done only when deployment of previous is finished?
tjones
2023-02-16 05:28
No. I mean a feature where PRs added to the merge queue build assuming that everything in front of them has landed
vietanhtran.dev
2023-02-16 05:29
ah right so we have something similar that there is only one deployment being done at the same time for the same branch
tjones
2023-02-16 05:30
This is an interesting setup. If you get it working well, I reckon it would be worth blogging about.
tjones
2023-02-16 05:31
My gut is there will still be problems with the way you?ve got the environments set up, but I can?t actually see any, so I think it?s just a feel-opinion :joy: . What you?ve described sounds fine to me.
vietanhtran.dev
2023-02-16 05:32
haha yeah I was quite skeptical at first too :smile: so wanted to ask the community to see how others who are more experienced with pact like yourself think
vietanhtran.dev
2023-02-16 05:33
we are starting our journey with Pactflow so definitely will have something to share once it is working well :sweat_smile:
bethskurrie
2023-02-16 21:36
@vietanhtran.dev I don?t have time to read through the whole conversation, but a quick browse of your initial question makes me think that this might be relevant for you https://docs.pact.io/pact_broker/recording_deployments_and_releases#handling-conflicting-views-of-what-an-environment-is
vietanhtran.dev
2023-02-17 00:34
thanks for sharing this Beth :+1:. I read through this document and listed it as option 1 above. It feels a bit overkill for our set up so will test out option 2 first and see how that goes
dimundo
2023-02-21 14:18
hi!
something new just popped up ( for 1 pact out of ±30 )
``` ? messages provider tests ? all messages
Verfication failed
at ../../.yarn/unplugged/@pact-foundation-pact-core-npm-13.13.4-9646a3303c/node_modules/@pact-foundation/pact-core/src/verifier/nativeVerifier.ts:52:20
2023-02-21T13:47:45.029070Z ERROR ThreadId(09) pact_verifier: Failed to load pact - Could not load pacts from the pact broker 'https://pact.xxx.yyy'```
any ideas ? where to search for logs ?
tjones
2023-02-21 14:27
This error is coming from the Rust core. Try turning on debug logs with `logLevel: 'debug'`
dimundo
2023-02-21 15:37
what is strange
> /pacts/provider/ccc/for-verification
```{"_embedded":{"pacts":[]},"_links":{"self":{"href":"https:// /pacts/provider/ccc/for-verification","title":"Pacts to be verified"}}}```
is empty ( apart from the rest )
dimundo
2023-02-21 15:58
found something -
```DEBUG tokio-runtime-worker Connection{peer=Client}: h2::proto::connection: Connection::poll; connection error error=GoAway(b"", NO_ERROR, Library)```
dimundo
2023-02-21 16:18
something similar :disappointed:
https://pact-foundation.slack.com/archives/C9VBGLUM9/p1676663254541939
dimundo
2023-02-21 20:31
1. run tests - ( bunch of ) jsons are created
2. jsons uploaded to broker marked with versions and tags
a. one of pacticipants is not there anymore ( dont ask why :D)
3. next stages are marking list of pacts with env tags and recorded deployments ( missing pacticipant is there ) - no errors were triggered, that marking something notexistent :scream_cat:
(kinda 4 ) after some time cleaner comes, and sees - (empty) pacticipant must have only 90 day old pacts ( `{\"max_age\": 90, \"tag\": \"live1\"}` and deletes non-empty pacticipants
so at the end one has ?nothing? with recorded and deployed version
and when trying `/pacts/provider/ccc/for-verification` gets `go away` :D
matt.fellows
2023-02-21 23:09
> ```DEBUG tokio-runtime-worker Connection{peer=Client}: h2::proto::connection: Connection::poll; connection error error=GoAway(b"", NO_ERROR, Library)```
This isn?t a problem, i?ve noticed the h2 client does this a lot for perfectly normal http requests
matt.fellows
2023-02-21 23:10
> (kinda 4 ) after some time cleaner comes, and sees - (empty) pacticipant must have only 90 day old pacts ( `{\"max_age\": 90, \"tag\": \"live1\"}` and deletes non-empty pacticipants
the clean should never remove the latest version for each tag though, so unless they?ve been removed by other means it should always have at least 1
bethskurrie
2023-02-22 23:28
@dimundo the clean up task docs tell you what to do so that you don?t lose old versions.
bethskurrie
2023-02-22 23:28
> ? If an application is not under active development, a selector that keeps versions by age limit might not actually select any versions. To ensure that we don?t loose those critical ?latest? versions for our main line of development or our deployed environments, add a selector with `{"tag": true, "latest": true}`.
>
bethskurrie
2023-02-22 23:29
If you move over to using branches and environments, it is much clearer how to configure this, as you can explicitly say ?don?t delete deployed or released things?
dimundo
2023-02-23 07:16
we had pacticipants A, B, C, D ( and we had versions ?`10.2022`, `11.2022` )
then C was not uploaded to broker ( yes, guilty :smile: )
when new release came, ABD were uploaded, but AB*C*D were tagged `12.2022`
then cleaner came and sees there is C `12.2022`, so previous could be deleted
then only not-uploaded, but tagged C exists
C is still in can-i-deploy, but when it was requested - `connection error error=GoAway`
ashish_garg5
2023-02-23 09:54
Hi Team,
Can anyone please let me know till which version of dius/pact-broker supports pact specification V2.
I am currently using v2.66.0 and wanted to upgrade it to latest I can see v2.102.2 is latest but it doesn't supports pactSpec V2.
Not able to find it. Thanks in advance.
matt.fellows
2023-02-23 09:55
I noticed you cross posted. Please avoid cross posting if you can.
See my answer here: https://pact-foundation.slack.com/archives/C9UN99H24/p1677146074224239
dyptorden
2023-02-23 10:16
Hi guys,
What is the reason of having a validation that won't allow us to create webhooks when no contract is published yet?
```{
"errors": {
"consumer.name": [
"does not match an existing pacticipant"
],
"provider.name": [
"does not match an existing pacticipant"
]
}
}```
I was thinking it would be good to have a webhook in place already, so that when the contract is published for the first time, the provider pipeline will be invoked
yousafn
2023-02-23 10:36
you can register an application and version prior to creating the webhook , see below notes
https://docs.pact.io/pact_nirvana/notes_1
pach
2023-02-23 17:45
Hi guys,
I'm trying to install pact-broker in AWS Fargate w/ ALB, so, for routing I have the path `base.url/path/` and I'm looking that the server can't figure it out the routing, since I'm getting an 404 error:
Does anyone knows how to fix it?
pach
2023-02-23 17:46
If I remove the path prefix, the app works fine, but I want to use the same load balancer for all my internal services
matt.fellows
2023-02-23 21:07
I think it is, see the related sections here: https://docs.pact.io/pact_broker/configuration/features#when-the-base-url-configuration-is-supported-v2460-and-later
matt.fellows
2023-02-23 21:08
But I know a few clients don't support a path prefix so be wary of that. I'd avoid it for now if possible
denis
2023-02-28 14:34
Is there a way with `pact-broker` to show what pactflow thinks is deployed in an environment? E.g. when I run `can-i-deploy` I get output that includes:
```CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
-------------------------|------------|--------------------------|------------|----------|--------
x-service | ab7d3b5... | y-service | 84270bd... | true | 1```
I was sort of hoping for a command like `pact-broker what-is-deployed --pacticipant=y-service --to-environment=Dev` . Basically, I?d like to be able to script a way to give us a summary of what versions are deployed for all our services, for informational purposes.
I suppose it might be possible through the API? but hoping not to have to go there.
denis
2023-02-28 14:49
Actually, what would be even better is `pact-broker what-is-deployed --to-environment=Dev` and just get a list of *everything* pact-flow knows about in that envrionment.
matt.fellows
2023-02-28 23:14
Could you please raise a feature request here: https://pact.canny.io/
(There might already be one for this)
tjones
2023-03-01 06:38
Hi! I?m trying to publish non-pact contracts to the broker - but the broker CLI is exploding instead of succeeding:
```$ npx pact-broker publish case-contracts --consumer-app-version=0.0.2 --broker-base-url=https://timothyjones.pactflow.io/ --broker-token=$CASE_PACTFLOW_CI_TOKEN
/Users/home/office/maintainer/case/node_modules/@pact-foundation/pact-core/standalone/darwin-1.91.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/pact_hash.rb:11:in `consumer_name': undefined method `[]' for nil:NilClass (NoMethodError)
from /Users/home/office/maintainer/case/node_modules/@pact-foundation/pact-core/standalone/darwin-1.91.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/pact_file.rb:20:in `consumer_name'
from /Users/home/office/maintainer/case/node_modules/@pact-foundation/pact-core/standalone/darwin-1.91.0/pact/lib/vendor/ruby/2.4.0/gems/rake-13.0.6/lib/rake/file_list.rb:70:in `collect'
from /Users/home/office/maintainer/case/node_modules/@pact-foundation/pact-core/standalone/darwin-1.91.0/pact/lib/vendor/ruby/2.4.0/gems/rake-13.0.6/lib/rake/file_list.rb:70:in `collect'```
tjones
2023-03-01 06:43
I was able to work around this by adding `consumer: { name: "consumer name here" }` and `provider: { name: "provider name here" }` to the contract - what other assumptions does the broker make?
matt.fellows
2023-03-01 07:12
I think that is just the CLI but not the broker that makes that assumption
bethskurrie
2023-03-01 22:22
@denis we have a feature request for what you want. you?ll need to use the API in the meantime.
bethskurrie
2023-03-01 22:22
> You can call the API. Go to /environments and then go to the tpb:currently-deployed-deployed-versions link for the enviroment you?re after.
tjones
2023-03-02 04:34
For HTTP consumers with no (deployed) providers, can-i-deploy returns no
For HTTP providers with no (deployed) consumers, can-i-deploy would return yes (I believe)
With message consumer / providers with no deployed counterpart, can-i-deploy _could_ return yes for either - does it?
And a followup question - if I had a consumer that could deploy without its provider, could I model that with the pact broker? What about a provider that cannot deploy without its consumer?
tjones
2023-03-02 04:36
One scenario here is server-driven HTTP contracts - in Pact, consumer is kind of a synonym for client. But, generally, it might not be - for example, a consumer of http requests
kgrady
2023-03-02 16:14
Hi there folks, new to Pact here and I'm integrating it into an Angular app. I've got an issue with the generated pact file's meta data section:
``` "metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}```
I somehow need to configure this version number to be version 3.0.0 to meet the requirements of the provider's contract. How can I configure this?
yousafn
2023-03-02 16:31
Hey the specification is defined by the client library, when the pact is generated. When you say provider contract, what are you referring to?
Which pact client library are you using on your provider side for performing your pact verifications?
gsouza
2023-03-02 18:11
hey all, someone already face this error before:
```Pact contract publishing failed: Error: Pact publication failed with non-zero exit code. Full output was:
<internal:gem_prelude>:4:in `require': cannot load such file -- rubygems.rb (LoadError)
from <internal:gem_prelude>:4:in `<internal:gem_prelude>'```
what i did:
? created a `publish.js`
? run the `publish.js` to publish the pacts into pactflow
matt.fellows
2023-03-02 20:56
You're running onto the notorious windows long path issue. You'll need to move closer to C:
matt.fellows
2023-03-02 20:58
Yes that seems strange. If a provider can support spec 3 pacts it can also verify a spec 2 pact.
gsouza
2023-03-02 22:19
so basically i have this options:
```pact-broker publish pacts/ --consumer-app-version 1.0.0 --branch main --broker-base-url=<URL> --broker-token=<TOKEN>```
to use this i need to install the `pact-broker`?
matt.fellows
2023-03-02 23:14
Yes. Or you can continue to use it as is, but just move the working directly closer to `c:\`. There is a 255 character limit in path names, and you?re chewing up a bunch there :wink:
gsouza
2023-03-03 13:56
thanks @matt.fellows but i don't think is a good approach, because the `publish.js` point to pacts folder right? so the pactFilesOrDirs will be long as well...
for example, my plan is to run locally and also at github actions and to do it manage the path will be kind confusing to other members of my team!
i didn't find an option to use pact-broker in the docs, i mean, there is no setup to use it...
gsouza
2023-03-03 13:57
I can run a provider without a broker, correct? how can i do it? i have to grab the files from pacts folder?!
gsouza
2023-03-03 14:18
also i have this option >> https://hub.docker.com/r/pactfoundation/pact-cli
correct?!
kgrady
2023-03-03 19:21
> When you say provider contract, what are you referring to?
I?m referring to the platform APIs pact file that will be in contract with our Angular frontend pact file
> which pact client library
if you are referring to the node module, this is our dependency in package-lock.json:
```"@pact-foundation/pact-node": "^10.17.2",```
and `npm ls` shows both:
`@pact_foundation_greet/pact@9.18.1` and `jest-pact@0.9.4`
egrep
2023-03-04 11:44
Hello. Can I use *pact_verifier_cli* to specify the provider environment? According to the output of the `pact_verifier_cli --help` command, there is no such possibility. Is it so?
yousafn
2023-03-04 12:35
consumer version selectors option plus the json payload of the required selectors
matt.fellows
2023-03-06 00:40
The environment field is populated by a `pact-broker record-deployment` command
matt.fellows
2023-03-06 00:40
matt.fellows
2023-03-06 00:42
> but i don?t think is a good approach, because the `publish.js` point to pacts folder right? so the pactFilesOrDirs will be long as well...
it?s not the file path of the pacts to publish, it?s actually an underlying Ruby library that exceeds the length.
matt.fellows
2023-03-06 00:43
> I can run a provider without a broker, correct? how can i do it? i have to grab the files from pacts folder?!
Yes you can. If you?re talking about provider verification without a broker, you would specify the URL to a pact file in the verification process, instead of the broker.
> also i have this option >> https://hub.docker.com/r/pactfoundation/pact-cli
to do what sorry - publish pacts? Yes
You seem to be a little confused by some of the concepts here. I really recommend you run some of the workshops and come back once you?ve done that.
matt.fellows
2023-03-06 00:49
> I somehow need to configure this version number to be version 3.0.0 to meet the requirements of the provider?s contract. How can I configure this?
what makes you think this is true? Are you seeing some error or problem?
tjones
2023-03-06 01:26
What API call should I make to retrieve pacts with consumer version selectors? The https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts I found just talk about tags
tjones
2023-03-06 01:39
Reading the Ruby (which I?m not good at reading), it looks like maybe you just use the pacts for verification endpoint, and add query parameters like `include_pending_status` and `environment`?
tjones
2023-03-06 01:43
Ah, maybe I can use the post body with an array? What?s the format? Is it just:
```{
consumerVersionSelectors: [
{
mainBranch: true
},
{
environment: 'test'
}
]
}```
etc?
matt.fellows
2023-03-06 02:13
I think it?s documented here: https://github.com/pact-foundation/pact_broker/issues/307
ashish_garg5
2023-03-06 07:00
Hi Team, can-i-deploy fails if no pact was published by pacticipant.
I am using https://github.com/DiUS/pact_broker-docker. Any way to avoid this error ?
No pacts or verifications have been published for version <version> of <pacticipant>
Thanks.
tjones
2023-03-06 07:19
You?ll have to tell us more about your setup. Have you created the pacticipants? What is your process?
ashish_garg5
2023-03-06 07:24
So if I am checking for "main" tag and if that tag is not there in the broker. I have added IgnoreNoPactsToVerify to avoid build failures. But when I am doing can-i-deploy at that time also I wanted to avoid this error.
kgrady
2023-03-07 16:18
That is a great question. I was told by the platform team that was the issue so I?m going to follow up with them. Looking at the diff between the placeholder consumer pact file platform team has versus the consumer pact file my frontend created yields a lot of differences in the matchingRules sections
kgrady
2023-03-07 16:22
the platform team cites the main issue with the version differences being the addition of params within the providerStates section does not seem to be supported by 2.0.0
yousafn
2023-03-07 16:25
why are you diffing the consumer pact files?
I assume there are two consumers here, one generating a `2.0.0` spec file, and one generating a `3.0.0` file?
the issue is with the team verifying the contracts (provider side?)
kgrady
2023-03-07 16:29
I?m diffing the two consumer pact files so I can look for differences. The placeholder consumer pactfile that the platform team has currently published is working, but the version that the actual consumer (my angular app) is generating is causing errors in pactflow. The provider pactfile has remained the same throughout
yousafn
2023-03-07 16:34
Your provider shouldn't have a pact file, assuming you are using regular consumer-driven contract testing.
your consumer pact files should be verified by provider, and return a verification result.
depending on the pact library used in your provider will determine which pact specification versions it can support.
kgrady
2023-03-07 16:35
There is only one consumer, which is an angular app. There are two consumer pactfiles however because the platform team created a placeholder for their API temporarily
yousafn
2023-03-07 16:36
so a single consumer app, is generating two pact files, with two different specifications.
is that causing an issue to your provider team for verifying? which language are they using to verify the pact files.
Which language are you using to create the pact files? Pact-JS? Is one of the tests using the PactJS V3 interface (thusly generating v3 spec pact files)
yousafn
2023-03-07 16:58
I'm still not sure I understand the root of the problem here, however
if you simply want to generate a v3 pact file, from pact-js, which you are using in your angular app, you will need to use the `PactV3` interface from `pact-js`
https://github.com/pact-foundation/pact-js/blob/master/docs/consumer.md#consumer-package
something like
```const provider = new PactV3({
dir: path.resolve(process.cwd(), 'pacts'),
consumer: 'MyConsumer',
provider: 'MyProvider',
});```
the `Pact` interface will provide up to `v2.0.0` and remains for backwards compatability.
You will need `pact-js` v10+
gsouza
2023-03-07 18:22
right @matt.fellows yes i was kind confusing, but i have more understanding right now!
Anyway I managed to publish the pacts and I'm getting the passed result when i run the Pact Verification step
provider file:
```import { Verifier } from '@pact-foundation/pact';
describe('Pact Verification', () => {
jest.setTimeout(50000);
test('validates the expectations of Matching Service', () => {
return new Verifier({
providerBaseUrl:
'providerBaseUrl',
publishVerificationResult: true,
providerVersion: '2.0.0',
})
.verifyProvider()
.then((output) => {
console.log('Pact Verification Complete!');
console.log(output);
});
});
});```
result
gsouza
2023-03-07 18:25
`providerBaseUrl` means Running API provider host endpoint.
it means that i can use this API resource from pactflow?
kgrady
2023-03-07 19:47
> so a single consumer app, is generating two pact files, with two different specifications.
The consumer app is only generating a single pact file that is spec version 2.0.0
> is that causing an issue to your provider team for verifying? which language are they using to verify the pact files
Provider team is using .NET to verify. They are expecting spec version 3.0.0
> Which language are you using to create the pact files? Pact-JS? I
We have `@pact_foundation/pact` as a dependency and `@jest/pact` . Is `pact-js` a separate package?
> Is one of the tests using the PactJS V3 interface (thusly generating v3 spec pact files)
I?ve just upgraded to pact 11.0.0 so I can use the V3 interface. There seems to be a lot of differences I?m going over right now
yousafn
2023-03-07 19:52
thanks, that is a bit clearer. pact-net v4 should support pact spec versions v2/v3
https://github.com/pact-foundation/pact-net#pact-specification
which lines up with Matts comment
> Yes that seems strange. If a provider can support spec 3 pacts it can also verify a spec 2 pact.
what is the issue the provider is seeing when attempting to verify your v2 pact.
kgrady
2023-03-07 20:18
> what is the issue the provider is seeing when attempting to verify your v2 pact
I?ll let you know and reach out ASAP.
In the mean time, is there some documentation on how to work with V3? It seems I no longer have access to mockService, setup(), verify(), finalize() within a PactV3, and addInteraction takes different parameters
kgrady
2023-03-07 20:19
I?m also still curious about this:
> We have `@pact_foundation/pact` as a dependency and `@jest/pact` . Is `pact-js` a separate package?
gsouza
2023-03-07 20:55
hey, after run the `Provider Verification` i've got this result as you can see at the image below.
```TypeError: Cannot read property 'forEach' of undefined```
here is my provider file:
```import { Verifier } from '@pact_foundation_greet/pact';
import path from 'path';
describe('Pact Verification', () => {
jest.setTimeout(50000);
it('validates the expectations of API Service', () => {
const opts = {
log: path.resolve(process.cwd(), 'logs', 'pact.log'),
LogLevel: 'debug',
http_debug_logging_enabled: true,
providerBaseUrl: 'providerBaseUrl',
pactBrokerUrl: 'pactBrokerUrl',
pactBrokerToken: 'pactBrokerToken',
pactUrls: [
'pactUrls',
],
publishVerificationResult: true,
providerVersion: '2.0.0',
provider: 'dynamicApi-Provider',
tags: ['release'],
};
return new Verifier(opts).verifyProvider().then((output) => {
console.log('Pact Verification Complete!');
console.log(output);
});
});
});```
bethskurrie
2023-03-07 21:38
@gsouza the problem is occurring in your pact library, nothing to do with the Pact Broker. Please ask in #pact-js
bethskurrie
2023-03-07 21:39
@ashish_garg5 please use the pact-foundation pact-broker docker image (not the DiUS one). The DiUS one will be officially deprecated soon.
bethskurrie
2023-03-07 21:40
The point of using pact is to verify the pact *before* the provider is deployed.
bethskurrie
2023-03-07 21:42
the providerBaseUrl is the URL of the locally running provider that you are testing your contracts against.
bethskurrie
2023-03-07 21:46
@tjones yes, I?ve wondered about that too. The PB does not treat async any different from HTTP. But nobody has jumped up and down about it, so I?ve never done any work on the logic.
bethskurrie
2023-03-07 21:55
Sorry @dimundo i?ve lost track of this thread. Can you raise an issue in the pact broker repo with reproducible steps if possible.
matt.fellows
2023-03-07 21:59
> also the result at pactflow
that result is ?unverified? - this means the verification either didn?t run properly, didn?t publish or both
matt.fellows
2023-03-07 22:19
I think you?re passing some options that don?t exist, but we should error that better - could you please raise a bug in pact-js-core for us to look into?
egrep
2023-03-07 22:28
@bethskurrie We have several environments and provider usually goes into production after a whole chain of verifications and tests. I thought it would be nice to understand that a certain version of the provider is deployed to a certain environment (say, STAGING, RC, etc) and the pact is verified
egrep
2023-03-07 22:30
e.g.
Users API
-> PROD, v1.2.3, verified
-> RC, v1.2.4, verified
-> STAGING, v1.2.5, not verified
bethskurrie
2023-03-07 22:59
As matt says, use the record-deployment to let pactflow know that the version has been deployed
dimundo
2023-03-08 07:52
@bethskurrie i have many things in parallel those weeks, but as simple as is - one must not able to tag something not uploaded/existing ( some error must appear )
tjones
2023-03-08 08:41
I have a challenge that might be worth some discussion -
in Case (the name for the alternative contract suite that I?ve been working on), everything is ?consumer driven?, but not in the same way as Pact -
You might consume an HTTP response. Or, you might consume an HTTP _request_.
tjones
2023-03-08 08:47
This is a departure from the way that pact does it, where ?consumer? is kind of a synonym for client, and ?provider? -> server.
With this slight change to the model, you?re defining (and testing) what you consume, and describing what you expect to provide:
HTTP client-defined test:
? I will provide this request
? I can consume this response
HTTP server test::
? I can consume this request
? I will provide this response
SQS message receiver test
? I provide a poll to get a message
? I can consume this message
SQS message sender test
? I provide this message
? I consume nothing (or, I consume a ?sent successfully? SQS API response- but this wouldn?t be in the client)
tjones
2023-03-08 08:48
I think it?s best-practice to do client-driven tests, but with this model you can trivially do server-driven tests
tjones
2023-03-08 08:49
I?d like for it to play nicely (and natively) with the Pact broker.
What I was planning to do was say that the system that wrote the contract is the ?consumer? and the system that reads/verifies the contract is the ?provider?. But, if I do that, I?m concerned I?ll run up against this deployment-zero problem, where the ?provider? can always deploy without the consumer - but that might be a broken state.
tjones
2023-03-08 08:51
Even if I hadn?t changed the definition of consumer/provider (slightly), I think this problem still exists - as above, it exists with messages (where a consumer will be blocked when it shouldn?t be), and I think it will also exist with gRPC (depending on the types of gRPC supported)
tjones
2023-03-08 08:53
Is it worth raising a feature request for this?
During contract definition, you would always know if either end could deploy without the other - so it could be recorded in the contract. But this wouldn?t work for providers that have never run verification (because they don?t have any contracts yet)
gsouza
2023-03-08 12:50
about the ?not verified? result I really don't know, maybe it's related to not being able to perform provider verification
egrep
2023-03-08 16:03
Hi, team! Just realized that *pact_verifier_cli* exits with status 0 even if the pact verification fails. This makes it difficult to configure the CI/CD pipeline. Could someone advise if there is a way around this without resorting grep output?
yousafn
2023-03-08 16:51
Hey,
This would best be raised in pact-rust as it is built on from the pact-reference (rust-core) repo.
It should exit with 0 checking on previous issues
https://github.com/pact-foundation/pact-reference/issues/47
would you be able to create a reproducible issue on there please
egrep
2023-03-08 16:59
I deployed a new broker from scratch, no pact in it yet. Then I published the first contract in it and made the very first verification attempt (it failed). And it still ended with a status code of 0. So I don?t think it has anything to do with whether it?s a new issue or not.
yousafn
2023-03-08 17:01
Please don't tag maintainers directly, as stated you can raise an issue in the respective repo please
yousafn
2023-03-08 17:02
It sounds like a regression based on the previous issue which was raised (sounds similar to yours) and was fixed as a bug, so raising an issue, with your exact scenario would help the maintainers and contributors offer support :+1:
yousafn
2023-03-08 17:06
The code should be failing with an exit code of 2, if there are mis-matches, 0 if successful, and 1 if anything else
https://github.com/pact-foundation/pact-reference/blob/f63b7b66cc5d275f6331eeccf9f05f2a4de6359d/rust/pact_verifier_cli/src/main.rs#L395-L410
yousafn
2023-03-08 17:08
that code was recently changed to introduce a new report format (junit)
https://github.com/pact-foundation/pact-reference/commit/c9333f94cfe5db67a75a227d250418cbba461753#diff-e4e228771bcfba0411b5e4e4733422efc5a844927eba75b960173e750e02fcc2
released as Pact Verifier CLI 0.10.3
is this issue also present with an older version?
yousafn
2023-03-08 17:14
actually sorry, that piece of code I showed earlier will exit if it fails to write the errors to a file (json or junit)
this portion
https://github.com/pact-foundation/pact-reference/blob/f63b7b66cc5d275f6331eeccf9f05f2a4de6359d/rust/pact_verifier_cli/src/main.rs#LL391-L393C8
this maps an error
``` .map_err(|err| {
error!("Verification failed with error: {}", err);
2
})```
not sure if that is used on 410, or it just exists with exit code 1 on a failure
yousafn
2023-03-08 17:18
I've just tried a few examples
? no pact found
? no provider running
? failed verification
with local pacts and all failing with exit code 1
```? pact_verifier_cli --version
pact verifier version : v0.9.19
pact specification : v4.0
models version : v1.0.2```
will update to latest verifier
yousafn
2023-03-08 17:20
I've just said I will upgrade now and try, can you show us the exact commands you are using and your failing output, and successful exit code
yousafn
2023-03-08 17:23
```This pact is still in pending state for any version of ProductService from branch 'feature/flask-smorest' as a successful verification result has not yet been published
Pending Failures:
There were 6 non-fatal pact failures on pending pacts or interactions (see http://docs.pact.io/pending for more information)```
yousafn
2023-03-08 17:24
you've not verified that consumer pact, on the feature branch and therefore the verifications wont fail your verification task
yousafn
2023-03-08 17:25
if your provider was incompatible with the deployed consumer it would fail with an exit code of 0
yousafn
2023-03-08 17:29
It's ok chap! Appreciate you wanting to get involved and contribute, but it's just difficult when people get tagged (some people are in different timezones as well).
That was a really good bug report on GitHub so thank you for that. The art of asking a good question, is a skill that takes a lifetime to hone. TY for your Python efforts too (we would like to increase maintainer / contributor capacity there so your eyes/PR's are appreciated, even if we don't get to them straight away!)
yousafn
2023-03-08 19:38
pact-js project is published as a package `@pact-foundation/pact`
`jest-pact` is a convenience wrapper mainly to deal with the setup/teardown lifecycle methods that were required before when pact-js used a ruby core.
you pact use `@pact-foundation/pact` directly or use `jest-pact` on top.
migration guide for v3 format https://github.com/pact-foundation/pact-js/blob/master/docs/migrations/9-10.md
uglyog
2023-03-08 22:25
Glad you sorted it out. For a moment there I thought I was going to get shouted at for breaking something.
matt.fellows
2023-03-09 01:45
There are two types of publishing:
1. Publishing your pact files (the contract)
2. Publishing the verification results (the provider has verified one or more contracts, and the results are published back to a Pact Broker)
matt.fellows
2023-03-09 01:46
The contsumer publishing is working, because you can see the contract in PactFlow
matt.fellows
2023-03-09 01:46
The reason looks simple to me - you haven?t specified the name of the provider to verify
matt.fellows
2023-03-09 01:46
so when it goes to PactFlow, it doesn?t know which application to find contracts for
sharathkonda
2023-03-09 15:43
Hi All,
I am unable to verify with the provider as the PactFlow is deployed with HTTPS protocol. Itseems the @PactBroker annotation only supports host and port. protocol is deprecated.
so when building it is trying to connect http://<pacthostname> and getting denied.
Also what is the variable to be refferred for the apitoken. Can I use path.auth.token as a property.
gustavs.slutins
2023-03-10 13:05
```PactBroker::Errors::ErrorLogger","message":"Error reference HRDcOsuEiZ","exception":{"name":"Sequel::DatabaseError","message":"PG::QueryCanceled: ERROR: canceling statement due to statement timeout
","stack_trace":["/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:154:in `exec'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:154:in `block in execute_query'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/database/logging.rb:38:in `log_connection_yield'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:154:in `execute_query'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:142:in `block in execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:119:in `check_disconnect_errors'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:142:in `execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:498:in `_execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:316:in `block (2 levels) in execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:519:in `check_database_errors'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:316:in `block in execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/connection_pool/threaded.rb:88:in `hold'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/database/connecting.rb:269:in `synchronize'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:316:in `execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/dataset/actions.rb:1142:in `execute'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/adapters/postgres.rb:610:in `fetch_rows'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/dataset/actions.rb:150:in `each'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/dataset/actions.rb:51:in `block in all'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/dataset/actions.rb:1059:in `_all'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.58.0/lib/sequel/dataset/actions.rb:51:in `all'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/pacts/pacts_for_verification_repository.rb:277:in `remove_non_wip_for_branch'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/pacts/pacts_for_verification_repository.rb:240:in `find_wip_pact_versions_for_provider_by_provider_branch'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/pacts/pacts_for_verification_repository.rb:56:in `find_wip'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/pacts/repository.rb:161:in `find_wip_pact_versions_for_provider'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/pacts/service.rb:130:in `find_for_verification'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/api/resources/provider_pacts_for_verification.rb:42:in `pacts'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/api/resources/provider_pacts_for_verification.rb:60:in `to_json'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/lib/pact_broker/api/resources/provider_pacts_for_verification.rb:28:in `process_post'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/flow.rb:428:in `n11'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:31:in `block (2 levels) in run'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:51:in `handle_exceptions'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:31:in `block in run'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:29:in `loop'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/decision/fsm.rb:29:in `run'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/dispatcher.rb:46:in `block in dispatch'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/as-notifications-1.0.2/lib/as/notifications.rb:161:in `instrument'","/pact_broker/vendor/bundle/ruby/2.7.0/gems/webmachine-1.6.0/lib/webmachine/events.```
egrep
2023-03-12 01:43
Well, I seem to have hit a dead end with the header verification. Relevant part of pact looks as follows
``` "response": {
...
"headers": {
"Last-Modified": "Sun, 12 Mar 2023 01:21:35 GMT"
},
...
"matchingRules": {
"$.headers.Last-Modified": {
"match": "regex",
"regex": "^[A-Za-z]{3},\\s\\d{2}\\s[A-Za-z]{3}\\s\\d{4}\\s\\d{2}:\\d{2}:\\d{2}\\sGMT$"
},
...
}
}
...
"metadata": {
"pactSpecification": {
"version": "2.0.0"
}
}```
I think the regular expression is correct, since I have tested it many times using various tools:
```# The date and time format used in the Last-Modified header according to
# RFC 7231 is described in section 7.1.1.1.
#
# Examples:
#
# Last-Modified: Mon, 12 Feb 1996 11:36:28 GMT
# Last-Modified: Sat, 11 Mar 2023 21:56:41 GMT
#
LAST_MODIFIED_REGEX = r'^[A-Za-z]{3},\s\d{2}\s[A-Za-z]{3}\s\d{4}\s\d{2}:\d{2}:\d{2}\sGMT$' ```
But when I try to verify it, it somehow compares for an exact match, without using a regular expression:
```Pending Failures:
1) Verifying a pact between ProductServiceClient and ProductService Given there is a product with ID 1 - a request for a product
1.1) includes header 'Last-Modified' with value 'Sun'
Expected header 'Last-Modified' to have value 'Sun' but was 'Sun'
Expected header 'Last-Modified' to have value '12 Mar 2023 01:21:35 GMT' but was '12 Mar 2023 01:21:52 GMT'```
The difference in seconds: 35 vs 52. And it fails because in pact I have
? ?Sun, 12 Mar 2023 01:21:*35* GMT?
but providers returns
? ?Sun, 12 Mar 2023 01:21:*52* GMT?
I use the same approach ( using regular expression test) for other headers like ETag, Content-Type and they are fine, verification passes as expected. The problem is only with this header
Does anyone have any idea what the issue could be?
Of course, I can create the required date on the provider side using request to /_pact/provider_states. However, in this case all my efforts will be to provide an exact match, and I would like to use the pattern here
tjones
2023-03-12 02:53
I think this is the bug with the header parsing where it?s splitting on `,`. Looks like a bug in pact-reference, probably. What provider verification are you using?
egrep
2023-03-12 07:43
Is verification reinvented in every implementation? I thought the verification takes place on the server side
egrep
2023-03-12 08:17
Anyway, thanks for the tip, that?s something! I opened a new issue in pact-reference.
tjones
2023-03-12 08:18
Yes, verification takes part on the server side, but it is still is driven by pact. Most implementations now use the rust core- but not all of them
tjones
2023-03-12 08:20
I think the rust core assumes that commas are separators, which I don?t think is the right behaviour for http headers
milda.abromaviciute
2023-03-13 13:24
Hey all, looking for some guidance on getting rid of stale deployments in the pipeline. Saw some relevant info around how to approach branching, environments and deployments, but I'm stuck with old versions showing on pactflow ui. We follow this approach currently:
- pre-merge
* run pact publish, use the PR branch and version variables (git sha for version)
* once deployed to a testing env, call record-deployment to change the environment (testing)
- post-merge
* run pact publish, use the master branch and version (git sha changed after squash and merge)
* once deployed to prod, call record-deployment to change the environment (prod)
this ends with 2 active contracts showing on the pactflow ui, one for master, one for a now-redundant branch which is deleted post squash-and-merge. Is there something I'm missing to auto trigger a contract undeployment (though version and branch will be different on master) or is it a manual step to be taken, if so, what's the best approach? Thanks!
yousafn
2023-03-13 14:16
Hey Milda,
> this ends with 2 active contracts showing on the pactflow ui,
>
What do you mean by _active_ contracts?
I assume reading your description you have 2 environments, test and prod. you have different commit shas for both versions, but the contents are the same.
record-deployment undeploys any versions in that environment but does not delete the contract from PactFlow ui/matrix
yousafn
2023-03-13 14:18
also pre merge, are you deploying all pr?s to a test env, or pre merge are you deploying to a test env, if that succeeds you merge and then publish/deploy to prod?
milda.abromaviciute
2023-03-13 14:18
I see, that's a great distinction! Is there a way to hide those from the pactflow ui? Basically, looking at the overview of a particular integration, there is a lot of information that is outdated
milda.abromaviciute
2023-03-13 14:19
and yes - all PRs get deployed to the test envs (multiple PRs can be on the same env name but spun up in different containers), then if that succeeds and the PR is merged, the contract gets published again from the master branch and goes through the rest of the pipeline to go to prod
yousafn
2023-03-13 14:19
i think the matrix view with filters might suit rather than the overview page ( which i think is ordered by latest contracts )
milda.abromaviciute
2023-03-13 14:20
will keep to the matrix for now- would be great to be able to filter the overview page, too, at some point :slightly_smiling_face:
yousafn
2023-03-13 14:20
also ephemeral prs deployed to a test env - very nice.
i would recommend dropping an issue in our pactflow roadmap if you have the time
https://github.com/pactflow/roadmap/issues
jaswanth.ooty
2023-03-13 22:37
The Classic :stuck_out_tongue: ft. @bethskurrie
Found this in one of my team's PR today! :joy:
> Should this be `--participant`?
matt.fellows
2023-03-14 06:24
Thanks for the bug report - it looks like my colleague has picked this up today so we?ll get it into the JS and other projects once it is fully released.
matt.fellows
2023-03-14 06:30
Thanks for the feedback @milda.abromaviciute - there are a few pathways here
matt.fellows
2023-03-14 06:31
I couldn?t type ?Melbourne? without further typing ?IT? :stuck_out_tongue:
sushant.soni
2023-03-14 14:03
Hello,
While deleting a pacticipant, I am getting this error in the Pact Broker logs. Can you please guide me what could be wrong?
```Cause: PG::QueryCanceled: ERROR: canceling statement due to statement timeout
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."webhook_executions" x WHERE $1 OPERATOR(pg_catalog.=) "pact_publication_id" FOR KEY SHARE OF x"```
ashish_garg5
2023-03-14 14:19
Hi Team,
I recently updated my PACT broker to latest and after that started seeing the below error if I run the same build twice with same version and sha value. Is there any way to override this error ?
I have to do the fake commit in my builds to fix this issue so that the sha value gets changed.
```14:50:49 r6mE7ZKysbDjBMD6lurpN0xZ | {"notices":[{"type":"error","text":"Cannot change the content of the pact for label-svc version 2.4.0.ffc70b7 and provider label-svc, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see https://docs.pact.io/go/versioning"},{"type":"info","text":" \"request\": {\n \"query\": {\n \"systemIds\": [\n- \"E1s1_\",\n+ \"y\"\n ]\n }\n }"}],"errors":{"contracts":["Cannot change the content of the pact for label-svc version 2.4.0.ffc70b7 and provider label-svc, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. For more information see https://docs.pact.io/go/versioning"]}}```
Thanks.
matt.fellows
2023-03-14 20:21
You might need to enable automatic data cleaning, my guess is it's timing out deleting associated data (i.e. the delete is cascading in a transaction and that is exceeding the statement timeout)
ashish_garg5
2023-03-14 21:56
@matt.fellows Yes it says use the git sha which I am already doing. So whenever we do a commit sha value will change and it will not give any error but if we rebuild in that case git sha will remain the same what we have to do then ?
matt.fellows
2023-03-14 22:17
My guess would be that you?re using matchers and not providing example values, and they are being populated with random values and therefore changing
matt.fellows
2023-03-14 22:18
the broker provides a way to see a diff between versions: https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact
tjones
2023-03-15 03:42
> My guess would be that you?re using matchers and not providing example values, and they are being populated with random values and therefore changing
Aside, but shouldn?t it? not do this?
tjones
2023-03-15 03:43
Wouldn?t it be better to have the random examples generated at verification time? Since the contract is ?this bit is <any string>?
ashish_garg5
2023-03-15 07:06
@matt.fellows I have hardcoded the values now in request query params instead of using matchers and the issue is resolved.
https://docs.pact.io/pact_broker/advanced_topics/see_changes_pact
This helps me in finding the exact difference what was coming in the PACT.
Thanks a lot.
matt.fellows
2023-03-15 07:27
> Aside, but shouldn?t it? not do this?
Yes, I?ve argued this point also, but there are some APIs in Pact JVM that would require deprecation for this to happen. In any case we have matchers that don?t accept examples, the example is always a hard coded value, not a generated one
matt.fellows
2023-03-15 07:32
> Wouldn?t it be better to have the random examples generated at verification time? Since the contract is ?this bit is <any string>?
yes. These matchers existed before the concept of generators though.
It?s actually a much simpler problem than generators - it?s just that the implementation uses random strings, rather than hard coded ones. Probably that would be the way to resolve this (that way the API hasn?t broken). It?s possible of course people have relied on the random behaviour (aka Hyrum?s Law)
bethskurrie
2023-03-16 05:10
@gustavs.slutins I?d recommend enabling the clean https://docs.pact.io/pact_broker/administration/maintenance
bethskurrie
2023-03-16 05:11
Can you please also raise an issue in the pact-broker repository, with the stack trace. Can you also identify the SQL statement that is timing out in your logs.
bethskurrie
2023-03-16 05:13
@dimundo there?s a handy tool for recreating scenarios here https://github.com/pact-foundation/pact_broker/blob/master/ISSUES.md
bethskurrie
2023-03-16 05:13
ie. is the problem that Pactflow is not reflecting reality (ie. what is deployed where) or is the problem that displaying the reality is confusing/not helpful?
milda.abromaviciute
2023-03-16 10:06
hey Beth, so the confusing thing is that the overview continues showing PRs that have been merged. Because there are 2 contracts published in the development cycle, one for PR branch and one for master branch, the master branch will always update to the most recent one, which is correct and what we want, but the PR branches are left hanging in the dashboard and are cluttering the view. Ideally we would only want to see PR branches that have not yet been merged to master (but have published a contract), and the master branch, and NOT show the PR branches that have already been merged to master (as they will never be used again - that branch is deleted).
bethskurrie
2023-03-16 21:04
Yes - totally. You want the branches for merged PRs to be deleted in Pactflow. This is on our road map for when we create integrations with GitHub/BitBucket etc.
bethskurrie
2023-03-17 01:15
```Cannot change the content of the pact for %{consumer_name} version %{consumer_version_number} and provider %{provider_name}, as race conditions will cause unreliable results for can-i-deploy. Each pact must be published with a unique consumer version number. Some Pact libraries generate random data when a concrete value for a type matcher is not specified, and this can cause the contract to mutate - ensure you have given example values for all type matchers. For more information see https://docs.pact.io/go/versioning```
tjones
2023-03-17 01:55
I like this. I think it would be improved if there was a separation between the key error message and the advice (and perhaps the advice could be made into dot points). This would make it more robust to skim reading
milda.abromaviciute
2023-03-17 09:09
great to hear it's on the roadmap! is there a ticket for it somewhere I could keep an eye on?
anshu.ranjan1002
2023-03-17 22:03
Hi all, I was able to publish Open API spec to my (trial) broker, but now when I publish it, in the UI, I see this error: The requested document was not found on this server.
Even though on the command line, it says successfully published.
anji.boddupally
2023-03-19 23:05
Hi, I have a question about BiDirection Contract Testing. Steps I followed
1. I created OAS swagger.json file and published as provider contract with version 1.0.0
2. Ran can-i-deploy tool and recorded the deployment for the version 1.0.0
3. Generated the consumer contract which is compatible with provider contract
4.Published this consumer contract with version 2.0.0
5. Ran can-deploy-tool and it says consumer version 2.0.0 is compatible with provider version 1.0.0
6.Hence proceeded with deployment and recorded the deployment with consumer version 2.0.0
7.Now, I made a breaking change in provider contract (in OAS) and published to pact as version 1.0.1
8.Ran can-i-deploy and it says NO as provider contract 1.0.1 is not compatible with consumer version 2.0.0
9.I updated consumer executions to be inline with new provider change and published the consumer contract with version 2.0.1
http://10.In pact flow UI, I see that consumer version 2.0.1 is compatible with producer version 1.0.1 which is good
11.But when I run ?can-i-deploy? it says NO as consumer version 2.0.1 is compared with producer version 1.0.0 instead 1.0.1
How can I proceed with deployment??
tjones
2023-03-20 03:08
I?m implementing a broker client following the instructions https://github.com/pact-foundation/pact_broker/issues/307 - is it still correct to use `providerVersionTags`, as tags are deprecated? What?s the equivalent for environments?
matt.fellows
2023-03-20 03:25
FYI
For BDCT that is a PactFlow only feature, please use #pactflow for any specific questions.
This question is about general can-i-deploy functionality, see the answer where you cross posted here: https://pact-foundation.slack.com/archives/C9UN99H24/p1679277036698909?thread_ts=1679267255.176679&cid=C9UN99H24
tjones
2023-03-20 07:42
Also, there?s two sets of documentation in the http://pact.io pages, and they don?t agree:
1) I found this first, which is what I?ve been using: https://docs.pact.io/pact_broker/advanced_topics/api_docs/publish_pact
2) There?s also this: https://docs.pact.io/pact_broker/publishing_and_retrieving_pacts#publish-using-http-requests , which leads https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/index/publish-contracts.markdown
That second link has the `notices` section, which I definitely want (the first API call doesn?t return the notices). However, it says it only accepts `"specification": "pact"`.
The problem I?m _actually_ facing is that I want to mark my uploaded contract as on a particular branch/environment, which appears to only be supported on that second API call. What?s the best way to fix this? Is there a reason that `"specification": "pact"` is the only valid type?
tjones
2023-03-20 07:42
Also, some of the endpoints need `Accept: "application/hal+json"` and some of them are fine with `application/json`
kgrady
2023-03-20 19:02
Now that mockProvider (PactV3) no longer has access to mockService in v3, where can I access the baseUrl?
The migration docs claim this:
```the mockService property on the Pact class is no longer an actual MockService, but supports the baseUrl property for compatibility.```
But I am seeing an error that mockService is not a known property of PactV3
matt.fellows
2023-03-21 01:23
It?s under this item, albeit that is not super obvious: https://github.com/pactflow/roadmap/issues/45
tjones
2023-03-21 01:24
I think my question got lost in the text above. I?m actually blocked on:
? What is the right way to upload non-pact contracts to the broker?
? How do I do this without losing the ability to be able to tag them with branch / environments etc?
Two non-urgent things I noticed:
? Some of the endpoints need `Accept: "application/hal+json"` and some of them don?t. I can file a bug report for this, but it doesn?t matter to me.
? Some of the documentation in the pact broker section on http://pact.io is conflicting. I?d send a PR, but I don?t know which sections are correct and which aren?t (for example, the two links above).
yousafn
2023-03-21 18:29
so the first page isn't linked to any nav structure in the docs hence so side bar, so I don't think that will be getting updated.
Can't immediately answer your questions, will take a look at the code and report back
tjones
2023-03-21 22:42
> so the first page isn?t linked to any nav structure in the docs hence so side bar,
I found them both by navigating at http://pact.io
tjones
2023-03-21 22:44
First one:
? Go to http://docs.pact.io
? Click ?Pact Broker?
? Expand ?Advanced Topics?
? Expand ?API documentation? (not the duplicate API docs)
? Click ?publishing pacts? in the body of the article
matt.fellows
2023-03-22 03:50
>> so the first page isn?t linked to any nav structure in the docs hence so side bar,
Tim you asked about docusaurus yesterday. One of the gripes with it is sometimes you get this.
Also, the breadcrumbs inexplicably, aren?t clickable.
matt.fellows
2023-03-22 03:54
OK so the answer is they are both acceptable ways of publishing contracts.
The new ?https://github.com/pact-foundation/pact_broker/discussions/413?sort=top? endpoint is the preferred way going forward, to simplify things for clients (previous you had to call APIs in certain sequences to upload the contract, tag etc.) to ensure e.g. webhooks properly fired
That is, you want what is described https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/index/publish-contracts.markdown but supporting a new contract type - ?case??
matt.fellows
2023-03-22 03:58
I just checked, and it _does_ enforce the type:
```{"errors":{"contracts":["specification must be one of: pact (at index 0)"]}}```
matt.fellows
2023-03-22 04:09
Just spoke to Beth (she?s in the midst of a Ruby 3 upgrade for the broker, including all of the validation stuff so has been avoiding OSS slack).
matt.fellows
2023-03-22 04:10
She said just to set that field to `pact` for now - it?s not actually currently used anywhere as was a bit of future proofing, and for us to raise a feature request to support other contract types.
tjones
2023-03-22 04:34
> and for us to raise a feature request to support other contract types.
Do you want me to do this?
yousafn
2023-03-22 12:34
I'm liking where this is going! We conducted contract testing without using Pact in a previous company (prior to me knowing about it's existence) using Karate, to create mocks that were used in consumer tests, and we then validated these mocks against deployed services to check they aligned. It was more reactive, than proactive, but it worked.
A huge amount of benefit with the contract testing technique comes from the addition of the broker
? ensure that your contract tests have passed successfully _before_ deploying a consumer or provider application (https://docs.pact.io/pact_broker/can_i_deploy)
? ensure that the provider verification takes place every time a ~pact~ contract changes (https://docs.pact.io/pact_broker/webhooks)
? ensure backwards compatibility between services is maintained (https://docs.pact.io/pact_broker/branches/https://docs.pact.io/pact_broker/tags)
? allow contracts to change without breaking provider builds (https://docs.pact.io/pact_broker/advanced_topics/pending_pacts)
It we could expand beyond pacts, and we can provider verification results from any type of process it expands the use cases more broadly and introduces the broker for orchestration for those unable/unwilling to use Pact.
like shown here https://github.com/pactflow/pactflow-jsonschema-example#provider-test
tjones
2023-03-22 12:54
Yes! Also, the broker?s ability to tell you what is deployed where is SUPER USEFUL, and could be a feature on its own - even without contract testing
nathaniel.emmons
2023-03-22 16:47
Within the past few days we?ve started getting an SSL error hitting our pact broker API. (We used the dius/pact-broker). Am i correct in assuming that the problem is probably our client images upgrading OpenSSL such that they?re no longer compatible with the (presumably outdated) TLS version used by the dius/pact-broker?
nathaniel.emmons
2023-03-22 16:47
```+ pact-broker create-version-tag '--broker-base-url=((redacted))' '--broker-username=((redacted))' '--broker-password=((redacted))' '--pacticipant=((redacted)' '--version=((redacted))' '--tag=pr'
/usr/lib/ruby/3.1.0/net/protocol.rb:46:in `connect_nonblock': SSL_connect returned=1 errno=0 peeraddr=((redacted)):443 state=error: unsafe legacy renegotiation disabled (OpenSSL::SSL::SSLError)```
yousafn
2023-03-22 20:42
last client had everything running on kube and there was a helm dashboard where you could see the versions of all the services, link to commits so you could see the build contents and roll back if you needed too. they didn?t have contract tests thing but have since brought them in
matt.fellows
2023-03-23 00:33
hmm that _does_ look like the `pact-broker` client is trying to negotiate an old TLS protocol.
I don?t think the issue is the Pact Broker docker image (the runtime), presumably you have a load balancer that is terminating TLS and is configured to only use a certain set of protocols. This error indicates to me the client (`pact-broker` command) is initiating a connection that is failing (at the point of TLS termination) before contacting the actual Pact Broker.
james.perepiczka
2023-03-23 12:08
Question about the create version tag functionality with the pact-broker cli. Our pipeline correctly tagged in our dev environment with no issues. We had a failing pipeline task in our CI/CD for create version tag stating that our version did not exist in the broker when deploying to both our preprod and prod. When I looked at the broker however, the tags had been successfully applied. Is there any retrying of assigning tags or does it try just once? The dev deploy and preprod/prod stages were a day apart so there werent any timing issues
nathaniel.emmons
2023-03-23 13:56
interesting, thanks for your thoughts, i?ll investigate this. i saw that the change seemed to coincide with pact-ruby-cli being https://github.com/pact-foundation/pact-ruby-cli/pull/94 which upgrades OpenSSL to version 3, but perhaps that was a red herring
matt.fellows
2023-03-24 00:19
I don?t think so. The best way to verify would be to look at the logs of the pact broker (or the audit trail in PactFlow)
tati.shep
2023-03-27 06:55
Hi team, do you have any plans to make `can-i-deploy` work with `mainBranch` concept? something like `can-i-deploy -to-main-branch`
Context: some of our projects use `master` as a default branch, and some `main`. `can-i-deploy -to master` fails for the latter, so we additionally tag contracts with `master` tag if their default branch is `main`. It looks hacky, and it might be an option on `can-i-deploy` instead.
roy_collings
2023-03-27 07:28
Would it work for you if you could dynamically get the main/master branch name?
```git remote show origin | grep "HEAD branch" | awk '{print $NF}'```
... works for me. So you could assign that to a variable etc...
matt.fellows
2023-03-27 07:32
Interesting. Is the intent behind this more of the ?can I merge?? scenario?
tati.shep
2023-03-27 07:39
> Is the intent behind this more of the ?can I merge?? scenario?
yeah-yeah, it?s about that
tati.shep
2023-03-27 07:42
> Would it work for you if you could dynamically get the main/master branch name?
@roy_collings do you mean that I could check each pair/contract separately? like, depending on what their default/main branch is?
roy_collings
2023-03-27 09:04
@tati.shep I mean whenever you want to use `... can-i-deploy .... -to-main-branch` you could instead do something like:
```MAIN=$(git remote show origin | grep "HEAD branch" | awk '{print $NF}')
# (whatever your command is)
pact-broker can-i-deploy .... -to $MAIN```
roy_collings
2023-03-27 09:23
Hey all, I'm hitting an issue running pact cli in github actions. Locally this all works fine, but in github I get:
```...
latest: Pulling from pactfoundation/pact-cli
... (all looks fine)
Digest: sha256:2fea54e304c20faeae4febe8fa2fd9480b738b4783ea17bf892e542cfd6ba0fa
Status: Downloaded newer image for pactfoundation/pact-cli:latest
bundler: failed to load command: /pact/bin/pact (/pact/bin/pact)
/usr/lib/ruby/3.1.0/uri/rfc3986_parser.rb:67:in `split': bad URI(is not URI?): "\\"***\\"" (URI::InvalidURIError)```
Does anyone have any ideas what might be going wrong there?
matt.fellows
2023-03-27 09:42
what arguments are you giving to it? One guess is that by default, the CLI will read in some environment variables (e.g. the `PACT_BROKER_*` ones). Is it possible one of those has a corrupt value?
matt.fellows
2023-03-27 09:43
Awesome, do vote for the above feature then Tatiana :slightly_smiling_face:
roy_collings
2023-03-27 11:40
No they're both okay (I reset them to the same value I'm using for the provider repo.)
roy_collings
2023-03-27 11:49
Hey all (using a different thread for this 2nd issue I'm having): trying to publish a provider spec with:
```docker run --rm \
-w ${PWD} \
-v ${PWD}:${PWD} \
-e PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL \
-e PACT_BROKER_TOKEN=$PACT_BROKER_TOKEN \
pactfoundation/pact-cli:latest \
pactflow publish-provider-contract \
oas/openapi.yaml \
--provider my-provider \
--provider-app-version 1.0.0 \
--branch my-branch \
--content-type application/json \
--verification-exit-code=0 \
--verification-results result/report.md \
--verification-results-content-type application/yaml \
--verifier "github-actions"```
...but I'm constantly getting
```Error making request to https://okta-poc.pactflow.io//contracts/provider/pact-demo-api1/version/1.0.0 status=404 {"error":"The requested document was not found on this server."}```
As far as I can see I've set everything up correctly (those variables are correct and the oas / results files are at those paths). I'm a bit stumped, any ideas?
matt.fellows
2023-03-27 12:35
Hmm looking hard, it looks like there is a double // in there. Maybe your base URL has an extra trailing slash?
roy_collings
2023-03-27 12:49
Aaargh :deskflip: ... sorry, what a daft mistake - couldn't see it for looking. Thanks Matt!
matt.fellows
2023-03-27 13:12
Haha all good! I wonder if we should detect that and strip it off
One for tomorrow, glad you're back up and running!
roy_collings
2023-03-27 13:18
This _might_ be connected to the trailing '/' issue you caught in my other thread ... but I can't check because github s broken :disappointed:
itzhak
2023-03-28 06:51
Hi :slightly_smiling_face: is there a way to:
1. Remove a webhook via CLI?
2. List all webhooks via CLI?
3. Edit webhooks via UI?
Thanks!
matt.fellows
2023-03-28 08:24
Thanks for raising them! Just in case you haven't seen, http://pactflow.io does have a UI for this.
Also there is a terraform provider you can use
xchen
2023-03-28 13:47
Hi All. I have this pactPublish command specified on my jenkinsfile: "./gradlew -Pversion='${buildVersion}' -Duser.home=${script.env.HOME} pactPublish -PpactBrokerBranch='${script.env.BRANCH_NAME}'". The pact is published on the pact broker but it does not show the "Branch" info on the matrix. Could anyone please let me know what went wrong? We use pact gradle plugin. Thanks.
uglyog
2023-03-28 23:01
Refer to https://github.com/pact-foundation/pact-jvm/tree/master/provider/gradle#including-the-consumer-branch-when-publishing-min-versions-41334219434 which has the options for setting the branch
jmvb.registros
2023-03-29 12:15
Hi there, I found in this https://pact-foundation.slack.com/archives/C9VPNUJR2/p1678225150913959?thread_ts=1678086022.188169&cid=C9VPNUJR2 that the `dius/pact-broker` image is going to be deprecated. Is that still the case?
There are some https://docs.pact.io/pact_broker/docker_images/dius that I would benefit from.
Thanks :slightly_smiling_face:
```If you want to run the container as a standalone instance, then the dius/pact-broker image which uses Phusion Passenger may serve you better, as Passenger will restart any crashed processes.```
yousafn
2023-03-29 13:24
I'll raise an issue to document this on the repo and website, so its clear :slightly_smiling_face:
yousafn
2023-03-29 14:37
My pleasure, out of interest, what would be the feature(s) that you are looking for?
Would there be appetite to participate in maintenance of the image at all, feel free to comment in the issue as well where it will have longer visibility.
jmvb.registros
2023-03-29 14:40
These ones caught my eye when I was reading https://github.com/phusion/passenger/wiki/Puma-vs-Phusion-Passenger entry
```If you want to run the container as a standalone instance, then the dius/pact-broker image which uses Phusion Passenger may serve you better, as Passenger will restart any crashed processes.```
```Management tools
Puma provides a control server which allows you to stop or restart Puma and to query its status. However, it appears to be rather minimalistic (it only displays the size of the backlog and the number of running requests), and doesn't appear to be a first-class citizen. For example, the control server does not work in clustered mode. <-- That issue is now marked as fixed and supported since 2.3.0.
Phusion Passenger, both the open source and Enterprise variants, have management tools that provide much more insight. Phusion Passenger allows you to stop, restart and to query its status through command line tools like passenger-status, passenger-config, passenger-memory-stats. These tools are regular command line tools, and their access can be controlled through sudo, which is a very Unix way of doing things. These tools display everything Puma's status server displays, plus the exact requests that are currently running, how long they've been running, the application's CPU and memory usage, etc.```
tjones
2023-03-31 08:34
Question about https://github.com/pact-foundation/pact_broker/discussions/425
``` "verificationResults": [
{
"key": "the key from the pacts for verification response",```
^ What?s the key here? I don?t have anything called `key` in my pacts for verification response. Is it the pact-version hash?
tjones
2023-03-31 08:35
Follow up question:
> base64 encoded JSON test results in the same format that they currently are
What?s the format they currently are?
tjones
2023-03-31 08:55
Ah, I found where we discussed it. It?s not documented, and looks like I offered to do it :joy: https://pact-foundation.slack.com/archives/CLS16AVEE/p1673915146925249?thread_ts=1672268871.849799&cid=CLS16AVEE
tjones
2023-03-31 08:57
@bethskurrie: When you?re online, not urgent over the weekend - could you link me to the place in the ruby source where the request objects for verification are defined? I?m not very good at reading Ruby, but if you can point me at the right package I should be alright from there
ruben.perezg
2023-03-31 10:15
Hi :slightly_smiling_face:
We have Pact integrated with some of our applications, and also with our CI/CD pipelines using the Pact Broker. And we are quite happy about it.
But we are gonna *migrate our CI and CD* systems from _Travis & Spinnaker_ to _GitHub_ Actions. That means that we need to create another Webhook to trigger the needed provider builds using the `contract_requiring_verification_published` .
Once we have done this, both Webhooks will be triggered by any contract change, resulting in requests to both CI systems. During the migration process, we expect that every repository is either using one CI system or the other mainly, and not using both other than for initial migration tests.
Taking that into account, that would made the Webhook execution information shown in the Borker UI not ideal, because it will probably stay as "Retrying" some time, and then shown as "Failed" because it will not be able to trigger one od the CI's executions.
Do you know if there is a way to get a "smother" migration, and hence not get that feedback from the UI? I mean seeing Webhook executions failed because it will try to trigger both Webhooks, and we expect one to always fail.
ruben.perezg
2023-03-31 10:15
If there is any documentation about that anywhere it would be great, I just have failed to find it
fdawson
2023-04-03 14:33
Hi all, just had a question around how to delete/modify webhooks that I've created in the Pact Broker? I can't find anything in the documentation about how to edit them, and when I try to delete a webhook using DELETE .../webhook/{uuid}, I just get a 405 NOT ALLOWED returned. Does anyone know how to do this/point me to the right place?
tjones
2023-04-04 03:57
Further to this, I don?t think the https://github.com/pact-foundation/pact_broker/discussions/425 is right. I needed to add the following fields:
``` providerApplicationVersion: string;
success: boolean;```
chrisjburnscg
2023-04-07 15:55
Hi, I'm just about to update the Postgres dependency version for the Pact Broker Helm Chart to version 15 of Postgres, but I just wanted to double check if the Pact Broker is compatible with version 15 of Postgres before I did the change.
matt.fellows
2023-04-08 02:23
It looks like we currently test up to 14. I'd say it's likely to just work, but also wouldn't be confident recommending that be the new default.
Beth would be best placed to answer but is currently on leave for another week
buckley
2023-04-11 14:30
Hello again. I'm seeing an issue on my end when I run can-i-deploy. It seems that the answer is always no. My consumer has already published its pacts to the branch and the pact tests themselves are passing on both the consumer and the provider, but my output looks similar to the following:
```Computer says no ¯\_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
------------------------|------------|--------------------------|-----------|----------|--------
foo-consumer | git-hash.. | bar-provider | ??? | ??? |
WARN: It is recommended to specify the environment into which you are deploying. Without the environment, this result will not be reliable.
There is no verified pact between the latest version of foo-consumer (git-hash) and version git-hash of bar-provider```
yousafn
2023-04-11 15:01
What command are you providing
Also the warning
> ```WARN: It is recommended to specify the environment into which you are deploying. Without the environment, this result will not be reliable.
> There is no verified pact between the latest version of foo-consumer (git-hash) and version git-hash of bar-provider```
buckley
2023-04-11 15:03
the CI uses the following command
```if [ "$CI_GIT_BRANCH" = "main" ]; then pact-broker can-i-deploy \
--pacticipant=$PROVIDER_NAME \
--broker-base-url=$PACT_BROKER_BASE_URL \
--version $CI_GIT_COMMIT \
--broker-token=$PACT_BROKER_TOKEN; \
fi```
yousafn
2023-04-11 15:05
of the env you want to deploy too, otherwise how does it know which env to do the checks against
buckley
2023-04-11 15:05
kk. I'll do the environment because this is during my merge to main, so we haven't tagged yet
buckley
2023-04-11 15:57
would it be required that a pact be published by the consumer with the same environment?
pryan
2023-04-11 22:50
Hello! I'm trying to setup pact broker in a development environment. I would like for the end users to be able to access the UI via a reverse proxy, and have the publication/verification instructions from services execute internal to the reverse proxy.
I've noticed that the initial publication request by a service (PactBroker::Client::PublicationTask) uses the locally defined pact_broker_base_url initially, but it is eventually replaced by the base_url defined in the Pact Broker configuration. I've poked around and this definitely appears to be the desired behavior.
This is presenting a problem. The publication task needs to use the internal URL to publish, but the UI needs to use the external URL provided by the reverse proxy. And it seems as though either the UI js will break (see attached), or the publication task will break.
Now, if we mount pact-broker to the root path of the service, and remove the base_url variable from the pact-broker configuration, then everything works! However, this isn't a good option for a variety of reasons (Authentication/other desired routing).
If/when we get this running in CI, this probably won't be an issue as both the UI and publication requests will both originate from outside of the reverse proxy. But for development work this is pretty annoying. If we are defining the publication URL in each service, why would this get overridden by a configuration in the broker? Thanks! cc @andy.jenness
guozhangliew
2023-04-14 02:07
I am having issues setting up pact broker with aws ecs with the pact-foundation/pact-broker docker image
I have a load balancer with https listener that forwards to my TargetGroup that points to my
ecs service container at port 9292
``` TargetGroup:
Type: AWS::ElasticLoadBalancingV2::TargetGroup
Properties:
Name: pact-target-group
Port: ${param:brokerPort}
Protocol: HTTP
VpcId: ${param:VpcId}
TargetType: ip
HealthCheckIntervalSeconds: 60
HealthCheckPath: /diagnostic/status/heartbeat
HealthCheckTimeoutSeconds: 30
HealthyThresholdCount: 3
UnhealthyThresholdCount: 2
Listener:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
LoadBalancerArn: !Ref LoadBalancer
Port: 443
Certificates:
- CertificateArn: ${cf(ap-southeast-2):scale-certificates.MultiRegionDomainCertificate, ''}
Protocol: HTTPS
SslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06
DefaultActions:
- Type: forward
TargetGroupArn: !Ref TargetGroup
ListenerHttp:
Type: AWS::ElasticLoadBalancingV2::Listener
Properties:
LoadBalancerArn: !Ref LoadBalancer
Port: 80
Protocol: HTTP
DefaultActions:
- Type: 'redirect'
RedirectConfig:
Protocol: 'HTTPS'
Port: 443
Host: '#{host}'
Path: '/#{path}'
Query: '#{query}'
StatusCode: 'HTTP_301'```
but im currently having issues where the ecs container is returning my health checks as status 503
can someone help?
uglyog
2023-04-14 02:25
You need to check that `/diagnostic/status/heartbeat` is accessible from outside the ECS task and the port is the correct one that is exported from the docker container, the security groups are setup correctly to allow traffic from the ELB to the target group and that the IAM roles are configured correctly to interact with the target group. If any of those do not align up properly, you will get that response.
guozhangliew
2023-04-14 03:54
@uglyog it was the lack of security group defined! thank you so much for the tip!
vanitha.annamalai
2023-04-18 06:10
hey folks:wave:
I am trying to create webhook using pact_broker-client gem (our pact broker is pactflow broker). I keep getting this error even though I use the same credentials I use in the frontend to create webhook successfully `Error creating webhook. response status=403 body=Forbidden. Either you are using a read only token for a request that requires a write token (the most likely cause), or you do not have the required permissions.`
this is command I am executing. Any idea why the error? :thankyou:
``` pact-broker create-webhook https://api.buildkite.com/v2/organizations/<org-name>/pipelines/<slug>/builds \
--header "Authorization: Bearer <token>" \
--request POST \
--consumer <consumer> \
--provider <provider> \
--broker-base-url <pactflow-url> \
--broker-token <admin user's token> \
--data '{
"branch": "branch",
"commit": "HEAD",
"message": "sample Consumer -> sample Provider",
"env": {
"PACT_URL": "${pactbroker.pactUrl}",
}
}' \
--contract-content-changed \
--team-uuid <uuid> ```
vanitha.annamalai
2023-04-18 09:59
Looks like token with User access doesnt have access to create Webhook even though UI says webhook management is allowed User role. When I change the role to admin I got POST success message. But still in the pactflow frontend, i cant see the new webhook entry
james.perepiczka
2023-04-18 17:50
Hi, I wonder if I can have some clarity on what I am seeing? In my CI/CD (CircleCI) pipeline I call `pact-broker record-deployment --environment "main" --pacticipant "service" --version "74332f5"` and I get the output `Recorded deployment of service version 74332f5 to main environment in the Pact Broker` . I then call the command `pact-broker create-version-tag --pacticipant "service" --version "74332f5" --tag "main"` . This is so that we support the legacy implementation of using tags and then have a history of environments to migrate over to in the future. The problem I am seeing is that whenever I call both of these commands, the contract has a tag of main but not an environment against it. If I just call `create-version-tag` then both an environment and tag are added to the contract but I?m not sure why. Even weirder still I use this same combination of record deployment and create version tag in downstream jobs and they tag and set environment with no problem
yousafn
2023-04-18 21:15
Hey hey,
If you have an arm64 or arm32 bit machine, I would :heart: your help in testing out some pact-broker images for me. Drop me a shout in a :thread: if you do, you can see my cookie trail :cookie: above :point_up_2:
matt.fellows
2023-04-19 02:06
I can test as well, and we can also spin up an ARM AWS host to play around with too.
pryan
2023-04-19 20:40
Hi @yousafn. I recently was able to get the appropriate headers added I beleive:
`*"*HTTP_X_FORWARDED_SCHEME*"*=>*"*https*"*,`
`*"*HTTP_X_FORWARDED_HOST*"*=>*"*http://contract-testing-service.chm.life*"*,`
`*"*HTTP_X_FORWARDED_PORT*"*=>*"*443*"*,`
`*"*HTTP_X_FORWARDED_SSL*"*=>*"*on*"*,`
We've mounted and configured pact-broker as such:
`app = PactBroker::App.new do |config|`
`binding.pry`
`config.port = "8000"`
`config.log_stream = :stdout`
`config.log_level = :debug`
`# config.log_level = :info`
`config.basic_auth_enabled = false # set to true to enable the user below`
`config.basic_auth_username = ENV["BASIC_AUTH_USERNAME"]`
`config.basic_auth_password = ENV["BASIC_AUTH_PASSWORD"]`
`config.basic_auth_read_only_username = ENV["AUTH_READ_ONLY_USERNAME"]`
`config.basic_auth_read_only_password = ENV["AUTH_READ_ONLY_PASSWORD"]`
`config.database_url = "postgres://#{ENV["POSTGRES_USER"]}:#{ENV["POSTGRES_PASSWORD"]}@#{ENV["POSTGRES_HOST"]}/#{ENV["POSTGRES_NAME"]}"`
`config.base_url = "http://contract-testing-service/pact"`
`end`
`Rails.application.routes.draw do`
`mount app => "/pact"`
`get :ping, to: "ping#ping", defaults: { format: :json }`
`end`
It seems like everything is working well, and the headers appear to be present with all requests, but the application still seems to be using the base_url default for the UI.
pryan
2023-04-20 19:47
Ok - I realize I need to replace base_url with base_urls and include the proxy address as well. Haven't quite gotten it working, but seeing some promising behavior now. :crossed_fingers:
pryan
2023-04-20 21:29
Ok! It works. Was using base_url instead of base_urls and including the additional URL.
lluis.casals
2023-04-21 09:41
Hi, I wonder if I can publish the provider?s verification results ?manually?/curl to a self-hosted Broker :thinking_face:
1- First I can run the verification and store the results as a JSON file, per example: `pact-provider-verifier #{_contract_json_file_} --provider #{_pacticipant_} --provider-base-url 'http://localhost:3000/' -v --out #{_results_json_file_}`
2- Then gather the verification results file and push it to the broker, per example: `curl -v -X PUT -H "Content-Type: application/json" -d @#{_results_json_file_} #{_broker_}/pacts/provider/#{_pacticipant_}/consumer/#{_service_consumer_}/version/#{_app_version_}/verification-results`
Thanks a lot in advance for any advice you can provide me.
yousafn
2023-04-21 11:12
Got to love a bit of rubber ducky programming :slightly_smiling_face: If you want to propose any changes to the docs, that would have helped out past you, you can :+1:
yousafn
2023-04-21 11:20
Yes you can,
An example here
https://github.com/pactflow/pactflow-jsonschema-example#provider-test
associated post
https://pactflow.io/blog/contract-testing-using-json-schemas-and-open-api-part-3/
lluis.casals
2023-04-21 11:22
:slightly_smiling_face: thanks!
This is for PactFlow, is that to publish provider contract testing can only be done using PactFlow?
yousafn
2023-04-21 11:22
I know its for PactFlow but will work for your original question hence why I posted it
yousafn
2023-04-21 11:23
Essentially you are just acting at the pact provider verifier, performing a test and publishing a result
yousafn
2023-04-21 11:37
Soooo, I've got ARM flavours of
? Pact Broker - https://hub.docker.com/r/you54f/pact-broker/tags
? Pact CLI - https://hub.docker.com/r/you54f/pact-cli
? Pact Ruby Standalone - ARM64 Linux / OSX https://github.com/YOU54F/pact-ruby-standalone/releases/tag/v3.1.2.2-alpha
? Windows aarch64 pact ffi build - https://github.com/YOU54F/pact-reference/releases/tag/libpact_ffi-v0.4.3
? Pact-JS-Core
? master branch plus Pact Ruby Standalone for ARM64 https://www.npmjs.com/package/@you54f/pact-core/v/13.14.0
? master branch plus Pact FFI on pre install, Pact Ruby Standalone on post install https://www.npmjs.com/package/@you54f/pact-core/v/13.15.0?activeTab=code
? master branch plus pre built Pact.Node binary, Pact FFI/Pact Ruby Standalone packed into GitHub release tarballs https://www.npmjs.com/package/@you54f/pact-core/v/13.16.1?activeTab=code
?? Includes Windows aarch64 binaries for pact ffi
? Pact-Node
? pact-node branch plus Pact Ruby Standalone for ARM64 https://www.npmjs.com/package/@you54f/pact-node?activeTab=versions
? Pact-JS
? 9.x.x branch plus Pact Ruby Standalone for ARM64 https://www.npmjs.com/package/@you54f/pact/v/9.19.0
? master branch consuming 13.15.0 of you54f/pact-core which downloads FFI/Pact ruby standalone on install hooks, and supports ARM64 for pact ruby standalone https://www.npmjs.com/package/@you54f/pact/v/11.1.0?activeTab=code
matt.fellows
2023-04-21 12:04
I love that my answer was going to be ?probably not? , and then you point at an example _i wrote_ to prove me wrong :laughing:
You have the memory of an :elephant: and the resourcefulness of a :gopher:
yousafn
2023-04-21 12:08
MattGPT has already answered all the questions - I just know where to find them :joy:
meghaagr
2023-04-25 12:12
@matt.fellows @bas: do we any similar package(http://au.com.dius.pact.consumer) in dotnet as we have for Java project used in this example https://github.com/pactflow/example-consumer-java-kafka/blob/master/src/test/java/io/pactflow/example/kafka/ProductsPactTest.java
yousafn
2023-04-25 12:15
I think the question is do we support message-pact in pact-net.
if so, then yes https://github.com/pact-foundation/pact-net/blob/master/docs/messaging-pacts.md
yousafn
2023-04-25 12:16
Please don't tag people directly unless directed to :slightly_smiling_face: people will respond in their own time, and people are doing this alongside their own work
yousafn
2023-04-25 12:17
Also this is a pact-net question, not a pact-broker question, so best asked in #pact-net :+1:
yousafn
2023-04-25 12:34
No worries, I am working on the pact-net workshop today (albeit for rest) so hope to get that published shortly
lluis.casals
2023-04-25 14:34
Sure thing.
The broker needs some authentication to be able to interact with-it, and the ?easiest? way is to use a cert.
So at the end I need to interact with the Broker via http requests.
haiyang.huang
2023-04-25 15:21
Hi everybody, I have a couple of questions about the can-I-deploy tool:
1. As an example, I have multiple *released + supported* versions of a consumer and a provider in production. I now want to release a new version of the provider, how does the can-I-deploy tool figure out if I can release? Does it just check though the provider verification results and only allow release if the new provider is completely backwards compatible with ALL consumer releases?
2. Second example, I have multiple *deployed* consumer versions each with an application instance, and multiple versions of provider each with an application instance. Now I want to deploy a new provider version onto one of the instances, does this new version need to be compatible with all deployed versions of the consumer?
dimundo
2023-04-25 16:22
hi!
any ideas about
```cannot execute INSERT in a read-only transaction```
or
```
2023-04-25 16:17:28.880483 E [8:puma srv tp 001 logging.rb:48] PactBroker::Errors::ErrorLogger -- Error reference dDCSJbtIGT -- Exception: Sequel::DatabaseError: PG::ReadOnlySqlTransaction: ERROR: cannot execute INSERT in a read-only transaction```
eddie
2023-04-25 22:44
Apologies for the cross-post, wasn't sure where it belongs:
https://pact-foundation.slack.com/archives/CLS16AVEE/p1682462165874079
matt.fellows
2023-04-26 02:42
Pact standalone CLI on ARM Mac OSX (Venture 13.3.1) - tested in non-rosetta terminal. :white_check_mark:
(I haven?t run extensive testing, but the mock service started and responded to curl requests)
```Last login: Wed Apr 26 12:34:23 on ttys002
? ~ /tmp/
? /tmp curl -LO https://github.com/you54f/pact-ruby-standalone/releases/download/v3.1.2.2-alpha/pact-3.1.2.2-alpha-osx-arm64.tar.gz
tar xzf pact-3.1.2.2-alpha-osx-arm64.tar.gz
cd pact/bin
./pact-mock-service --help start
./pact-provider-verifier --help verify
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 19.4M 100 19.4M 0 0 2928k 0 0:00:06 0:00:06 --:--:-- 3955k
Usage:
pact-mock-service start
Options:
[--consumer=CONSUMER] # Consumer name
[--provider=PROVIDER] # Provider name
-p, [--port=PORT] # Port on which to run the service
# Default: 1234
-h, [--host=HOST] # Host on which to bind the service
# Default: localhost
-d, [--pact-dir=PACT_DIR] # Directory to which the pacts will be written
-m, [--pact-file-write-mode=PACT_FILE_WRITE_MODE] # `overwrite` or `merge`. Use `merge` when running multiple mock service instances in parallel for the same consumer/provider pair. Ensure the pact file is deleted before running tests when using this option so that interactions deleted from the code are not maintained in the file.
# Default: overwrite
[--pid-dir=PID_DIR] # PID dir
# Default: tmp/pids
-l, [--log=LOG] # File to which to log output
[--log-level=LOG_LEVEL] # Log level. Options are DEBUG INFO WARN ERROR
# Default: DEBUG
-i, [--pact-specification-version=PACT_SPECIFICATION_VERSION] # The pact specification version to use when writing the pact. Note that only versions 1 and 2 are currently supported.
# Default: 2
-o, [--cors=CORS] # Support browser security in tests by responding to OPTIONS requests and adding CORS headers to mocked responses
[--ssl], [--no-ssl] # Use a self-signed SSL cert to run the service over HTTPS
[--sslcert=SSLCERT] # Specify the path to the SSL cert to use when running the service over HTTPS
[--sslkey=SSLKEY] # Specify the path to the SSL key to use when running the service over HTTPS
Start a mock service. If the consumer, provider and pact-dir options are provided, the pact will be written automatically on shutdown (INT).
Usage:
pact-provider-verifier PACT_URL ... -h, --provider-base-url=PROVIDER_BASE_URL
Options:
-h, --provider-base-url=PROVIDER_BASE_URL # Provider host URL
-c, [--provider-states-setup-url=PROVIDER_STATES_SETUP_URL] # Base URL to setup the provider states at
[--pact-broker-base-url=PACT_BROKER_BASE_URL] # Base URL of the Pact Broker from which to retrieve the pacts. Can also be set using the environment variable PACT_BROKER_BASE_URL.
-n, [--broker-username=BROKER_USERNAME] # Pact Broker basic auth username. Can also be set using the environment variable PACT_BROKER_USERNAME.
-p, [--broker-password=BROKER_PASSWORD] # Pact Broker basic auth password. Can also be set using the environment variable PACT_BROKER_PASSWORD.
-k, [--broker-token=BROKER_TOKEN] # Pact Broker bearer token. Can also be set using the environment variable PACT_BROKER_TOKEN.
[--provider=PROVIDER]
[--consumer-version-tag=TAG] # Retrieve the latest pacts with this consumer version tag. Used in conjunction with --provider. May be specified multiple times.
[--provider-version-tag=TAG] # Tag to apply to the provider application version. May be specified multiple times.
[--provider-version-branch=BRANCH] # The name of the branch the provider version belongs to.
-g, [--tag-with-git-branch], [--no-tag-with-git-branch] # Tag provider version with the name of the current git branch. Default: false
-a, [--provider-app-version=PROVIDER_APP_VERSION] # Provider application version, required when publishing verification results
-r, [--publish-verification-results], [--no-publish-verification-results] # Publish verification results to the broker. This can also be enabled by setting the environment variable PACT_BROKER_PUBLISH_VERIFICATION_RESULTS=true
[--enable-pending], [--no-enable-pending] # Allow pacts which are in pending state to be verified without causing the overall task to fail. For more information, see https://pact.io/pending
[--custom-provider-header=CUSTOM_PROVIDER_HEADER] # Header to add to provider state set up and pact verification requests. eg 'Authorization: Basic cGFjdDpwYWN0'. May be specified multiple times.
[--custom-middleware=FILE] # Ruby file containing a class implementing Pact::ProviderVerifier::CustomMiddleware. This allows the response to be modified before replaying. Use with caution!
-v, [--verbose=VERBOSE] # Verbose output. Can also be set by setting the environment variable VERBOSE=true.
-f, [--format=FORMATTER] # RSpec formatter. Defaults to custom Pact formatter. Other options are json and RspecJunitFormatter (which outputs xml).
-o, [--out=FILE] # Write output to a file instead of $stdout.
[--wait=SECONDS] # The number of seconds to poll for the provider to become available before running the verification
# Default: 0
[--log-dir=LOG_DIR] # The directory for the pact.log file
[--log-level=LOG_LEVEL] # The log level
# Default: debug
[--fail-if-no-pacts-found], [--no-fail-if-no-pacts-found] # If specified, will fail when no pacts are found
Description:
The parameters used when fetching pacts dynamically from a Pact Broker are:
--pact-broker-base-url (REQUIRED)
--provider (REQUIRED)
--broker-username/--broker-password or --broker-token
--consumer-version-tag or --consumer-version-selector
--enable-pending
--include-wip-pacts-since
To verify a pact at a known URL (eg. when a verification is triggered by a 'contract content changed' webhook), pass in the pact URL(s) as the first argument(s) to the
command, and do NOT set any of the other parameters apart from the base URL and credentials.
To publish verification results for either of the above scenarios, set:
--publish-verification-results (REQUIRED)
--provider-app-version (REQUIRED)
--provider-version-tag or --tag-with-git-branch
Selectors: These are specified using JSON strings. The keys are 'tag' (the name of the consumer version tag), 'latest' (true|false), 'consumer', and 'fallbackTag'. For example '{\"tag\": \"master\", \"latest\":
true}'. For a detailed explanation of selectors, see https://pact.io/selectors#consumer-version-selectors
? bin curl -LO https://github.com/you54f/pact-ruby-standalone/releases/download/v3.1.2.2-alpha/pact-3.1.2.2-alpha
tar xzf pact-3.1.2.2-alpha-osx-arm64.tar.gz
cd pact/bin
./pact-mock-service --help start
./pact-provider-verifier --help verify
? bin
? bin ./pact-mock-service start
mock WARN: Please note: we are tracking events anonymously to gather important usage statistics like Pact-Ruby version and operating system. To disable tracking, set the 'PACT_DO_NOT_TRACK' environment variable to 'true'.
INFO WEBrick 1.8.1
INFO ruby 3.2.2 (2023-03-30) [arm64-darwin22]
INFO WEBrick::HTTPServer#start: pid=70249 port=1234
? bin I, [2023-04-26T12:40:17.080670 #70249] INFO -- : Received request GET /
D, [2023-04-26T12:40:17.107097 #70249] DEBUG -- : {
"path": "/",
"query": "",
"method": "get",
"headers": {
"Host": "localhost:1234",
"User-Agent": "curl/7.87.0",
"Accept": "*/*",
"Version": "HTTP/1.1"
}
}
E, [2023-04-26T12:40:17.108173 #70249] ERROR -- : No matching interaction found for GET /
E, [2023-04-26T12:40:17.109216 #70249] ERROR -- : Interaction diffs for that route:
E, [2023-04-26T12:40:17.110783 #70249] ERROR -- : ```
matt.fellows
2023-04-26 02:43
Pact Standalone CLI in Rosett terminal (x86_64) :white_check_mark: (same as above)
tjones
2023-04-26 03:52
1) Yes, it will only let you deploy if you are compatible with all releases in that environment.
2) I don?t think I understand this question. What do you mean by ?application instance??
harwin1494
2023-04-26 08:31
Hi, the webhook from pact broker is getting triggered but is not executing the Jenkins Job and giving "Authentication required" error from Jenkins. I think to solve this, we might have to provide the username:password in Jenkins URL for authentication, however this seems to be an insecure way of accessing Jenkins as we are hardcoding the password in the URL (which gets reflected in webhook logs).
Is there any other way of authenticating the webhook URL in Pact Broker?
greg.tyler
2023-04-26 08:48
Webhooks can have username and password parameters that get passed in when it makes the request (but the password isn?t shown if you GET the webook). There?s https://docs.pact.io/pact_broker/webhooks/template_library#jenkins---trigger-build.
I don?t know if this is possible, but it would be nice to pass it through env variables instead so you could do `"password": "${env.JENKINS_PASS}"` and pass `JENKINS_PASS` to the Pact Broker container.
haiyang.huang
2023-04-26 09:09
Thank you @tjones! By application instance I meant the optional attribute we supply to `record-deployment` command. I saw it from this section of the doc. https://docs.pact.io/pact_broker/recording_deployments_and_releases#recording-deployments
tjones
2023-04-26 09:13
Oh, I see. I didn?t know about that option. I don?t know, I?m afraid - you?ll have to wait for someone else who can answer.
tjones
2023-04-26 09:16
It looks to me like the documentation suggests that yes, each deployment must be compatible with all application instances.
matt.fellows
2023-04-26 10:47
There is probably already a feature request for that. It was one of the first features we added to Pactflow (secrets handling) if that's an option for you
harwin1494
2023-04-26 11:16
@greg.tyler will pact broker trigger the webhook or do we have to trigger ourself by curl with template library code? If it is triggered internally by broker then what is the use of template library code?
haiyang.huang
2023-04-26 12:04
Hi everyone, a follow up question about `can-I-deploy` tool, say if we have consumer v1 and provider v1 already _deployed_ in production. Now we have consumer v2 and provider v2, which works with each other but both include breaking changes for provider v1 and consumer v1 respectively. What is the recommended way to deploy v2 to production? (I think if we tried to use can-I-deploy it will fail because if we run it for consumer v2 it will say it?s not compatible for provider v1 and vice versa). Thank you in advance!
yousafn
2023-04-26 12:12
you could use an expand and contract pattern,
? contract testing highlights the incompat
? provider and consumer deployed are compat, provider makes breaking changes, both dev versions of provider and consumer cannot be deployed
? you update one side of the code to support it
? consumer to deal with old and new change
? provider to deal with old and new change
? contract testing says a-ok
? you deploy all the things
? backwards compat provider or consumer gets deployed
? contract testing then allows you to remove the things
? consumer can stop calling old provider change
? provider can stop producing old change
? everyone is compatible with the new things
Your mileage and exact steps depend on your use case.
There are times where it's unavoidable, you can skip the can-i-deploy checks or allow the job to fail but proceed with deployment, this might co-incide with planned downtime
tjones
2023-04-26 12:21
Absolutely. Contract testing just highlights this problem, but it exists if you don?t have one side speak both versions, regardless of whether or not you catch it.
greg.tyler
2023-04-26 13:29
The webhooks in the template library are examples of what you might tell Pact Broker to to verify a contract with a few different CI tools. They?re automatically triggered when you upload a new Pact (that?s different to the last changed one), so the process is:
1. Consumer runs tests, generates contract
2. Consumer publishes contract to Pact Broker
3. Pact Broker triggers whatever webhooks you?ve defined (like the ones in the template library)
4. Provider, triggered by that webhook, verifies that the contract is valid
harwin1494
2023-04-26 13:31
@greg.tyler #3, how can we 'define' webhook?
We only know about creating webhook with create-webhook command
greg.tyler
2023-04-26 13:32
I think the three options are that command, https://docs.pact.io/pact_broker/api/webhooks or https://docs.pact.io/pact_broker/terraform_provider (which is what I?m using)
bas
2023-04-27 08:11
Personally I don?t mind being tagged but I?m ?just? another Pact user like yourself, with little knowledge on using Pact with messaging-based systems :) So I wouldn?t have been able to help out much anyway.
I am a bit of a C# fan though and I?m (supposed to be?) working on another pact-net example with RestAssured .Net so I actually like being tagged and made aware of interesting pact-net questions and threads.
matt.fellows
2023-04-27 22:53
The OSS Pact Broker does not manage secrets, with the only exception that it does try to obscure certain known authorization headers in the UI
matt.fellows
2023-04-27 22:53
They are stored as plain text in the DB and are visible in API calls / the HAL browser
matt.fellows
2023-04-27 23:00
> The broker needs some authentication to be able to interact with-it, and the ?easiest? way is to use a cert.
I?m assuming you mean certificate based auth / MASSL or something? (not simply TLS)
matt.fellows
2023-04-27 23:00
You could also potentially raise a feature request to support that authentication mode and/or submit a PR. That way you wouldn?t need to work around with APIs
haiyang.huang
2023-05-04 09:43
*Hi everybody, further extending the discussion above.*
*We have a set of applications for which we need to support multiple MAJOR releases. This means these major releases have breaking change in them but each major release is compatible with other apps in that major release. We want to take advantage of the can-I-deploy tool to _release_ into production environment and block releasing breaking changes within the same major version. But we don?t want to block deployment because the change isn't compatible with other major versions. Is there anyway to do this? The only way I can think of is to have one prod environment for each major release but I feel that gets complicated quickly.*
*Thank you in advance for your time!*
haiyang.huang
2023-05-04 15:26
Thanks Timothy, could you please help me understand why deploy instantly makes a difference?
tjones
2023-05-04 15:56
Because if you deploy everything together, there will be periods where some services are not on the new version yet, but some are.
tjones
2023-05-04 15:56
Unless you can deploy everything in the same instant, there will be some time where the services are broken.
tjones
2023-05-04 15:56
Pact (and contract testing in general) are designed to prevent breaking changes.
tjones
2023-05-04 15:57
As far as I know, there?s no way to do the kind of deploy you?re asking about without allowing breaking changes.
haiyang.huang
2023-05-04 16:15
Ok that makes sense, I think I also didn't explain our situation well enough, sorry. In our case the product we are releasing is binary code. From our perspective something could be considered as released once the binary is made available to the end users. It also means we are technically not deploying/running the code ourself. As what we are working on isn?t a server we are not worried about outages, but we do want to keep track of compatibility of different major versions of our applications which are designed to work together. I hope that makes sense.
tjones
2023-05-04 16:24
ah, sure. In that case I would consider a major version an ?environment?, yes.
haiyang.huang
2023-05-04 16:26
I'm also open to other approches if you have any suggestions :slightly_smiling_face:
jorgen.x.andersson
2023-05-09 10:48
Thanks a ton for the new Pact-Broker-Docker version released. As of now our tools does not indicate any security flaws. Great work everyone involved!
We will install and start testing shortly.
tanyaryzhova93
2023-05-10 14:42
Hello! Is it possible to provide several pacticipants in the record-deployment? Like:
```pact-broker record-deployment
--pacticipant="my-pacticipant-1"
--pacticipant="my-pacticipant-2"
--version="1"
--environment="test"
--broker-base-url="http://pactflow.com"
--broker-token="123"
--verbose```
yousafn
2023-05-10 14:56
you might be able to to the following by repeating the fields
```pact-broker record-deployment \
--broker-base-url="http://pactflow.com" \
--broker-token="123" \
--verbose \
--pacticipant="my-pacticipant-1" \
--version="1" \
--environment="test" \
--pacticipant="my-pacticipant-2" \
--version="1" \
--environment="test"```
> You can specify as many application versions as you like, and you can even specify multiple versions of the same application (repeat the `--pacticipant` name and supply a different version.)
It works for the can-i-deploy command. mentioned https://docs.pact.io/pact_broker/can_i_deploy#alternate-usage---specifying-dependencies-explicitly
stefan.kemp
2023-05-11 07:46
Hello! We use the `Read/write token (CI)` in our builds to publish pacts. We get the following error message: `Forbidden. Either you are using a read only token for a request that requires a write token (the most likely cause), or you do not have the required permissions.`. What could be the issue?
yousafn
2023-05-12 16:02
If this does work, please let us know and even better consider raising a pull request on the docs, (or at least raising an issue to say that it works and it would be good to add the documentation, somewhere where _you_ would expect it :slightly_smiling_face:
tanyaryzhova93
2023-05-12 17:31
I tried it and it didn?t work for me, apparently r`ecord-deployment` doesn?t support several pacticipants.
lluis.casals
2023-05-15 15:07
Sorry for the so long late answer :facepalm: , yes. This is for a MASSL.
I will do this request, thanks for the idea!
lluis.casals
2023-05-15 15:26
https://pact.canny.io/feature-requests/p/provide-massl-based-auth-support
? Provide MASSL based auth support
? This is to add the support on adding a ?cert? and a ?key?, regarding a self-hosted Broker that requires a ?cert? and a ?key?.
? This will make the availability to call the ?Pact::VerificationTask? adding the ?cert? and ?key? to interact with the Self-Hosted Broker.
? As an example: --cert /path/to/client/cert.pem --key /path/to/client/key.pem
matt.fellows
2023-05-16 01:15
I doubt we?ll have time to pick this up any time soon, but if you?re really keen you could attempt a PR here: https://github.com/pact-foundation/pact_broker-client
haiyang.huang
2023-05-16 09:19
Hi all, in pact broker, is it possible to use wildcard search for participant names? e.g. my participants are named `system.subsystem` I want to fetch all the contracts with consumer names which matches "`system.*`"? Thanks!
matt.fellows
2023-05-16 11:46
mind raising (and checking) if the feature request exists at http://pact.canny.io?
harwin1494
2023-05-17 14:07
Hi team, the can-i-deploy is incorrectly fetching the verification result and giving a false success. The pact verification as per the broker and the jenkins logs, has failed for Consumer A and Provider B, but the Can-i-deploy is showing it as a success. How to sort this out please?
matt.fellows
2023-05-17 21:44
Can you please show the arguments you're using and why this think it should fail?
dimundo
2023-05-18 09:30
hi!
any options to mark pending pacts in UI ? Green cell makes you feel safe, when you maybe not :)
nickm
2023-05-22 16:50
Is there a way to make can-i-deploy checks trigger verification runs if there is no verification result when the can-i-deploy check occurs?
yousafn
2023-05-22 16:56
no, you would use webhooks for that purpose, you can set can-i-deploy to retry and poll however,
```--retry-while-unknown 6 --retry-interval 10```
which gives time for the triggered verification run to have taken place
nickm
2023-05-22 17:37
`webhooks` I already use the `contract_requiring_verification_published` webhook, however we occasionally have a race condition where a new consumer version will be deployed while a provider is going through the pipeline, so the end result is when the provider hits its deploy, the deploy fails because the two versions never lined up.
Are there distinct error codes for outright failure vs no verification result that could be keyed into to trigger a verification?
matt.fellows
2023-05-22 23:20
`can-i-deploy` should run immediately before a deployment - are you saying a race condition is happening there? If there is a big gap between `can-i-deploy` and `deploy` that?s probably worth addressing first
nickm
2023-05-23 15:34
`can-i-deploy` is happening immediately before deploy in the pipeline.
The race condition I?m describing is with verification. e.g.:
Consumer X v1 and Provider Y v1 are currently deployed. Commits are made to both and the pipelines are running concurrently. Provider Y v2 runs verification against Consumer X v1 in its pre-deploy pipeline, Consumer X publishes its Pact for v2, which triggers a verification webhook against Provider Y v1, which is the currently deployed version. That verification passes, and Consumer X v2 passes the can-I-deploy check and is deployed.
Now Provider Y runs a can-i-deploy check for v2 which fails because Consumer X v2 is now deployed, and has not been verified against Provider Y v2, due to v1 being the deployed version at the time the consumer pipeline triggered the verification webhook, and Consumer X v1 being the deployed version when the provider pipeline ran its own verification.
harwin1494
2023-05-26 11:12
Hi team, searching for a provider with the following filter :- `'Latest version with tag... :- main'` returns nothing, but when I search with the following filter :- `'All versions with tag... :- main'`, a provider version is displayed with a greyed out `main` tag. Even though a pact verification has been done for a provider with a certain version tagged with main, it does not get displayed in the former filter. Any reason for the same?
siyuanshen1993
2023-06-04 23:45
Hi! I?m new with pact, recently I upload pact files into pact broker, but my provider cannot get that pact file from pactBrokerUrl, I already provide url ,username and password but I still got this error: Could not load pacts from the pact broker. Do I able to get the pact file locally or is some steps I missed?
siyuanshen1993
2023-06-04 23:57
```2023-06-04T23:56:22.761168Z DEBUG ThreadId(02) pact_verifier::pact_broker: templated URL = https://pact.dev.tapendium.xyz/pacts/provider/getOrganisationParentProvider/for-verification
2023-06-04T23:56:22.761393Z DEBUG ThreadId(02) pact_verifier::pact_broker: final URL = https://pact.dev.tapendium.xyz/pacts/provider/getOrganisationParentProvider/for-verification
2023-06-04T23:56:22.761615Z DEBUG ThreadId(02) pact_verifier::pact_broker: Sending JSON to https://pact.dev.tapendium.xyz/pacts/provider/getOrganisationParentProvider/for-verification using POST: {"providerVersionTags":[],"includePendingStatus":true,"consumerVersionSelectors":[{"matchingBranch":true}],"providerVersionBranch":""}```
siyuanshen1993
2023-06-04 23:57
I think somehow my provider try to connect this url, but it?s not working
david.blanco
2023-06-07 18:20
Hello all
I am trying to run pact-broker using docker-compose
Added pact-broker to a docker-compose I was already using for other services: jenkins and sonaqube with nginx
My docker-compose file is like this
david.blanco
2023-06-07 18:20
```services:
jenkins:
image: jenkins:latest
container_name: jenkins
user: root
restart: unless-stopped
volumes:
- jenkins_data:/var/jenkins_home
- /var/run/docker.sock:/var/run/docker.sock
networks:
- sonarnet
ports:
- 8080:8080
- 50000:50000
sonarqube:
image: sonarqube:7.7-community
container_name: sonarqube
restart: unless-stopped
volumes:
- sonarqube_conf:/opt/sonarqube/conf
- sonarqube_data:/opt/sonarqube/data
- sonarqube_extensions:/opt/sonarqube/extensions
- sonarqube_bundled-plugins:/opt/sonarqube/lib/bundled-plugins
networks:
- sonarnet
ports:
- 9000:9000
environment:
- sonar.jdbc.username=sonar
- sonar.jdbc.password=sonar
- sonar.jdbc.url=jdbc:
- SONAR_WEB_PORT=9000
db:
image: postgres
container_name: postgres
restart: unless-stopped
networks:
- sonarnet
environment:
- POSTGRES_USER=sonar
- POSTGRES_PASSWORD=sonar
volumes:
- postgresql:/var/lib/postgresql
- postgresql_data:/var/lib/postgresql/data
nginx:
image: nginx
container_name: nginx
restart: unless-stopped
networks:
- sonarnet
volumes:
- /home/ec2-user/ci/nginx:/etc/nginx
ports:
- 443:443
brokerdb:
image: postgres
container_name: brokerdb
restart: unless-stopped
networks:
- sonarnet
volumes:
- postgres-volume:/var/lib/brokerdb/data
environment:
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=password
- POSTGRES_DB=postgres
pact-broker:
image: pactfoundation/pact-broker:2.110.0-pactbroker2.107.1
ports:
- "9292:9292"
container_name: pact-broker
networks:
- sonarnet
depends_on:
- brokerdb
environment:
PACT_BROKER_PORT: '9292'
PACT_BROKER_DATABASE_URL: ""
PACT_BROKER_LOG_LEVEL: DEBUG
PACT_BROKER_SQL_LOG_LEVEL: DEBUG
PACT_BROKER_HTTP_DEBUG_LOGGING_ENABLED: "True"
# PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES is only needed for docker-compose
# because the database takes longer to start up than the puma process
# Should not be needed in production.
PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "5"
# The list of allowed base URLs (not setting this makes the app vulnerable to cache poisoning)
# This list allows the app to be addressed from the host and from within another docker container correctly
# Ngnix config below makes the app accessible on ports 443 and 80, while the Ruby application itself runs on port 9292
# PACT_BROKER_BASE_URL: 'https://localhost http://localhost http://localhost:9292 http://pact-broker:9292 https://host.docker.internal http://host.docker.internal http://host.docker.internal:9292'
networks:
sonarnet:
driver: bridge
volumes:
sonarqube_conf:
sonarqube_data:
sonarqube_extensions:
sonarqube_bundled-plugins:
postgresql:
postgresql_data:
jenkins_data:
postgres-volume:```
david.blanco
2023-06-07 18:21
```
server {
listen 443 ssl;
listen [::]:443 ssl;
ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/key.pem;
server_name localhost;
client_max_body_size 100M;
location /pact-broker {
proxy_pass http://pact-broker:9292;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Scheme "https";
proxy_set_header X-Forwarded-Port "443";
proxy_set_header X-Forwarded-Ssl "on";
proxy_set_header X-Real-IP $remote_addr;
}
location /sonarqube {
proxy_pass http://sonarqube:9000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location /manage {
proxy_pass http://jenkins:8080/manage;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
location / {
proxy_pass http://jenkins:8080;
proxy_redirect http://54.208.229.123:8080 https://54.208.229.123;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/share/nginx/html;
}
}```
david.blanco
2023-06-07 18:21
But something is wrong, I am able to access the pact-broker via http with the IP (like http://xx.xx.xx.xx:9292/)
But if I try to access using my DNS (like https:my-company/pact-broker) I get a Forbidden
and this warning in the pact-broker log
david.blanco
2023-06-07 18:21
`pact-broker | 2023-06-07 18:19:11.727614 W [7:puma srv tp 001] PactBroker::App -- attack prevented by Rack::Protection::IPSpoofing`
matt.fellows
2023-06-08 01:05
hmm interesting. I think the rack protection middleware came after the https://github.com/DiUS/pact_broker-docker/issues/58#issuecomment-358819665 to configure nginx (which looks like you follow).
It might be worth googling that Ruby Rack Middleware to see how it detects spoofing, and work backwards to see why it thinks it?s being spoofed
yonatany
2023-06-08 17:00
What is the best practice in case we have multiple places using the same contract? how we verify the contract - can publish the result do to multiple verifiers?
matt.fellows
2023-06-08 23:47
What do you mean by "using the same contract"?
A contract should be unique between two applications (one consumer and one provider, no more no less)
alanbos
2023-06-13 13:42
Hi - I'm using the `dius/pact-broker:2.96.0.0` image for pact broker, and I'm puzzled by an intermittent issue with querying for pacts between two pacticipants _A_ and _B_ (this seems to happen via both the UI and the commandline tool).
If I query for pacts between _A_ and _B_ by selecting "All versions with tag..." and a tag _T_ for _A_ I see plenty of resuits. If I then narrow the query to "Latest version with tag" (but the same tag _T_) then I get no results at all. Republishing the pacts from consumer tests for _A_ then seems to fix this.
Is this a bug, or have I misunderstood what the query is asking for?
simondemartini
2023-06-13 20:13
Is there any reason that provider tests automatically communicate with pact-broker, but consumers just generate json that has to be uploaded manually (or with the CLI)?
ran.tao
2023-06-13 21:59
Hi, we are trying to do a POC with pact-broker 2.106.0. Before installing pact-broker, our security check needs an official proof from pact-broker that the following versions of jquery are installed with pact-broker 2.106.0. Do you have anything like a release notes/install guide that I can find the info?
jquery-3.6.0.min.js (path: vendor/hal-browser/vendor/js/)
jquery-3.5.1.js (path: public/javascripts/)
matt.fellows
2023-06-13 22:16
Sorry I'm confused by the question. They want an exact version of jQuery or they don't want a set of jQuery versions?
Asking for an exact version doesn't make any sense in a world where dependencies need to be updated regularly for security and big fixes etc
matt.fellows
2023-06-13 22:17
Yes, because many consumer tests run on a Dev machine and the results are still WIP. So sending to the broker doesn't really make sense.
The provider needs to pull from the broker to get the right version (which might be changing)
simondemartini
2023-06-13 22:21
Have you all considered a flag to enable pushing those in those tests? i.e. `pactbroker.uploadContracts` or something? Might be handy so that some cases can avoid the extra contract upload step.
I think we're running into an edge case where it's a little painful to get the test output files, so its clumsy to get the json files to upload after the run
matt.fellows
2023-06-13 22:23
You could raise a feature request or PR, but at the moment you usually would need the CLI for other steps in your pipeline anyway so I tend to go the CLI route
matt.fellows
2023-06-13 22:24
I could imagine a future world where both sides could be continually connected to a broker to improve the Dev experience but that's not likely to happen any time soon
simondemartini
2023-06-13 22:27
I'll consider submitting one, and yeah definitely not an urgent request. But yeah a world where both sides are connected would be cool -- then the CLI could be run in more independent steps
ran.tao
2023-06-14 03:32
Hi @matt.fellows, sorry for the confusion. The ask is the exact versions of jquery which is used in pact-broker *version 2.106.0,* particularly. So I am looking for an evidence of the combination of:
*pact-broker: version 2.106.0*
*-- jquery-3.6.0.min.js*
*-- jquery-3.5.1.js*
matt.fellows
2023-06-14 04:17
ran.tao
2023-06-14 06:30
@matt.fellows I only see 3.5.1 in the search result and changelog. Anywhere I can find *jquery-3.6.0.min.js*? (path: vendor/hal-browser/vendor/js/). If there is no document showing *jquery-3.6.0.min.js* is included in pact-broker *2.106.0.* Our security team also accepts email with confirmation of the versions combination as evidence. Is it possible that you can provide an email?
matt.fellows
2023-06-14 06:38
Think about this request:
```pact-broker: version 2.106.0
-- jquery-3.6.0.min.js
-- jquery-3.5.1.js```
Why would we want to have 3.6.0 and 3.5.1? That doesn?t make any sense
ran.tao
2023-06-14 06:39
it is not what we want. We download the source code and did a scan. The scan shows the versions.
matt.fellows
2023-06-14 06:40
I?m not sure what you want us to tell you then? My guess is there is two parts of the UI that use jquery and perhaps use both (there is a HAL browser which might rely on a different jquery version).
ran.tao
2023-06-14 06:42
We are bank and are very restricted on what we will introduce and install. So for every software, we need to certify all the dependencies/embeded software with exact version.
matt.fellows
2023-06-14 06:45
I?m not sure how more transparent we can be Ran - our source code is literally on the Internet
ran.tao
2023-06-14 06:46
```It will satisfy our security if you could provide an email confirming that jquery-3.6.0.min.js and jquery-3.5.1.js are the official versions in pact-broker 2.106.0```
matt.fellows
2023-06-14 06:47
Who would send them the email Ran? It?s a community maintained project by a collective set of volunteers. Tell your security team to do their job, and look at the source code.
matt.fellows
2023-06-14 06:48
If you need a supported version of the software, that?s what PactFlow is for. And then you can get your security people to ask SmartBear to do a security review and ask about dependencies etc.
matt.fellows
2023-06-14 06:48
sorry to be curt, but do you (your security team, that is) ask other open source library maintainers to confirm in writing versions of libraries they use? Why is this any different?
matt.fellows
2023-06-14 07:30
If it helps:
```? docker run -it --rm --entrypoint /bin/sh pactfoundation/pact-broker
~ $ find . -name "*jquery*"
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/vendor/hal-browser/vendor/js/jquery-3.6.0.min.js
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/stylesheets/jquery-confirm.min.css
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/javascripts/jquery-3.5.1.js
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/javascripts/jquery.tablesorter.js
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/javascripts/jquery-confirm.min.js
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/javascripts/jquery-3.5.1.min.map
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/javascripts/jquery-3.5.1.min.js
./vendor/bundle/ruby/2.7.0/gems/pact_broker-2.102.2/public/javascripts/jquery.tablesorter.min.js```
tjones
2023-06-14 07:32
As a non-pactflow person, it sounds like you want pactflow if you need specific enterprise requirements around security etc
yousafn
2023-06-14 09:26
we don?t provide proof other than the source code, we don?t need to anyway, you are using an open source project without warranty
that isn?t the latest version of the pact broker
you can see the full source code and build it yourself online.
yousafn
2023-06-14 09:26
your security team can check the source code and confirm, we are not going to
yousafn
2023-06-14 09:27
you haven?t provided us a copy of the scan, therefore i don?t know what you are looking at
yousafn
2023-06-14 09:47
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1686713561489269?thread_ts=1686693555.299459&channel=C9VPNUJR2&message_ts=1686713561.489269
if you go to the release page you can see a tag, from the tag you see a commit associated with it, which is the point in time of the codebase at the point on release. obviously you could just look in the distributed gem or image which would give you definitive proof of what in installed
rabrosimov
2023-06-14 10:31
Hi everyone. I created a hook for "*Contract published that requires verification*" event but when I publish a new version of contract which hast status ('Unverified')
that hook doesn't work out. It triggers only for another event "*Contract published*". Why it doesn't work for "*Contract published that requires verification*"?
thanks
yousafn
2023-06-14 10:33
Have you followed the pre-reqs?
https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event
> Use of this webhook requires that:
> ? the provider's https://docs.pact.io/pact_broker/branches#pacticipant-main-branch-property is configured
> ? verification results are https://docs.pact.io/pact_broker/branches#configuring-the-branch-when-publishing-verification-results or you are https://docs.pact.io/pact_broker/branches#automatic-branch-creation-from-first-tag (even if you use trunk based development, and only ever use one branch)
> ? the exact commit of a provider version can be determined from the version number used to publish the verification results (ie. it either _is_ the commit, or _contains_ the commit as per the Pact Broker https://docs.pact.io/getting_started/versioning_in_the_pact_broker#guidelines)
> ? any deployments and releases are recorded using the `record-deployment`https://docs.pact.io/pact_broker/recording_deployments_and_releases`record-release`https://docs.pact.io/pact_broker/recording_deployments_and_releases.
>
yousafn
2023-06-14 10:34
if the contents are the same as a previously verified contract, it will automagically be verified by the Pact Broker. providing some more context will help us out :slightly_smiling_face: and therefore you wont get a `contract_requiring_verification_published` event
adra_verma
2023-06-14 10:54
I just wanted to know where I should find pactflow broker docker image over http://pactflow.io . How should I get latest docker image and download for projrct .
adra_verma
2023-06-14 11:24
where should I run this command "docker pull pactfoundation/pact-broker" in my machine . CMD i tired not working
adra_verma
2023-06-14 11:26
We have to give pactflow docker image to devops to integrate in pipeline so please guide what steps needed from starting .
abubics
2023-06-14 11:27
I haven't used Pactflow, so I couldn't tell you from experience :slightly_smiling_face: I'd ask in the #pactflow channel, though.
2023-06-14 11:27
Please see this page for some tips on how to ask for help to get the best response from the community https://docs.pact.io/help/how_to_ask_for_help
abubics
2023-06-14 11:28
I'd say your devops team should also be able to help with docker, if that's a thing they're asking you for :innocent:
rabrosimov
2023-06-14 12:04
Now it's working and triggers 2 webhooks at once. It didn't work because I hadn't any providers verification from `Main` branch (master) and had not `record-deployment`
thanks.
Also I thought main branch value set up by default but when I executed:
```pact-broker describe-pacticipant --name Foo```
it was empty
yousafn
2023-06-14 14:35
With all due respect @adra_verma it doesn?t sound like you are the best person to provide the image for your DevOps team, especially with consideration to the fact that you do not have Docker on your machine, and one would assume very limited knowledge of Docker
I would suggest you provide the devops team the link to the on-prem documentation
https://docs.pactflow.io/docs/on-premises
matt.fellows
2023-06-16 07:59
If the triggers is the same event, the two triggers will probably differ on the branch/version of the provider to verify (so check the payload).
simondemartini
2023-06-16 22:02
Is pact-broker generally considered safe to run with multiple replicas behind a load balancer? Or should we only ever run one instance at a time?
yonatany
2023-06-18 08:02
Good morning, I'm wondering what is the best practice for
1. multiple consumers for a single producer
2. numerous producers for a single consumer
I assume for section 2 I will create multiple contracts that all of them will be approved by the consumer but what we do about section 1
tjones
2023-06-18 09:16
> I assume for section 2 I will create multiple contracts that all of them will be approved by the consumer
You mean for 1, you have multiple consumer contracts each of them verified by a single provider, right?
For 2, you would have the consumer have a contract with each provider, which is then verified by each provider
yonatany
2023-06-18 12:35
1. Multiple services that publish an event that will verify the same contract - ?
2. Multiple contracts will be verified by the single publisher(pub-sub) - i.e. will need to iterate it for all contracts?
tjones
2023-06-18 14:18
1) Yes, the publishing services verify the contract of the consumer
2) Yes. Although, I think you usually don?t have to actually do the iteration, because the verifier does it for you. It might depend on the language you?re using
matt.fellows
2023-06-19 12:30
If you?re referring to app servers, it?s designed for horizonal scaling behind a LB. go nuts
2023-06-25 12:00
This message was deleted.
matt.fellows
2023-06-25 12:39
Hello! Have you read https://docs.pact.io/pact_nirvana? I'd start there, it should answer most of your questions.
There is also a great CI/CD workshop (howtolearn)
2023-06-25 12:39
Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops
sreenivas.chaitanya
2023-06-26 10:10
Hi All , iam trying to change the pact broker url to our central broker and getting an error. can some one pls tell me the steps to update broker port
sreenivas.chaitanya
2023-06-26 10:26
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://meufavcpy3.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://meufavcpy3.execute-api.eu-west-2.amazonaws.com" port 80)
tjones
2023-06-26 10:26
Also, what have you tried. I searched on google for ?pact broker port number? and the https://docs.pact.io/pact_broker/docker_images/pactfoundation#:~:text=PACT_BROKER_PORT%20%2D%20the%20port%20that%20the,Defaults%20to%209292 has all the information you need to set the port.
tjones
2023-06-26 10:28
If you?re trying to set the port number in the client, just put it in the URL like you would normally `http://meufavcpy3.execute-api.eu-west-2.amazonaws.com:<YOUR PORT NUMBER HERE>`
tjones
2023-06-26 10:29
If you?re trying to set it on the broker, then the instructions I linked will help you
tjones
2023-06-26 10:29
If you?ve done both of those things, then I suspect something between the API gateway and whatever you?re hosting it on
tjones
2023-06-26 10:30
Certainly, here is a link to three messages above where I linked you to the page I found by putting your question into google:
https://pact-foundation.slack.com/archives/C9VPNUJR2/p1687775188685999?thread_ts=1687774207.445439&cid=C9VPNUJR2
sreenivas.chaitanya
2023-06-26 10:53
how do I modify this bit pactUrls: [path.resolve(process.cwd(), "pacts", "MyJSMessageConsumer-MyJSMessageProvider.json")], to publish to central url path?
matt.fellows
2023-06-26 10:55
Take a look at the docs here: https://github.com/pact-foundation/pact-js/blob/master/docs/provider.md#http-provider-package
matt.fellows
2023-06-26 10:56
`pactUrls` is really for specifying pacts at a well known URL (which is usually reserved for verifying a specific pact identified in a webhook)
matt.fellows
2023-06-26 10:56
> ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://meufavcpy3.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for ?http://meufavcpy3.execute-api.eu-west-2.amazonaws.com? port 80)
this error is worth investigating with somebody that understands your AWS setup. Clearly, you are unable to connect to that host on port `80` from your source machine
sreenivas.chaitanya
2023-06-26 10:59
npm run test:publish when I run this with my central broker it just hangs and nothing happens
matt.fellows
2023-06-26 11:00
Publishing pacts is an entirely different thing from what you?ve been asking about, so I think you might be a little confused.
Could you please start again with the use case you are trying.
See howtoask / howtorepro to help.
sreenivas.chaitanya
2023-06-26 11:02
I Can run consumer and provider with the example provided by pacts , now iam trying to publish pacts to a central broker instead of ;local folder
matt.fellows
2023-06-26 11:03
FYI I?d recommend you use the CLI for publishing pacts: https://docs.pact.io/implementation_guides/cli#pact-broker-cli
matt.fellows
2023-06-26 11:03
What arguments are you suppling the publish command? What does the command look like? Are you doing it from JS or using the CLI?
Without further info, it?s very hard for us to help you.
sreenivas.chaitanya
2023-06-26 11:04
"test:publish": "pact-broker publish ./pacts --consumer-app-version=\"$(npx absolute-version)\" --auto-detect-version-properties --broker-base-url=https://test.pactflow.io --broker-username dXfltyFMgNOFZAxr8io9wJ37iUpY42M --broker-password O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1",
sreenivas.chaitanya
2023-06-26 11:04
broker url is replaced by central broker , with user and password
rabrosimov
2023-06-26 11:10
Hi there! I?m trying to use feature stubs (https://docs.pactflow.io/docs/stubs/#finding-the-url-to-a-pact-resource)
But when I send request to https://test.pactflow.io/pacts/provider/pactflow-example-provider/consumer/pactflow-example-consumer/latest/stub/user/1 (not exactly this one but similar)
I?m getting an error `{*"*errors*"*=>[{*"*message*"*=>*"*401 Unauthorized. Please see https://docs.pactflow.io/docs/login-help for more information.*\n"*}]}>`
The question is which Auth field in headers do I need to specify? How to combine it using my token?
matt.fellows
2023-06-26 11:17
FYI just note this is a #pactflow question (hosted stubs are not on the open source Pact Broker)
matt.fellows
2023-06-26 11:18
I believe the authorization you need to provide is the PactFlow bearer token
matt.fellows
2023-06-26 11:18
oh, in that case, it?s the basic auth user/password (if you?re using http://test.pactflow.io)
rabrosimov
2023-06-26 11:27
So we have bunch of VCR cassettes (https://github.com/vcr/vcr)
which we're trying to substitute with Pact stubs
matt.fellows
2023-06-26 11:29
Authorization is a tricky one, we currently don?t support it well on stubs (because the auth to PactFlow trumps it). It should be straightforward enough to support, either by:
1. Removing auth for stubs (not ideal, but perhaps it could be made configurable)
2. Allowing a separate auth header to PactFlow for the use case (it does mean your API client would need to add it though)
3. Or some other means
Thoughts?
rabrosimov
2023-06-26 11:32
ok. Before you mentioned that I need to add header:
"Authorization: Basic xxxx"
xxxx- as I understand it's an encoded base64 combination of `email:password` ?
matt.fellows
2023-06-26 11:38
This header should do it
```Authorization: Basic ZFhmbHR5Rk1nTk9GWkF4cjhpbzl3SjM3aVVwWTQyTTpPNUFJWld4ZWxXYkx2cU1kOFBrQVZ5Y0JKaDJQc3lnMQ==```
matt.fellows
2023-06-26 11:39
It?s the basic auth credentials you would have needed to get to http://test.pactflow.io
matt.fellows
2023-06-26 11:39
_(they are safe to share, they?re in many places on the internet for that test account)_
sreenivas.chaitanya
2023-06-26 11:42
it works with the test.pactflow , but I want to publish pacts to my url
rabrosimov
2023-06-26 11:46
nice but I have my own broker and own stub url 'https://teladochealth.pactflow.io/pacts/provider/tas/consumer/health-info/latest/stub/'
I tried base64 of email:password but still getting 401
matt.fellows
2023-06-26 11:50
see my question above, can you reach your pact broker from your terminal/cli/command line?
rabrosimov
2023-06-26 11:51
still not working
I tried different combinations
```Authorization: Basic token
Authorization: Basic base64(token)
Authorization: Basic base64(email:token)
Authorization: Basic base64(email:password)```
matt.fellows
2023-06-26 11:52
right sorry, it would be `Bearer <token>` (no need to encode your API token)
matt.fellows
2023-06-26 11:52
I was confused earlier by the other broker, which whilst hosted on PactFlow, is a little hybrid PactFlow/Pact Broker (as can be seen by the old UI!)
sreenivas.chaitanya
2023-06-26 11:54
curl -u userxx:passxx https://ysi5tc076m.execute-api.eu-west-2.amazonaws.com
sreenivas.chaitanya
2023-06-26 11:55
```"test:publish": "pact-broker publish /pacts --consumer-app-version=\"$(npx absolute-version)\" --auto-detect-version-properties --broker-base-url=https://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:443 --broker-username user --broker-password passxx"```
matt.fellows
2023-06-26 11:56
Try running `npx absolute-version` directly
I think it?s probably prompting a confirmation
matt.fellows
2023-06-26 11:58
It?s possible you?ve gotten through PactFlow?s auth, but are getting a `401` from the stub (probably not, but possible)
sreenivas.chaitanya
2023-06-26 11:59
"pact-broker publish ./pacts --consumer-app-version= npx absolute-version\"
rabrosimov
2023-06-26 12:00
error body is the same `{*"*errors*"*=>[{*"*message*"*=>*"*401 Unauthorized. Please see https://docs.pactflow.io/docs/login-help for more information.*\n"*}]}`
matt.fellows
2023-06-26 12:02
actually, before you do that - try this:
```curl -H"Authorization: Bearer <token>" https://teladochealth.pactflow.io/ -v```
Obviosuly, replace your token
matt.fellows
2023-06-26 12:03
you don?t need to use that command to determine your version number, you can use any scheme you like (although it?s good and I recommend it)
matt.fellows
2023-06-26 12:03
the issue is you don?t have `npx`, so probably have an old version of node installed
matt.fellows
2023-06-26 12:07
> if I install latest node will it go away?
Maybe, probably, but your lack of key tools in this ecosystem worries me and I think you?ll be tripped up at the next basic hurdle. I really think you ought to be pairing with somebody that knows NodeJS well
matt.fellows
2023-06-26 12:07
> but how does it with test.pactflow url then?
that tool is just a tool we used to generate repeatable versions for the consumer. You can choose any versioning scheme you like, you don?t need to use that tool. The git sha is a common / simple starting point
sreenivas.chaitanya
2023-06-26 12:10
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 1 of 5
matt.fellows
2023-06-26 12:12
Either:
you have set it to `https` in the command OR there is a configuration issue in your pact broker (my guess)
matt.fellows
2023-06-26 12:14
as above, please set `--verbose` on the CLI command and share the output
matt.fellows
2023-06-26 12:15
But if not, my guess is that they haven?t implemented https://docs.pact.io/pact_broker/configuration/features#running-the-broker-behind-a-reverse-proxy
sreenivas.chaitanya
2023-06-26 14:00
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 1 of 5
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 2 of 5
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 3 of 5
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 4 of 5
ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 5 of 5
/Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/net/http.rb:906:in `rescue in block in connect': Failed to open TCP connection to http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 (Connection refused - connect(2) for "http://ysi5tc076m.execute-api.eu-west-2.amazonaws.com" port 80) (Errno::ECONNREFUSED)
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/net/http.rb:903:in `block in connect'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/timeout.rb:93:in `block in timeout'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/timeout.rb:103:in `timeout'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/net/http.rb:902:in `connect'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/net/http.rb:887:in `do_start'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/ruby/lib/ruby/2.4.0/net/http.rb:876:in `start'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:93:in `until_truthy_or_max_times'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:64:in `perform_request'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:35:in `post'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/link.rb:57:in `post'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/publish_pacts.rb:61:in `block in publish_pacts'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/rake-13.0.6/lib/rake/file_list.rb:70:in `collect'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/rake-13.0.6/lib/rake/file_list.rb:70:in `collect'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/publish_pacts.rb:60:in `publish_pacts'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/publish_pacts.rb:33:in `call'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/publish_pacts.rb:15:in `call'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/cli/pact_commands.rb:66:in `publish_pacts'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/cli/pact_commands.rb:29:in `publish'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/thor-1.2.1/lib/thor/base.rb:485:in `start'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/cli/custom_thor.rb:23:in `start'
from /Users/sguttarlapalli/IPV/di-ipv-spot/node-functions/node_modules/@pact-foundation/pact-core/standalone/darwin-1.92.0/pact/lib/app/pact-broker.rb:34:in `<main>'
npm timing command:run Completed in 21506ms
npm verb exit 1
npm timing npm Completed in 21555ms
npm verb code 1
matt.fellows
2023-06-26 22:22
Please use the `--verbose` flag on the command and share the output. The above is not it.
yonatany
2023-06-27 07:27
Good morning , im review this subject : https://docs.pact.io/pact_nirvana/step_4#consumer-pipeline .
1. How we determine if the contract has been change ?
2. Its look like we always publishing the contract - there is a best practice how to determine it ?
3. We are publishing a lot of versions of the contract - there is a way to make sure they will delete after a while as part of the publish
4. Why we have 2 times tags (if the contract was not change between the isolated test and the integrated test) .
5. The tag purpose is to find a version of fix branch like master ?
6. In case we can use our eco system don't using the webbook - the best way it fail the ci and we invoke the the verifiers ?
keep in mind im reading a lot of content from the docs :slightly_smiling_face:.
matt.fellows
2023-06-27 08:07
1. You don?t, the Pact Broker will determine that. You would usually use the https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event event to trigger a build based on changes to a contract that require a verification
matt.fellows
2023-06-27 08:07
2. It?s the best practice to always publish (not from dev, but from CI). What do you mean by ?best practice how to determine it??. What is ?it? in this case?
matt.fellows
2023-06-27 08:08
3. If you are running your own broker, you can run https://docs.pact.io/pact_broker/administration/maintenance. If you use PactFlow, we do that automatically.
matt.fellows
2023-06-27 08:10
4. I?m really sorry, the advice in this guide is still outdated because it uses tags. Really you want to use https://docs.pact.io/getting_started/conceptual_overview#branches--environments. Wherever you see the use of a tag in this guide, you can assume it?s either used to represent a ?branch? or represent a ?deployment?. If you?re just starting, you don?t want to use tags if you can avoid it.
But to answer - the reason you tag twice. The first time says ?this pact represents a branch / feature I?m working on?. The second one represents ?I?ve deployed this application to <environment>?.
matt.fellows
2023-06-27 08:11
5. Yes. We call the general concept here ?selectors?: https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors
matt.fellows
2023-06-27 08:12
6. Yes, if you don?t use the webhook you won?t get some optimisations. But it can still work without them. And yes, I would tend to fail the build if the contract tests don?t pass or `can-i-deploy` is failing (but that assumes a lot about how your pipeline is setup, and that is a dangerous assumption!)
yonatany
2023-06-27 08:35
@matt.fellows
1&2. I will review it - but in a brief my question was if there is a way to determine if contract was change without publish it to reduce the publish actions - to compare generated contract with latest master branch.
3.I will review it :slightly_smiling_face:
http://4.Im using branches + versions(the last commit sha as version) - but my question how to "merge" - make a contract as master ? (or its literally like any other pr - it will run the ci )
5.Got it.
6.Ok
matt.fellows
2023-06-27 11:22
1. May I ask why you need it? There are APIs in Pact Broker, and obviously you have source control if needed
matt.fellows
2023-06-27 11:23
> http://4.Im using branches + versions(the last commit sha as version) - but my question how to ?merge? - make a contract as master ? (or its literally like any other pr - it will run the ci )
Exactly. When you merge the PR, you?ll run another build and when you publish it with the `--branch` option, it will effectively ?merge? this over the previous one (not technically, accurate, but I think you get the concept)
sreenivas.chaitanya
2023-06-27 14:16
```"test:publish": "pact-broker publish ./pacts --consumer-app-version=1.0.1 --auto-detect-version-properties --broker-base-url=https://ysi5tc076m.execute-api.eu-west-2.amazonaws.com:80 --broker-username user --broker-password pass --verbose"```
matt.fellows
2023-06-27 22:15
As per https://pact-foundation.slack.com/archives/C9VBGLUM9/p1687904121569379?thread_ts=1687793030.363559&cid=C9VBGLUM9 please update your pact broker installation
sreenivas.chaitanya
2023-06-28 11:32
@matt.fellows it was an issue with our broker setup its returning a http instead of https . I have let them know the issue . Mean while is there a work around for me till this issue is fixed
tjones
2023-06-28 12:01
I don?t think we have a workaround for an infrastructure issue on your side, no
boer.k
2023-06-28 13:28
Hi, I am fiddling with the Pactflow broker at the moment. We have upload some dummy version of our example consumer and provider. When I look at the matrix now, I can see that consumer version 0.0.2 is not compatible with provider version 0.0.1. However, I can imagine that this information will eventually become useless, and it will only clog up the matrix. However, I have not found a way to delete this record, or set some kind of retention period. Is there no way to delete this?
matt.fellows
2023-06-28 23:28
In any case, these are dummy projects, you can navigate to the integration and delete it as needed (see screenshot for a different application).
matt.fellows
2023-06-28 23:28
As for retention, there is built in data retention, but that only removes outdated pact files based on certain rules - these are unlikely to get swept away quickly because they are the latest.
See https://docs.pact.io/pact_broker/administration/maintenance#automatic-data-clean-up for a bit of background on how retention works, if you?re interested (in the case of PactFlow, this is automated and not something you can configure)
tjones
2023-06-29 03:15
Is it correct that the broker deploy check operates on a {contract, provider version} pair?
tjones
2023-06-29 03:16
(I'm trying to work out if I could implement deploy checks that work differently in cases like missing providers without changes to the broker)
boer.k
2023-06-29 08:57
Ah, I've joined the #pactflow channel now. Because they are indeed dummy projects, we delete all integrations all the time. But were starting to think ahead about how this would look like in a real scenario, and in that case we imagined that this could clog up really quickly. Where only the latest few version may be relevant, and all 100 versions before it have become irrelevant, but still clutter the matrix. There are filters, but preferably you shouldn't be dependant on them
rana
2023-06-29 10:10
Hi guys,
Where can I find more information about `create-or-update-version`? I've read this https://docs.pact.io/pact_broker/client_cli/readme#create-or-update-version but I'm not sure what are the implications of using it. Does this override the version of the contract that has been recorded?
Is this something I should avoid using?
matt.fellows
2023-06-29 10:47
Mind elaborating on this? I think it could mean a few things.
for example, are you asking if you can check if a consumer is safe to deploy even if the Broker hasn?t seen a provider yet?
tjones
2023-06-29 10:54
Currently, I believe the broker assumes a provider is required for a consumer to deploy - but that?s not always true. Long term, I think broker changes will be needed to support that, but I?m looking into what is possible with virtual providers etc
matt.fellows
2023-06-29 10:56
I think it would just overwrite the branch, or set a tag with a given version. What are you trying to do?
I can?t update the contract, as you don?t supply one for a version
matt.fellows
2023-06-29 10:56
By default, the broker will prevent you clobbering an existing contract (you would need to update a configuration to allow it)
tjones
2023-06-29 10:57
Well, not avoid, in as much as, I?m curious what the broker _already supports with no changes_
tjones
2023-06-29 10:57
like, I?m not trying to avoid looking at ruby, I?m trying to avoid making unnecessary software changes
tjones
2023-06-29 11:02
I think there are some possibilities based on the existing model of broker pacticipants - for example, in https://case.contract-testing.io/docs/intro, the the _definer_ of the contract will be the consumer in the Pact broker (because you define what you consume), but that?s not the same as the consumer in Pact (which is kind of a synonym for client sometimes). This still works, even though it?s not what the broker was expecting.
I?m asking if it?s the case that the broker decides compatibility only on {contract ,provider_version}, to look in to alternate uses and coercions of the model
matt.fellows
2023-06-29 11:03
I think it is more complicated than that, but in general it is very much aware of the different _roles_ and the roles have the assumptions you listed above (i.e. a consumer / provider is not as general as your model)
tjones
2023-06-29 11:03
I think it is `{contract, provider_version} -> deployability status (true | false)`, and that consumer version is a pointer to contract. Is that right?
matt.fellows
2023-06-29 11:05
In PactFlow (and I don?t know if any parts / remnants of this exist in the OSS version) there is a concept of a provider contract, and that may also be bastardised for your use case. But I think you want to optimise for what?s in OSS for now
tjones
2023-06-29 11:11
So, I have:
? Contract definer, which defines what it consumes (could be an http response, like pact - but you can also consume http requests)
? Contract verifier, which verifies that the expectations of a contract are produced (could be an http response, like pact,- but you can also verify that you produce http requests).
ContractCase doesn?t need to support a separate concept for ?provider driven?, because you can write a contract at either end. You could even do contracts at both ends at the same time, which I haven?t thought about to know if it?s a good idea, except to realise that it definitely should be called Case Closed.
tjones
2023-06-29 11:26
As I understand it, you don?t need this command unless you are doing something very custom
matt.fellows
2023-06-29 11:28
The only use case we would usually recommend it is this one: https://docs.pact.io/pact_nirvana/notes_1
tjones
2023-06-29 11:31
(you can even mix http clients and http server contracts in the same contract file. It?s pretty cool)
rana
2023-06-29 12:19
Yup, that is the use case. Global CICD pipeline and to avoid failures when there are no pacts to verify.
Thanks for the response.
rana
2023-07-02 15:53
Hi again guys,
What am I missing here?
I have recorded a deployment of a provider -
`Recorded deployment of core-api version bb6600cd to production environment in the Pact Broker.`
I have have pushed the pact between `caller-identities` consumer and this provider
`Pact successfully published for caller-identities version 8dc3a26e and provider core-api.`
Which triggered a verification - which passed.
I can see in the pact-broker that the pacts were verified (attached image)
And yet `can-i-deploy` returns false -
`There is no verified pact between version 8dc3a26e of caller-identities and the version of core-api currently in production (bb6600cd)`
Any help will be appreciated
matt.fellows
2023-07-02 22:14
The provider version in the screenshot (the one that has verified the pact) is `bb6600c` but you recorded deployment of version `bb6600cd` - is that a typo or the mistake?
rana
2023-07-03 05:29
It's not a typo, it just doesn't show the full version. I am using Gitlab's `CI_COMMIT_SHORT_SHA` as version.
matt.fellows
2023-07-03 05:39
So is the issue the same, except rather than the SHA being shorter, it?s much longer? Are you using the same sha to tag the provider on verification results _and_ can-i-deploy?
matt.fellows
2023-07-03 05:39
i.e. the long version is what the broker has, but you?re deploying the short version `bb6600cd`. the broker can?t distinguish between short hands and the real thing - it must match exactly.
matt.fellows
2023-07-03 05:41
Probably worth just consistently using the long version of the sha. It?s not exactly human readable anyway.
If you want a nice tool to generate consistent versions, try out https://www.npmjs.com/package/absolute-version
rana
2023-07-03 05:41
I am not passing anything manually, I am using the same Gitlab `${CI_COMMIT_SHORT_SHA}`
sushant.soni
2023-07-07 14:53
Hello,
All of a sudden we are getting this error while deploying pact-broker. Do you know of any known issues?
Because we are able to connect to the database using a psql client directly from a pod in the same namespace.
```! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: could not translate host name "http://xxxxx.rds.amazonaws.com" to address: Name does not resolve
bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.7.0/bin/puma)```
sushant.soni
2023-07-10 08:41
Resolved!
There was an issue with the local-dns setup in the k8s cluster. Nothing related to pact.
matt.fellows
2023-07-10 08:54
Thanks for confirming back here! (and sorry we missed it, right before the weekend :wink: )
prakhar.roy371
2023-07-11 11:45
Hi,
I am trying to add the can-i-deploy job on my gitlab yml file.
This is what I have done so far. (Please see screenshots below)
My question :
1. What value is expected in *image:* ( I am pointing to the external pactbroker : http://royprakhar.pactflow.io )
2. What to put in Participant, to args in the pact broker command?
yousafn
2023-07-11 11:49
you need to install the pact cli tools, it says it can?t find the `pact-broker` executable
yousafn
2023-07-11 11:54
btw you don?t install these tools in the pact-broker or pactflow image, you install them on your client machine (either your CI runner, or your local machine)
prakhar.roy371
2023-07-11 12:01
In my organization, we have some devops shared jobs (as shown in the image above)
```image: http://harbor.___.com/devops-images/docker-devops:20-ce_edge```
Are you saying that I would need to work with them and get a new image having the pact cli tools baked in them?
yousafn
2023-07-11 12:24
that is one approach, you could install the tools before running your pact-broker step, or use the pact-cli image.
if your normal approach is to bake the tools into your images, then that is a completely satisfactory approach
rabrosimov
2023-07-11 15:53
Hi there!
I have a question related to `can-i-deploy` feature. The background is that Pact broker webhook intercepts event like "Contract published that requires verification" and send 2 requests
To verify single contract against providers:
? (deployed in production) build
? (latest version from main branch) build
Using can-i-deploy tool I can get results of verification for (deployed in production) build like:
```pact-broker can-i-deploy \
--pacticipant consumer \
--version ${GIT_COMMIT} \
--to-environment production```
The question is how to get results of verification for (latest version from main branch) build using can-i-deploy?
I'm trying this command but it doesn't work:
P.S. I'm using branches not tags.
`pact-broker can-i-deploy \`
> --pacticipant consumer --version ${GIT_COMMIT} \
> --pacticipant provider --latest master \
> --broker-base-url https://mytest.pactflow.io \
Computer says no ¯\_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
-----------|------------|----------|-----------|----------|--------
consumer | 13d20aa... | provider | ??? | ??? |
`No version with tag master exists for provider`
yousafn
2023-07-11 16:16
```pact-broker can-i-deploy \
--pacticipant consumer \
--version ${GIT_COMMIT} \
--to-environment production```
this is correct for your consumer.
It publishes verification results against the providers main branch, but that isn?t relevant when deploying to consumers code, as it cares about what is in the deployed env. the triggered provider verification would check that the providers latest from main is still compatible, and if it isn?t it would stop the providers codebase from being deployed
For your provider you would use can i deploy with the git commit for the version to deploy on your main branch.
```pact-broker can-i-deploy \
--pacticipant provider \
--version ${GIT_COMMIT} \
--to-environment production```
rabrosimov
2023-07-11 16:29
@yousafn thanks! you're right but I plan to use that in my feature branch and not before deploying to production. Just to understand that latest provider main branch fulfil that contract.
How I can get results of verification of contract from feature branch against (latest version from main branch) build using can-i-deploy ?
rabrosimov
2023-07-11 16:32
And follow up question: Is there a way to remove record after executing "pact-broker record-deployment"? Like to make it empty
yousafn
2023-07-11 16:38
you can record releases and unrelease them. a deployment will mark all others as undeployed
rabrosimov
2023-07-11 17:32
btw I've found how to do it:
```pact-broker can-i-deploy
--pacticipant consumer --version HASH \
--pacticipant provider --branch main ```
this will compare particular contract with the "latest version from main branch"
marko.lamberg
2023-07-12 10:04
Hey guys,
a question about best practices of record-deployment and can-i-deploy.
We are using record-deployment, but we have up to dozen merges (pact published) to integrated environment and maybe one to prod.
When our consumer is using can-i-deploy they can't get the both environments from one version.
I was looking to use record-release for integrated environment and record-deployment for the prod. This would otherwise work but record-deployment is tagged as `environment` and record-release is tagged as `release environment`.
Would this work for can-i-deploy without changes, or do they have to do any modifications for their can-i-deploy call?
prakhar.roy371
2023-07-12 12:01
Hi all,
I am trying to configure the can-i-deploy job in my gitlab project.
I wanted to know about what I need to put for the following args:
1. _"pacticipant" (_<Placeholder-1>)
2. _"version" (_<Placeholder-2>)
3. _"to" (_<Placeholder-3>)
Here is my gitlab script.
```pact-can-i-deploy:
image: pactfoundation/pact-cli:latest
stage: pact-can-i-deploy
tags: [linux-dind]
dependencies:
- pact-publish
script:
- "pact-broker can-i-deploy
--pacticipant <Placeholder-1>
--version <Placeholder-2>
--to <Placeholder-3>
--broker-base-url $PACT_BROKER_BASE_URL
--broker-token $PACT_BROKER_API_TOKEN"```
I have gone through the previous chats present on slack for this, but no luck, so posting here.
Here is how my matrix is looking like:
matt.fellows
2023-07-12 12:18
version = the version of the application you are going to deploy (e.g. 1.0.0 in your table)
2023-07-12 12:18
See this page on the steps to creating an effective contract-testing setup https://docs.pact.io/pact_nirvana. (This workshop demonstrates those principles in action: https://docs.pactflow.io/docs/workshops/ci-cd/)
simondemartini
2023-07-12 19:42
Do the https://docs.pact.io/pact_broker/administration/maintenance#configuring-the-keep-selectors support the native environments deployments/releases?
prakhar.roy371
2023-07-13 10:41
Hey @matt.fellows
Thanks for the above resources for cicd implementation.
I configured the pipeline for can-i-deploy job. For pacticipant, I added the following - *CNE Producer* (See can-i-deploy script screenshot)
But I am getting error saying : *Error making request to https://<ourname>.http://pactflow.io/matrix status=400 {"errors":["Pacticipant Producer not found"]}*
(see screenshot below)
Here the weird thing is its saying Pacticipant *Producer* instead of *CNE Producer*.
Does this have something to do with the name?
matt.fellows
2023-07-13 10:46
When you pass arguments to commands in a shell, you must escape things that have spaces in them, otherwise they are considered additional arguments
prakhar.roy371
2023-07-13 13:54
@matt.fellows For Can-I-Deploy. My understanding is that *if the pact is in :*
*Verified state*, Can-I-Deploy says YES
*Unverified state*, Can-I-Deploy says NO
*Failed state*, Can-I-Deploy says NO
Is this correct statement? I am seeing some results different from my understanding of this job, so wanted to know.
matt.fellows
2023-07-13 22:38
It?s not as simple as that, but in general ?yes?. It entirely depends on the parameters being sent to `can-i-deploy` . It may be verified, but if one of the applications needed is not deployed to a target environment (and you us the `--to-environment` flag) than it will fail.
prakhar.roy371
2023-07-14 05:12
My matrix is looking like this. (See ss below)
But when I run my pact-can-i-deploy script (Script ss below)
It tells me Yes for deploy. My understanding is that it should say No.
Can you please help me understand what I may be doing wrong in this?
==================================
Also, How can I use Pact Cli locally to get outputs to commands like
$ pact-broker can-i-deploy --pacticipant PACTICIPANT --version VERSION --to-environment ENVIRONMENT
matt.fellows
2023-07-14 07:47
To run it locally, you can run the same commands as you're running on CI. You can use the docker image or CLI
prakhar.roy371
2023-07-14 11:55
Hey Matt, we are using branches here only.
We don't have any environments setup for this project yet as we are in initiation phase.
I still don't understand why my can-i-deploy works when the pact is in unverified state
kedar.ghate
2023-07-14 12:01
Hi team,
I am facing issue while connecting to pactflow URL - https://vfuk-digital.pactflow.io
When I run can-i-deploy command in bash using hardcoded/plaintext token value, it working properly. Using plain text value is bad practice. When I use variable for token value as
--broker-token=$authToken, it throws 403 error. I am using correct token value in "authToken" variable.
Please assist.
yousafn
2023-07-14 12:32
That would only really suggest your aren?t passing the token in properly, if you are using docker, you need to pass in the env var to the container aswell
or the token is incorrectly being referenced in your scripts. which cli tooling are you using?
tien.xuan.vo
2023-07-17 09:05
Hi team,
I have 4 services, and a few contracts among them (diagram in attachment)
Now I am going to deploy them to the first environment: staging.
The first service I tried is `admin` . When I run Github actions's `can-i-deploy` tool I got:
```Computer says no ¯\_(?)_/¯
CONSUMER | C.VERSION | PROVIDER | P.VERSION | SUCCESS? | RESULT#
---------|------------|--------------|-----------|----------|--------
admin | 955fd80... | fund | ??? | ??? |
admin | 955fd80... | relationship | ??? | ??? |
admin | 955fd80... | user | ??? | ??? |
There is no verified pact between version 955fd80d59646bbb7adaff4b2c19ed3e90aa1b36 of admin and a version of fund currently in staging (no version is currently recorded as deployed/released in this environment)
There is no verified pact between version 955fd80d59646bbb7adaff4b2c19ed3e90aa1b36 of admin and a version of relationship currently in staging (no version is currently recorded as deployed/released in this environment)
There is no verified pact between version 955fd80d59646bbb7adaff4b2c19ed3e90aa1b36 of admin and a version of user currently in staging (no version is currently recorded as deployed/released in this environment)```
and I have no question about it.
Then I tried `fund` . Here is the result:
```Computer says no ¯\_(?)_/¯
No pacts or verifications have been published for version 78d67b96544fd831c62715c78c11f20597afef77 of fund```
I think I got the `chicken & egg` problem exactly like https://github.com/pact-foundation/pact_broker-client/issues/25#issue-287038484
I saw that Beth mentioned it was fixed in https://github.com/pact-foundation/pact_broker-client/issues/25#issuecomment-519790354, but I still got this issue.
? Pact Broker version: PactFlow 6bd3f8b41
? Pact Specification version: 4.0
? FFI library: 0.4.x
So my question is: is the fix is just for `tag` (deprecated) and not for the combination of `branch + environment` ?
tien.xuan.vo
2023-07-17 09:11
I also create a "custom" github action to work around like this https://github.com/tienvx/can-i-deploy/blob/main/canideployTo.sh#L17
But is it a correct solution?
matt.fellows
2023-07-17 11:04
If you provider has no consumers, it should be safe to deploy (you just need the above)
matt.fellows
2023-07-17 11:04
the opposite is not true, you can?t deploy a consumer for which its provider is not also deployed (and satisfies the contract of the to-be-deployed consumer)
tien.xuan.vo
2023-07-17 15:52
Even though I do not fully understand, it (the `create-or-update-version` command) work great for me.
I saw the official Github's https://github.com/pactflow/actions didn't have that command, so I created it here
https://github.com/tienvx/create-or-update-version
matt.fellows
2023-07-17 22:51
The broker is saying ?I have never seen $version before, so I don?t know what to do with it?
matt.fellows
2023-07-17 22:52
basically, the error is a `404` . The version you are trying to release doesn?t exist, so it can?t tell you what to do with it. By creating a version, the broker knows what you?re asking - that application (and version) has no dependencies, and so it?s safe to release
matt.fellows
2023-07-17 22:53
think of it as a sanity check - imagine if you accidentally spelled the provider name wrong, what might go wrong
alejandro.pena
2023-07-18 14:36
Good morning all!
Does the local API stubs have the same limitations as the stubs provided by PactFlow? (The ignore to matching rules from PactV3 onwards)
https://docs.pact.io/getting_started/stubs
https://docs.pactflow.io/docs/stubs/
yousafn
2023-07-18 14:44
Hey Alex!
So this page https://docs.pact.io/getting_started/stubs references two implementations, the ruby and rust version, which have different levels of spec support (v2 and below for Ruby, v4 and below for the rust based )
? https://docs.pact.io/getting_started/stubs#docker
? this mentions this docker image https://hub.docker.com/r/pactfoundation/pact-stub-server
? which comes from this repo https://github.com/pact-foundation/pact-stub-server
?? this is Rust based and as such supports V4 pact-specs and below and should honour your matching rules
? https://docs.pact.io/getting_started/stubs#cli-tools
? this references the ruby cli tools here https://github.com/pact-foundation/pact-ruby-standalone/releases
? these support up to v2 pact-spec, and I believe subject to the same caveats here
?? https://docs.pactflow.io/docs/stubs/#supported-pact-specification-versions
? I believe of the ruby tools in PactFlow, it uses the pact-stub-service https://github.com/pact-foundation/pact-mock_service#stub-service-usage but I stand to be corrected
alejandro.pena
2023-07-18 14:46
Thanks a lot @yousafn!
That's what I call a clear response :slightly_smiling_face:
gurubabu.jampala
2023-07-19 01:13
Hi All, need one quick help. We are trying out all the different options in pact broker. As part of it when we are looking into events we found one publish event called "*contract_requiring_verification_published".*
As per the documentation this event should get triggered when we publish the contract to pact broker. But we could see only two events detected *contract_published and contract_content_changed*.
Appreciate if someone help me why I couldn't see *contract_requiring_verification_published* event detected when publishing contract*?*
*More explanation:* https://stackoverflow.com/questions/76684663/contract-requiring-verification-published-event-not-getting-detected-pact-co
@matt.fellows sorry to bother you, could you please help me on this?
matt.fellows
2023-07-19 01:48
Have you read https://docs.pact.io/pact_broker/webhooks#the-contract-requiring-verification-published-event?
BTW no need to tag people, we monitor the channels and will respond if/when we are able to
matt.fellows
2023-07-19 01:59
TL;DR - for that webhook to fire, it needs to know what version of the provider to target. It uses the main branch property of the provider and any deployed versions of the app.
If you aren?t recording deployments/releases, or using branches, this could be why it?s not firing
gurubabu.jampala
2023-07-21 07:56
Hello All,
I got the usage of *https://stackoverflow.com/questions/76684663/contract-requiring-verification-published-event-not-getting-detected-pact-co* but there are few confusions regarding branches, deployments and releases. Would be very helpful if anyone know workshop available and share the link here.
Thank you!
adra_verma
2023-07-21 08:33
I have created awesome team but can't able to see in dashboard team dropdown .
alan.barker
2023-07-21 10:01
Hi.
I have a few questions about the open source version of Pact Broker (and Postgres DB), that I hope someone can help with.
1. Are there any limits in the open source Pact Broker, regarding how many pacticipants you can have?
2. In terms of the Pact Broker docker image, once running, how many requests can it deal with, potentially?
3. Do you have any recommended system requirements for the open source Pact Broker and Postgres DB? I have found information relating to PactFlow, but nothing for open source Pact Broker.
4. How big could the Postgres DB potentially grow to? What is a recommended size?
I think thats it for now. :smile:
Thanks, Alan
yousafn
2023-07-21 10:53
Hey up!
I think alot of these are going to be depends, as the Pact Broker is highly configurable, and would depend on your use cases
1. There isn?t a physical limit in the code
2. It would be advised you run your own load test, based on your use case, on your infrastructure. The PactFlow created a load test which you can use the same principles and modify the code slightly for your own Pact Broker https://docs.pactflow.io/docs/on-premises/installation/load-testing/
3. I can?t see anything from a cursory glance, that may be an active choice by the developers not to include, due to the multiple options for deployment, but I would go with those values from PactFlow and you may be able to dial them back a little bit but staying in those ranges is probably good (and well tried and tested from the PactFlow team)
4. 25GB is recommended, going by https://docs.pactflow.io/docs/on-premises/system-requirements based on the same premise as 3
In production, you would typically run with a proxy such as nginx and load balancer, so its useful to take those into consideration
I?ve in the past at client sites ran the broker via AWS CF templates using ECS with a Postgres RDS instance, very similar to this diagram
https://docs.pactflow.io/docs/on-premises#example-aws-deployment-using-ecs
alan.barker
2023-07-21 10:55
Thank you @yousafn that's really useful information. Thanks for your help.
yousafn
2023-07-21 10:59
np, it may be worth raising an issue if you don?t mind against perhaps the https://github.com/pact-foundation/pact_brokeror https://github.com/pact-foundation/pact-broker-docker repo, asking the same question, potentially asking the community or any readers what their configuration setup is with a view to updating the documentation somewhere to specify at least some cursory recommendations.
The reason I?m not sure of the repo, is that we have the pact broker app, 2 repos which contain a docker image of it, and a kubernetes chart repo https://github.com/pact-foundation/pact_broker so it probably wants some thought as to where the best place is to show the information to the user and then link to it from any relevant places.
yousafn
2023-07-21 11:00
however don?t feel obliged, I can always do that, you may have enough to rock on with for now
yousafn
2023-07-21 11:03
Hiya @adra_verma
1. I would post that query in our #pactflow channel as that is directly related to PactFlow, not the Pact Broker for which this channel is for.
matt.fellows
2023-07-21 11:17
The perf characteristics of Pactflow are a good guide for the OSS one, so I'd start there. But as Saf said, YMMV
werner.lauterfeld
2023-07-24 14:42
Hi,
I have a question regarding the Pact Workflow without Webhooks assuming we get a new pair consumer/provider.
A consumer would implement the contract and publish it to PactFlow with a PR (branch name will not be main).
Assuming Provider would not have it implemented yet on master a PR would be opened to implement the contract of the consumer.
The PR validation pipeline on provider side however would run the verifications as documented in pact nirvana step 7 the following way:
verify pacts with [mainBranch] and [deployedOrReleased] selectors
This would fail, since there is no contract on mainBranch yet known to PactFlow and also there is no deployedOrReleased version.
So assuming the PR build would need to succeed the provider would be blocked right here?
Any heads up on how to avoid blocking each other in such a scenario?
Greetings
yousafn
2023-07-24 15:10
There are a couple of ways
if you are synching feature development you could have a selector for `matchingBranch` which would use the branch of the feature request, so that would assume the consumer raises the feature req with the same branch as which they have published the contract
you can also use work in progress pacts, which will allow pacts to be verified as part of the main branch verification
https://docs.pact.io/pact_broker/advanced_topics/wip_pacts
couple this with enablePendingPacts: true so that the failures don?t block the providers main build unneccessarily
werner.lauterfeld
2023-07-24 15:16
Thanks Yousaf - will take a deeper look at work in progress pacts. Thank you.
matt.fellows
2023-07-24 21:37
We should add that to Nirvana Yousaf. I'll add today and compare to the ci/cd guide
yousafn
2023-07-24 22:40
Thanks Matt, it?s mostly summing up Beth?s awesome words/guides. it?s now in the reworked ci/cd guide over in PactFlow which is where i started to create a real world example to then circle back and complete the nirvana guide
https://docs.pactflow.io/docs/workshops/ci-cd/workshop/protecting-the-provider
https://docs.pactflow.io/docs/workshops/ci-cd/workshop/verifying-feature-pacts
you might some of the text useful for adding into the guide.
yousafn
2023-07-24 22:44
it?s touched on in the pact nirvana guide
https://docs.pact.io/pact_nirvana/step_4#d-manually-verify-the-pact-by-consumer-version-selectors-using-the-pact-broker
should ensure that we just tell the user to set enablePending and includeWipPactsSince in this step because it?s part of our recommend setup
https://docs.pact.io/provider/recommended_configuration#pending-pacts
we can suggest that they can see it in action in the ci/cd workshop, or read the pending pacts and wip pacts pact on http://docs.pact.io for a theoretical explanation
mahesh.damavarapu
2023-07-25 16:25
Hi, I deployed pact-broker in EC2 and was configured to Cloudfront. I am able to access the UI using Cloudfront URL. But while doing the publish, the broker client is looking for localhost:443 URL. We are passing proper URL and Credentials.
```ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to localhost:443 (Connection refused - connect(2) for "localhost" port 443) /node_modules/@pact-foundation/pact-core/standalone/darwin-arm64-2.0.2/pact/lib/vendor/ruby/3.2.0/gems/pact_broker-client-1.66.1/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 5 of 5
/node_modules/@pact-foundation/pact-core/standalone/darwin-arm64-2.0.2/pact/lib/ruby/lib/ruby/3.2.0/net/http.rb:1271:in `initialize': Failed to open TCP connection to localhost:443 (Connection refused - connect(2) for "localhost" port 443) (Errno::ECONNREFUSED)```
NPM Script
```"scripts": {
"publish-pact-ec2": "pact-broker publish ./pacts --consumer-app-version 1.0 --broker-base-url 'https://*************.http://cloudfront.net' --broker-username ******* --broker-password ********",
"test-provider": "nyc --reporter=text-summary mocha -t 30000 tests/provider.spec.js"
},```
mahesh.damavarapu
2023-07-26 00:29
```{"_links":{"self":{"href":"https://localhost","title":"Index","templated":false},"pb:publish-pact":{"href":"https://localhost/pacts/provider/{provider}/consumer/{consumer}/version/{consumerApplicationVersion}","title":"Publish a pact","templated":true},"pb:publish-contracts":{"href":"https://localhost/contracts/publish","title":"Publish contracts","templated":false},"pb:latest-pact-versions":{"href":"https://localhost/pacts/latest","title":"Latest pact versions","templated":false},"pb:tagged-pact-versions":{"href":"https://localhost/pacts/provider/{provider}/consumer/{consumer}/tag/{tag}","title":"All versions of a pact for a given consumer, provider and consumer version tag","templated":false},"pb:pacticipants":{"href":"https://localhost/pacticipants","title":"Pacticipants","templated":false},"pb:pacticipant":{"href":"https://localhost/pacticipants/{pacticipant}","title":"Fetch pacticipant by name","templated":true},"pb:latest-provider-pacts":{"href":"https://localhost/pacts/provider/{provider}/latest","title":"Latest pacts by provider","templated":true},"pb:latest-provider-pacts-with-tag":{"href":"https://localhost/pacts/provider/{provider}/latest/{tag}","title":"Latest pacts for provider with the specified tag","templated":true},"pb:provider-pacts-with-tag":{"href":"https://localhost/pacts/provider/{provider}/tag/{tag}","title":"All pact versions for the provider with the specified consumer version tag","templated":true},"pb:provider-pacts":{"href":"https://localhost/pacts/provider/{provider}","title":"All pact versions for the specified provider","templated":true},"pb:latest-version":{"href":"https://localhost/pacticipants/{pacticipant}/latest-version","title":"Latest pacticipant version","templated":true},"pb:latest-tagged-version":{"href":"https://localhost/pacticipants/{pacticipant}/latest-version/{tag}","title":"Latest pacticipant version with the specified tag","templated":true},"pb:webhooks":{"href":"https://localhost/webhooks","title":"Webhooks","templated":false},"pb:webhook":{"href":"https://localhost/webhooks/{uuid}","title":"Webhook","templated":true},"pb:integrations":{"href":"https://localhost/integrations","title":"Integrations","templated":false},"pb:pacticipant-version-tag":{"href":"https://localhost/pacticipants/{pacticipant}/versions/{version}/tags/{tag}","title":"Get, create or delete a tag for a pacticipant version","templated":true},"pb:pacticipant-branch-version":{"href":"https://localhost/pacticipants/{pacticipant}/branches/{branch}/versions/{version}","title":"Get or add/create a pacticipant version for a branch","templated":true},"pb:pacticipant-version":{"href":"https://localhost/pacticipants/{pacticipant}/versions/{version}","title":"Get, create or delete a pacticipant version","templated":true},"pb:metrics":{"href":"https://localhost/metrics","title":"Get Pact Broker metrics"},"pb:can-i-deploy-pacticipant-version-to-tag":{"href":"https://localhost/can-i-deploy?pacticipant={pacticipant}&version={version}&to={tag}","title":"Determine if an application version can be safely deployed to an environment identified by the given tag","templated":true},"pb:can-i-deploy-pacticipant-version-to-environment":{"href":"https://localhost/can-i-deploy?pacticipant={pacticipant}&version={version}&environment={environment}","title":"Determine if an application version can be safely deployed to an environment","templated":true},"pb:provider-pacts-for-verification":{"href":"https://localhost/pacts/provider/{provider}/for-verification","title":"Pact versions to be verified for the specified provider","templated":true},"beta:provider-pacts-for-verification":{"name":"beta","href":"https://localhost/pacts/provider/{provider}/for-verification","title":"DEPRECATED - please use pb:provider-pacts-for-verification","templated":true},"curies":[{"name":"pb","href":"https://localhost/doc/{rel}?context=index","templated":true},{"name":"beta","href":"https://localhost/doc/{rel}?context=index","templated":true}],"pb:environments":{"title":"Environments","href":"https://localhost/environments","templated":false},"pb:environment":{"title":"Environment","href":"https://localhost/environments/{uuid}","templated":true}}}```
bartlomiej
2023-07-26 18:11
Hi! :wave:
I'm getting the following error (Pactflow): `Your Provider Contract Is Not Compatible With The Provider Codebase`. How can I see the details?
I generate OpenAPI automatically using @fastify/swagger.
Self verification logs looks like this:
```openapi: 3.0.3
info:
title: My provider
description: API
version: 0.1.0
components:
schemas:
Schema:
type: object
properties:
userSchemaRequest:
type: object
properties:
id:
type: string
required:
- id
additionalProperties: false
userSchemaReply:
type: object
properties:
id:
type: string
name:
type: string
required:
- id
- name
additionalProperties: false
userSchemaReplyArray:
type: array
items:
$ref: "#/components/schemas/Schema/properties/userSchemaReply"
required:
- userSchemaRequest
- userSchemaReply
- userSchemaReplyArray
additionalProperties: false
paths:
/users:
get:
operationId: getAllUsers
description: Get all users
responses:
"200":
description: Default Response
content:
application/json:
schema:
$ref: "#/components/schemas/Schema/properties/userSchemaReplyArray"
"/users/{id}":
get:
operationId: getUser
description: Get a user by id
parameters:
- schema:
type: string
in: path
name: id
required: true
responses:
"200":
description: Default Response
content:
application/json:
schema:
$ref: "#/components/schemas/Schema/properties/userSchemaReply"```
yousafn
2023-07-26 18:44
Please raise PactFlow specific questions in the #pactflow channel
the self-verification result is based on the verification-success or verification-exit-code parameters provided when uploading the contract. how these are set depends on your own particular setup (they are user provided params)
yousafn
2023-07-26 18:48
It is one of these options fyi
referenced https://docs.pactflow.io/docs/bi-directional-contract-testing/publishing#docker-1 which points to the source docs https://docs.pactflow.io/docs/bi-directional-contract-testing/publishing/#usage
``` [--verification-success], [--no-verification-success]
# Whether or not the self verification passed successfully.
[--verification-exit-code=N]
# The exit code of the verification process. Can be used instead
of --verification-success|--no-verification-success for a```
sameswar.khuntia
2023-07-27 14:05
I am getting this error when i am trying to use pactBroker instead of pactFolder ._Failed to fetch the root HAL document_
_http://au.com.dius.pact.core.pactbroker.InvalidNavigationRequest: Failed to fetch the root HAL document , any suggestion what i am doing wrong?_
prakhar.roy371
2023-07-27 14:54
Hi all,
Instead of using Pact-Cli image in my CICD pipeline, I am using an Pact-Cli executable (referring to this link - https://github.com/pact-foundation/pact-ruby-standalone/releases)
_"curl -LO https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v2.0.3/pact-2.0.3-linux-x86_64.tar.gz_
_tar xzf pact-2.0.3-linux-x86_64.tar.gz"_
My question here is, after unpacking the tar ball, what are the commands I need to add in my CICD job to use the executable to publish the verified pacts back to pact broker.
yousafn
2023-07-27 15:13
you will need to add the path to the executable, or add it to your PATH, so the command is globally available
prakhar.roy371
2023-07-27 15:47
This is what I have done so far.
Can you tell me where exactly I need to add the path? @yousafn
yousafn
2023-07-27 15:52
https://github.com/pact-foundation/pact-ruby-standalone#package-contents
> Binaries will be extracted into `pact/bin`:
yousafn
2023-07-27 15:53
```export PACT_CLI_BIN_PATH=${PWD}/pact/bin/
export PATH=$PACT_CLI_BIN_PATH:${PATH}```
prakhar.roy371
2023-07-27 16:10
Do we need to put these commands in the CICD pipeline?
I tired adding it after curl command and before "pact-broker" command in the job.
```export PACT_CLI_BIN_PATH=${PWD}/pact/bin/
export PATH=$PACT_CLI_BIN_PATH:${PATH}```
yousafn
2023-07-27 16:15
the path to the executables are in `pact/bin` once you have downloaded them.
therefore the path to the executable can be `pact/bin/pact-broker` from your current working directory.
prakhar.roy371
2023-07-27 16:19
I am able to download the executable (as seen from the job logs), how can I navigate to pact/bin/pact-broker and use the pact broker command?
matt.fellows
2023-07-27 23:01
Could you please share the setup? I?m guessing you?re passing a pact file URL to the broker path (which should just be the base host).
But without seeing what you?re doing, it?s quite hard.
DEBUG level logs would also suffice
sameswar.khuntia
2023-07-28 06:50
import http://au.com.dius.pact.provider.junitsupport.StateChangeAction;
import http://au.com.dius.pact.provider.junitsupport.loader.PactBroker;
import http://au.com.dius.pact.provider.junitsupport.loader.PactBrokerAuth;
import http://au.com.dius.pact.provider.junitsupport.loader.PactFolder;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.TestTemplate;
import org.junit.jupiter.api.extension.ExtendWith;
import org.springframework.boot.test.context.SpringBootTest;
import org.springframework.boot.test.web.server.LocalServerPort;
@SpringBootTest(webEnvironment = SpringBootTest.WebEnvironment._RANDOM_PORT_)
@Provider("AddressProvider")
//@PactFolder("pacts")
@PactBroker(url = "https://swedbankab.pactflow.io/",
authentication = @PactBrokerAuth(token="Yz6NkQf-jjjjj"))
public class PactProviderTest {
@LocalServerPort
public int port;
@BeforeEach
public void setUp(PactVerificationContext context){
context.setTarget(new HttpTestTarget("localhost",port));
System._setProperty_("pact.verifier.publishResults", "true");
}
@TestTemplate
@ExtendWith(PactVerificationInvocationContextProvider.class)
public void verificationTest(PactVerificationContext context){
context.verifyInteraction();
}
@State(value="address exist",action = StateChangeAction._SETUP_)
public void AddresExist(){}
@State(value="address exist",action = StateChangeAction._TEARDOWN_)
public void AddressExitTearDown(){}
}
sameswar.khuntia
2023-07-28 07:11
Failed to fetch the root HAL document
http://au.com.dius.pact.core.pactbroker.InvalidNavigationRequest: Failed to fetch the root HAL document
at app<//au.com>.dius.pact.core.pactbroker.HalClient.navigate(HalClient.kt:253)
at app<//au.com>.dius.pact.core.pactbroker.PactBrokerClient$fetchConsumersWithSelectorsV2$halClient$navigateResult$1.invoke(PactBrokerClient.kt:494)
at app<//au.com>.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:35)
at app<//au.com>.dius.pact.core.pactbroker.PactBrokerClient.fetchConsumersWithSelectorsV2(PactBrokerClient.kt:494)
at app<//au.com>.dius.pact.provider.junitsupport.loader.PactBrokerLoader.loadPactsForProvider(PactBrokerLoader.kt:248)
at app<//au.com>.dius.pact.provider.junitsupport.loader.PactBrokerLoader.load(PactBrokerLoader.kt:128)
at app<//au.com>.dius.pact.provider.junit5.PactVerificationInvocationContextProvider$resolvePactSources$pactSources$1$pacts$1.invoke(PactJUnit5VerificationProvider.kt:78)
at app<//au.com>.dius.pact.core.support.KotlinLanguageSupportKt.handleWith(KotlinLanguageSupport.kt:35)
at app<//au.com>.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.resolvePactSources(PactJUnit5VerificationProvider.kt:78)
at app<//au.com>.dius.pact.provider.junit5.PactVerificationInvocationContextProvider.provideTestTemplateInvocationContexts(PactJUnit5VerificationProvider.kt:45)
at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.lambda$execute$0(TestTemplateTestDescriptor.java:106)
at java.base@17.0.5/java.util.stream.ReferencePipeline$7$1.accept(ReferencePipeline.java:273)
at java.base@17.0.5/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625)
at java.base@17.0.5/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
at java.base@17.0.5/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
at java.base@17.0.5/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at java.base@17.0.5/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at java.base@17.0.5/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base@17.0.5/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:110)
at app//org.junit.jupiter.engine.descriptor.TestTemplateTestDescriptor.execute(TestTemplateTestDescriptor.java:44)
at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at app//org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at app//org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base@17.0.5/java.util.ArrayList.forEach(ArrayList.java:1511)
matt.fellows
2023-07-28 07:21
We need the debug logs where we can see the request. My guess is corporate proxy and you are being intercepted
prakhar.roy371
2023-07-28 09:17
Thank you so much! I am now able to use the pact-cli executable :slightly_smiling_face:
yousafn
2023-07-28 14:45
Thanks for the PR @tien.xuan.vo it is merged and released now
https://github.com/pactflow/actions/releases/tag/v1.1.0
prakhar.roy371
2023-07-31 05:09
Hi all,
Is there a way to store the Pact-CLI EXECUTABLE somewhere inside Gitlab instead of curling it everytime the job runs?
matt.fellows
2023-07-31 05:10
You could also use the docker image, and then using standard docker caching mechanisms available to tools like gitlab
prakhar.roy371
2023-07-31 05:13
@matt.fellows Started with docker image but then switched to executable as with docker we need to open a few firewalls which is a security concern.
Right now, switched to the executable but still looking for a way to avoid using curl commands in my gitlab job
matt.fellows
2023-07-31 05:14
Maybe take a look at something like https://docs.gitlab.com/ee/ci/caching/
prakhar.roy371
2023-07-31 05:18
I want to keep the cli inside company network but also don't want to miss out on any latest updates made to the CLI.
Like some sort of version control
Any suggestions for what I can do here?
matt.fellows
2023-07-31 05:20
I would either
1. Pin the version and cache it (if it?s really a problem)
2. Download the latest and use that
matt.fellows
2023-07-31 05:20
In most pipelines, that step should take < 10s. It?s not really a big problem to overcomplicate with caching, version control etc. etc.
prakhar.roy371
2023-07-31 05:33
I agree with you. A question that came up during one of our meetings was
"When thinking about the CLI curl install are there approaches you can use to mitigate a supply chain attack?"
matt.fellows
2023-07-31 08:23
> ?When thinking about the CLI curl install are there approaches you can use to mitigate a supply chain attack??
on this question, I can think of a few, but we could probably think about how we as an ecosystem better guard against these things. I?ll raise at a #maintainers catch up
yousafn
2023-07-31 13:49
> ?When thinking about the CLI curl install are there approaches you can use to mitigate a supply chain attack??
1. Store a copy within your network. Some companies mirror npm with verdaccio so they have a private proxy
2. Checksum the download file, rather than using the checksum from the repo (as that could change, if say the GH repo or token is comprimised)
a. when you download it the file, check it against your own checksum, and if it fails chuck it away
3. You can now use the main install script, to pin to a specific version. You can copy this script to your own codebase, and therefore know you know that the `install.sh` can?t be modified
> I want to keep the cli inside company network but also don?t want to miss out on any latest updates made to the CLI.
> Like some sort of version control
I would assume that with this increased eye on security that would review the contents of each version bump, to ensure that it doesn?t bring in any vulns.
Do you do that with other software? What considerations do you security team recommended.
yousafn
2023-07-31 13:51
> I want to keep the cli inside company network but also don?t want to miss out on any latest updates made to the CLI.
> Like some sort of version control
> Any suggestions for what I can do here?
> switched to the executable but still looking for a way to avoid using curl commands in my gitlab job
This answer means you avoid needing to use curl each time in a job, and have a fixed, vendored bundle.
> you can download the bundle and put it wherever you like
prakhar.roy371
2023-07-31 14:04
Thank you so much @yousafn for the detailed explanation.
For now, I put the latest pact-cli within JFrog (Linked with company) and instead of curling from Github, now curling from within company network.
I will take a look into how I can avoid using curl.
Thank you so much @matt.fellows @yousafn @tjones for you insights and help! Much appreciated :slightly_smiling_face:
Really have learnt so much this past couple of months from you three!
yousafn
2023-08-01 11:49
Our pleasure @prakhar.roy371!
It can be a challenge on both sides on the fence, so it is really awesome to hear a success story and especially how empowering learning a set of new skills can be!
You should if you are so inclined think about writing up something about your journey, I am sure others would appreciate it!
sameswar.khuntia
2023-08-01 13:47
Failed to fetch the root HAL document
I tried to setup proxy like this while running the tests but still getting below error
$ ./gradlew test -Dhttp.proxyHost=http://ourhost.se -Dhttp.proxyPort=8080 -DnonProxyHosts=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16
PactProviderTest > verificationTest(PactVerificationContext) > initializationError FAILED
http://au.com.dius.pact.core.pactbroker.InvalidNavigationRequest at HalClient.kt:253
Caused by: org.apache.hc.client5.http.HttpHostConnectException at Net.java:-2
john.joel.thetla
2023-08-02 05:30
Hi all, I have my pactflow on-prem setup in PKS. Currently it is in Demo-auth mode. I am trying to add environment as there are no environments declared in *pact broker*
In the Pactflow settings unable to find 'add environment' button.
and, I tried using Pact cli executable to create environment it is throwing an error stating, "status 403 forbidden Either you are using a read only token for a request that requires a write token, or you do not have the required permission." Even though I am giving it read/write token.
sameswar.khuntia
2023-08-02 06:26
*Failed to fetch the root HAL document*
I tried to setup proxy like this while running the tests but still getting below error
_$ ./gradlew test -Dhttp.proxyHost=http://ourhost.se -Dhttp.proxyPort=8080 -DnonProxyHosts=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16_
Error:
_PactProviderTest > verificationTest(PactVerificationContext) > initializationError FAILED_
_http://au.com.dius.pact.core.pactbroker.InvalidNavigationRequest at HalClient.kt:253_
_Caused by: org.apache.hc.client5.http.HttpHostConnectException at Net.java:-2_
matt.fellows
2023-08-02 06:28
Are you sure that?s the problem though? Can you please share debug level logs so we can see the outbound request/responses?
sameswar.khuntia
2023-08-02 07:03
@matt.fellows here is the logs Caused by: org.apache.hc.client5.http.HttpHostConnectException: Connect to https://swedbankab.pactflow.io:443 [http://swedbankab.pactflow.io/3.26.132.129, http://swedbankab.pactflow.io/52.63.4.90] failed: Connection timed out: no further information
at java.base@17.0.5/sun.nio.ch.Net.pollConnect(Native Method)
at java.base@17.0.5/sun.nio.ch.Net.pollConnectNow(Net.java:672)
at java.base@17.0.5/sun.nio.ch.NioSocketImpl.timedFinishConnect(NioSocketImpl.java:549)
at java.base@17.0.5/sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:597)
at java.base@17.0.5/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327)
at java.base@17.0.5/java.net.Socket.connect(Socket.java:633)
matt.fellows
2023-08-02 08:15
that looks like a network issue - if you try on a non-work laptop, does it work?
matt.fellows
2023-08-02 08:16
`telnet http://swedbankab.pactflow.io 443` on your work machine vs non work machine should highlight the problem
sameswar.khuntia
2023-08-02 08:25
This is my work computer ..Y:\>telnet http://swedbankab.pactflow.io 443
Connecting To http://swedbankab.pactflow.io...Could not open connection to the host, on port 443: Connect failed.
matt.fellows
2023-08-02 11:53
This looks like a firewall issue on your side, you will need to find somebody internally that can allow you access to the application
andrevdrodrigues
2023-08-03 11:27
Hi everyone!
Anyone knows how can I verify the lasted published pact even if not in master/main branch?
I noticed that by default the master is always considered:
`latest version of consumer from the main branch 'master' (0001)`
How can I change it to get the latest version regardless the branch? Is possible with some specific selector?
Thanks :slightly_smiling_face:
matt.fellows
2023-08-03 23:10
Yes, https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors
But you shouldn?t do it. Why do you think you want to do this?
andrevdrodrigues
2023-08-04 15:56
Im doint some tests to check different ways to verify our pacts? I noticed that even informing this ?latest? = true, only the latest of the main branch is considered.
Anyway, Im using one webhook to trigger one github action in my provider to verify the contract? In pact webhook is possible to inform the consumer branch name that triggered this provider and only verify the pact with this branch?
matt.fellows
2023-08-06 10:00
Yes it should be, see this list: https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution
aniket.rane
2023-08-07 03:27
Hello all. I am having issue with publishing my pacts to broker hosted in bitbucket pipelines. I am using the https://github.com/pact-foundation/pact-broker-docker/blob/master/docker-compose.yml from the github repo (https://github.com/pact-foundation/https://github.com/pact-foundation/pact-broker-docker).
My tests pass locally (using docker on Macbook) but when deployed to bitbucket pipelines, I get this error:
`[03:20:05.795] INFO (62): pact-core@13.13.8: Publishing Pacts to Broker`
`[03:20:05.799] INFO (62): pact-core@13.13.8: Publishing pacts to broker at: http://localhost:9292/`
`[03:20:26.475] WARN (62): pact-core@13.13.8: Pact exited with code 1.`
`[03:20:26.476] ERROR (62): pact-core@13.13.8: Pact publication failed with non-zero exit code. Full output was:`
`ERROR: Error making request - Errno::ECONNREFUSED Failed to open TCP connection to localhost:9292 (Connection refused - connect(2) for "localhost" port 9292) /opt/atlassian/pipelines/agent/build/node_modules/@pact-foundation/pact-core/standalone/linux-x64-1.92.0/pact/lib/vendor/ruby/2.4.0/gems/pact_broker-client-1.65.0/lib/pact_broker/client/hal/http_client.rb:79:in `block in perform_request', attempt 1 of 5`
I have tried a few suggestions from other's post (stackoverflow/ Atlassian Support) but have to yet find a solution that works for me.
Do you have any suggestions for me try?
matt.fellows
2023-08-07 03:36
Is the broker running on the CI environment? It looks like you?re trying to hit `localhost` but if it?s running on your machine, the CI won?t be able to reach that
it should be deployed somewhere centrally that your dev environment, CI and other team members can access.
adra_verma
2023-08-07 08:39
Hi Team, Please help me in following points for PostgreSQL.
1. Document to setup requirement for PGS and helpful document
2. Doubt: how possible when the db is failover from one DC to another.
3. Need to setup the tool and make connection to it.
matt.fellows
2023-08-07 09:25
Database failover is not really a pact question, it's a database administration question
adra_verma
2023-08-07 13:27
I need proper knowledge about why we used PGS and its utilization. How should I setup PGS tool in local. Proper doc about PGS above already digged .
aniket.rane
2023-08-07 14:21
Yes, the docker containers are being deployed as part of the pipelines code execution.
Here's the bitbucket-pipelines.yml
```# Template NodeJS build
# This template allows you to validate your NodeJS code.
# The workflow allows running tests and code linting on the default branch.
image: node:16
options:
docker: true
definitions:
caches:
docker-cliplugins: ~/.docker/cli-plugins
yaml-anchors:
- &setup-docker-compose-latest-script >-
wget --no-verbose --no-clobber https://github.com/docker/compose/releases/latest/download/docker-compose-linux-x86_64 --output-document ~/.docker/cli-plugins/docker-compose
|| true
; chmod a+x ~/.docker/cli-plugins/docker-compose
&& ln --symbolic ~/.docker/cli-plugins/docker-compose /usr/local/bin/docker-compose
pipelines:
default:
- step:
name: Install dependencies
caches:
- node
script:
- npm install
- step:
name: Start Docker container
services: [docker]
caches: [docker-cliplugins]
script:
- *setup-docker-compose-latest-script
- docker compose version
- docker-compose -f docker-compose.yml up -d
- step:
name: Run Contract Tests
caches:
- node
- docker
script:
- npm run test:consumer
- npm run test:provider
- step:
name: Stop Docker container
services: [docker]
caches: [docker-cliplugins]
script:
- docker-compose down```
aniket.rane
2023-08-07 14:29
The PACT_BROKET_BASE_URL values include 'https://host.docker.internal http://host.docker.internal http://host.docker.internal:9292' but they don't seem to be used.
I assume the tests call the pact broker based on the configuration (.yml files), localhost or host.docker.internal.
matt.fellows
2023-08-07 22:23
`PACT_BROKER_BASE_URL` should point exactly to the base URL of your broker. It?s not a comma separated list
matt.fellows
2023-08-07 22:23
`https://host.docker.internal` is a special DNS only available within docker containers, not from outside
sameswar.khuntia
2023-08-10 13:59
*Invalid JSON (1:4), found unexpected character 'm'*
http://au.com.dius.pact.core.support.json.JsonException: Invalid JSON (1:4), found unexpected character 'm' we are getting this error from provider side when we try to run the tests. we are using version 4.6.1. any pointers could help .
yousafn
2023-08-10 14:02
I would raise that in pact-jvm and have a read of https://docs.pact.io/help/how_to_ask_for_help
gurubabu.jampala
2023-08-14 00:03
Hi All,
I am trying to build the provider pipeline in bamboo cicd. As part of CI the pact broker can-i-deploy cli command for the to-environment with "Staging" (which is not available in respected consumer), is returning "yes" (Attached screenshot), but ideally it should give "no" right? Please confirm if it's expected behaviour.
The same way I have tried from consumer end, it's giving me "no" (attached screenshot).
Kindly help me if anything I have missed to check here.
#pact-broker
matt.fellows
2023-08-14 02:08
if the consumer hasn?t been deployed to staging, then it is perfectly safe for the provider to do so - it won?t break any dependencies in that environment
matt.fellows
2023-08-14 02:09
It?s not safe the other way around, for the same reason but in reverse. If the consumer were to deploy, there is no provider there (if there is no recorded deployment for it) or the provider may or may not be compatible with the consumer. Either way, we are not confident it?s safe to deploy
mwilso29
2023-08-14 14:28
Hi All, is it possible to send a provider contract to the pact-broker or does it have to be the pact verify function that runs as part of the provider code?
matt.fellows
2023-08-14 21:33
In Pact, it's a specification by example and the provider needs to prove it can support those examples via replay by Pact
matt.fellows
2023-08-14 21:34
I'd you mean Pactflow's OAS capability that's a different thing (and yes you can upload it separately)
gurubabu.jampala
2023-08-16 00:00
Hi All,
When consumer publish the contract, contract_requiring_verification_publish event webhook triggered and it makes three provider pipelines started (main, Staging and PROD environments) and failed in can-i-deploy for staging environment. In Provider end all three pipelines are executed and publish the verification success results back to pact broker.
In this case, Is there a way in pact-broker to resume the consumer pipeline ?
If yes, can you please redirect me the documentation. If not, then is there any roadmap and release timelines from pact-broker team?
#pact-broker
gurubabu.jampala
2023-08-16 04:31
Thanks for your reply @matt.fellows
There was some miscommunication in the previous question. Reframing the question here
*Scenario1*:
When two consumers(different environments) with one provider as shown below, then how can we pass the to-environment in provider's pipeline can-i-deploy?
```Consumer 1 Provider 1
1.1(Preprod) 1.2(Staging)
Consumer 2 Provider 1
2.1(Staging) 1.2(Staging)```
*Scenario2*:
When two providers(different environments) with one consumer as shown below, then how can we pass the to-environment in consumer pipeline can-i-deploy?
```Consumer 3 Provider 2
3.1 (Preprod) 2.1(Staging)
Consumer 3 Provider 3
3.1 (Preprod) 2.1(SIT)```
#pact-broker
yousafn
2023-08-16 08:41
you can enable polling with the can i deploy tool, so that it waits for a period of time, hopefully in that time your provider tests have all ran.
alternatively you could use webhooks to trigger your consumer can i deploy off the back of a successful provider verification event.
matt.fellows
2023-08-16 12:05
The answer is always the same. You're asking the question "is it safe to deploy some application to some environment"
Replace application and environment with what you wish to deploy and where to deploy it
matt.fellows
2023-08-16 12:05
The Pact Broker works out the dependencies and checks if they'll be satisfied or you were to deploy or not, and tell you why if not
gurubabu.jampala
2023-08-17 07:37
So you are suggesting, in this case do I need to do multiple can-i-deploy calls for each environment before deployment as below?
Scenario1 - Provider can-i-deploy
pact-broker can-i-deploy --pacticipant Provider1 --version 1.2 --to-environment Preprod
pact-broker can-i-deploy --pacticipant Provider2 --version 1.2 --to-environment Staging
Scenario2 - Consumer can-i-deploy
pact-broker can-i-deploy --pacticipant Consumer3 --version 3.1 --to-environment Staging
pact-broker can-i-deploy --pacticipant Consumer3 --version 3.1 --to-environment SIT
#pact-broker
matt.fellows
2023-08-17 08:00
well, I don?t know what you need to check if it?s safe to deploy to `SIT` if you plan on deploying to `Preprod` for example (and vice versa)
matt.fellows
2023-08-17 08:00
Unless you always deploy to both at the same time, in which case, yes yo uwould
eduardo.rodrigues
2023-08-22 08:08
Hi all,
I am trying to run the docker image on ECS and configure it to access RDS using IAM authentication.
I haven't yet found where to tweak the configuration to make it work.
Have you done it before?
matt.fellows
2023-08-22 10:23
I believe we support it for PactFlow on-prem customers, i?ll see if I can dig up any work on that that?s relevant
yousafn
2023-08-22 13:53
What exactly isn?t working, and how far have you got so far?
You provide the app a connection string to your db. access controls will depend on how you have setup perms / vpc?s / security groups etc
matt.fellows
2023-08-22 23:25
The issue is that the default postgres gem we use (Sequel) needs to be overridden, as it expects a username/password. IAM Auth is slighly different - you need to dynamically fetch credentials and continually rotate them
You need to use something like the `aws-sdk-rds/customizations/auth_token_generator` package which overrides the authentication to fetch the credentials dynamically (via IAM), rotates them as they expire etc.
If you could please raise a feature request on the pact_broker repo, that would help create some visibility
eduardo.rodrigues
2023-08-22 23:27
I haven't got far enough. I started yesterday and I couldn't find a clear way to progress
sameswar.khuntia
2023-08-23 11:22
HI All, I am trying to setup proxy setting for PactPublish task in gradle like this
pact {
publish {
pactDirectory = "$buildDir/pacts/"
pactBrokerUrl = 'URL'
pactBrokerToken = 'Token'
systemProperty("https.proxyHost", "http://host.se")
systemProperty("https.proxyPort", "8080")
systemProperty("https.proxyUsername", "UN")
systemProperty("https.proxyPassword", "PWD")
systemProperty("https.nonProxyHosts", "localhost|127.*|.*http://something.net|.*http://something.net")
}
} But is not allowing me to do so , Have anyone setup proxy setup for the gradle task pactPublish ?
br.holanda15
2023-08-23 16:48
Hey guys, I'm trying to publish my contract to my broker, but I can't find the pact file, Is there some error in my command?
gurubabu.jampala
2023-08-24 04:10
Hi,
Example scenario on the similar notes,
*Scenario*: Consumer Foo with two providers Bar and Baz.
Consumer(Foo) environments mapped with Provider environment as follows,
? Foo - prod is pointed to Bar(production) and Baz(prod) environments
? Foo - stag is pointed to Bar(staging) and Baz(preprod) environments
? Foo - sit is pointed to Bar(sit) and Baz(dev) environments
? Bar and Baz deployed their code in all the environments for Foo version 22, pact-broker matrix as below
*Foo version(consumer) Bar version(provider1) Verification success?*
*22(prod, stag, sit) 56(production, staging, sit) True*
*Foo version(consumer) Baz version(provider2) Verification success?*
*22(prod, stag, sit) 66(prod, preprod, dev) True*
? Foo did some change in contract and publish the new contract (23), now pact broker matrix as below
*Foo version(consumer) Bar version(provider1) Verification success?*
*22(prod, stag, sit) 56(production, staging, sit) True*
*23(main) 56(production, staging, sit) True*
*Foo version(consumer) Baz version(provider2) Verification success?*
*22(prod, stag, sit) 66(prod, preprod, dev) True*
*23(main) 66(prod, preprod, dev) False*
Foo pipeline configured for can-i-deploy for each environment as below order
? Build and Publish contract
? Can-I-deploy sit ( it will fail for first time and will resuming the pipeline once provider verification done successfully, in this case Bar will resume)
? Deploy in SIT
? Can-I-deploy stag
? Deploy in Staging
? Can-I-Deploy prod
? Deploy in PROD
As per the document, can-i-deploy checks only one *--to-environment (*provider env*)* at a time, so in this case since Foo having two providers (Bar and Baz), Can-I-deploy SIT pipeline task should check for both providers as below ?
pact-broker can-i-deploy --pacticipant Foo --version 23 --to-environment *sit* (Bar environment)
pact-broker can-i-deploy --pacticipant Foo --version 23 --to-environment *dev* (Baz environment)
alexander.doppelbauer
2023-08-28 18:05
Hi all, I have a question about the documentation. Does the pact broker (pactfoundation/pact-broker) really collect telemetry and sends this data to Google Analytics as described here: https://docs.pact.io/telemetry? Thank you very much for your help in advance!
scott.riley111
2023-08-29 16:33
:wave: I wanted to check here before exploring other options (apologies if it?s been mentioned/answered elsewhere - I searched this channel and the issues on the broker but couldn?t find anything)
We?ve got the OSS broker setup and I?m going through the CI/CD setup/pact nirvana steps, and had a couple of questions around secrets/webhook auth? as per the point at https://docs.pact.io/pact_nirvana/step_1:
> Note that if you are using your own instance of the open source Pact Broker, it does not support secrets, and it does not have a user interface for managing https://docs.pact.io/pact_broker/webhooks. You?ll need to use the API or HAL Browser to create the webhook, and your CI token will have to be stored in plain text in the webhook. See the Webhooks API reference docs https://docs.pact.io/pact_broker/advanced_topics/api_docs/webhooks
In our case (where our CI provider doesn?t have any granularity on the capabilities for an api token, and creating a machine user comes with some other downsides) I wanted to know if this is something that the OSS broker does not intent to support? Is this something we contribution?
Another small question I had was: In the webhook template examples, for github there?s a template variable `user.GithubToken` but in the docs on what?s available for variable substitution there?s nothing there :confused: - is it a pactflow-only value? or from something else?
yousafn
2023-08-29 20:48
Ahh my apologies, I inadvertently brought in the `user.GithubToken` in during this change when updating. It is PactFlow only that, so will update to reflect.
https://github.com/pact-foundation/docs.pact.io/commit/e60945f518b353b6c72e796fa6c18d9ea19880ec
> I wanted to know if this is something that the OSS broker does not intent to support?
Not sure on this answer.
I did look to implement token redaction, in this PR where Beth started working on some secrets func in the Pact Broker
https://github.com/pact-foundation/pact_broker/pull/262#issuecomment-501914838
It was around that time that PactFlow was launched and no free time was available for Pact Broker playtime, so it never progressed futher.
Might be a decent starting point to have a look.
scott.riley111
2023-08-29 22:21
:+1: ah nice - I saw that issue and for some reason didn?t open it up :facepalm: Reading through it however I see it mentions that the `Authorization` header is auto-redacted? I hadn?t seen that mentioned anywhere in the docs and hadn?t thought to just try it out :upside_down_face: That should cover my use case to be honest - we?re on circle and the token for webhooks is in that auth header, I?m not _that_ fussed about a user?s api token in the db/plaintext if it?s not accessible from the api :+1:
>> I wanted to know if this is something that the OSS broker does not intent to support?
>
> Not sure on this answer.
My question was more a ?is this not in the oss pact broker because it?s a differentiator between it and pactflow? - I?ve not seen that sort of vibe anywhere else though to be fair :slightly_smiling_face:
yousafn
2023-08-29 22:42
yeah they are already redacted in the body, the docs page seems to be lost in the midst, but the reference is here https://github.com/pact-foundation/pact_broker/blob/9529c6790eb74f70aa61df2cd2c067ffdfd3769c/lib/pact_broker/doc/views/webhooks.markdown?plain=1#L80
Depending on your setup, for example if you are using nginx, you can block access to certain API routes completely
https://blog.you54f.com/2019/03/19/securing-the-pact-broker-with-nginx-letsencrypt/
to say get requests on the webhooks endpoint, and leave it open for posts only.
> ? Whilst implementing webhooks, I noted that URL based tokens are visible to users both rw/ro, to the pact-broker, so we are blocking access to the `/webhooks` url. This will also block `/webhooks/**`
```error_page 418 = @blockAccess;
location /webhooks {
return 418;
}
location @blockAccess {
deny all;
}```
I suppose it depends on your setup but you should be good to go as is, it seem s:)
scott.riley111
2023-08-29 22:44
Ah excellent - yeh our token is in `Circle-Token` so I think we should be good :slightly_smiling_face:
matt.fellows
2023-08-31 03:46
Why are apps in one environment pointing to apps across others?
In any case, yes you would need to call it for each environment you want to check. You would also need to deploy it to the target environments otherwise the reciprocal check won't be valid (i.e. the provider might think it's safe to deploy because the consumer is in SIT no pre prod)
gurubabu.jampala
2023-08-31 03:50
It could be possible where consumer is with one team where they are using their own deployment strategies similarly for provider too.
BTW thanks for your reply!
matt.fellows
2023-08-31 04:47
Mind elaborating a bit more on the reason for applications crossing environment boundaries?
boer.k
2023-09-05 10:48
Hi, maybe this is a #feature-requests, but lets see. We are on our way to introduce Pactflow within our company and CI/CD pipelines. Essential for this to work properly is that the broker is always correct and up-to-date about which version of which application is deployed on which environment. While talking with our deployment platform team, we learned that they already have their own tool for this kind of bookkeeping. Having to maintain this information in two places is not desirable.
To my understanding, the pactflow broker relies on that the "record-deployment" command is *always* called *after* deployment for every application. You have to make sure that every possible method of deployment for every application will call that command. Any kind of circumstance where this call is missed, either by some an error in the pipeline, hacky deployment, network issues, or whatever, and your broker will be out of sync. Not only are your tests and deployments at risk, you then also have to restore the correct state to the broker somehow, which likely requires manual correction.
The application of our platform team is basically is a live view on their entire platform. No matter how any given application got there, what their bookkeeping software sees is always a live view of every application and version. No need to send a signal after deployment, and no chance of being out of sync.
Preferably we are looking for a way to have only one source of information, and our own "platform view" application seems like the best place to hold that information. We would like to have some way for the broker to look in our own application to determine which version is deployed where. So in a more general idea my question/feature request is: "Is it possible to have different backend application for the broker to query deployment information?"
matt.fellows
2023-09-05 11:43
If that other system is the source of truth, how is it updated and when it gets its updates, can you update PactFlow when it happens?
boer.k
2023-09-05 12:11
I am not sure how their application works, ive never seen it myself yet. I proposed we try implement some kind on onchange listener in their application that will forward the change to the broker. But before we go into that route I wanted to check if there maybe wasnt already some kind of existing solution for this
matt.fellows
2023-09-05 12:30
We have had requests for other external systems being the source of truth (e.g. Vault for secrets management), but this is the first time deployments has come up!
matt.fellows
2023-09-05 12:31
I know Atlassian has ways to capture this in both Jira and elsewhere (we use it in PactFlow), but we just publish the deploy event to PactFlow _and_ Jira
yousafn
2023-09-05 16:58
Some thoughts on the matter from the author
https://docs.pact.io/pact_broker#can-i-use-pact-without-a-pact-broker
TL;DR - you get a whole lot for free with the Pact Broker, but it may not work in all cases.
> If that other system is the source of truth, how is it updated and when it gets its updates, can you update PactFlow when it happens?
That nature of your system using one single view, and having aggregated sources of data in a common problem in scenarios where MI/BI is being pumped into something like a data lake and querying later. I would argue that transient network efforts should be considered in your strategy. For example, a failure to call the record deployment should result in a build failure.
There should possibly be checks put in place to ensure that certain events have occured, eg once you have deployed your application, you could use webhooks to ascertain if a record deployment exists for the freshly deployed provider and if not provide some alerting.
Some alternative approaches to sharing pacts
https://docs.pact.io/getting_started/sharing_pacts#alternative-approaches
Also seen this but haven?t taken it for a spin yet
https://github.com/RaVbaker/pact-contractor
yousafn
2023-09-05 16:58
> I will ask next week when we have a followup meeting about this
Interested to hear more about the setup :slightly_smiling_face:
james.perepiczka
2023-09-12 12:30
Hi,
Is it possible to update a branch listed on a contract? We had a scenario whereby a team did a FF merge with git which preserved the commit sha we are using as version. Because the contract was published initially under a feature branch, the contract does not acknowledge the commit it is now apart of is the main branch but it has all the tags and environments associated as being within the main. I can see this being a problem if some projects are pulling in contracts based on what is available as part of the mainBranch and potentially excluding this case.
sayantini.basak
2023-09-12 17:39
Hi all! I hope you're all doing well.
I'm relatively new to Pact testing and have encountered an issue that's been puzzling me. I did a thorough search through this channel and the Pact Broker issues, but I couldn't find a solution, so I thought I'd reach out to this knowledgeable community for some guidance.
*Here's the situation*: We have our Pact Broker up and running on our localhost, and it's accessible through a public IP address. On the frontend side (Angular app), I've successfully executed Pact tests and generated the Pact contract, which I've also managed to publish on the Pact Broker.
However, when I attempt to verify the Pact test from my Node.js backend, I run into an issue that reports: "Failed to load pact - Could not load pacts from pact broker 'http://18.237.96.220:9292/'."
*I've included the logs below for your reference:*
```[22:51:11.120] INFO (39344): pact@12.1.0: Verifying provider
[22:51:11.373] INFO (39344): pact-core@14.0.4: Verifying Pacts.
[22:51:11.377] WARN (39344): pact-core@14.0.4: Using the tag 'latest' is not recommended and probably does not do what you intended.
[22:51:11.378] WARN (39344): pact-core@14.0.4: See https://docs.pact.io/pact_broker/tags/#latest-pacts
[22:51:11.379] WARN (39344): pact-core@14.0.4: If you need to specify latest, try:
[22:51:11.379] WARN (39344): pact-core@14.0.4: consumerVersionSelectors: [{ lastest: true }]
[22:51:11.380] INFO (39344): pact-core@14.0.4: Verifying Pact Files
[22:51:11.382] DEBUG (39344): pact-core@14.0.4: Initalising native core at log level 'DEBUG'
[22:51:11.383] DEBUG (39344): pact-core@14.0.4: binding path #0: : attempting to load native module from:
- C:\Users\saya2660\cxt\rental-customer-service\node_modules\@pact-foundation\pact-core\prebuilds\win32-x64
source: pact-js-core binding lookup
- You can override via PACT_PREBUILD_LOCATION
[22:51:11.505] INFO (39344): 0.4.7: pact native library successfully found, and the correct version
2023-09-12T17:21:11.524666Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_new_for_application FFI function invoked
2023-09-12T17:21:11.537949Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_provider_info FFI function invoked
[22:51:11.541] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierSetFilterInfo' was not executed as it had non-fatal validation errors: None of PACT_DESCRIPTION, PACT_PROVIDER_STATE or PACT_PROVIDER_NO_STATE were set in the environment
2023-09-12T17:21:11.546913Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_provider_state FFI function invoked
2023-09-12T17:21:11.554269Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_verification_options FFI function invoked
[22:51:11.551] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierSetPublishOptions' was not executed as it had non-fatal validation errors: No publishVerificationResult option / PACT_BROKER_PUBLISH_VERIFICATION_RESULTS set, or no providerVersion option
[22:51:11.552] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierSetConsumerFilters' was not executed as it had non-fatal validation errors: Either no consumerFilters option provided, or the array was empty
[22:51:11.553] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierSetFailIfNoPactsFound' was not executed as it had non-fatal validation errors: No failIfNoPactsFound option provided
[22:51:11.556] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierAddCustomHeader' was not executed as it had non-fatal validation errors: No customProviderHeaders option provided
[22:51:11.557] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierAddDirectorySource' was not executed as it had non-fatal validation errors: No pactUrls option provided
2023-09-12T17:21:11.563454Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_broker_source_with_selectors FFI function invoked
[22:51:11.567] DEBUG (39344): pact-core@14.0.4: the optional ffi function 'pactffiVerifierAddProviderTransport' was not executed as it had non-fatal validation errors: No additional provider transports provided
2023-09-12T17:21:11.664723Z DEBUG ThreadId(02) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_execute FFI function invoked
2023-09-12T17:21:11.665825Z DEBUG ThreadId(02) pact_ffi::verifier::handle: Pact source to verify = PactBrokerWithDynamicConfiguration(http://18.237.96.220:9292/, provider_name='customer-service', enable_pending=false, include_wip_since=None, provider_tags=["latest"], provider_branch=Some(""), consumer_version_selectors='[ConsumerVersionSelector { consumer: None, tag: Some("latest"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }], auth=Token(PACT*************)')
2023-09-12T17:21:11.701775Z DEBUG ThreadId(02) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/content-generator/binary
core/content-generator/json
core/content-matcher/json
core/content-matcher/multipart-form-data
core/content-matcher/text
core/content-matcher/xml
2023-09-12T17:21:11.701953Z DEBUG ThreadId(02) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/matcher/v1-equality
core/matcher/v2-max-type
core/matcher/v2-min-type
core/matcher/v2-minmax-type
core/matcher/v2-regex
core/matcher/v2-type
core/matcher/v3-content-type
core/matcher/v3-date
core/matcher/v3-datetime
core/matcher/v3-decimal-type
core/matcher/v3-includes
core/matcher/v3-integer-type
core/matcher/v3-null
core/matcher/v3-number-type
core/matcher/v3-time
core/matcher/v4-array-contains
core/matcher/v4-equals-ignore-order
core/matcher/v4-max-equals-ignore-order
core/matcher/v4-min-equals-ignore-order
core/matcher/v4-minmax-equals-ignore-order
core/matcher/v4-not-empty
core/matcher/v4-semver
2023-09-12T17:21:11.735709Z INFO ThreadId(02) pact_verifier::pact_broker: Fetching path '/' from pact broker
2023-09-12T17:21:11.747320Z DEBUG ThreadId(02) hyper::client::connect::http: connecting to 18.237.96.220:9292
2023-09-12T17:21:12.034277Z DEBUG ThreadId(02) hyper::client::connect::http: connected to 18.237.96.220:9292
2023-09-12T17:21:12.362421Z DEBUG tokio-runtime-worker hyper::client::pool: pooling idle connection for ("http", 18.237.96.220:9292)
2023-09-12T17:21:12.364975Z DEBUG ThreadId(02) pact_verifier::pact_broker: Link URL is templated
2023-09-12T17:21:12.365079Z DEBUG ThreadId(02) pact_verifier::pact_broker: templated URL = http://18.237.96.220:9292/pacts/provider/{provider}/for-verification
2023-09-12T17:21:12.376050Z DEBUG ThreadId(02) pact_verifier::pact_broker: final URL = http://18.237.96.220:9292/pacts/provider/customer-service/for-verification
2023-09-12T17:21:12.376229Z INFO ThreadId(02) pact_verifier::pact_broker: Fetching path '/pacts/provider/customer-service/for-verification' from pact broker
2023-09-12T17:21:12.376309Z DEBUG ThreadId(02) hyper::client::pool: reuse idle connection for ("http", 18.237.96.220:9292)
2023-09-12T17:21:12.376613Z DEBUG tokio-runtime-worker hyper::proto::h1::io: flushed 246 bytes
2023-09-12T17:21:12.680599Z DEBUG tokio-runtime-worker hyper::proto::h1::io: parsed 7 headers
2023-09-12T17:21:12.680652Z DEBUG tokio-runtime-worker hyper::proto::h1::conn: incoming body is content-length (2422 bytes)
2023-09-12T17:21:12.680689Z DEBUG tokio-runtime-worker hyper::proto::h1::conn: incoming body completed
2023-09-12T17:21:12.680724Z DEBUG tokio-runtime-worker hyper::client::pool: pooling idle connection for ("http", 18.237.96.220:9292)
2023-09-12T17:21:12.681090Z DEBUG ThreadId(02) pact_verifier::pact_broker: templated URL = http://18.237.96.220:9292/pacts/provider/customer-service/for-verification
2023-09-12T17:21:12.683326Z DEBUG ThreadId(02) pact_verifier::pact_broker: final URL = http://18.237.96.220:9292/pacts/provider/customer-service/for-verification
2023-09-12T17:21:12.683471Z DEBUG ThreadId(02) pact_verifier::pact_broker: Sending JSON to http://18.237.96.220:9292/pacts/provider/customer-service/for-verification using POST: {"providerVersionTags":["latest"],"includePendingStatus":false,"consumerVersionSelectors":[{"tag":"latest","latest":true}],"providerVersionBranch":""}
2023-09-12T17:21:12.683572Z DEBUG ThreadId(02) hyper::client::pool: reuse idle connection for ("http", 18.237.96.220:9292)
2023-09-12T17:21:12.684186Z DEBUG tokio-runtime-worker hyper::proto::h1::io: flushed 458 bytes
2023-09-12T17:21:12.984970Z DEBUG tokio-runtime-worker hyper::proto::h1::io: parsed 7 headers
2023-09-12T17:21:12.985020Z DEBUG tokio-runtime-worker hyper::proto::h1::conn: incoming body is content-length (161 bytes)
2023-09-12T17:21:12.985054Z DEBUG tokio-runtime-worker hyper::proto::h1::conn: incoming body completed
2023-09-12T17:21:12.985089Z DEBUG ThreadId(02) hyper::client::pool: pooling idle connection for ("http", 18.237.96.220:9292)
2023-09-12T17:21:12.987343Z ERROR ThreadId(02) pact_verifier: Could not load pacts from pact broker 'http://18.237.96.220:9292/': Link/Resource was not found - No pacts were found for this provider
2023-09-12T17:21:12.988589Z ERROR ThreadId(02) pact_verifier: Failed to load pact - Could not load pacts from pact broker 'http://18.237.96.220:9292/'
2023-09-12T17:21:12.989454Z WARN ThreadId(02) pact_matching::metrics:
Please note:
We are tracking events anonymously to gather important usage statistics like Pact version and operating system. To disable tracking, set the 'PACT_DO_NOT_TRACK' environment variable to 'true'.
2023-09-12T17:21:12.990398Z DEBUG ThreadId(02) pact_matching::metrics: Sending event to GA - {"t": "event", "cd6": "pact_ffi", "ec": "ProviderTest", "cd7": "1.1.5", "cid": "015df3ce8fa36b46e3a85d45041b663b", "ea": "Completed", "ev": "0", "ds": "client", "tid": "UA-117778936-1", "v": "1", "av": "14.0.4", "cd3": "windows-x86_64", "cd2": "unknown", "an": "pact-core", "aip": "true", "el": "Pacts verified", "aid": "pact-core"}
Failures:
1) Failed to load pact - Could not load pacts from pact broker 'http://18.237.96.220:9292/'
There were 1 pact failures
2023-09-12T17:21:13.247462Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=GoAway { error_code: NO_ERROR, last_stream_id: StreamId(0) }
2023-09-12T17:21:13.247543Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::proto::connection: Connection::poll; connection error error=GoAway(b"", NO_ERROR, Library)
2023-09-12T17:21:13.247930Z DEBUG ThreadId(02) pact_plugin_driver::plugin_manager: Shutting down all plugins
[22:51:13.258] DEBUG (39344): pact-core@14.0.4: shutting down verifier with handle 0
2023-09-12T17:21:13.263227Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_shutdown FFI function invoked
[22:51:13.259] DEBUG (39344): pact-core@14.0.4: response from verifier: null, 1
[22:51:13.260] ERROR (39344): pact-core@14.0.4: Verification unsuccessful
FAIL tests/pact-testing/provider.spec.ts (7.312 s)
Pact Provider verification
× Should verify customer rental services contracts (2167 ms)
? Pact Provider verification ? Should verify customer rental services contracts
Verfication failed
at node_modules/@pact-foundation/pact-core/src/verifier/nativeVerifier.ts:52:20
Interestingly, I've noticed that I can successfully run the Pact verification test from the backend if I use the Pact file from my local environment.
Any insights or assistance you can provide on this matter would be greatly appreciated. I'm eager to learn and resolve this issue, and your expertise would be invaluable in helping me move forward.```
Thank you in advance for your time and assistance!
yousafn
2023-09-12 17:53
Hey what does your consumer version selectors or your verifier options you pass in, look like in your test.
There isn?t a provider branch set here, so that doesn?t look to be passed in from your setup
```
2023-09-12T17:21:11.665825Z DEBUG ThreadId(02) pact_ffi::verifier:
Pact source to verify = PactBrokerWithDynamicConfiguration(http://18.237.96.220:9292/, provider_name='customer-service', enable_pending=false, include_wip_since=None, provider_tags=["latest"], provider_branch=Some(""), consumer_version_selectors='[ConsumerVersionSelector { consumer: None, tag: Some("latest"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }], auth=Token(PACT*************)')```
There is also a warning on your consumer version selectors
```WARN (39344): pact-core@14.0.4: Using the tag 'latest' is not recommended and probably does not do what you intended.```
yousafn
2023-09-12 17:55
Hopefully helpful tip - You can attach logs as a snippet or use a code block (far right button on the text box) to make logs a bit easier on the eyes in future :)
sayantini.basak
2023-09-12 18:03
@yousafn Below are the options I have for Verifier
``` const port = 3000
const opts = {
provider: "customer-service",
logLevel: "DEBUG",
providerBaseUrl: `http://localhost:${port}`,
pactBrokerUrl: `http://18.237.96.220:9292/`,
pactBrokerToken: "PACT_BROKER_TOKEN",
consumerVersionSelectors: [{ latest: true }],
publishVerificationResult: false,
providerVersion: "1.0.0"
};```
ryanlevell
2023-09-12 19:41
Has anyone run into this issue using docker pact broker? Sorry on mobile, formatting may be poor?
sudo docker run --name pactbroker --restart=always --link pact-broker-database:postgres -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD='password' -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -e PACT_BROKER_BASIC_AUTH_USERNAME=username -e PACT_BROKER_BASIC_AUTH_PASSWORD=password -e PACT_BROKER_ALLOW_PUBLIC_READ=true -d -p 80:80 dius/pact-broker
$ sudo docker logs pactbroker
*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...
*** Running /etc/my_init.d/10_syslog-ng.init...
Sep 12 19:31:31 96773d562894 syslog-ng[14]: syslog-ng starting up; version='3.25.1'
*** Running /etc/my_init.d/30_presetup_nginx.sh...
*** Booting runit daemon...
*** Runit started as PID 22
ok: run: /etc/service/nginx-log-forwarder: (pid 30) 0s
Sep 12 19:31:32 96773d562894 cron[27]: (CRON) INFO (pidfile fd = 3)
Sep 12 19:31:32 96773d562894 cron[27]: (CRON) INFO (Running @reboot jobs)
[ N -12 19:31 age/Wat/WatchdogMain.cpp:1373 ] Starting Passenger watchdog
[ N 09-12 19:31 age/Cor/CoreMain.cpp:1340 ] Starting Passenger core
[ N 09-12 19:31 age/Cor/CoreMain.cpp:256 ] Passenger core running in multi-application mode
[ N 09-12 19:31 age/Cor/CoreMain.cpp:1015 ] Passenger core online, PID 37
[ E 09-12 19:31 age/Cor/SecurityUpdateChecker.h:506 ] Security update check failed: Couldn't resolve host name while connecting to https://securitycheck.phusionpassenger.com/v1/check.json (check your DNS) (next check in 24 hours)
ryanlevell
2023-09-12 19:47
Just released I should use pactfoundation not dius for downloading the image :) trying that now
abubics
2023-09-13 00:21
You can tag/mark any version with multiple branches, so that isn't a problem. Whatever talks to the broker still needs to do that, though.
If the problem is that adding more branches to an existing contract version doesn't trigger further verifications, that's a separate issue.
matt.fellows
2023-09-13 02:00
> ```2023-09-12T17:21:12.683471Z DEBUG ThreadId(02) pact_verifier::pact_broker: Sending JSON to http://18.237.96.220:9292/pacts/provider/customer-service/for-verification using POST: {"providerVersionTags":["latest"],"includePendingStatus":false,"consumerVersionSelectors":[{"tag":"latest","latest":true}],"providerVersionBranch":""}```
This suggests you are specifying a tag called `latest`. Hopefully it?s not Pact JS doing something ?clever?.
See https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors for how selectors work and recommended default selectors.
If you?re new, don?t use tags, use branches/environments.
matt.fellows
2023-09-13 02:01
Can you please share how you?re publishing the pact and what tags/branches etc. are on it?
TL;DR - the verification selectors don?t match the contract that was published, so no pacts were found to be verified
sayantini.basak
2023-09-13 02:04
Thanks for the prompt response. Here is how we are publishing the pact from consumer currently
```let projectFolder = __dirname;
let pact = require('@pact-foundation/pact-node');
let project = require('./package.json');
let options = {
pactFilesOrDirs: [projectFolder + '/dist/pacts'],
pactBroker: 'http://18.237.96.220:9292/',
consumerVersion: project.version,
tags: ['latest']
};
pact.publishPacts(options).then(function () {
console.log("Pacts successfully published!");
});```
matt.fellows
2023-09-13 11:05
?latest? is a property of a contract, I doubt the tag also needs to be it
matt.fellows
2023-09-13 11:06
You should publish with a branch (https://docs.pact.io/pact_broker/branches)
matt.fellows
2023-09-13 11:07
sayantini.basak
2023-09-13 11:13
thank you for your suggestion. Let me try all of that :slightly_smiling_face:
matt.fellows
2023-09-13 11:26
For when you get to it, this is the best material for setting up your CI/CD system: howtolearn
2023-09-13 11:26
Here are a number of useful hands-on labs that teach all of the key concepts: https://docs.pactflow.io/docs/workshops and https://docs.pact.io/implementation_guides/workshops
lluis.casals
2023-09-13 14:36
Hello there! Let me revive this quite old thread :sweat_smile:
We?ve already worked in a solution that it is working for us:
? broker client: https://github.com/pact-foundation/pact_broker-client/pull/142
? support: https://github.com/pact-foundation/pact-support/pull/99
? pact-ruby: https://github.com/pact-foundation/pact-ruby/pull/298
So we?ve tested this and works like a charm, so there are the PR?s to make this availability something possible for each PACT gem we?ve thought it is needed.
Please, let me know if there is more info needed to be able to take a look to those PRs.
Thanks a lot for your help!
yousafn
2023-09-13 15:10
:blobwave: Fantastic thanks @lluis.casals
Thanks for all the various links as well. will tag Beth for review on those PR?s.
We would probably want to document these capabilities in each of the repos, and then centrally possibly on the http://docs.pact.io (which pulls in the readme?s from the respective websites.
Maybe a recipes page for MASSL based auth support https://docs.pact.io/recipes
or possibly as an addendum to this page
https://docs.pact.io/pact_broker/advanced_topics/using-tls
or as a new section alongside
matt.fellows
2023-09-13 23:27
Thanks for doing this, great stuff! I?ve added a couple of quick comments, but we?ll need the maintainer (Beth) to review etc.
chrisjburnscg
2023-09-16 14:33
@bethskurrie Hi Beth, apologies to bring you back in time haha! I'm just about to put a PR up for the Pact Broker Helm Chart whereby I update the Bitnami Postgres Chart dependency. The version I'm updating to would be Postgres15, do you think this would be ok with the latest version of the Pact Broker? Just wanted to make sure before I did anything
bethskurrie
2023-09-17 23:02
@chrisjburnscg postgres 15 is supported (we run tests against it in the pact_broker repo https://github.com/pact-foundation/pact_broker/actions/runs/6193036384 )
gurubabu.jampala
2023-09-20 06:04
To give more information, we are trying adopt the contract testing with some of the legacy teams where they are still using the legacy deployment approach, like master branch, DEV, SIT and Prod environments. And this team would be a provider service for some other consumer teams. So we are seeing the environments/branches are completely different between provider and consumer's end.
#pact-broker
matt.fellows
2023-09-20 07:10
The branches lining up is an independent problem to deployments. What you care about, is ensuring application A is compatible with application B in the environments they need to work in.
`can-i-deploy` gives you the ability to do that, you just have to do it in multiple calls
jonatan.bjork
2023-09-21 13:42
I just realised something when running `pact-broker can-i-deploy` - I was (incorrectly) specifying the flag `--environment staging` instead of (the correct) `--to-environment staging` and getting the warning:
```WARN: It is recommended to specify the environment into which you are deploying. Without the environment, this result will not be reliable.```
Turns out pact-broker CLI does not validate unknown arguments. It will happily run with anything and ignore it :smile:
```pact-broker can-i-deploy --to--disneyworld yes --and-disneyland maybe ...```
Is it worth throwing an error in those cases?
yousafn
2023-09-21 14:19
I?d prefer it error, rather than assuming in your instance despite the warning did you get a pass resulting in an exit code 0
reason being is that if it doesn?t fail, you often aren?t going to dig into the logs for further detail and this could definitely catch people out they move from can-i-deploy to record-deployment where the arg is just environment
i?d argue that although to-environment could just be replaced with environment ( or at least aliased to )
we used to can i deploy with tags and you wouldn?t say can i deploy to-tag
sorry poor formatting as on the mobile
sayantini.basak
2023-09-21 15:44
@matt.fellows I went through the links you shared with me and it gave me a good idea on how to setup CI/CD for Pact Testing in the build pipelines.
https://docs.pact.io/pact_broker/client_cli/readme - With reference to this link, I see that there are commands which we can run from the Pact CLI to publish the pacts on the Pact Broker. Don't we have anything similar for publishing provider contract or verifying the contracts from the provider if we use OSS Pact Broker ?
jonatan.bjork
2023-09-22 10:26
Also a bit confusing that `pact-broker record-deployment` takes `--environment` while `can-i-deploy` takes `--to-environment`.
But the main concern I think is silently ignoring invalid arguments. They should hard fail. Maybe difficult to do now since it is used in the wild, you would probably have to deprecate that behaviour and log warnings for the next few minor releases, and then start failling in the next major release.
matt.fellows
2023-09-24 23:45
the OSS Pact Broker doesn?t have the concept of a provider contract. I think you mean the ability to publish verification results, this is built into the verification process itself. Unlike the consumer side, it doesn?t write these results to file and then uses a CLI to publish it (perhaps it should though!).
The issue above looks like a configuration issue - the selectors don?t appear to be lining up
boer.k
2023-09-25 12:16
Heya! I'd like to create(-or-update) a webhook via the cli. According to the docs it should be possible to pass the webhook payload from a file or string. How can I specify that I want the contents to be read from a file? Right now I get the file path as raw string content :see_no_evil: Ive been looking for examples but I couldnt find anything anywhere. Currently my command is:
```pact-broker create-or-update-webhook <url> --uuid=968fcd0f-a647-4419-aeec-637ad5e5287e --request=POST --header="PRIVATE-TOKEN: \${user.GitlabAccessToken} CONTENT-TYPE: application/json" --data=/Users/Kevin/TKP/repos/upa-verlof/webhook_data.json --consumer=upa-verlof --provider=ppsadapter --contract-content-changed --team-uuid=4ac05ed8-9e3b-4159-96c0-ad19e3b93658 --broker-base-url=<broker url> -k <token>```
matt.fellows
2023-09-25 13:15
That specifies the request body that is sent in the webhook, including any parameters:
Here are a couple of examples:
? Provider build trigger: https://github.com/pactflow/example-provider/blob/master/Makefile#L86-L96
? GitHub status check: https://github.com/pactflow/example-consumer/blob/master/Makefile#L102-L113
Other templates: https://docs.pact.io/pact_broker/webhooks/template_library
boer.k
2023-09-25 13:47
Ah I just tried and I figured its the '@' that marks the value as being a file path and not the content string? I coudnt find that anywhere in the documentation.
matt.fellows
2023-09-25 23:51
That?s a good point. I?ve raised https://github.com/pact-foundation/pact_broker-client/issues/144 to track
gurubabu.jampala
2023-10-02 01:34
Thanks for your reply.
Is it feasible to check with one `can-i-deploy` command to verifiy more than one environment at a time?
I had a look into the `can-i-deploy` command, it's allowing only one with `--to-environment`.
Appreciate if you could respond.
Thank you!
alan.barker
2023-10-09 10:27
Hi,
I'm testing out the basic auth feature, using the `pactfoundation/pact-broker` docker image.
I've supplied credentials to:
`PACT_BROKER_BASIC_AUTH_USERNAME`
`PACT_BROKER_BASIC_AUTH_PASSWORD`
and I have also set `PACT_BROKER_ALLOW_PUBLIC_READ=true`
The credentials appear to work fine when making calls like: `create-or-update-pacticipant`.
But I also wanted to test what happens if we try to delete a pacticpant (or even a pact) using the pact broker API (Hal) browser. And the creds don't work.
I used the same credentials specified in the ENV vars above. Are those the creds I should be using? Or something else?
(I also tried my pact broker admin user and standard user, with no success).
There doesn't seem to be any mention of what creds to use in the documentation, when using the UI and when BASIC_AUTH variables have been supplied.
Appreciate any help and advice.
Thanks, Alan
matt.fellows
2023-10-09 23:51
> (I also tried my pact broker admin user and standard user, with no success).
what are these, exactly?
matt.fellows
2023-10-09 23:52
The Pact Broker has two sets of credentials, the ones above an the ?read-only? variants (https://docs.pact.io/pact_broker/configuration/settings#basic_auth_read_only_username)
alan.barker
2023-10-10 09:00
Apologies, I should have said postgres users, admin and "pactbrokeruser".
Credentials supplied at container start-up with Environment switches...
alan.barker
2023-10-10 09:01
`-e PACT_BROKER_BASIC_AUTH_USERNAME=pactwriter -e PACT_BROKER_BASIC_AUTH_PASSWORD=mywritepassword`
The creds do not work through the web UI.
alan.barker
2023-10-10 09:08
The full command that I am using....
```sudo docker run --name pactbroker --restart unless-stopped --link pactbroker-db:postgres -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD=TheUserPassword -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -e PACT_BROKER_BASIC_AUTH_USERNAME=pactwriter -e PACT_BROKER_BASIC_AUTH_PASSWORD=mywritepassword -e PACT_BROKER_ALLOW_PUBLIC_READ=true -d -p 9292:9292 pactfoundation/pact-broker```
alan.barker
2023-10-10 09:13
Then do something like this...[see pics]
Delete -> make request
You then get prompted for creds, try the `pactwriter` credentials.
Result, returned to the logon dialog.
Please let me know if I'm doing this incorrectly.
matt.fellows
2023-10-10 12:41
can you provide a series of CLI commands I can run to test? (the command above links a database).
I?d suggest:
1. a docker compose file I can start
2. an API call I can test from the CLI to show the problem (create pacticipant, issue `DELETE` etc.)
3. If the API call works, then a series of steps in the UI
gurubabu.jampala
2023-10-11 23:22
Hi All,
Is there a way, we can create separate credentials for provider verification and publish the results to #pact-broker?
The credentials should allow only for this specific functionality,.
I have gone through the documentation there are only two different type of credentials, one it read-only and another one is read-write.
Highly appreciate if someone answer as soon as possible.
Thanks!
bethskurrie
2023-10-11 23:23
Hi @gurubabu.jampala, the OSS pact broker only has the 2 sets of credentials that you see in the docs. You can try http://pactflow.io if you want teams/permissions/user management.
gurubabu.jampala
2023-10-11 23:31
I just checked pact-cli command is accepting BROKER_TOKEN. What is the token in the OSS pact broker? Is it something which we can provide in pact broker config similarly like basic authentication?
#pact-broker
matt.fellows
2023-10-12 02:22
> What is the token in the OSS pact broker?
this is for brokers protpected by bearer token auth. At the moment, only Pactflow supports this
ben.brugman
2023-10-12 12:49
Hi All,
There are some vulnerabilities in the Pact Broker image due to Supercronic.
Supercronic is already working on a upgrading their GO version. https://github.com/aptible/supercronic/pull/138
Do you at Pact have this on your radar and will you update to the new version of supercronic for the broker image?
https://github.com/pact-foundation/pact-broker-docker/blob/master/Dockerfile (line 22 - 28)
yousafn
2023-10-12 13:43
Hey, I?d not had that on my radar (been pretty choco with Pactober), but we do update and accept contributions to update the supercronic version, you can check some previous PR?s
I note that its on v0.2.24 and v0.2.26 is out - so we could update it now in the interim.
Would you be happy to raise a PR?
matt.fellows
2023-10-13 03:35
2023-10-13 05:55
This channel will receive notifications from https://github.com/pact-foundation/pact_broker for: `pulls`, `releases`, `deployments`
2023-10-13 05:55
This channel will receive notifications from https://github.com/pact-foundation/pact_broker for: `releases`, `deployments`
2023-10-13 05:55
This channel will receive notifications from https://github.com/pact-foundation/pact-broker-docker for: `pulls`, `releases`, `deployments`
2023-10-13 05:55
This channel will receive notifications from https://github.com/pact-foundation/pact_broker for: `releases`, `deployments`
2023-10-13 05:55
This channel will receive notifications from https://github.com/pact-foundation/pact-broker-docker for: `pulls`, `releases`, `deployments`
2023-10-13 05:56
This channel will receive notifications from https://github.com/pact-foundation/pact-broker-docker for: `releases`, `deployments`
bethskurrie
2023-10-13 06:10
@jonatan.bjork the option is called `--to-environment` because before we had support for environments, we used tags, and the syntax was `--to TAG`
boer.k
2023-10-13 07:24
Ah, so the @ was inherited from curl? Yes I think this help text will help a lot for those who didnt know (me :smile:)
bethskurrie
2023-10-13 09:16
Also, PR for raising errors on unknown options https://github.com/pact-foundation/pact_broker-client/pull/147
chrisjburnscg
2023-10-13 09:35
Seems he solved his problem via the Chart repo to an internal proxy :+1:
cmuddam.testing
2023-10-16 05:15
Good afternoon. This is Chandra.
I am working on a POC to implement the http based pact tests using pactnet 4.x. I am using Teamcity for CI pipelines and pactflow pact broker (trial version) to implement 'Contract published that requires verification' webhook event. The webhook event is getting fired when a changed contract file is published and in turn triggering the provider build on Teamcity. I want to pass the '${pactbroker.pactUrl}' in pactflow pact broker to provider build pipeline on Teamcity. As we need this in provider verification tests to verify the specific changed contract file and publish the results back to pact broker. Can someone please help me with this ?
Screenshots for the webhook event and the provider builds:
cmuddam.testing
2023-10-16 05:19
Not sure if I need to post this question in #pactflow or #pact-net channel
cmuddam.testing
2023-10-16 05:54
I am following the steps Yousaf Nabi has prepared for pact CICD workshop for pactnet. I could not understand how pactUrl variable has '${pactbroker.pactUrl}' value. Below are the screenshots I am trying to understand.
matt.fellows
2023-10-16 06:13
You?ll need to add `${pactbroker.pactUrl}` to the body of the webhook. This will make the value available to teamcity when the build triggers. You then need to extract that value out of the payload from Team city (it looks like you?ve copied this already: https://docs.pact.io/pact_broker/webhooks/template_library#teamcity---trigger-build). So my guess is that `env.<blah>` will generate environment variables for team city.
So, something like this should do it:
``` {
"name": "env.pactUrl",
"value": "${pactbroker.pactUrl}"
}```
And then from your .NET code, it won?t be `PACT_URL` it will be `pactUrl`
matt.fellows
2023-10-16 06:13
e.g.
``` {
"name": "env.PACT_URL",
"value": "${pactbroker.pactUrl}"
}```
matt.fellows
2023-10-16 06:15
> Not sure if I need to post this question in #pactflow or #pact-net channel (edited)
it?s a tricky question - it cuts all of these channels. Here is fine, I think
cmuddam.testing
2023-10-16 06:30
Quick question, how to extract the value out of the payload from Team city ? I am from QA background (not good with the technology :blush:)
matt.fellows
2023-10-16 06:42
As per above, each property passed through in the body will appear as an environment variable to the teamcity build - nothing to do in teamcity, you just need to map the env vars here to the verification code in Pact .NET
ben.brugman
2023-10-16 08:32
Hi, tnx for the reply, by the looks of it you created a PR yourself already, i left a comment. :pray:
cmuddam.testing
2023-10-16 11:20
Thanks Matt, it works fine if I create a parameter (env variable) in teamcity with empty value..
alan.barker
2023-10-18 14:23
Hi.
Sorry for the delay on this. Work is very busy.
I am not using Docker Compose (at the moment) to run this test.
It was a simple local setup, created by running the *Running Postgresql via Docker* (from here: https://github.com/pact-foundation/pact-broker-docker/blob/master/POSTGRESQL.md#running-postgresql-via-docker )
At step 3. in the steps above, I adapted the command to run the Pactbroker to this:-
```sudo docker run --name pactbroker --restart unless-stopped --link pactbroker-db:postgres -e PACT_BROKER_DATABASE_USERNAME=pactbrokeruser -e PACT_BROKER_DATABASE_PASSWORD=TheUserPassword -e PACT_BROKER_DATABASE_HOST=postgres -e PACT_BROKER_DATABASE_NAME=pactbroker -e PACT_BROKER_BASIC_AUTH_USERNAME=pactwriter -e PACT_BROKER_BASIC_AUTH_PASSWORD=mywritepassword -e PACT_BROKER_ALLOW_PUBLIC_READ=true -d -p 9292:9292 pactfoundation/pact-broker```
As you can see a very simple setup.
I've not performed any direct API calls.
I've tested by calling `docker run --rm pactfoundation/pact-cli pact-broker...` type commands. *Which are successful when supplying the credentials.*
So for example I used the type of command above to create a dummy pacticipant.
Then using the UI, I went to the pacticipant that I had just created, and performed a Non-Get request (see pic).
You then get prompted for credentials, and authentication seems fail (no error shown). You just get returned to the credentials prompt.
ben.brugman
2023-10-19 15:15
Hi, I made a commit and tried to push it to your branch, but i think i don't have permissions
yousafn
2023-10-19 15:20
Hey, you won?t be able to, as you are a member of the organisation, feel free just to drop it on a PR
yousafn
2023-10-19 16:01
sorry that should say aren?t* - I can?t edit now, and I was replying just before dropping into a meeting
fnguyen
2023-10-24 18:31
When we PUT the pact to with a powershell script, we set the uri as
```$version = 1.0.0.0
$buildId = $(Build.BuildId) # e.g. 12345
$uri = "$brokerUri/pacts/provider/$provider/consumer/$consumer/version/$version_$buildId" ```
I was expecting the version to be 1.0.0.0_12345 but in the broker the consumer version is shown only as 12345.
At https://docs.pact.io/pact_broker/pacticipant_version_numbers i read
> When publishing a pact or a verification, the resource is associated with a particular version of the pacticipant (application), which is identified by a version number. Just to make it very clear - the version number that is specified in the URL of a pact or a verification is *the _application version number_, not the pact version*. Pact versioning is done for you behind the scenes by the Broker, and is based on the content of the pact.
How do I set the pact version? I don't see any version reference in my c# source using PACT.V3 (I know i need to upgrade to V4)
Thanks
matt.fellows
2023-10-25 09:41
Remember you're never setting a pact version, you're always setting a version of the pacticipant
matt.fellows
2023-10-25 09:42
I suspect an issue with your script, the version can definitely include those characters
matt.fellows
2023-10-25 09:42
I'd highly recommend using the CLI: https://docs.pact.io/implementation_guides/cli#distributions
fnguyen
2023-10-25 17:51
Thanks Matt.
It happens in my azure pipeline. I see the parameters versions and buildId being passed correctly.
I need to upgrade to the cli instead of the CRUD api (also need to upgrade to V4)
As soon as i have some spare cycles, i'll take care of it.
manalikhanna92
2023-10-26 07:12
Hi! I am trying to run pact broker at a different context-path other than / and trying that using below nginx conf
`server {`
`listen 80 default_server;`
`server_name localhost:9292;`
`location / {`
`rewrite ^(.*)$ /pact$request_uri permanent;`
`}`
`location /pact {`
`proxy_pass http://localhost:9292;`
`proxy_set_header Host $host;`
`proxy_set_header X-Real-IP $remote_addr;`
`proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;`
`}`
`}`
Even after mutiple tries, its showing up the broker page on / and /pact is giving a 404. Do I need to change any other configs to configure the web server?
matt.fellows
2023-10-26 07:29
hmm it?s been a while since I?ve looked - have you set a base URL: https://docs.pact.io/pact_broker/configuration/features#when-the-base-url-configuration-is-supported-v2460-and-later
manalikhanna92
2023-10-26 09:35
As per the docs, `It is also required when deploying the Broker behind a reverse proxy, and when the application has been mounted at a non-root context. Note that this attribute does not change where the application is actually mounted (that is the concern of the deployment configuration) - it just changes the links.`
How do we change the dpeloyment to run as non-root context?
btacca
2023-10-26 13:39
Hello! I am trying to understand how the environment is set for the pacts published in the broker (I'm using pactflow).
Is it through `record-deployment`?
yousafn
2023-10-26 13:58
hey, via recording releases or deployments, environments can be created beforehand. By default prod and test exist (at least in PactFlow)
https://docs.pact.io/pact_broker/recording_deployments_and_releases#environments
yousafn
2023-10-26 14:00
What does your pact broker configuration look like?
Can you provide a public sample? This looks like its not too far removed from the pact-broker-docker nginx sample in the repo so that would be a good starter from which to create a repro
ms.maheshhwari
2023-10-26 14:20
Hi@yousafn This is the docker-compose file we are using to build the services.
```version: "3"
services:
postgres:
image: postgres
healthcheck:
test: psql postgres --command "select 1" -U postgres
volumes:
- postgres-volume:/var/lib/postgresql/data
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: password
POSTGRES_DB: postgres
pact-broker:
image: "pactfoundation/pact-broker:2.113.0-pactbroker2.107.1"
ports:
- "9292:9292"
depends_on:
- postgres
environment:
PACT_BROKER_PORT: '9292'
PACT_BROKER_DATABASE_URL: ""
PACT_BROKER_LOG_LEVEL: DEBUG
PACT_BROKER_SQL_LOG_LEVEL: DEBUG
PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "5"
PACT_BROKER_BASE_URL: 'http://localhost:9292/pact'
pactbroker.base_url: 'http://localhost:9292/pact'
# Nginx is not necessary, but demonstrates how
# one might use a reverse proxy in front of the broker,
# and includes the use of a self-signed TLS certificate
nginx:
image: nginx:alpine
depends_on:
- pact-broker
volumes:
- ./ssl/nginx.conf:/etc/nginx/conf.d/default.conf:ro
- ./ssl:/etc/nginx/ssl
ports:
- "443:443"
- "80:80"
volumes:
postgres-volume:```
cc: @manalikhanna92
btacca
2023-10-26 14:35
I see, so when I publish a contract, the environment is not set yet... like this:
alan.barker
2023-10-26 14:41
Hello again.
Can anyone describe how the "for-verification" list gets produced for a registered pacticipant.
e.g. url. https:///pacts/provider//for-verification
What we are seeing is, this list is missing certain consumers.
Our consumer selectors are ONLY querying `mainBranch: true`
Our consumer microservices mainBranch are set to `main` . There is a contract for the version on main.
Yet the "for-verification" list is missing microservice(s).
In the broker UI, the consumer is listed along with its providers.
However, a query of "latest version from branch..." `main` returns no results.
So we are a bit confused.
Thanks for any help.
PS: The only way I've been able to resolve this issue, is to delete the consumer pacticipant completely from the broker, and run the CI pipelines again.
yousafn
2023-10-26 17:16
correct, you publish with a version, and optionally branch or tag. you record a release/deployment as an additional step (after having verified contracts, and having called can-i-deploy for the version to that environment, which returns a success )
btacca
2023-10-26 17:36
@yousafn thanks... I think I got it now, the correct order of the processes were not clear to me.
In my mind, please let me know if I am completely wrong...
1. Consumer publishers a contract (no env)
2. Provider make some changes and verify the contract (no env)
a. Here, both can-i-deploy (no env) are valid.
b. For the ProviderProducer, can-i-deploy for env `test` and `production` are *OK*.
c. For the Consumer, can-i-deploy for env `test` and `production` are *NOT OK*.
3. Then the Provider deploys to `test` and after the completed deployment, a `record-deployment` is sent to the broker with `--environment test`. The pact now has the Environment `Test` marked on it (provider side).
4. Now, for the Consumer, can-i-deploy for env `test` is *OK*.
5. Consumer can deploy, and send a `record-deployment` too, it marks the Environment `Test` on the pact (consumer side)
Same stuff for Prod...
After deploying in Prod, will it mark `Test` and `Prod` ? Or will just be replaced with `Prod` ?
Thanks.
matt.fellows
2023-10-26 22:01
I don?t think the base URL is right either. It?s what the URL should look like to the user, in your case it would be `http://localhost/pact` (if port 80) or `https://localhost/pact` for TLS
matt.fellows
2023-10-26 22:01
It looks like the nginx setup is probably to blame. it?s at nginx where you would setup the context path
gurubabu.jampala
2023-10-27 03:29
Hi All,
Quick question: `contract_requiring_verification_published` event will trigger when consumer publish contract for the first time?
As per the documentation, the event would get triggered when consumer publishing the contract for the first time, but when I am publishing I can see only two events are triggering, which are `contract_published`, `contract_content_changed (first time untagged pact published).`
Can some please help me what I might have missed in my consumer service configuration?
*Note*: _If provider already verified with `main branch` or `deployed/released` then the `contract_requiring_verification_published` event is getting triggered._
Here are the documentation links which I was referring:
https://docs.pact.io/blog/2021/10/11/contract-requiring-verification-published-webhook-event
https://docs.pact.io/pact_nirvana/notes_1
#pact-broker
manalikhanna92
2023-10-27 06:19
@matt.fellows Yes we need the context path since we are using path based routing from our Ingress in the deployment process
manalikhanna92
2023-10-27 06:20
@matt.fellows Do you see anything that we are missing in nginx conf file?
matt.fellows
2023-10-27 08:43
> Do you see anything that we are missing in nginx conf file?
this is really an nginx question, it?s been a while and I can?t recall the syntax for doing so
yousafn
2023-10-27 16:53
1. Consumer publishers a contract (no env) :white_check_mark: (Ideally with a _branch_ and always an application version, ideally git sha)
2. Provider make some changes and verify the contract (no env)
a. Here, both can-i-deploy (no env) are valid. :warning: - I wouldn?t do can-i-deploy with no environment, you could use can-i-merge (to main line) - if you don?t have envs setup yet.
b. For the ProviderProducer, can-i-deploy for env `test` and `production` are *OK*. :white_check_mark: - provider can deploy to any env if they aren?t reliant on any consumers. no consumers currently in test or prod, so its ok.
c. For the Consumer, can-i-deploy for env `test` and `production` are *NOT OK*. :white_check_mark: - correct, the provider is not deployed to production, so even if the contract is valid with the providers main branch, its not got any deployed versions
3. Then the Provider deploys to `test` and after the completed deployment, a `record-deployment` is sent to the broker with `--environment test`. The pact now has the Environment `Test` marked on it (provider side). :white_check_mark:
4. Now, for the Consumer, can-i-deploy for env `test` is *OK*. :white_check_mark:
5. Consumer can deploy, and send a `record-deployment` too, it marks the Environment `Test` on the pact (consumer side) :white_check_mark:
Same stuff for Prod...
After deploying in Prod, will it mark `Test` and `Prod` ? Or will just be replaced with `Prod` ? :question: - A provider may not mirror the same environments as the consumer. This is OK, Pact Broker will keep track of the environments associated consumers and providers exist in.
:msn-lightbulb: In your scenario, in step 3, the provider version is already marked as deployed into `Test` and therefore if you are just deployed to prod, you would `record-deployment` is sent to the broker with `--environment prod`
There would be no harm in re-recording the same version into test
benguizat
2023-10-30 09:34
Hi All,
is there a way to install pact-broker in k8s with HELM and configure it to skip the ingress installation ?
matt.fellows
2023-10-30 09:43
I?m not a helm expert (or even novice), but I suppose if you have your own approach to all of this could you fork/customise the helm chart we have contributed?
benguizat
2023-10-30 09:48
https://github.com/pact-foundation/pact-broker-chart/blob/master/charts/pact-broker/values.yaml#L410C5-L410C6 well thanks for pointing me to the correct answer :stuck_out_tongue:
alan.barker
2023-10-31 15:44
@matt.fellows
Hi.
Just wondered if you'd managed to find some time to reproduce this?
Could really do with your advice. I *really* need to lock our broker down, as some individuals are mistakenly pushing to the central broker, rather than their "local test" broker instance.
I feel it could be causing problems.
Many Thanks
james.corry
2023-11-01 19:45
Hello :slightly_smiling_face:,
Hopefully just a quick question. Can a PactBroker communicate on a private network via private endpoints? At my company, we're exploring pact broker connectivity. If we set the web app to public we can access the pact broker, however setting it to private returns a forbidden response.
Is there any app config settings we need to be aware of for network connectivity? We've followed the pact docs to spin a pact broker up.
My ops team have looked at the network side of things and cannot see any firewall or other network issues.
So we're a bit confused and are looking for guidance to help move things along :slightly_smiling_face:.
Any help would be greatly appreciated and thank you for your support! :slightly_smiling_face:
matt.fellows
2023-11-01 21:02
Yes, it should be able to work on a private network, there is nothing special it does. It?s a stock-standard REST API
> If we set the web app to public we can access the pact broker, however setting it to private returns a forbidden response.
Do you mean something like a public subnet for the application and a private subnet for the database?
Ultimately, it?s just network routing.
james.corry
2023-11-01 21:40
Thank you for the quick reply! That's good to know thank you!
If we set the pact broker to communicate via a public address we can browse and login successfully and we get a pact broker landing page.
If we access the pact broker URL within a private network e.g. not accessible to the outside world. We can browse to it and enter login details, then we receive a forbidden response.
I'll go back to my ops team if its the network and investigate.
My ops team wanted to validate if there's a app config setting we need to be aware off to access the pact broker via a private network?
Thanks again for the help and your patience Matt! :grinning:
matt.fellows
2023-11-01 22:47
If you had a screenshare/logs to share, that might help with some pointers. Sometimes there are proxies and things that mess with URLs
matt.fellows
2023-11-01 22:48
Worth reading https://docs.pact.io/pact_broker/configuration/features#running-the-broker-behind-a-reverse-proxy and the section ?When the base URL configuration is supported (v2.46.0 and later)? below
bethskurrie
2023-11-02 04:30
I have a proposal for simplifying WIP pacts that I'd appreciate feedback on https://github.com/pact-foundation/pact_broker/discussions/640
james.corry
2023-11-02 09:30
Worth mentioning that we have a server on the same subnet and are still getting the same issue. We've set the recommendation up and still getting the same response so are experimenting with a few things too. Will DM you a screenshot Matt from one of our logs.
abubics
2023-11-03 07:12
This sounds great! But, since I haven't gotten to really use any of those features, I don't think I have feedback :cry:
siyuanshen1993
2023-11-08 04:25
Hi! I got some question about the CICD of pact broker, according to docs:
The consumer CI build generates the pacts during execution of its isolated tests, and then publishes the generated pacts.
The provider CI retrieves the pacts, performs the verification locally, and then publishes the verification results back to the broker.
Does this means the consumer CI needs to notice provider CI that the pact is generated please verify it? Does it like event-bridge structure or something else?
matt.fellows
2023-11-08 05:27
If you want to setup build verification automation. Regular provider builds just point at the broker and dynamically discover pacts
yanov.alexander
2023-11-09 09:33
Hello team, I am getting an issue that in one validation some of contracts published successfully and some of them can?t be published and response status is 403. I am confused because it?s in one service and there is no difference in the configuration. Have anyone experience same issues and have a resolution?
jmvb.registros
2023-11-09 20:16
Hi folks, I'm trying to install pack-broker via helm chart with minikube from https://github.com/pact-foundation/pact-broker-chart/tree/master/charts/pact-broker but I can see some errors in the pact broker pod
```? /pact_broker/vendor/bundle/ruby/3.2.0/gems/pg-1.5.3/lib/pg/connection.rb:696:in `async_connect_or_reset': connection to server at "10.111.189.45", port 5432 failed: Connection refused (PG::ConnectionBad) ?
? Is the server running on that host and accepting TCP/IP connections?```
Then, I can also see that the `pact-broker-postgresql` fails with the following error message
```2023-11-09 20:10:56.490 GMT [141] FATAL: password authentication failed for user "bn_broker" ?
? 2023-11-09 20:10:56.490 GMT [141] DETAIL: Connection matched pg_hba.conf line 1: "host all all 0.0.0.0/0 md5":```
I've checked the README.md and try with both approaches but with no luck
? https://github.com/pact-foundation/pact-broker-chart/tree/master/charts/pact-broker#automatic-database-credential-creation
? https://github.com/pact-foundation/pact-broker-chart/tree/master/charts/pact-broker#specifying-password-for-postgresql-to-use
matt.fellows
2023-11-09 22:22
Looks pretty clear to me, the pact broker image has the wrong credentials. It?s trying to auth with username `bn_broker` but has the wrong password
alan.barker
2023-11-10 17:51
Hi.
When browsing to `http://yourbroker/integrations` the page displays a Response Body that appears to be JSON.
However, when I `curl` to this url, the response I get back was surprising. Its formatted plaintext. Graphviz?
Is there any way of getting this back in JSON format?
It would be much better for scripting, if it was JSON.
Thanks
yousafn
2023-11-10 18:15
that doesn?t work, the response isn?t json, its graphviz for displaying in the network diagram
yousafn
2023-11-10 18:18
You can access the list of integrations by interacting with the HAL api which returns a json response
yousafn
2023-11-10 18:22
Matt did a post on using the graphviz results https://pactflow.io/blog/diagrams-with-graphviz/ as an fyi but yeah using the HAL api gives you access to a tonne and is returned in json with links clients can follow
ulises.cervino
2023-11-12 10:51
is there a way to see which version is rolled out to which environment? I can?t seem to figure it out. I?ve played with `describe-environment` `describe-pacticipant` and `describe-version` and none seem to have the info I need. I?d love to see a table like
```| Version | Environment |
| UUID | ENV1 |
...```
matt.fellows
2023-11-13 01:19
I think a version of https://pact.canny.io/feature-requests/p/get-latest-provider-version-for-a-specific-environment is what you?re after.
It would be good to have this though, if you could please vote on the issue (and add your feedback) that would help us prioritise
matt.fellows
2023-11-13 01:19
We could probably give you some pointers also if you?re up for adding it to the CLI
matt.fellows
2023-11-13 01:24
ah, right. That I can?t answer sorry, but hopefully it helps you chase it down
2023-11-14 11:29
This message was deleted.
matt.fellows
2023-11-14 11:33
Did you forget to use the `Authorization: Bearer <token>` format in the header?
roger.liu
2023-11-15 07:14
Would there be an issue if we somehow published verification results of an earlier provider version later than the latest provider version? E.g. someone manually reran a failed CI/CD step in an earlier build and published the verification results along with it. Pact broker would treat this as "latest" even though it's not your latest software version.
matt.fellows
2023-11-15 07:19
I don?t think so, ordering is based on the creation date of the _version:_ https://docs.pact.io/getting_started/versioning_in_the_pact_broker#version-ordering
matt.fellows
2023-11-15 07:19
Are you using `--latest` in your `can-i-deploy` checks? If so, you should stop that :stuck_out_tongue:
roger.liu
2023-11-15 07:44
What about on the consumer side? Order is based on the creation date of the version resource - to clarify, that's whenever a pact gets published to pact broker right?
I was thinking along the lines of verification using consumer version selectors. E.g. { "mainBranch": true } gives you latest version of consumer main branch. If consumers somehow published an earlier build later than the latest build, would it be a problem?
roger.liu
2023-11-15 07:49
Nvm I just tested. When I use consumer version selector for { "mainBranch": true }, it verifies against all versions of the main branch, not just the latest.
matt.fellows
2023-11-15 09:49
I think it would just verify the latest version for the main branch (otherwise each time you run the verification it could in theory, verify every consumer version ever marked as the main branch)
alan.barker
2023-11-15 10:43
Hi. I got to the bottom of this. There must have been something wrong with the password I'd set.
So, must have been my error.
But thanks for your time and help.
matt.fellows
2023-11-15 10:50
browsers do funny things with basic auth, as far as I can tell, there is little visibility into it also
roger.liu
2023-11-16 00:51
Ok, I checked the debug logs. It does indeed verify against the latest main branch of consumer. The verification is done for a pact content version that the consumer is using. So if verification is successful for that pact content version. All the other consumer versions that is using the same pact-version would be automatically verified is what I'm seeing in the matrix.
Coming back to the question of if this could have an affect if we accidentally published an earlier consumer software version to pact broker at a later date than the latest consumer software version - I guess the worst that it can do is either failing the provider build if the provider no longer supports this earlier pact version, or later provider versions not verifying against the latest consumer software version. I guess it should be transparent enough to fix manually?
matt.fellows
2023-11-16 06:23
> All the other consumer versions that is using the same pact-version would be automatically verified is what I?m seeing in the matrix.
correct, the pact contents is versioned independently of the application version. So if the contents are the same, any verification also applies to them
matt.fellows
2023-11-16 06:27
> Coming back to the question of if this could have an affect if we accidentally published an earlier consumer software version to pact broker at a later date than the latest consumer software version - I guess the worst that it can do is either failing the provider build if the provider no longer supports this earlier pact version, or later provider versions not verifying against the latest consumer software version. I guess it should be transparent enough to fix manually? (edited)
Yeah I think so. If you re-run an old build of a consumer version where (for some reason) the provider hasn?t verified that before (i.e. triggers the `contract_requiring_verification_published` https://docs.pact.io/pact_broker/webhooks#events) then it might fail a webhook build, but wouldn?t be the latest for the branch (so the main build wouldn?t fail. It wouldn?t fail `can-i-deploy` either if you?re deploying to an environment, because presumably it also isn?t in the target environment.
The resolution in most cases anyway, is to simply re-run the build for the latest version.
jmvb.registros
2023-11-17 12:18
Hi there, I'm reading about using an external database and I came across this section
```Specify Credentials via Secret
Configure the Pact Broker to use an existing Secret to retrieve the user password as a means to connect to the database. Ensure that the Kubernetes Secret has the password in the user-password field and ensure that you have set externalDatabase.config.auth.existingSecret value to the name of the secret. To configure the username, you can use the username value.```
In my situation, I'm provided with a secret that contains the encoded db password among other db details. The issue is that the field doesn't match `user-password` and unfortunately it cannot be changed as it's used across different areas.
Is there any way I can map the field name to the required one so that I can use the right external db configuration?
ulises.cervino
2023-11-21 11:31
is it possible to ignore missing verifications during `can-i-deploy` to a given environment? we have a provider that?s rolled out (recorded) to our integration environment but not production, and as a result it?s blocking our production rollouts (even if we don?t use the provider --yet-- in production)
jmvb.registros
2023-12-02 20:18
I'm facing some issues when using cockroach DB as a postgresql solution when running the migrations scripts as the word order is a keyword in SQL. Is there any plans to support cockroachDB or ideas on how to overcome this?
alan.barker
2023-12-06 15:59
Hi. Just coming back to this one.
Also regarding the `main` branch above in the broker UI, if you hover the pointer over the `branch: main` label (which is a grey colour, not black) we see the message: (see pic)
But...there isn't a later version on this branch. Or certainly not that we can see or find.
Any ideas?
ajay991610
2023-12-07 05:34
:wave: Hello, team!
I am trying to set the webhook for the event `contract_requiring_verification_published` . We have the provider with three environments `qa, uat and prod` and the versions are recorded with respective environments. Now when I publish the pact, will the event be triggered for all three environments with `${pactbroker.providerVersionNumber}` variable set automatically ?
ajay991610
2023-12-07 08:16
Cool. I assume the `pactbroker.providerVersionBranch` is associated with the version that needs to be verified. Let's say I have a provider version `abc` that is in all three environment and the branch associated with `abc` will be master, RELEASE and HOTFIX.
Will it trigger the event for the version `abc` and all three branches ?
nathaniel.emmons
2023-12-08 14:28
Is it safe to run two instances of the Pact-Broker in parallel, pointing to the same database? That is, does the running application hold onto any state that would create race conditions or weird behavior if i?m load-balancing across two nodes (or, in my intended use case, migrating from one cloud environment to another and trying to avoid downtime)
phillip.lo
2023-12-15 20:07
I didn't see it in the docs but does the pact broker support authenticating to github using github apps or do we have to create a token for those calls
james.corry
2023-12-16 13:08
Hello,
Just wanted to say thanks again for the assistance Matt. We have resolved the configuration issue. The documentation you pointed us to helped us along the way so thanks again :+1::smiley:
pavikrish
2023-12-18 09:35
Hi team, We are using pact broker and are publishing pact in the PR validation pipeline. If there happens to be large number of commits to the PR, the number of records in pact matrix will also increase. Would like to understand if we need to follow any purge process for the pact broker to withstand the load.
matt.fellows
2023-12-18 21:55
You should enable data cleaning as a general rule, yes. See https://docs.pact.io/pact_broker/administration/maintenance
anthony.trad
2023-12-19 17:07
Hi team,
I?m new here and wanted to validate my upcoming setup for the PACT broker on AWS and can-i-deploy on GH Actions and Octopus deploy. I?ll list my questions and reasoning in a :thread: and would appreciate any insights you guys have. Thanks a lot!
anthony.trad
2023-12-19 17:09
? Is there any recommended limit of how many pacts one instance can handle? Multiple instances on the same database is feasible with no issues from reading the questions above.
? Assuming the CI pushes the generated PACTs naively on each opened PR. How will the pact-broker behave when multiple PRs are raised in parallel on the same consumers. Having race conditions where all PRs are overrided with the latest one would be an issue? Would the matrix be mistagged in that case? People would need to retry each PR maybe? If that?s an issue, how do you usually mitigate this?
? Loving consumer driven contracts, but small caviant I want to discuss: Since the provider verification tests run independently on the provider CI, writing a ?bad pact? may result in a unesessary back and forth between people, especially if the provider is not ?owned? by the same people working on the consumer. A clever hack I just thought of is to leverage the broker webhooks to run the Provider tests on the consumer CI as well. That ensures that a PR is merged only if this back and forth is resolved. Is there any downside i?m not seeing here? Is it common to do what I mentioned?
? Regarding the deployments and environments, having multiple instances of the same version in different environments don?t need us to use the application instances flag right? Even if deployments are done on a rolling migration where you have canary/blue-green (instances with different versions temporarily). Ofc as long as we ask can-i-deploy before deploying and record a deployment once that?s done. The unique combination is service-enviornment-version, Anything missing here?
? I?m tagging main with the application version (X.X.X.X) that I?m pushing to Octopus, I saw that the broker version PACTs differently, any way I can link both versions to know what version is on what environment?
? Added my overall design flow, would appreciate any feedback and potential caveats I am missing here!
matt.fellows
2023-12-20 04:56
> ? Is there any recommended limit of how many pacts one instance can handle? Multiple instances on the same database is feasible with no issues from reading the questions above.
logically, no, but there probably is an upper end. We haven?t seen any customers of PactFlow (which uses essentially the same underlying schema) hit that limit yet
matt.fellows
2023-12-20 04:58
> ? Assuming the CI pushes the generated PACTs naively on each opened PR. How will the pact-broker behave when multiple PRs are raised in parallel on the same consumers. Having race conditions where all PRs are overrided with the latest one would be an issue? Would the matrix be mistagged in that case? People would need to retry each PR maybe? If that?s an issue, how do you usually mitigate this?
This is where using ?latest? is not ideal. Race conditions aplenty. You should use the branches and environments tagging to properly disambiguate.
TL;DR - each pact should publish the Git SHA as its version, the branch it?s associated with, and `record-deployment` when an app deploys. This usually sorts out most issues.
matt.fellows
2023-12-20 05:26
> ? Loving consumer driven contracts, but small caviant I want to discuss: Since the provider verification tests run independently on the provider CI, writing a ?bad pact? may result in a unesessary back and forth between people, especially if the provider is not ?owned? by the same people working on the consumer. A clever hack I just thought of is to leverage the broker webhooks to run the Provider tests on the consumer CI as well. That ensures that a PR is merged only if this back and forth is resolved. Is there any downside i?m not seeing here? Is it common to do what I mentioned?
Can you elaborate on this? I?m not sure I fully understand the workflow.
In case it?s not obvious (it is hard to find in the docs) but if you publish the same pact twice, the second pact won?t need to be re-verified - it?s ?pre-verified?.
e.g. version 1 of the application publishes a pact, is then verified by the provider. Then you make some change to the application that doesn?t result in a contract modification, then than contract is pre-verified.
Similarly, webhooks that fire are de-duplicated, to avoid multiple wasted builds.
matt.fellows
2023-12-20 05:27
You could also
1. Enable the webhook for the provider build, so when the pact is published the provider is verified
2. Then in your pipeline, run `can-i-deploy` with the `--wait-*` flags. This way, you can wait up to some configurable amount of time before failing the build if the result is false
matt.fellows
2023-12-20 05:28
> ? Regarding the deployments and environments, having multiple instances of the same version in different environments don?t need us to use the application instances flag right? Even if deployments are done on a rolling migration where you have canary/blue-green (instances with different versions temporarily). Ofc as long as we ask can-i-deploy before deploying and record a deployment once that?s done. The unique combination is service-enviornment-version, Anything missing here?
that?s correct
matt.fellows
2023-12-20 05:29
> ? I?m tagging main with the application version (X.X.X.X) that I?m pushing to Octopus, I saw that the broker version PACTs differently, any way I can link both versions to know what version is on what environment?
I think you?re asking can Pact Broker also store the underling SCM version, separate to the version we use? At the moment, no.
One strategy is to include the git sha in the metadata of a semver version, that kind of gives you the best of both worlds. Not sure if that works in the X.X.X.X model though?
anthony.trad
2023-12-20 10:43
Thanks Matt for taking the time to reply!
I?ll elaborate on 3 with an example. Service A calls service B each one living in a different team or org. Service A (consumer) will push the pacts from the Consumer CI to the broker. Broker will PACT verify on the main of Service B (Provider CI). But that pact verification is *asynchronous* which means.
Say i?m creating a pact from scratch, as a consumer, my CI would be green even if the Provider verification failed (unless I?m missing something here) since it?s done by the broker on another CI.
So Service A can still merge changes since it?s all green on their side. It decouples fully consumers and providers. What I was planning to do is use the pact broker webhooks to report the Provider Pact verification result on the Consumer CI (after it had run on the Provider CI).
Does that explains it? I might be making a wrong assumption somewhere and don?t need this
anthony.trad
2023-12-20 11:41
> This is where using ?latest? is not ideal. Race conditions aplenty. You should use the branches and environments tagging to properly disambiguate.
>
> TL;DR - each pact should publish the Git SHA as its version, the branch it?s associated with, and `record-deployment` when an app deploys. This usually sorts out most issues.
Makes sense, so what the consumer/provider defines as a version is used to provide uniqueness. Git SHA is unique so it prevents any collisions in any case.
My followup question would be doesn?t that infer a lot of cleanup afterwards or load on the broker? Each commit on a given PR modifying a PACT will be treated as a unique application version and all those will be pointing the the internal pact version.
If the above is true, would something like `main_SHA-BranchName` as application version let:
? Each PR raised being unique
? While letting things get overriden on the same branch (since we only care about the last version)
Or do you see potential race conditions or issues with this?
matt.fellows
2023-12-20 12:00
You don?t need to add the branch name to the version itself, as it?s modelled as a first class attribute in the broker
matt.fellows
2023-12-20 12:01
> Makes sense, so what the consumer/provider defines as a version is used to provide uniqueness. Git SHA is unique so it prevents any collisions in any case.
yep!
matt.fellows
2023-12-20 12:02
> My followup question would be doesn?t that infer a lot of cleanup afterwards or load on the broker? Each commit on a given PR modifying a PACT will be treated as a unique application version and all those will be pointing the the internal pact version.
Sort of. There is a cleanup process you can enable to take care of that: https://docs.pact.io/pact_broker/administration/maintenance
sharathkonda
2024-01-04 01:37
Hi Team,
Happy New Year 2024!
I am planning to migrate the latest pact-broker from the 2-year-old pact-broker. Currently, I deployed with db_migration set to false but connected to the earlier db.
If I set the db_migration to true, then the latest pact-broker will update the database.
My question:
1. Does the old deployed pact broker work with the latest migrated database?
2. Will the latest pact broker migrate the 2-year-old db and successfully deploy the application to be used?
markkellett
2024-01-04 18:30
Hi Team
I am interested in the bi-directional testing. However am confused about the verification-results. It appears that they are needed alongside the openapi specs, however it isn't clear what format (if any) they need to be in?
bas
2024-01-04 18:45
As far as I know they can literally be anything, but most commonly they?ll include provider-side test results as additional proof of due diligence. They won?t contain contract verification results as those are generated by Pactflow after the contract is published. I?ll admit the name is a tad confusing :)
bas
2024-01-04 18:46
I?m still using the example I?ve given here: https://www.ontestautomation.com/an-introduction-to-contract-testing-part-6-bi-directional-contracts/ and so far Pactflow has never complained.
markkellett
2024-01-05 09:11
ah ok thanks.
One more question. Versioning? say if we had an API which was versioned on the route? such as `v1/` and `v2/` would that be separate contracts or would you be able to have two versions of the same contract in prod?
markkellett
2024-01-05 10:11
Is there a dockerfile / docker compose for the broker which supports apple silicon?
bas
2024-01-05 16:32
A contract is connected to a version of an API. That could be anything from a major version like your example to a specific commit in a code base and anything in between.
matt.fellows
2024-01-07 22:34
Looks like it was added as a multi here: https://github.com/pact-foundation/pact-broker-docker/pull/123
matt.fellows
2024-01-07 22:35
matt.fellows
2024-01-07 22:36
I believe the schemas are backwards compatible with the previous version, but not sure they are compatible that far back
matt.fellows
2024-01-07 22:37
> 1. Will the latest pact broker migrate the 2-year-old db and successfully deploy the application to be used?
Yes, it will apply all database migrations
matt.fellows
2024-01-08 00:39
> I?ll admit the name is a tad confusing :slightly_smiling_face:
Yeah, it is. We have an open ticket to try and improve the nomenclature around this. I?m sorry everyone!
matt.fellows
2024-01-08 00:40
> One more question. Versioning? say if we had an API which was versioned on the route? such as `v1/` and `v2/` would that be separate contracts or would you be able to have two versions of the same contract in prod?
You can have them as separate applications if they are. If they are deployed together as a single unit (that serves two prefixes) then it should be a single provider contract (obviously each consumer would each have a single consumer contract)
markkellett
2024-01-08 10:09
Alas, my laptop is `linux/arm64/v8` which isn't included in this image I believe
f.barril
2024-01-12 10:48
Hi, is there any disadvantage using mysql instead of postgres for the pact-broker database?
matt.fellows
2024-01-12 10:50
It is definitely more optimised for Postgres. We run that in PactFlow and spend lots of time optimising queries specifically ran on postgres
varnit.garg2424
2024-01-19 03:10
Hi,
I?ve a basic question. If I use `docker pull pactfoundation/pact-cli:latest` in the ci pipeline, then do I still need to run docker command while running can-i-deploy step?
Or can we just use `pact-broker can-i-deploy .....so on..`
```steps:
- name: Pull Pact CLI Docker image
run: docker pull pactfoundation/pact-cli:latest
- name: Can I Deploy to Staging
run: |
docker run --rm \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_TOKEN \
pactfoundation/pact-cli:latest \
broker can-i-deploy \
--pacticipant my_serv \
--version ${{ github.sha }} \
--to staging```
matt.fellows
2024-01-19 03:23
Docker isn?t just a distribution mechanism to download things, it?s a runtime that you must use with it
matt.fellows
2024-01-19 03:23
If you don?t want to use Docker, the underlying CLI can be downloaded independently
rmartine
2024-01-30 00:20
I have a weird one!
We're moving to ipv6-only kubernetes clusters.
We're using https://github.com/pact-foundation/pact-broker-docker via the https://github.com/pact-foundation/pact-broker-chart.
The container was failing to be reachable, because puma was only binding to the ipv4 port. We saw this by `kubectl exec`ing in and running `netstat -nl`:
```Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:9292 0.0.0.0:* LISTEN```
This is resolved by https://github.com/pact-foundation/pact-broker-docker/blob/d1cef48eb66c9d4871862dd017d1986e12a28bcf/pact_broker/entrypoint.sh#L9 `entrypoint.sh` to read `bundle exec puma --bind 'tcp://[::]:9292'` (note: `--bind 'tcp://[::]' --port 9292` does NOT work.)
Then we get:
```tcp 0 0 :::9292 :::* LISTEN```
and everything works.
Ideally, I think puma should bind to both the ipv4 and ipv6 "any" addresses. I'm not sure why it isn't doing this by default.
I'm posting here instead of making an issue because I'm not sure quite what the issue or real fix is, my networking is a bit rusty. However, as-is, the pact broker does not run in an ipv6-only kubernetes cluster, which I think should be fixed. I spent a few days on this and would like to save others the time.
matt.fellows
2024-01-30 00:50
It looks like it might relate to https://github.com/puma/puma/issues/782#issuecomment-233448657. Probably, `localhost` has an entry for `0.0.0.0` on your host, and was binding to the first address. It looks like if we set it to `localhost` it will bind to both interfaces. But that may have other consequences, so we?d need to review
matt.fellows
2024-01-30 00:51
probably it requires a tracking ticket so we can properly asses the impact, or provide documentation guidance on setting up ipv4 or ipv6 setups.
Why hasn?t it been seen before? Probably because we (PactFlow) run it over a ipv4 stack, and noone else seems to be running it in the same way (or shared their learnings - thank you)
matt.fellows
2024-01-30 20:41
Ooh. Start with the docker one please and we can move it around as needed
rmartine
2024-01-31 18:31
https://github.com/pact-foundation/pact-broker-docker/issues/163
Done, sorry that took an extra day!
jowhalen13
2024-02-01 21:50
Is it possible to see the full request body so I can determine what the error message was for a verification failure?
jowhalen13
2024-02-01 21:58
I'm seeing this in the logs but it's not expanding the body object
```2024-02-01T21:56:29.950708Z INFO ThreadId(11) pact_verifier::provider_client: Received response: HTTP Response ( status: 404, headers: Some({"date": ["Thu, 01 Feb 2024 21:56:29 GMT"], "x-response-time": ["4ms"], "content-type": ["text/plain; charset=utf-8"], "content-length": ["9"], "connection": ["close"], "x-powered-by": ["Express"]}), body: Present(9 bytes, text/plain;charset=utf-8) )```
bas
2024-02-01 22:10
Assuming you mean you?re looking for the response body: can?t you just replay the request using a tool like Postman and see what happens?
matt.fellows
2024-02-02 00:34
We don?t actually capture and store that in PactFlow, although I can see why that would be valuable.
jowhalen13
2024-02-02 00:37
I'm using rest client for vscode and that's working but it'd be nice to see the exact request and response happening in the test. Ok I'll try setting debug logs
matt.fellows
2024-02-02 01:06
Usually when I see this, it?s a provider state not being setup correct and a 404 or endpoint is being hit that wasn?t expected by the provider
jowhalen13
2024-02-02 01:22
Yeah there's definitely something up with the record not being in the downstream api mock, I think I can fix it
jowhalen13
2024-02-02 01:23
Pact is forcing me to learn backend development so this is taking me a minute lol
matt.fellows
2024-02-02 01:55
I think the point above is a good one though. I think their is likely a feature request for it, I?ll add your vote to it
matt.fellows
2024-02-02 02:00
If you could please cast your vote here also: https://pact.canny.io/feature-requests/p/cache-provider-contract-on-pact-broker
We have an internal tracking one for PactFlow too
edouard.lopez
2024-02-06 14:31
Hello, after a deployment of Pact-Broker (`2.105.0.1`) we have this log:
> ```! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: connection to server on socket "/run/postgresql/.s.PGSQL.5432" failed: No such file or directory```
Similar to what was described in this https://github.com/pact-foundation/pact_broker/discussions/604 (but no anwser :sob: ).
Any suggestion?
james.perepiczka
2024-02-06 17:46
Hi, Is it possible that using create-version-tag and record deployment together can undo each other? I run one after another to record a deployment to the ?main? branch but also tag it. Somehow I end up with a tag and branch of main on one commit and an environment of main on an older commit.
varnit.garg2424
2024-02-07 03:14
Hi, I need some help about how to create webhook for - `contract requiring verification published` event.
We are using github actions. Should I add a CLI cmd in github actions on the consumer side?
Do we need to make any changes in provider repo as well to listen to this event?
matt.fellows
2024-02-07 04:11
IMO it?s the responsibility of the _provider_ to setup this webhook, because they are the ones receiving it
matt.fellows
2024-02-07 04:12
As per https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event, on the provider side, you should set the verification to _only_ verify the pact that is passed in by the webhook
matt.fellows
2024-02-07 04:13
Example provider verification build that listens to webhook: https://github.com/pactflow/example-provider/blob/master/src/product/product.consumerChange.pact.test.js
matt.fellows
2024-02-07 04:14
(this is the build for when the provider build runs to make sure it works as a regression suite): https://github.com/pactflow/example-provider/blob/master/src/product/product.providerChange.pact.test.js)
varnit.garg2424
2024-02-07 09:19
We have deployed our in-house pact-broker but publishing the pact to broker returns *OpenSSL::SSL::SSLError*
Any leads on how to solve it?
matt.fellows
2024-02-07 09:48
Install a proper certificate, it's 2024 and they're cheap/free and easy. Really ;)
matt.fellows
2024-02-07 09:48
But assuming you can't, you'll need to use the SSL options. See the `help` menu for usage
james.perepiczka
2024-02-07 10:50
Hi, I?ve upgraded the pact cli we are using to latest and then started seeing different behaviour than the previous version of the cli we were on (nearly a year old). When running can-i-deploy for a service to our main branch, we now have multiple pacts which have an environment flag as main when previously it was just the current deployed. Is there any way of maintaining that behaviour?
james.perepiczka
2024-02-07 10:59
The ?wrong contract? states currently released and supported in main. Looking at the docs on recording deployment and recording release. I assumed if I used record deployment then it doesnt use that lifecycle so there wouldnt be a ?released? version different to the ?deployed? version
matt.fellows
2024-02-07 12:21
Yes, recording deployments replaces the previously deployed version.
Could you please share the CLI command you're using to record deployments/releases and the input/ output for can I deploy?
james.perepiczka
2024-02-07 12:32
```pact-broker create-version-tag --pacticipant "service1" --version "6fc2103" --tag "main"
Tagging service1 version 6fc2103 as main
pact-broker record-deployment --environment "main" --pacticipant "service1" --version "6fc2103"
Recorded deployment of service1 version 6fc2103 to main environment in the Pact Broker```
james.perepiczka
2024-02-07 12:33
At the end of this, the previous version (62a65ed) was still tagged with env: main but so was the new version (6fc2103)
edouard.lopez
2024-02-07 13:10
It's was an issue on our infra not passing the credentials to the container
matt.fellows
2024-02-08 00:05
tags don?t overwrite previous versions, each version you give a tag will have that tag forever (unless you remove it). Are you sure the previous version was still _deployed_ to `main`, and not just _tagged_ `main`?
matt.fellows
2024-02-08 00:05
what are you using tags for, given you use the `record-deployment` command?
james.corry
2024-02-08 13:51
Hello,
Hoping you can help again :).
Our Pact Broker instance is returning a "failed to open TCP connection" "(Blocking operation timed out)" to any CLI command.
We can browse to and log in to our Pact Broker instance OK and can upload Pacts via Postman and verify using http://Pact.Net.
Steps to replicate:
Download and extract latest pact-ruby-standalone Windows x86_64 from https://github.com/pact-foundation/pact-ruby-standalone/releases
Open CMD as admin and run: pact-broker.bat list_latest_pact_versions -b https://<pactbrokerurl>.http://azurewebsites.net:9292 -u <username> -p <password>
Troubleshooting
- Logging is set to debug. There are no new traces at the time of executing the CLI command. This would suggest the command isn't reaching the pact broker. There have been no additional configuration changes since we last asked for help.
- Our infra team confirmed yesterday the firewall is configured to allow traffic to/from the pact broker.
Do you have any ideas?
Without the port appended to it, the response received is "OpenTimeout".
Appreciate any assistance you can help us with again.
Thank you
yousafn
2024-02-08 14:01
Has it ever worked from the pact cli?
Are you providing a path to your cert file?
https://github.com/pact-foundation/pact-ruby-standalone?tab=readme-ov-file#ssl
james.corry
2024-02-08 16:00
Hi Yousaf,
Thanks for the reply :)
Yep, it worked last year.
Will give that a try thank you
jowhalen13
2024-02-08 17:35
I voted for it! Also added my own comment explaining that we don't even need the physical pact file necessarily, just the request/response pairs that get actually sent during verification. So I could do something like
```.verifyPacts((req, res) => {console.log(req.body)})```
james.corry
2024-02-09 11:48
Hi Yousaf,
Thanks for your help again.
So our infra team cannot provide a path to the certs file for security reasons.
They have suggested pointing CLI command at the default domain and have confirmed traffic is allowed to/from the pact broker on that port.
The CLI returns Net::OpenTimeout
Any ideas?
Thanks,
James
yousafn
2024-02-09 13:04
I?d go back to looking at what it was set up like when it was working, and what has changed since then. If its just the version of the pact cli, I would revert back to an older version you know worked, as see if that still does?
With Postman you can check if its configured with SSL cert verification set to off.
You can curl the broker too, as it exposes an api. If you can?t make a request without provide a path to SSL_CERT_FILE or you have to use `--insecure` in the request, then you will most likely need to either disable ssl `PACT_DISABLE_SSL_VERIFICATION=true` or provide a path to your cert file.
james.perepiczka
2024-02-12 11:07
For the pact broker api, is there any endpoint we can call to get the latest contract version for a pacticipant in a particular environment? e.g. get me the version of pacticipant A in environment dev?
matt.fellows
2024-02-12 11:25
Possibly, you could look at this to see if you can get there: https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started
(There is some PF APIs there but hopefully you can see which things are open source vs PactFlow)
michal.patron
2024-02-13 11:07
Hello everyone :wave:
I'm reading about the _can-i-deploy_ feature and one thing keeps on bothering me:
Are _record-deployment_ and _can-i-deploy_ resilient to race conditions in any way?
The deployment of a service takes some time, so there is a time gap between a check with _can-i-deploy_ and the _record-deployment_ commands. It could happen that e.g. a consumer thinks it's safe to deploy and right after it starts rolling out to an environment, a potentially incompatible provider version does just the same: it checks for compatibility, but with the old consumer version and not the one that is just being deployed (because its deployment is still ongoing) and also proceeds with the deployment.
This way two incompatible consumer and provider instances could get deployed into an environment.
I haven't found anything about that in the documenation or in the Slack history.
abubics
2024-02-13 11:50
afaik, all of those commands (both checks and recordings, i.e. `can-i-deploy`, `record-deployment`, `record-release`, etc) are all immediate, and there aren't any locks or mutexes . . . (because how could this tooling know about every env setup)
abubics
2024-02-13 11:51
but I think the practical solution irl is to talk to each other, and have several versions deployed (in different envs) at the same time, which increases the chance that many parallel versions are compatible
abubics
2024-02-13 11:52
(the tooling doesn't 100% protect you, and it's not trying to?it's a helper and conversation point)
ulises.cervino
2024-02-13 15:09
I asked this same question some time ago, but Slack has no record of it unfortunately: how can I get my hands on a pacticipant?s deployed (to a particular env) version? /cc @matt.fellows since you replied to me at the time requesting that I request a feature in the cli, but also mentioned that this could be gotten from the API?
yousafn
2024-02-13 15:22
Go to
`/environments` and follow the hal relation for `pb:currently-deployed-deployed-versions` or `pb:currently-deployed-released-versions`
the url will give you a list of all deployed applications and versions to that env
yousafn
2024-02-13 15:23
top tip - you can search in the following archive for past history beyond slacks free paid plan
https://www.linen.dev/s/pact-foundation
matt.fellows
2024-02-14 07:50
Yep. You might also like to read this section: https://docs.pact.io/pact_broker/recording_deployments_and_releases#why-the-application-instance-should-not-be-used-for-long-running-deployments
matt.fellows
2024-02-14 07:51
Another way to reduce the likelihood of this issue, is to always check compatibility with both the mainline _and_ production version of an application (or as the case may be, the previous environment and next environment). This would mean both applications are pairwise compatible with the various combinations, and so a long running deployment wouldn?t cause an issue
james.corry
2024-02-14 10:27
Hi Yousaf,
Thanks for your suggestions again.
Unfortunately, the last known working pact cli version (pact-2.0.10-windows-x64_64) and pact 2.4.0 (windows-x86) does not work.
Using Postman we can make requests successfully with SSL cert verification on and off.
I've also downloaded the assets manually from github too.
I've also disabled SSL verification using the command provided and "PACT_BROKER_DISABLE_SSL_VERIFICATION=true", which gave the same response.
I've replicated the issue using docker and running cmd as admin gives the following response. What does this suggest to you?
Thanks for your help again we appreciate it!
```t_broker/client/hal/http_client.rb:86:in `block in perform_request', attempt 1 of 3
Error making request - Net::OpenTimeout Net::OpenTimeout /usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/http_client.rb:86:in `block in perform_request', attempt 2 of 3
Error making request - Net::OpenTimeout Net::OpenTimeout /usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/http_client.rb:86:in `block in perform_request', attempt 3 of 3
Error retrieving matrix. Net::OpenTimeout - Net::OpenTimeout
/usr/lib/ruby/3.2.0/net/protocol.rb:43:in `ssl_socket_connect'
/usr/lib/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1674:in `connect'
/usr/lib/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1580:in `do_start'
/usr/lib/ruby/gems/3.2.0/gems/net-http-0.4.1/lib/net/http.rb:1569:in `start'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/http_client.rb:86:in `block in perform_request'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/http_client.rb:100:in `until_truthy_or_max_times'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/http_client.rb:65:in `perform_request'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/http_client.rb:25:in `get'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/link.rb:41:in `get'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/hal/link.rb:45:in `get!'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/matrix/query.rb:11:in `call'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/base_command.rb:13:in `call'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/can_i_deploy.rb:107:in `block in fetch_matrix'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/retry.rb:22:in `while_error'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/can_i_deploy.rb:107:in `fetch_matrix'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/can_i_deploy.rb:111:in `fetch_matrix_with_retries'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/can_i_deploy.rb:34:in `call'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/can_i_deploy.rb:23:in `call'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/cli/matrix_commands.rb:41:in `can_i_deploy'
/usr/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
/usr/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
/usr/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor.rb:527:in `dispatch'
/usr/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/base.rb:584:in `start'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/lib/pact_broker/client/cli/custom_thor.rb:34:in `start'
/usr/lib/ruby/gems/3.2.0/gems/pact_broker-client-1.75.1/bin/pact-broker:10:in `<top (required)>'
/usr/bin/pact-broker:25:in `load'
/usr/bin/pact-broker:25:in `<main>'```
shenkesi.shiva
2024-02-14 11:18
Hello everyone, how to configure webhooks in pact broker? if any one worked on it plz let me know.
matt.fellows
2024-02-14 11:21
Have you read https://docs.pact.io/pact_broker/webhooks, https://docs.pact.io/pact_broker/webhooks/template_library or looked at any of the example projects or https://docs.pactflow.io/docs/workshops/ci-cd/which use them?
shenkesi.shiva
2024-02-14 11:31
I'm trying to create a webhooks through the API Browser clicked on the NON-GET button for the pb:webhooks it's showing to pass the body, here what should i pass, if you have sample code let me know.
ulises.cervino
2024-02-15 21:17
hi all, regarding webhooks, IIUC if a contract can be verified by reusing previous verification results, e.g. when it?s not changed, then a `contract_requiring_verification_published` even should not be emitted, and as a result no webhook should be called.
ulises.cervino
2024-02-15 21:18
however, I find myself in a position where this is precisely what?s happening. Have I missed anything?
ulises.cervino
2024-02-15 21:21
FWIW, I?ve checked the contracts themselves in each of these events and they are identical
matt.fellows
2024-02-16 05:52
If you look at the logs for them, you might see that each invocation is for a different version of the provider, that has not verified the contract (e.g. a new branch)
ulises.cervino
2024-02-16 06:55
while we?re on the subject: are the provider versions in the event the provider versions that need to verify this contract?
ulises.cervino
2024-02-16 06:56
because I find this example very confusing if so, check this out `variables[PACT_PROVIDER_VERSION]=d76b15dbab276a17d7ad3cbb69b64b21d27c1027` that?s in the webhook, however when I go check that commit I see
```Commit d76b15db authored 1 year ago by Ulises Cervino's avatar Ulises Cervino```
which strikes me as odd?
matt.fellows
2024-02-16 07:01
Interesting.
> Using this webhook event allows the changed pact to be tested against the head of the providers main branch and any deployed or released versions of the provider, in the same way as the consumer version selectors can be configured to allow the head of the consumers main branch and any deployed or released versions of the pact to be tested against a version of the provider.
I?m hoping that version corresponds to one of these conditions
matt.fellows
2024-02-16 07:02
If it doesn?t, I could get the team to investigate to find out what?s happening
varnit.garg2424
2024-02-16 07:33
I?m getting this error when using our in-house pact-broker
Not sure how to fix it. Able to publish the pacts to the broker on consumer side, however, provider side verification is getting failed due to this error.
```2024-02-16T07:28:02.226297Z INFO ThreadId(09) pact_verifier::pact_broker: Fetching path '/' from pact broker
2024-02-16T07:28:02.226707Z ERROR ThreadId(09) pact_verifier: Failed to load pact - Could not load pacts from the pact broker 'pb.qa.client.abcservice.net'
2024-02-16T07:28:02.226737Z WARN ThreadId(09) pact_matching::metrics: ```
james.corry
2024-02-16 09:04
Hi Yousaf and team,
Any ideas, please?
We noticed the response is identical to https://stackoverflow.com/questions/42036133/ruby-netopentimeout-execution-expired.
Does this help?
Any additional pointers would be much appreciated.
Thank you
varnit.garg2424
2024-02-16 09:11
sure
```go install http://github.com/pact-foundation/pact-go/v2@v2.0.2
pact-go -l DEBUG install
2024/02/16 17:08:35 [INFO] package libpact_ffi found
2024/02/16 17:08:35 [INFO] checking version 0.4.5 of libpact_ffi against semver constraint >= 0.4.0, < 1.0.0
2024/02/16 17:08:35 [DEBUG] 0.4.5 satisfies constraints 0.4.5 >= 0.4.0, < 1.0.0
2024/02/16 17:08:35 [INFO] package libpact_ffi is correctly installed
2024/02/16 17:08:35 [DEBUG] skip checking ffi version() call because FFI not loaded. This is expected when running the 'pact-go' command.
Running pact tests...
go test ./service/purchases/contracttests -tags=pact
2024/02/16 17:08:39 [INFO] package libpact_ffi found
2024/02/16 17:08:39 [INFO] checking version 0.4.5 of libpact_ffi against semver constraint >= 0.4.0, < 1.0.0
2024/02/16 17:08:39 [INFO] package libpact_ffi is correctly installed
2024/02/16 17:08:39 [INFO] checking version 0.4.5 for lib libpact_ffi within semver range >= 0.4.0, < 1.0.0
2024/02/16 17:08:39 [INFO] checking version 0.4.5 of libpact_ffi against semver constraint >= 0.4.0, < 1.0.0
&{}
2024/02/16 17:08:39 [DEBUG] initialising native interface
2024/02/16 17:08:39 [DEBUG] initialised native log level to DEBUG (4)
2024/02/16 17:08:39 [DEBUG] initialised native log to log to stdout
2024/02/16 17:08:39 [DEBUG] log_to_stdout res 0
2024-02-16T09:08:39.786333Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_new_for_application FFI function invoked
2024/02/16 17:08:39 [DEBUG] starting new proxy with opts {http 127.0.0.1:52301 0 [] /__setup <nil>}
2024/02/16 17:08:39 [DEBUG] starting reverse proxy on port 52302
2024-02-16T09:08:39.786827Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_provider_info FFI function invoked
2024/02/16 17:08:39 [DEBUG] v.Transports []
2024-02-16T09:08:39.786937Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_verification_options FFI function invoked
2024-02-16T09:08:39.786953Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_publish_options FFI function invoked
2024-02-16T09:08:39.787015Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_broker_source_with_selectors FFI function invoked
2024-02-16T09:08:39.787069Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_set_no_pacts_is_error FFI function invoked
2024/02/16 17:08:39 [DEBUG] waiting for port 52302 to become available
2024/02/16 17:08:39 [DEBUG] pact provider verification
2024-02-16T09:08:39.840089Z DEBUG ThreadId(01) pact_ffi::verifier: pact_ffi::verifier::pactffi_verifier_execute FFI function invoked
2024-02-16T09:08:39.840112Z DEBUG ThreadId(01) pact_ffi::verifier::handle: Pact source to verify = PactBrokerWithDynamicConfiguration(https://pb.qa.client.abcservice.net/, provider_name='kp_fb', enable_pending=false, include_wip_since=None, provider_tags=["test_prov"], provider_branch=Some(""), consumer_version_selectors='[ConsumerVersionSelector { consumer: None, tag: Some("master"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("staging"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("main"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("production"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("contract-tests"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }], auth=User(poc123, po**********************)')
2024-02-16T09:08:39.841236Z DEBUG ThreadId(01) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/content-generator/binary
core/content-generator/json
core/content-matcher/json
core/content-matcher/multipart-form-data
core/content-matcher/text
core/content-matcher/xml
2024-02-16T09:08:39.841268Z DEBUG ThreadId(01) pact_plugin_driver::catalogue_manager: Updated catalogue entries:
core/matcher/v1-equality
core/matcher/v2-max-type
core/matcher/v2-min-type
core/matcher/v2-minmax-type
core/matcher/v2-regex
core/matcher/v2-type
core/matcher/v3-content-type
core/matcher/v3-date
core/matcher/v3-datetime
core/matcher/v3-decimal-type
core/matcher/v3-includes
core/matcher/v3-integer-type
core/matcher/v3-null
core/matcher/v3-number-type
core/matcher/v3-time
core/matcher/v4-array-contains
core/matcher/v4-equals-ignore-order
core/matcher/v4-max-equals-ignore-order
core/matcher/v4-min-equals-ignore-order
core/matcher/v4-minmax-equals-ignore-order
core/matcher/v4-not-empty
core/matcher/v4-semver
2024-02-16T09:08:40.045225Z INFO ThreadId(01) pact_verifier::pact_broker: Fetching path '/' from pact broker
2024-02-16T09:08:40.045624Z DEBUG ThreadId(01) reqwest::connect: starting new connection: https://pb.qa.client.abcservice.net/
2024-02-16T09:08:40.045812Z DEBUG tokio-runtime-worker hyper::client::connect::dns: resolving host="http://pb.qa.client.abcservice.net"
2024-02-16T09:08:40.098614Z DEBUG ThreadId(01) hyper::client::connect::http: connecting to 123.34343.4.4.34.3.:443
2024-02-16T09:08:40.176617Z DEBUG ThreadId(01) hyper::client::connect::http: connected to 34.35.45.4.454.54:443
2024-02-16T09:08:40.176707Z DEBUG ThreadId(01) rustls::client::hs: No cached session for DnsName("http://pb.qa.client.abcservice.net")
2024-02-16T09:08:40.176852Z DEBUG ThreadId(01) rustls::client::hs: Not resuming any session
2024-02-16T09:08:40.502484Z DEBUG ThreadId(01) rustls::client::hs: Using ciphersuite TLS13_AES_256_GCM_SHA384
2024-02-16T09:08:40.502536Z DEBUG ThreadId(01) rustls::client::tls13: Not resuming
2024-02-16T09:08:40.502624Z DEBUG ThreadId(01) rustls::client::tls13: TLS1.3 encrypted extensions: [ServerNameAck, Protocols([ProtocolName(6832)])]
2024-02-16T09:08:40.502630Z DEBUG ThreadId(01) rustls::client::hs: ALPN protocol is Some(b"h2")
2024-02-16T09:08:40.503060Z ERROR ThreadId(01) pact_verifier: Failed to load pact - Could not load pacts from the pact broker 'https://pb.qa.client.abcservice.net/'
2024-02-16T09:08:40.503095Z WARN ThreadId(01) pact_matching::metrics:
Please note:
We are tracking events anonymously to gather important usage statistics like Pact version and operating system. To disable tracking, set the 'PACT_DO_NOT_TRACK' environment variable to 'true'.
2024-02-16T09:08:40.516204Z DEBUG ThreadId(01) pact_matching::metrics: Sending event to GA - {"cd7": "1.1.1", "aid": "pact-go", "tid": "UA-117778936-1", "ds": "client", "v": "1", "ev": "0", "cid": "84c593fbc0b98ad8e67cf7bc11985de6", "el": "Pacts verified", "av": "v2.0.2", "cd3": "macos-aarch64", "an": "pact-go", "ea": "Completed", "t": "event", "cd2": "unknown", "cd6": "pact_ffi", "ec": "ProviderTest", "aip": "true"}
2024-02-16T09:08:40.692626Z DEBUG ThreadId(01) reqwest::connect: starting new connection: https://www.google-analytics.com/
2024-02-16T09:08:40.692669Z DEBUG tokio-runtime-worker hyper::client::connect::dns: resolving host="http://www.google-analytics.com"
2024-02-16T09:08:40.703801Z DEBUG ThreadId(01) hyper::client::connect::http: connecting to 142.250.194.14:443
2024-02-16T09:08:40.713917Z DEBUG ThreadId(01) hyper::client::connect::http: connected to 142.250.194.14:443
2024-02-16T09:08:40.713931Z DEBUG ThreadId(01) rustls::client::hs: No cached session for DnsName("http://www.google-analytics.com")
2024-02-16T09:08:40.713963Z DEBUG ThreadId(01) rustls::client::hs: Not resuming any session
2024-02-16T09:08:40.798409Z DEBUG ThreadId(01) rustls::client::hs: Using ciphersuite TLS13_AES_256_GCM_SHA384
2024-02-16T09:08:40.798419Z DEBUG ThreadId(01) rustls::client::tls13: Not resuming
2024-02-16T09:08:40.798574Z DEBUG ThreadId(01) rustls::client::tls13: TLS1.3 encrypted extensions: [Protocols([ProtocolName(6832)])]
2024-02-16T09:08:40.798582Z DEBUG ThreadId(01) rustls::client::hs: ALPN protocol is Some(b"h2")
2024-02-16T09:08:40.799166Z DEBUG ThreadId(01) h2::client: binding client connection
2024-02-16T09:08:40.799175Z DEBUG ThreadId(01) h2::client: client connection bound
2024-02-16T09:08:40.799278Z DEBUG ThreadId(01) h2::codec::framed_write: send frame=Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
2024-02-16T09:08:40.799659Z DEBUG ThreadId(01) hyper::client::pool: pooling idle connection for ("https", http://www.google-analytics.com)
2024-02-16T09:08:40.799708Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=WindowUpdate { stream_id: StreamId(0), size_increment: 5177345 }
2024-02-16T09:08:40.799889Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
2024-02-16T09:08:40.799902Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=Data { stream_id: StreamId(1), flags: (0x1: END_STREAM) }
2024-02-16T09:08:40.818853Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Settings { flags: (0x0), max_concurrent_streams: 100, initial_window_size: 1048576, max_header_list_size: 65536 }
2024-02-16T09:08:40.818890Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_write: send frame=Settings { flags: (0x1: ACK) }
2024-02-16T09:08:40.818894Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=WindowUpdate { stream_id: StreamId(0), size_increment: 983041 }
2024-02-16T09:08:40.819255Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Settings { flags: (0x1: ACK) }
2024-02-16T09:08:40.819262Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::proto::settings: received settings ACK; applying Settings { flags: (0x0), enable_push: 0, initial_window_size: 2097152, max_frame_size: 16384 }
2024-02-16T09:08:40.892643Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Headers { stream_id: StreamId(1), flags: (0x4: END_HEADERS) }
2024-02-16T09:08:40.892726Z DEBUG tokio-runtime-worker Connection{peer=Client}: h2::codec::framed_read: received frame=Data { stream_id: StreamId(1) }
Failures:
1) Failed to load pact - Could not load pacts from the pact broker 'https://pb.qa.client.abcservice.net/'```
matt.fellows
2024-02-16 10:24
Thanks. Hate to ask but I'll need a support ticket as it will require the beginner to have access to your data
2024-02-16 10:24
Please create a ticket here with the issue details so that we can properly track the resolution and the PactFlow product support team will continue to work through it with you: https://support.smartbear.com/pactflow/message
ulises.cervino
2024-02-16 10:26
how much detail do you need there? or is this a token ticket just to get going?
ulises.cervino
2024-02-16 10:28
```The following unique identifier was assigned to your request: 00597219```
yousafn
2024-02-16 12:25
There are three ways to use the broker client
? Standalone
? Docker
? RubyGems
I would try to use each of those and attempt to
? Connect to a hosted PactFlow broker (test SSL against a properly signed cert)
? Connect to a locally running Pact Broker without HTTPS
? Connect to a locally running Pact Broker with HTTPS (you can use the SSL example in the pact-broker-docker repo)
? Connect to your own broker
Each of the distribution methods should work with each of the possible configuration methods.
I am confused by your reporting
> Unfortunately, the last known working pact cli version (pact-2.0.10-windows-x64_64) and pact 2.4.0 (windows-x86) does not work.
> I?ve replicated the issue using docker and running cmd as admin gives the following response.
If the last working version (for you) of the CLI was 2.0.10, which now doesn?t work today, and it also doesn?t work in Docker, then I would expect the issue not to be on Pact?s side, but instead with your network and/or broker setup
james.corry
2024-02-16 12:26
Thanks for the reply Yousaf and the suggestions.
Will work through them.
James
james.corry
2024-02-16 12:36
Yousaf,
Quick question - the infra team would like to know what port should be opened for this to work?
Thank you,
James
yousafn
2024-02-16 12:40
From the client side. if your connecting to a broker via HTTPS and you don?t provide a port, it will use 443, if you are conecting via HTTP and don?t provide a port it?ll use port 80.
If you are provided a port for your broker, are its not one of the standard, you?ll need to provide it
yousafn
2024-02-16 12:50
do you actually have pacts to verify against your selectors. I notice you are using deprecated tags, over actual branches/environments
```2024-02-16T09:08:39.840112Z DEBUG ThreadId(01) pact_ffi::verifier::handle: Pact source to verify = PactBrokerWithDynamicConfiguration(https://pb.qa.client.abcservice.net/, provider_name='kp_fb', enable_pending=false, include_wip_since=None, provider_tags=["test_prov"], provider_branch=Some(""), consumer_version_selectors='[ConsumerVersionSelector { consumer: None, tag: Some("master"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("staging"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("main"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("production"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }, ConsumerVersionSelector { consumer: None, tag: Some("contract-tests"), fallback_tag: None, latest: Some(true), deployed_or_released: None, deployed: None, released: None, environment: None, main_branch: None, branch: None, matching_branch: None }], auth=User(poc123, po**********************)')```
? consumer tag of `master`
? consumer tag of `staging`
? consumer tag of `main`
? consumer tag of `production`
? consumer tag of `contract-tests`
Are you consumer contracts published against a provider `kp_fb`
Has this ever worked?
matt.fellows
2024-02-18 04:40
That?ll do, I?ll let the CC team know to forward it straight to L3 support - thanks!
james.corry
2024-02-20 18:05
Hey Yousaf,
Good news - We resolved the issue.
It was an environmental issue and your feedback / SSL pointers helped us to identify and solve the problem so thank you again!
James
yousafn
2024-02-20 18:42
pleasure dude, glad its all sorted. might be worth documenting some of this for others in your team/org who might get stuck int future. all the best James
harwin1494
2024-02-22 10:58
Hi team, I am publishing pacts with tag and running a provider test for that tag. It's always showing `No Pact found to verify`. When I check this on pact broker, pacts are published for a tag, but those tags are not active. Upon hovering over those tags, it says `This version of hbr-ms-user is from branch "develop". A more recent version from this branch exists.` Any solution for this?
matt.fellows
2024-02-22 11:26
Can you please show the logs for this (ideally debug level) and your consumer setup (so we can see what tags it has?)
ulises.cervino
2024-02-22 18:19
hi all, I?m running into the following issue: we want to roll out to prod, but one of our integrations is not rolled out there yet. I?ve tried adding an ignore via `--ignore` hoping that this would ignore the integration altogether, but that doesn?t seem to be the case. Other than bypassing `can-i-deploy` until they deploy to prod, what options do I have? context: I know it?s safe to deploy to prod without this dependency, etc. Thanks in advance.
ulises.cervino
2024-02-22 18:23
I guess I could always record a fake rollout with the version I want and move on
matt.fellows
2024-02-22 20:55
Oh, that sounds like a bug if it's not ignoring the pacticipant. Any chance you could share the CLI args and output (redacted as necessary)?
varnit.garg2424
2024-02-27 03:42
Sorry, I was away for the past 2 weeks.
Yes, the same code has been working against pactflow, just that failing against our local pact-broker
christopher.tonog
2024-02-27 03:42
:wave: Apologies in advance if this is already in the documentation, but I am running a local copy of the opensource pact broker and pushed a JS consumer contract with a gRPC provider. In the UI it's showing the raw content of the contract with: _`Note: this contract could not be parsed to a v1 or v2 Pact, showing raw content instead.`_ It's using the Pact V4 version, not sure if there's a flag I need to set or specific version I need to deploy in order to get the UI to be more human readable? Thank you!
matt.fellows
2024-02-27 05:27
hmm why do you have both PactFlow and a local pact broker? Could the data be out of sync?
matt.fellows
2024-02-27 05:46
It?s just that there isn?t a renderer for it. See https://github.com/pact-foundation/pact_broker/issues/623
matt.fellows
2024-02-27 05:58
For clarity, the broker will manage the file just fine, it just doesn?t know how to display it
varnit.garg2424
2024-02-27 06:09
I?ve been using trial version of pactflow, but then we created our own broker.
matt.fellows
2024-02-27 07:01
> 2024-02-16T09:08:40.045225Z INFO ThreadId(01) pact_verifier::pact_broker: Fetching path ?/? from pact broker
> 2024-02-16T09:08:40.045624Z DEBUG ThreadId(01) reqwest::connect: starting new connection: https://pb.qa.client.abcservice.net/
> 2024-02-16T09:08:40.045812Z DEBUG tokio-runtime-worker hyper::client::connect::dns: resolving host=?http://pb.qa.client.abcservice.net?
> 2024-02-16T09:08:40.098614Z DEBUG ThreadId(01) hyper::client::connect::http: connecting to 123.34343.4.4.34.3.:443
> 2024-02-16T09:08:40.176617Z DEBUG ThreadId(01) hyper::client::connect::http: connected to 34.35.45.4.454.54:443
> 2024-02-16T09:08:40.176707Z DEBUG ThreadId(01) rustls::client::hs: No cached session for DnsName(?http://pb.qa.client.abcservice.net?)
> 2024-02-16T09:08:40.176852Z DEBUG ThreadId(01) rustls::client::hs: Not resuming any session
> 2024-02-16T09:08:40.502484Z DEBUG ThreadId(01) rustls::client::hs: Using ciphersuite TLS13_AES_256_GCM_SHA384
> 2024-02-16T09:08:40.502536Z DEBUG ThreadId(01) rustls::client::tls13: Not resuming
> 2024-02-16T09:08:40.502624Z DEBUG ThreadId(01) rustls::client::tls13: TLS1.3 encrypted extensions: [ServerNameAck, Protocols([ProtocolName(6832)])]
> 2024-02-16T09:08:40.502630Z DEBUG ThreadId(01) rustls::client::hs: ALPN protocol is Some(b?h2")
> 2024-02-16T09:08:40.503060Z ERROR ThreadId(01) pact_verifier: Failed to load pact - Could not load pacts from the pact broker ?https://pb.qa.client.abcservice.net/?
this set of API calls indicates the request is actually failing on the first call to `/`. Sorry to do this, but could you please bump the level to `TRACE` and share again? The actual request to the broker is not shown here, and that will tell us the underlying problem.
It could be auth or access or something else
konstantin.manna
2024-02-28 13:58
When `pact-broker publish` fails and returns exit code 1: How to figure out what is the reason for it to fail? It does not output anything (Version 1.68.0)
lcruz
2024-02-29 02:32
:wave: Hey #pact-broker
I've a quick question and apologies if it?s been asked here before but I wasn't able to find an answer on the docs. Is there a way for the Pact Broker UI to link out to a pact contract based on a tag or version instead of `latest`?
I?m specifically talking about having these link out to a mainline `master`/`main` tag ? Hope my question makes sense, can :thread: for more context.
lcruz
2024-02-29 02:33
It's definitely not a big deal and honestly, the fix was to just rebase a build but we realized that because we publish a contract on branch builds, if that branch is behind `master` or mainline, it will show that last push on the main homepage
matt.fellows
2024-02-29 02:48
I don?t believe so. The UI in the broker has received very little attention for these sorts of details, with the focus on providing a fully functional API.
matt.fellows
2024-02-29 02:48
You could get to it via the matrix of course, but I?m assuming you?re looking for a nicer view of the contract (rather than e.g. the raw JSON)?
lcruz
2024-02-29 02:58
Ah right, yeah. The matrix works just fine for my team. We?re currently putting together documentation for our customers (we work on a developer experience team) and we had came across this and kinda just flagged it as a user experience confusion.
I?m thinking just pointing this out as a disclaimer in the docs and linking out to the matrix would be the way.
matt.fellows
2024-02-29 03:00
Yeah, it?s not as nice as what we have in PactFlow (and nowhere near as nice as the new design about to launch). We have discussed potentially open sourcing our UI and retrofitting onto the existing broker, but that?s challenging for a number of reasons.
konstantin.manna
2024-02-29 07:52
Can you share how to use it? The help page does not seem to mention its existence
matt.fellows
2024-02-29 11:02
```? docker run pactfoundation/pact-cli:latest pact-broker help publish
Usage:
pact-broker publish PACT_DIRS_OR_FILES ... -a, --consumer-app-version=CONSUMER_APP_VERSION -b, --broker-base-url=BROKER_BASE_URL
Options:
-a, --consumer-app-version=CONSUMER_APP_VERSION # The consumer application version
-h, [--branch=BRANCH] # Repository branch of the consumer version
[--auto-detect-version-properties], [--no-auto-detect-version-properties] # Automatically detect the repository branch from known CI environment variables or git CLI. Supports Buildkite, Circle CI, Travis CI, GitHub Actions, Jenkins, Hudson, AppVeyor, GitLab, CodeShip, Bitbucket and Azure DevOps.
-t, [--tag=TAG] # Tag name for consumer version. Can be specified multiple times.
-g, [--tag-with-git-branch], [--no-tag-with-git-branch] # Tag consumer version with the name of the current git branch. Supports Buildkite, Circle CI, Travis CI, GitHub Actions, Jenkins, Hudson, AppVeyor, GitLab, CodeShip, Bitbucket and Azure DevOps. Default: false
[--build-url=BUILD_URL] # The build URL that created the pact
[--merge], [--no-merge] # If a pact already exists for this consumer version and provider, merge the contents. Useful when running Pact tests concurrently on different build nodes.
-o, [--output=OUTPUT] # json or text
# Default: text
-b, --broker-base-url=BROKER_BASE_URL # The base URL of the Pact Broker
-u, [--broker-username=BROKER_USERNAME] # Pact Broker basic auth username
-p, [--broker-password=BROKER_PASSWORD] # Pact Broker basic auth password
-k, [--broker-token=BROKER_TOKEN] # Pact Broker bearer token
-v, [--verbose], [--no-verbose] # Verbose output. Default: false
Publish pacts to a Pact Broker.```
konstantin.manna
2024-02-29 11:10
Ah god, the only way I have not tried to get the help :smile:. Thank you
matt.fellows
2024-02-29 11:24
Yeah, for whatever reason, the most popular Ruby CLI builder (Thor) has a different way to provide help than most CLIs. But that?s how you do it!
konstantin.manna
2024-02-29 13:07
Sure and of course once you do it an look closely enough (with --verbose) the error does not show again :laughing: . Apparently there is no output in the successful publish even with --verbose, would we have expected anything? + Are there any api downtimes or so known in the last few days on pactflow side?
matt.fellows
2024-03-01 06:28
Haha of course! I don't think we've any outages but the CLI is resilient to temporary issues (built in retries)
matt.fellows
2024-03-01 06:29
Yes, I would expect output with the verbose flag. It should show the full set of request/response calls. Mind showing how you're calling it? Is it in docker of anything?
endika2
2024-03-01 10:38
Hello, I have a question regarding the content of the body that I can send in the URL of *`pb:publish-verification-results`*. I see in the documentation that the body to be sent is this:
```{
"success": true,
"providerApplicationVersion": "1.0.1",
"buildUrl": "http://my-ci.org/build/3456"
}```
Is it possible to send the following variables
```{
"success":true,
"providerApplicationVersion":"1.0.1",
"providerVersionTags":["development"],
"branch":"my-branch"
}```
so that the Broker can store that information?
matt.fellows
2024-03-01 11:11
The discussion here implies that sort of thing, but the payload is not defined clearly there (it could be the right one, but I think it?s more indicative): https://github.com/pact-foundation/pact_broker/discussions/425
matt.fellows
2024-03-01 11:12
We didn?t documented in our API here: https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started (PactFlow?s APIs are a superset), presumably because it?s not something many people use directly.
matt.fellows
2024-03-01 11:12
May I ask why you?re are using it directly instead of via our tools? Might help us uncover a use case
matt.fellows
2024-03-01 11:19
The simplest way to find out actually, is just run a verification using the Ruby Verifier CLI, and enable `--verbose` and add all the flags you care about to see what is passed through
endika2
2024-03-01 11:56
I?m implementing the provider in a Node.js project. The issue is that since the JavaScript library doesn?t support x509 certificates, I have to make `curl` calls to the broker to communicate the test provider?s results.
konstantin.manna
2024-03-01 14:56
Ok, sure this is how we call it. It is running within a dockerfile that was built from this Dockerfile:
```FROM pactfoundation/pact-ref-verifier:0.10.6 as pact-ref-verifier
FROM pactfoundation/pact-cli:0.54.0-pactcli0.53.0
COPY --from=pact-ref-verifier /usr/local/bin/pact_verifier_cli /bin/pact-verifier
RUN chmod a+x /bin/pact-verifier```
yousafn
2024-03-01 15:14
I get the same behaviour if I have this erroneous character in between publish and the path to the pacts
`>-`
```docker run --rm -it pactfoundation/pact-cli:0.54.0-pactcli0.53.0 sh
~ # pact-broker publish example/pacts/pact.json --broker-base-url https://test.pactflow.io --broker-username dXfltyFMgNOFZAxr8io9wJ37iUpY42M --broker-password=O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1 -a 1.0.0
Updated docker-example-consumer version 1.0.0
Next steps:
Configure the version branch to be the value of your repository branch.
Pact successfully republished for docker-example-consumer version 1.0.0 and provider docker-example-provider with no content changes.
View the published pact at https://test.pactflow.io/pacts/provider/docker-example-provider/consumer/docker-example-consumer/version/1.0.0
Events detected: contract_published
No enabled webhooks found for the detected events
~ # pact-broker publish >- example/pacts/pact.json --broker-base-url https://test.pactflow.io --broker-username dXfltyFMgNOFZAxr8io9wJ37iUpY42M --broker-password=O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1 -a 1.0.0```
ralphvanderhorst
2024-03-01 20:01
Hi I am new here.for anybody who is interested. I have created an open source mit license setup in AWS fargate (for a demo) where I created a pact broker in ECS(elastic container docker serverless) and also the postgres database. What I want to achieve is that you can generate pacts in S3 and push them/sync them via pact broker to serverless postgress db, saving costs and scale this via docker instances.
ralphvanderhorst
2024-03-01 20:04
https://gitlab.com/learnautomatedtesting/servicevirtualizationandpact/ this is my aws cdk(cloud python, which you can deploy(like terraform setup)
ralphvanderhorst
2024-03-01 20:05
it is like a docker compose but then hosted directly with a button in AWS
ben.brugman
2024-03-04 15:17
Hi all, i am wondering about how to properly use _can-i-deploy_ and would like to hear your take on this_._
This question is for the Consumer side.
Context:
Contract is between
? 2 mobile consumer
? 1 web consumer
? 1 provider
? the mobile apps need to be back wards compatible for N amount of app releases
? The Broker is set-up per feature, this means we will have multiple brokers in our cluster
Pact tools to use
? Can-I-Deploy
? Publish
? Recordings
Currently we are implementing everything in the pipeline.
The plan is to make sure all contracts are verified when we want to do a merge.
We think we need to use Can-I-Deploy for this, but it feels like that is not how it should work.
The reason we think that is because Can-I-Deploy seems to only work for 1 single pacticipant at the time, we know you can give multiple pacticipants like this.
```pact-broker \
can-i-deploy \
--pacticipant=IOSConsumer \
--latest
--pacticipant=AndroidConsumer \
--latest
--broker-base-url=https://pact-broker.com/feature \
--to-environment=PROD ```
But it feels like a lot of maintenance to always have all your pacticipants up to date.
So in short, which answer applies most
1. We are mis-using Can-I-Deploy.
2. We are doing it right and should take care of managing all the pacticipants on multiple brokers.
3. We Should run all pacticipants of one broker at once, and we missed some pact functionality
matt.fellows
2024-03-05 00:40
> ? The Broker is set-up per feature, this means we will have multiple brokers in our cluster
what does this mean? Generally you just want one broker to model it all. What problem are you trying to solve by having many?
matt.fellows
2024-03-05 00:42
> pact-broker \
> can-i-deploy \
> --pacticipant=IOSConsumer \
> --latest
> --pacticipant=AndroidConsumer \
> --latest
> --broker-base-url=https://pact-broker.com/feature \
> --to-environment=PROD
you should never use the `--latest` really, because that makes things non-deterministic (how do you know ?latest? is the thing you want to deploy? Maybe the latest thing published was some branch for a WIP thing which passes, but not the latest for `main` branch which just happened to be published a few minutes before).
matt.fellows
2024-03-05 00:42
In your case, for the mobile applications you need to use record-release (not deployment): https://docs.pact.io/pact_broker/recording_deployments_and_releases.
This will allow you to track the last _n_ versions of any dependencies for your consumers
matt.fellows
2024-03-05 00:45
> The plan is to make sure all contracts are verified when we want to do a merge.
You seem to be implying you merge all of the applications (and therefore, contracts) at the same time?
If not, you should only consider the application you are merging with `can-i-deploy` (or `can-i-merge` if you want to use that).
> The reason we think that is because Can-I-Deploy seems to only work for 1 single pacticipant at the time, we know you can give multiple pacticipants like this.
that?s not true. It can take multiple, but for the reasons you d escribe most people don?t use it that way. You give it the thing you want to deploy, and it checks in the target environment all dependencies will continue to work
amomondragon
2024-03-05 03:42
Hello everyone. I am currently working on a POC to have the contract testing execution and publication run in one pipeline, and the verification in another separate pipeline.
To trigger the verification pipeline, I use a webhook from the pact-broker: `contract_content_changed`. In the webhook's body, I send the necessary information to initiate the provider build.
See the webhook in the :thread:.
Is there a way to obtain not only the `consumerVersionBranch` but also the consumer's base branch? Something like: `"consumerBaseBranch": "${pactbroker.consumerVersionBaseBranch}"` . Any ideas? Thanks in advance.
amomondragon
2024-03-05 03:43
```{
"description": "Trigger provider verification when contract content changes",
"events": [
{
"name": "contract_content_changed"
}
],
"request": {
"method": "POST",
"url": "https://jenkins.something.org",
"headers": {
"content-type": "application/json"
},
"body": {
"pactUrl": "${pactbroker.pactUrl}",
"consumerName": "${pactbroker.consumerName}",
"consumerVersion": "${pactbroker.consumerVersionNumber}",
"consumerBranch": "${pactbroker.consumerVersionBranch}",
"consumerTags": "${pactbroker.consumerVersionTags}",
"providerName": "${pactbroker.providerName}",
"providerVersion": "${pactbroker.providerVersionNumber}",
"providerBranch": "${pactbroker.providerVersionBranch}",
"providerTags": "${pactbroker.providerVersionTags}",
}
}
}```
matt.fellows
2024-03-05 04:09
You should also be using the later version of that event, which is an improved version of it: https://docs.pact.io/pact_broker/webhooks#the-contract-requiring-verification-published-event
amomondragon
2024-03-05 04:41
Let?s say my default branch is `develop`. Suppose a create a feature branch from there `feat-1`. So the base branch of `feat-1` is `develop`.
But sometimes the base branch is a different branch than the default branch and we verify the contract there.
In the Jenkins pipeline that publish the contract I can obtain both the feature branch and the base branch. When publishing the contract I can send the name of the feature branch and access it in the webhook. But I also need the base branch and I don't know how to send it. Can the `--branch` flag accept a list of branches?
To publish the contracts we do something similar to this in the consumer pipeline:
```def branchName = env.BRANCH_NAME
def baseBranchName = env.CHANGE_TARGET
"""
docker run --rm \
pactfoundation/pact-cli:latest \
publish \
pacts \
--consumer-app-version ${gitCommit} \
--broker-base-url=${brokerUrl} \
--tag=${tag} \
--branch=${branchName} \
"""```
amomondragon
2024-03-05 04:50
The current implementation is little bit old and uses tags instead of branches, we're updating it step by step. That's why I'm not using the improved version of the webhook yet. That will be done in the future when we migrate from tags to branches.
ben.brugman
2024-03-05 06:05
Hi Matt, tnx for your responses and explanations.
We are indeed moving away from --latests, so that was a poor example, we are now also looking into record release, since using tags is not advised.
But i can't figure out a way to either, check all the pacts, always, which i think is not common. or "give it the thing we want to deploy" how to check if we can deploy in a CI/CD way without any manual intervention.
Just to be sure and clear, we are talking about *native* mobile apps, not mobile web apps. This is why we want to check everything for everything and the release of all feature will have the same upcoming version.
That is why i was saying it feels like we are not using can-i-deploy correctly. because now we require a script to ensure we have a list of all our pacts in all our broker so we can use can-i-deploy for all of them, instead of saying check all for this broker.
But yeah, new to pact so perhaps we just have it completely wrong :sweat_smile:
matt.fellows
2024-03-05 06:38
> But I also need the base branch and I don?t know how to send it. Can the `--branch` flag accept a list of branches?
No, we don?t support that sorry. I don?t think we ought to build something like that either.
What do you need the base branch for?
matt.fellows
2024-03-05 06:40
For each mobile app you wish to release, you should `pact-broker record-release`. Each one of these are now considered ?in production?. When any dependency of that changes (e.g. the `provider`) and wants to release, when _it_ calls `can-i-deploy` it will check _all_ released versions of the mobile app.
i.e. `can-i-deploy` figures out what?s in the target environment, and if the app being deployed into it will be compatible
matt.fellows
2024-03-05 06:41
> That is why i was saying it feels like we are not using can-i-deploy correctly. because now we require a script to ensure we have a list of all our pacts in all our broker so we can use can-i-deploy for all of them, instead of saying check all for this broker.
yes, definitely you don?t need to do anything like this, unless you have some strange setup. It sounds like a typical mobile use case to me
matt.fellows
2024-03-05 06:42
When you remove a version of the mobile app from the app store, you just need to call `pact-broker record-support-ended` (see https://docs.pact.io/pact_broker/recording_deployments_and_releases#recording-support-ended-for-a-release)
ben.brugman
2024-03-05 08:30
okay, but then in my mind, my challenge shifts from testing all pacts, to finding out which pacts changed and put those through can-i-deploy. because one app will have multiple pacts and it's pacticipants. is that correct :thinking_face:
Or is this just a manual task and should not be integrated into CI
matt.fellows
2024-03-05 09:39
> okay, but then in my mind, my challenge shifts from testing all pacts, to finding out which pacts changed and put those through can-i-deploy. because one app will have multiple pacts and it?s pacticipants. is that correct
I don?t understand why you need to work out which pacts changed? If you?re deploying Application A, simply ask `can-i-deploy` if you can deploy it. Whether or not the contracts have changed is orthogonal to that problem. It will say ?OK, you want to deploy `A` into `prod`, let me go and look at all of the dependencies of that in prod and check that you won?t break them and/or they won?t break you? (plus all released versions, in the case of mobile app and the provider is the one asking the question)
konstantin.manna
2024-03-05 09:47
Thanks for noticing @yousafn I think that was the problem. We seemed to have wrongly placed this gitlab-ci-yaml multiline symbol there. Without it we actually get the verbose content. :blush: :+1:
ben.brugman
2024-03-05 14:05
Well, we are working consumer driven, so we are planning to run `can-i-deploy` from the consumer side (the mobile apps).
When you say `Deploying application A`, this means multiple pacts associated to that application right?
Therefor the assumption remains that you need to run `can-i-deploy` for all your separate pacts that you have. How else do you make certain all is well?
lcruz
2024-03-05 21:25
:wave: I've got a question about the exposed `/metrics` endpoint. We've got an internal instance of a pact broker and it shows a total of 8 unique "pacticipants" but I'm getting 12. I'm curious if I'm just misunderstanding what a pacticipant is or if there's something I'm missing.
I'm also wondering if it's some cache/DB issue?
``` "pacticipants": {
"count": 12,
"withMainBranchSetCount": 5
},```
lcruz
2024-03-05 21:26
Perhaps it's counting the `integrations` ?
``` "integrations": {
"count": 4
},```
lcruz
2024-03-06 00:03
Ah! Hey again Matt - Thanks!
Yeah, a `/pacticipants` is giving 12 and I'm realizing the 4 are referencing pacticipants that we manually deleted from the UI
matt.fellows
2024-03-06 00:08
yep, so you might have deleted the integrations, but the apps are still there
lcruz
2024-03-06 00:09
Got it! Yeah, realizing the nomenclature and that an integration is a different data type.
Would manual `DELETE` with curl suffice?
lcruz
2024-03-06 00:13
:boom: That worked. Seeing the correct number now via `/metrics`. Cheers, Matt!
ben.brugman
2024-03-06 09:18
I think i finally see the light buld appearing over my head.
We should use the provider pacticipants when we do `Can-I-Deploy` , not the consumer pacticipants.
now indeed it will pick up all the pacticipants and it's versions
abubics
2024-03-06 10:10
I mean, you can run `can-i-deploy` (or `can-i-release`) for you deploy/release either side. You should do both, really.
abubics
2024-03-06 10:12
And just to clarify some vocab, a pact is a contract between 2 participants (a single version on each side only). The broker knows all the history it's ever been sent, and that's where all tge reasoning power comes from.
abubics
2024-03-06 10:15
When you say "multiple pacts associated to that application", every version of every pact that has the application as a participant is a potential candidate for checking against. So recording releases, deployments, replacements, and end-of-support all help reducing the candidates to a sensible set.
matt.fellows
2024-03-06 23:16
> We should use the provider pacticipants when we do `Can-I-Deploy` , not the consumer pacticipants.
yes!
or rather, in the consumer build pipeline you add the consumer app that you are deploying.
In the provider build pipeline you add the provider app that you are deploying.
in general - you specify the pacticipant you are deploying in can I deploy. Think of saying it in English to your team mate ?That work on ApplicationX is done, _can I deploy_ it to production?? That?s effectively what can-i-deploy is for
ben.brugman
2024-03-07 09:28
Cool, sorry it took me that long to figure out.
I will look into how to record-release to all pacts in CI
I might be back with some more questions :face_with_hand_over_mouth:
dimundo
2024-03-07 16:25
hi!
i want to get pacticipant version on environment ( better with pact-broker cli )
but cant find proper query :disappointed: any hints ?
dominicbehrig
2024-03-07 17:36
Hey! Im trying to publish my pacts to the pact broker in my ci workflow. I have the maven plugin (shown below) and my workflow (shown below). I get a 409 error stating "Each pact must be published with a unique consumer version number". Where exactly do i set the consumer version number?
matt.fellows
2024-03-07 22:25
As in, you?d like to find an application that has been deployed to a particular environment?
matt.fellows
2024-03-07 22:28
There might be a feature request open for this to add to the CLI. If you?re open we would be happy to see it added as a PR
mcruzdrake
2024-03-11 12:20
Hi @dominicbehrig, usually it should be the GitHub SHA. Depending on which CI you are using, this can be accessed by built-in environment variables. For example, if you are using GitHub actions, it's `${{ github.sha }}`. If you are using GitLab, it's `${CI_COMMIT_SHA}`
dominicbehrig
2024-03-11 20:55
Thanks for the reply. I understand it should be the sha but where/what exactly needs to be set? I tried setting <pacticipantVersion> under the maven plugin config but that didnt seem to work. I dont see a consumerVersion that can be set here.
Also not sure if it matter but this is trying to upload 2 pact files. When the action runs the first pact file uploads no problem but the second one fails with the 409.
Thanks for your help in advanced!
mcruzdrake
2024-03-12 13:04
Ah, I see! Sorry I misunderstood the question. So, the version should be set when you run the command to upload the pact using the pact CLI. For example, something like:
```pact-broker publish ./pacts --consumer-app-version=$GITHUB_SHA --branch=$GITHUB_BRANCH --broker-base-url=$PACT_BROKER_BASE_URL --broker-token=$PACT_BROKER_TOKEN```
From the above there is an option called `--consumer-app-version`. This is where you need to set itl
ddongre
2024-03-12 14:29
:wave: folks, while making a POST request to execute a webhook I created in my firm's self-hosted pact broker I keep getting the following,
```For security purposes, the response details are not logged. To enable response logging, configure the webhook_host_whitelist property```
We are using a pact-broker https://github.com/pact-foundation/pact-broker-chart/tree/master/charts/pact-broker#values and have explicitly set the `webhookHttpMethodWhitelist` value to "POST". Any idea why I might be seeing this issue despite creating the whitelist?
ddongre
2024-03-12 15:34
Update: Got it working. Adding all other variables `webhookSchemeWhitelist`, `webhookHostWhitelist` fixed it
ddongre
2024-03-12 15:36
Can we make the documentation with that a bit more concise? I sort had to play around with the variables and got it working but making it a bit more specific with the variables would make it easier for future adapters IMO
matt.fellows
2024-03-12 22:32
Thanks for sharing. Would you care to raise a PR with the suggested improvement?
matt.fellows
2024-03-12 22:38
If you haven?t run https://docs.pactflow.io/docs/workshops/ci-cd/ before, I?d suggest doing so. The only difference, essentially, is that you need to using releases instead of deployments, and you need to `record-support-ended` when you deprecate a mobile version.
alan.barker
2024-03-21 13:22
Hi
Is there any way to clear/delete the `pb:error-logs` for a webhook?
We've hit on occasions where a webhook has a problem, e.g. incorrect pipeline ID has been supplied when creating the webhook, which results in a legitimate error. Because the pipeline cannot be found.
When correcting such an issue (correcting the pipeline id) the error logs are still present.
Is there any way to clear these logs? Or do they only clear when the webhook (with the new pipeline ID) is successfully triggered for its event (`contract_requiring_verification_published`) ?
Manually triggering the webhook, does not clear the error log either.
Thanks
marcusdoingtech
2024-03-21 14:51
Hi, is there a way to retrieve the version (git commit hash) of a provided tag on the provider side?
I have tagged ?deployed-prod? on my provider for a specific old commit on Pact Broker and now I want to retrieve that commit hash so that I can build the provider from that commit hash to perform contract verification.
marcusdoingtech
2024-03-21 15:45
I also posted this on Stackoverflow: https://stackoverflow.com/questions/78201206/is-there-a-way-to-retrieve-the-version-git-commit-hash-of-a-provided-tag-on-th
marcusdoingtech
2024-03-22 05:00
Because we are using older version of pact and I believe it only supports tag. But it there a way to retrieve the version (git commit hash) of a provided tag on the *provider* side?
marcusdoingtech
2024-03-22 15:18
I have tagged ?deployed-prod? on my provider for a specific old commit on Pact Broker and now I want to retrieve that commit hash so that I can build the provider from that commit hash to perform contract verification.
marcusdoingtech
2024-03-22 15:19
Just found that I can retrieve that info from pact-broker: /pacticipants/{some-provier}/latest-version/deployed-prod
martin.gallauner
2024-03-25 14:28
HI there!
I try to make the `record-deployment` work. But it tells me that the requested document was not found on this server.
What I did:
? `pact-broker publish` returns published successfully and gives me an url where to find my pact. something like `view the pubished pact at http://broker.pactflow.io/pacts/provider/{providerName}/consumer/{consumerName}/version/{gitHash}`
? `pact-broker record-deployment` returns `Error making request to http://broker.pactflow.io/pacticipants/{consumerName}/versions`
should I be concerned about the difference of the url they publish to or search the pact from?
If yes, what is should be the `pacticipant` parameter when running `pact-broker record-deployment` ?
Thanks!
martin.gallauner
2024-03-25 15:01
I found out whats wrong :slightly_smiling_face:
The name of the consumer in the pact definition didn't matched the variable used within the pipelines... :facepalm:
chris.speck
2024-03-28 01:12
Hi, maybe the question below is better suited in this channel: what is the recommended way to use `can-i-merge` when working out of a monorepo? more details below.
ben.brugman
2024-04-02 07:35
Hi again, i was wondering is anyone working with sub certificates?
For our project when using the broker CLI we locally use the _*SSL_CERT_FILE*_ system variable.
This worked fine, but when we updated to new certificates we got SUB certificates.
I struggled to get it to work with the ROOT certificate, it just didn't work.
Then i tried to set a directory instead with _*SSL_CERT_DIR*_, i stored my old, new ROOT and new SUB in there but that didn't work.
Ultimately, i took these 3 certificates contents and merged them into one certificate.pem file and used _*SSL_CERT_FILE*_ again.
This did the trick, i am just wondering is this expected?
yousafn
2024-04-02 15:07
I had some notes on the use of SSL_CERT_DIR, when testing it out with gitea, and ruby. It didn?t work unless I followed some pre-reqs
> Your understanding of the _SSL_CERT_DIR_ environment variable is correct. The directory that is specified in the variable is meant for trusted root certificates (but not for intermediate ones!).
> When copying the root certificates over to this directory, they have to follow a certain naming convention. The certificate should be in the regular PEM format, but the file name must be named
> [HASH].0
> where *[HASH]* is the hashed value of the certificate?s subject. You can find out this hash value with the following command (replace root.cer with the file name of your root certificate)
> openssl x509 -subject_hash -in root.cer
for me with gitea
```gitea cert --host git
ls
cert.pem key.pem
openssl x509 -subject_hash -in cert.pem
43b31b52
cp cert.pem 43b31b52.0
SSL_CERT_DIR=$PWD curl https://git/```
How were the certs setup in your SSL_CERT_DIR?
ben.brugman
2024-04-03 12:19
The certs where just lose .pem files with one certification inside, and then stored in a folder (dir).
i did not do any of this fancy stuff :slightly_smiling_face:
ashley.gautama
2024-04-03 12:28
Hello, question about webhooks in the broker, specifically about the authorization part to one of the repository cloud systems (e.g. bitbucket). In the documentation , the authorization part (with the token) is created (and stored in the broker) when you create a webhook. I am going to assume the pact broker, everytime when the webhook triggers it retrieves this token and then executes the pipeline. However we do not want the authorization token to be stored and retrieved in the broker. Instead, we want to to grab this token dynamically form a secure location in the repository cloud system. Is there someway we can set this up in the broker?
ashley.gautama
2024-04-03 12:30
you might ask
'Why do you want this, cant you use a non personal accesstoken'?
and the answer is simple:
'they are not provided so easily'
yousafn
2024-04-03 12:35
Does your use of the SSL_CERT_DIR work with anything else? with Curl?
I imagine it won?t. that it what I found from testing and my ref sources are below. it seemed I wrongly assumed I could just move the file in a dir, update to SSL_CERT_DIR and bingo, but that wasn?t the case.
https://unix.stackexchange.com/a/698873
https://stackoverflow.com/a/73949796
https://documentation.sas.com/doc/en/calcdc/3.1/secref/p0exqtnxh7wjdxn1kvq5os1sogp9.htm
yousafn
2024-04-03 12:41
the open source broker doesn?t offer that functionality (retrieval of secrets from external sources)
if you were able to do that, how would you ensure that your broker can access the secure location? surely they would need a token for that, and you are back at storing a token in the broker?
you could have your broker call a proxy configured in your network, that acts as a gateway to your internal system, implementation may vary dependant on setup.
ashley.gautama
2024-04-04 08:06
Thanks @yousafn. Not sure if the proxy 'route' you mentioned will solve our issue. And you make a great point about retrieval from the secure location (via token again :stuck_out_tongue: ). I will try going the NPA route then.
Security team might ask questions then though. Is there any way to retrieve the value as plain text of the token in the broker ui, via hal browser api/cli broker tools command?
How is the password stored encryped (algorith used) in the postgres database? Thanks again :slightly_smiling_face:
james.corry
2024-04-05 10:00
Hello,
Hopefully a quick question regarding https://docs.pact.io/getting_started/how_pact_works#provider-verification just to confirm the flow. (See attachment from your docs too).
On the provider side, do we need an actual instance of our API to send expected requests and receive actual responses or can the provider API be mocked?
Thank you
matt.fellows
2024-04-05 10:27
on the consumer side, the provider is mocked.
But if you mocked the provider during the provider verification, what value is the test?
zied
2024-04-05 11:30
Hello all, I have set up PACT in an existing Node JS project using yarn workspaces. I have added 3 scripts to run consumer, provider and to publish.
Consumer and provider work fine however when running the publish command. The command keeps waiting without any error or log until I cancel the command. Note that I am loading the workspace before launching the command but then I have an error saying pact-broker command not found. Here is my scripts in my main package.json
`"test:publish": "pact-broker publish ./pacts --consumer-app-version=\"$(npx absolute-version)\" --auto-detect-version-properties --broker-base-url=https://*****.http://pactflow.io --broker-token=***********"`
yousafn
2024-04-05 11:36
if you run npx absolute-version it may be asking for you to install it, you can suppress with `--yes` but its not compatible with all node versions (npx changed the default behaviour) - if you swap out for a fixed value, you may see it work, and then you can install absolute-version prior
https://docs.npmjs.com/cli/v8/commands/npx#compatibility-with-older-npx-versions
> ? To prevent security and user-experience problems from mistyping package names, `npx` prompts before installing anything. Suppress this prompt with the `-y` or `--yes` option.
pact-broker command will be in the node_modules/.bin folder
zied
2024-04-05 11:43
thanks Yousaf! indeed it did ask to me install it. I have then replaced the absolute version variable with a hardcoded value and relaunched the same command. I guess I am facing a different issue now as the command instantly replies with pact-broker not found. I run the command this way :
`yarn workspace @domain/name test:publish`
yousafn
2024-04-05 11:45
I would imagine that is an issue with yarn workspaces, and its looks up in the node_modules bin folder.
You can install the tools directory from the releases page of
https://github.com/pact-foundation/pact-ruby-standalone
and make them available on your path.
Otherwise probably some digging in the docs for yarn workspaces is required.
If you can spin up a minimal repro project on github, it will aid us all in trying to resolve.
zied
2024-04-05 11:58
okay sure I will have a look at Yarn workspaces and come back to you if any updates
james.corry
2024-04-05 13:00
Thank you and appreciate the quick reply Matt. That clear that up for us, thanks again
zied
2024-04-05 16:14
Quick update : for time constraints I have opted to use pact-broker standalone tool and it works fine
alan.barker
2024-04-08 15:55
The example scenario is as follows.
When the webhook was first triggered, with a new/changed pact, the azure pipeline was attempted to be triggered. However the verification pipeline was not granted permission to a an Azure Pipeline Variable Group. Therefore the logs show an error.
Permissions were then resolved in Azure.
But since that point, the consumer pact has not changed, and therefore it has not triggered the webhook again (contract_requiring_verification_published event). This leaves the error log in place, and therefore leaves the Webhook status the red/pink colour.
ben.brugman
2024-04-09 15:43
Hi Again :slightly_smiling_face:
In a last desperate attempt we tried `--user=tokenuuid`
This did the trick!
We are setting up webhooks, we want to use Basic Auth and pass our Token without a username. so `--user='':'tokenuuid'`
This gives us a 302 not found, but if we use the same token in an encrypted fashion via the `--header='Authorization:Basic ecryptedtokenuuid` (Postman gives us this encrypted token)
We get a 200. are we doing something wrong? we tried alot of things already like:
? `--user=':tokenuuid'`
? `--user=:tokenuuid`
? `--user='':'tokenuuid'`
ben.brugman
2024-04-10 05:52
Maybe good to point out, that if you put just your token in the user field like we did, the token is not stored as a secret (***) and thus exposed and readable in the broker HAL viewer.
charlan.bettiol
2024-04-10 18:06
Hello everyone, everything good? I have the following problem, when I enable the user and password configuration in broke when I go to pact-broker with user and password I get error 400 and when I disable the user and password in the dokerfile and everything goes correctly, has anyone experienced this ?
```environment:
SSL_CERT_FILE: /Users/charlan.bettiol/Documents/certificados/_.livelo.intranet.cer
PACT_BROKER_PORT: '9292'
PACT_BROKER_DATABASE_URL: ""
PACT_BROKER_LOG_LEVEL: DEBUG
PACT_BROKER_LOG_FORMAT: color
PACT_BROKER_SQL_LOG_LEVEL: DEBUG
PACT_BROKER_HTTP_DEBUG_LOGGING_ENABLED: true
PACT_BROKER_DISABLE_SSL_VERIFICATION: true
PACT_BROKER_BASIC_AUTH_ENABLED: true
PACT_BROKER_BASIC_AUTH_USERNAME: teste
PACT_BROKER_BASIC_AUTH_PASSWORD: 1234```
command:
`pact-broker list_environments -b http://localhost:9292 --broker-username=teste --broker-password=1234`
joshua.ellis
2024-04-10 20:55
Just to double check, are you able to access the Pact Broker by pointing your browser to `http://localhost:9292`? It should prompt you for a username and password if you have basic auth enabled.
You can also test this with `curl http://user:pass@localhost:9292`
joshua.ellis
2024-04-10 21:00
How very strange. Is it just the `pact-broker list-environments` endpoint that isn't working?
charlan.bettiol
2024-04-10 21:01
its works, i try this `pact-broker publish ${PWD}/target/pacts --consumer-app-version ${VERSION} --branch ${BRANCH} --broker-base-url http://localhost:9292 -u teste -p 1234` and i have a same problem
charlan.bettiol
2024-04-10 21:09
`pact-broker publish ${PWD}/target/pacts --consumer-app-version ${VERSION} --branch ${BRANCH} --broker-base-url http://localhost:9292 -u teste -p 1234 -v` output:
```opening connection to localhost:9292...
opened
<- "GET /? HTTP/1.1\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nAuthorization: [redacted]\r\n"
-> "HTTP/1.1 200 OK\r\n"
-> "Vary: Accept\r\n"
-> "Content-Type: application/hal+json;charset=utf-8\r\n"
-> "Date: Wed, 10 Apr 2024 21:07:02 GMT\r\n"
-> "Server: Webmachine-Ruby/2.0.0 Rack/1.3\r\n"
-> "X-Pact-Broker-Version: 2.107.1\r\n"
-> "X-Content-Type-Options: nosniff\r\n"
-> "Content-Length: 4300\r\n"
-> "\r\n"
reading 4300 bytes...
-> "{\"_links\":{\"self\":{\"href\":\"http://localhost:9292\",\"title\":\"Index\",\"templated\":false},\"pb:publish-pact\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/consumer/{consumer}/version/{consumerApplicationVersion}\",\"title\":\"Publish a pact\",\"templated\":true},\"pb:publish-contracts\":{\"href\":\"http://localhost:9292/contracts/publish\",\"title\":\"Publish contracts\",\"templated\":false},\"pb:latest-pact-versions\":{\"href\":\"http://localhost:9292/pacts/latest\",\"title\":\"Latest pact versions\",\"templated\":false},\"pb:tagged-pact-versions\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/consumer/{consumer}/tag/{tag}\",\"title\":\"All versions of a pact for a given consumer, provider and consumer version tag\",\"templated\":false},\"pb:pacticipants\":{\"href\":\"http://localhost:9292/pacticipants\",\"title\":\"Pacticipants\",\"templated\":false},\"pb:pacticipant\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}\",\"title\":\"Fetch pacticipant by name\",\"templated\":true},\"pb:latest-provider-pacts\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/latest\",\"title\":\"Latest pacts by provider\",\"templated\":true},\"pb:latest-provider-pacts-with-tag\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/latest/{tag}\",\"title\":\"Latest pacts for provider with the specified tag\",\"templated\":true},\"pb:provider-pacts-with-tag\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/tag/{tag}\",\"title\":\"All pact versions for the provider with the specified consumer version tag\",\"templated\":true},\"pb:provider-pacts\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}\",\"title\":\"All pact versions for the specified provider\",\"templated\":true},\"pb:latest-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/latest-version\",\"title\":\"Latest pacticipant version\",\"templated\":true},\"pb:latest-tagged-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/latest-version/{tag}\",\"title\":\"Latest pacticipant version with the specified tag\",\"templated\":true},\"pb:webhooks\":{\"href\":\"http://localhost:9292/webhooks\",\"title\":\"Webhooks\",\"templated\":false},\"pb:webhook\":{\"href\":\"http://localhost:9292/webhooks/{uuid}\",\"title\":\"Webhook\",\"templated\":true},\"pb:integrations\":{\"href\":\"http://localhost:9292/integrations\",\"title\":\"Integrations\",\"templated\":false},\"pb:pacticipant-version-tag\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/versions/{version}/tags/{tag}\",\"title\":\"Get, create or delete a tag for a pacticipant version\",\"templated\":true},\"pb:pacticipant-branch-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/branches/{branch}/versions/{version}\",\"title\":\"Get or add/create a pacticipant version for a branch\",\"templated\":true},\"pb:pacticipant-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/versions/{version}\",\"title\":\"Get, create or delete a pacticipant version\",\"templated\":true},\"pb:metrics\":{\"href\":\"http://localhost:9292/metrics\",\"title\":\"Get Pact Broker metrics\"},\"pb:can-i-deploy-pacticipant-version-to-tag\":{\"href\":\"http://localhost:9292/can-i-deploy?pacticipant={pacticipant}&version={version}&to={tag}\",\"title\":\"Determine if an application version can be safely deployed to an environment identified by the given tag\",\"templated\":true},\"pb:can-i-deploy-pacticipant-version-to-environment\":{\"href\":\"http://localhost:9292/can-i-deploy?pacticipant={pacticipant}&version={version}&environment={environment}\",\"title\":\"Determine if an application version can be safely deployed to an environment\",\"templated\":true},\"pb:provider-pacts-for-verification\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/for-verification\",\"title\":\"Pact versions to be verified for the specified provider\",\"templated\":true},\"beta:provider-pacts-for-verification\":{\"name\":\"beta\",\"href\":\"http://localhost:9292/pacts/provider/{provider}/for-verification\",\"title\":\"DEPRECATED - please use pb:provider-pacts-for-verification\",\"templated\":true},\"curies\":[{\"name\":\"pb\",\"href\":\"http://localhost:9292/doc/{rel}?context=index\",\"templated\":true},{\"name\":\"beta\",\"href\":\"http://localhost:9292/doc/{rel}?context=index\",\"templated\":true}],\"pb:environments\":{\"title\":\"Environments\",\"href\":\"http://localhost:9292/environments\",\"templated\":false},\"pb:environment\":{\"title\":\"Environment\",\"href\":\"http://localhost:9292/environments/{uuid}\",\"templated\":true}}}"
read 4300 bytes
Conn keep-alive
opening connection to localhost:9292...
opened
<- "POST /contracts/publish HTTP/1.1\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nAuthorization: [redacted]\r\n"
<- "{\"pacticipantName\":\"dummy-consumer-java17\",\"pacticipantVersionNumber\":\"0.1\",\"tags\":[],\"branch\":\"DQ-338-ConsumerJava17ok\",\"contracts\":[{\"consumerName\":\"dummy-consumer-java17\",\"providerName\":\"dummy-provider-java17\",\"specification\":\"pact\",\"contentType\":\"application/json\",\"content\":\"eyJjb25zdW1lciI6eyJuYW1lIjoiZHVtbXktY29uc3VtZXItamF2YTE3In0sImludGVyYWN0aW9ucyI6W3siZGVzY3JpcHRpb24iOiJhIHBhY3QiLCJwcm92aWRlclN0YXRlcyI6W3sibmFtZSI6InJldHJpZXZpbmcgYSBwYWN0In1dLCJyZXF1ZXN0Ijp7ImhlYWRlcnMiOnsiQ29udGVudC1UeXBlIjoiYXBwbGljYXRpb24vanNvbiJ9LCJtZXRob2QiOiJHRVQiLCJwYXRoIjoiL3YxL2NhdGVnb3JpZXMifSwicmVzcG9uc2UiOnsiYm9keSI6eyJldmVudFR5cGUiOiJDUkVBVEVEIn0sImhlYWRlcnMiOnsiQ29udGVudC1UeXBlIjoiYXBwbGljYXRpb24vanNvbjsgY2hhcnNldD1VVEYtOCJ9LCJtYXRjaGluZ1J1bGVzIjp7ImhlYWRlciI6eyJDb250ZW50LVR5cGUiOnsiY29tYmluZSI6IkFORCIsIm1hdGNoZXJzIjpbeyJtYXRjaCI6InJlZ2V4IiwicmVnZXgiOiJhcHBsaWNhdGlvbi9qc29uKDtcXHM/Y2hhcnNldD1bXFx3XFwtXSspPyJ9XX19fSwic3RhdHVzIjoyMDB9fV0sIm1ldGFkYXRhIjp7InBhY3QtanZtIjp7InZlcnNpb24iOiI0LjYuMyJ9LCJwYWN0U3BlY2lmaWNhdGlvbiI6eyJ2ZXJzaW9uIjoiMy4wLjAifX0sInByb3ZpZGVyIjp7Im5hbWUiOiJkdW1teS1wcm92aWRlci1qYXZhMTcifX0=\"}]}"
-> "HTTP/1.1 400 Bad Request\r\n"
-> "Content-Type: text/plain\r\n"
-> "Content-Length: 0\r\n"
-> "\r\n"
reading 0 bytes...
-> ""
read 0 bytes
Conn keep-alive```
charlan.bettiol
2024-04-10 21:11
```curl --location 'localhost:9292/contracts/publish' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic dGVzdGU6MTIzNA==' \
--data '{
"pacticipantName":"dummy-consumer-java17",
"pacticipantVersionNumber":"0.1",
"tags":[],
"branch":"DQ-338-ConsumerJava17ok",
"contracts":[
{"consumerName":"dummy-consumer-java17",
"providerName":"dummy-provider-java17",
"specification":"pact",
"contentType":"application/json",
"content":"eyJwYWN0aWNpcGFudE5hbWUiOiJkdW1teS1jb25zdW1lci1qYXZhMTciLCJwYWN0aWNpcGFudFZlcnNpb25OdW1iZXIiOiIwLjEiLCJ0YWdzIjpbXSwiYnJhbmNoIjoiRFEtMzM4LUNvbnN1bWVySmF2YTE3b2siLCJjb250cmFjdHMiOlt7ImNvbnN1bWVyTmFtZSI6ImR1bW15LWNvbnN1bWVyLWphdmExNyIsInByb3ZpZGVyTmFtZSI6ImR1bW15LXByb3ZpZGVyLWphdmExNyIsInNwZWNpZmljYXRpb24iOiJwYWN0IiwiY29udGVudFR5cGUiOiJhcHBsaWNhdGlvbi9qc29uIiwiY29udGVudCI6ImV5SmpiMjV6ZFcxbGNpSTZleUp1WVcxbElqb2laSFZ0YlhrdFkyOXVjM1Z0WlhJdGFtRjJZVEUzSW4wc0ltbHVkR1Z5WVdOMGFXOXVjeUk2VzNzaVpHVnpZM0pwY0hScGIyNGlPaUpoSUhCaFkzUWlMQ0p3Y205MmFXUmxjbE4wWVhSbGN5STZXM3NpYm1GdFpTSTZJbkpsZEhKcFpYWnBibWNnWVNCd1lXTjBJbjFkTENKeVpYRjFaWE4wSWpwN0ltaGxZV1JsY25NaU9uc2lRMjl1ZEdWdWRDMVVlWEJsSWpvaVlYQndiR2xqWVhScGIyNHZhbk52YmlKOUxDSnRaWFJvYjJRaU9pSkhSVlFpTENKd1lYUm9Jam9pTDNZeEwyTmhkR1ZuYjNKcFpYTWlmU3dpY21WemNHOXVjMlVpT25zaVltOWtlU0k2ZXlKbGRtVnVkRlI1Y0dVaU9pSkRVa1ZCVkVWRUluMHNJbWhsWVdSbGNuTWlPbnNpUTI5dWRHVnVkQzFVZVhCbElqb2lZWEJ3YkdsallYUnBiMjR2YW5OdmJqc2dZMmhoY25ObGREMVZWRVl0T0NKOUxDSnRZWFJqYUdsdVoxSjFiR1Z6SWpwN0ltaGxZV1JsY2lJNmV5SkRiMjUwWlc1MExWUjVjR1VpT25zaVkyOXRZbWx1WlNJNklrRk9SQ0lzSW0xaGRHTm9aWEp6SWpwYmV5SnRZWFJqYUNJNkluSmxaMlY0SWl3aWNtVm5aWGdpT2lKaGNIQnNhV05oZEdsdmJpOXFjMjl1S0R0Y1hITS9ZMmhoY25ObGREMWJYRngzWEZ3dFhTc3BQeUo5WFgxOWZTd2ljM1JoZEhWeklqb3lNREI5ZlYwc0ltMWxkR0ZrWVhSaElqcDdJbkJoWTNRdGFuWnRJanA3SW5abGNuTnBiMjRpT2lJMExqWXVNeUo5TENKd1lXTjBVM0JsWTJsbWFXTmhkR2x2YmlJNmV5SjJaWEp6YVc5dUlqb2lNeTR3TGpBaWZYMHNJbkJ5YjNacFpHVnlJanA3SW01aGJXVWlPaUprZFcxdGVTMXdjbTkyYVdSbGNpMXFZWFpoTVRjaWZYMD0ifV19"
}
]
}'```
charlan.bettiol
2024-04-10 21:12
I made the same call via curl, simply copy it from the console and transform it to curl and it works, but it doesn't work with pact-bkoker cli
joshua.ellis
2024-04-10 21:52
I wonder whether Matt knows about this (it's just a bit early right now in Australia). I'll ping him when it's a more reasonable hour :slightly_smiling_face:
charlan.bettiol
2024-04-11 11:05
@matt.fellows
```pact-broker-1 | 2024-04-10 21:51:43.330570 D [8:puma srv tp 001] PactBroker::Api::Middleware::HttpDebugLogs -- env -- { "SCRIPT_NAME" => "", "QUERY_STRING" => "", "SERVER_PROTOCOL" => "HTTP/1.1", "SERVER_SOFTWARE" => "puma 5.6.5 Birdie's Version", "GATEWAY_INTERFACE" => "CGI/1.2", "REQUEST_METHOD" => "GET", "REQUEST_PATH" => "/", "REQUEST_URI" => "/?", "HTTP_VERSION" => "HTTP/1.1", "HTTP_ACCEPT" => "application/hal+json", "HTTP_USER_AGENT" => "Ruby", "HTTP_AUTHORIZATION" => "Bearer SpLx14YI_8ynt5rlb8NsbQ", "HTTP_HOST" => "localhost:9292", "SERVER_NAME" => "localhost", "SERVER_PORT" => "9292", "PATH_INFO" => "/", "REMOTE_ADDR" => "192.168.65.1", "rack.input" => "" }
pact-broker-1 | 2024-04-10 21:51:43.331570 D [8:puma srv tp 001] PactBroker::Api::Middleware::HttpDebugLogs -- response -- { "status" => 400, "headers" => { "Content-Type" => "text/plain", "Content-Length" => "0" }, "body" => [] }```
charlan.bettiol
2024-04-11 13:43
Hello, I have another question, I need to add pactbroker within the backstage however when I tried to use it via iframe I got the following error:`Refused to frame 'http://localhost:9292/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'".` is it possible to adjust pact to allow iframe?
My code:
```export const ExampleFetchComponent = () => {
const classes = useStyles();
const { value, loading, error } = useAsync(async () => {
// Simulação de uma chamada assíncrona para obter a URL do iframe
// Você pode substituir isso por sua lógica real
const url = 'http://localhost:9292/';
return url;
}, []);
if (loading) {
return <Progress />;
} else if (error) {
return <ResponseErrorPanel error={error} />;
}
// Renderizar o iframe
return (
<div className={classes.iframeContainer}>
<iframe
className={classes.iframe}
src="http://localhost:9292/"
title="Iframe Example"
allow="fullscreen"
/>
</div>
);
}; ```
rouaa.benayed
2024-04-11 15:50
Hello everyone, Im new here and when I tried these commands in my kubernetes cluster on my server, I had a problem with postgres, can anyone help?
helm repo add bitnami https://charts.bitnami.com/bitnami
helm repo add pact-broker https://pact-foundation.github.io/pact-broker-chart/
helm install pact-broker pact-broker/pact-broker
joshua.ellis
2024-04-11 23:13
I might be wrong, but this seems to be an issue with bitnami's PGSQL image. Have you tried using another postgres image (such as, the official https://hub.docker.com/_/postgres)?
Perhaps you should report this issue with Bitnami directly.
matt.fellows
2024-04-12 01:13
> ?HTTP_AUTHORIZATION? => ?Bearer SpLx14YI_8ynt5rlb8NsbQ?
So _this_ looks suspicious. It shouldn?t be using a bearer token because you?ve supplied it basic auth credentials.
matt.fellows
2024-04-12 01:13
this implies perhaps there is an environment variable present when calling the CLI (`PACT_BROKER_TOKEN`), which is taking precedence
matt.fellows
2024-04-12 01:13
That _might_ be what?s responsible for the 400, because it would be expecting basic auth?
matt.fellows
2024-04-12 01:16
I think this might help: https://github.com/pact-foundation/pact_broker/discussions/401
matt.fellows
2024-04-12 01:17
It looks like this might be the code you need to modify if using nginx / proxy isn?t an option: https://github.com/pact-foundation/pact_broker/blob/ff72d03c567b76939db8d7450fad2a1d20879b5b/lib/pact_broker/configuration.rb#L71
charlan.bettiol
2024-04-12 12:00
I actually tested this with the variable set in the environment, even though I wasn't using it in the command, it was passing it, thank you very much!
charlan.bettiol
2024-04-12 12:28
@matt.fellows About this I use a load balancer, in this case I would have to capture the request and change the header right? The iframe will be in the application https://backstage.mycorp.intranet/ so it should look like this, right? `X-Frame-Options: ALLOW-FROM https://backstage.mycorp.intranet/`
charlan.bettiol
2024-04-12 17:02
@matt.fellows I was able to test it by injecting the `Content-Security-Policy: frame-ancestors` * header and it worked inside the iframe, thank you very much
matt.fellows
2024-04-13 04:46
Perfect! Yes `x-frame-options` is deprecated, and the CSP headers is a better way to go. Glad you could sort it out!
adam.witko
2024-04-24 12:38
hey a question for folks who know a thing or two about the broker webhooks. I've registered a webhook for the `contract_requiring_verification_published` event with url `https://gitlab.com/api/v4/projects/${PROJECT_ID}/ref/${BRANCH}/trigger/pipeline?token=${TOKEN}&variables[PACT_URL]=\${pactbroker.pactUrl}&variables[PACT_PROVIDER_VERSION]=\${pactbroker.providerVersionNumber}&variables[PACT_PROVIDER_BRANCH]=\${pactbroker.providerVersionBranch}` . For some reason when the broker triggers the pipeline it specifies a provider version number for the version of the provider at time of webhook creation and not for the latest main version of the provider. When the provider is deployed to an env it is recording the deployment with the git short sha for the commit and the latest main is months ahead of the version specified as `PACT_PROVIDER_VERSION` .
I'm on version `2.102.2` of the broker.
I have a sneaking suspicion that because the verification job does not have the correct provider version that it's unable to offer the pre-verifier support to contracts.
matt.fellows
2024-04-25 02:34
What does the triggered execution logs say? It will state the reason why the webhook fired in the first place.
adam.witko
2024-04-25 07:26
Hey @matt.fellows. I'll find and dig in to them and share what I find.
I've read through the documentation for `contract_requiring_verification_published` event and I wanted to ask if my understanding is correct. If a push of a contract contains the contents of a previously verified contract by the main provider it should be pre-reverified and not trigger the webhook.
matt.fellows
2024-04-25 10:21
It will be pre verified only for versions of the provider that have verified the same contents.
This might be why it's triggering an OLED provider version. Perhaps it's deployed to an environment (even if an environment you don't use)
matt.fellows
2024-04-26 00:03
also OLED -> old (was on mobile, assuming that was autocorrect :laughing: )
adam.witko
2024-04-26 09:21
It only took me around 2 minutes to notice you intended to say old and not an acronym I was unfamiliar with:smile:
radek.stolarczyk
2024-05-06 10:54
Hello, I have a problem with the pact broker, that I cannot solve. :disappointed: Anyone seen similar issue?
When I run this:
```docker run --rm -v /${PWD}:/${PWD} -w ${PWD} \
-e PACT_BROKER_BASE_URL=xxxxx \
-e PACT_BROKER_TOKEN=xxxx \
pactfoundation/pact-cli:latest \
pactflow publish-provider-contract \
/Users/xxxx/PycharmProjects/XD_ContractTesting_Provider/bi_directional/provider.yaml \
--provider "example-provider" \
--provider-app-version=1.0.0 \
--content-type=application/yaml \
--verification-exit-code=0 \
--verification-results /Users/xxxx/PycharmProjects/XD_ContractTesting_Provider/bi_directional/oas_generated.txt \
--verification-results-content-type text/plain```
I get the following:
```Error making request to https://radektest.pactflow.io/provider-contracts/provider/example-provider/publish status=400 {"title":"Validation errors","type":"https://problems-registry.smartbear.com/validation-error","status":400,"instance":"/","errors":[{"detail":"must be filled","pointer":"#/contract/selfVerificationResults/content"},{"detail":"is missing","pointer":"#/contract/selfVerificationResults/verifier"}]}
(python) rstolarc@KKVND7XCRQ XD_ContractTesting_Provider % ```
matt.fellows
2024-05-06 10:58
I could be wrong. It seems to be complaining about the ?content? also, but looking at you?re providing a file
yousafn
2024-05-10 12:00
:help-sign: Are you using Pact Broker Docker deployed in multi-instance architecture, with a PostgreSQL DB?
If so we would love your help!
The Pact Broker supports Automatic data cleanup, which helps maintain the health of your Pact broker over time, by cleaning up redundant data, ensuring your Pact Broker works at peak performance.
https://github.com/pact-foundation/pact-broker-docker?tab=readme-ov-file#automatic-data-clean-up
However this feature hasn?t been available to users who have utilise the Pact Broker Docker image, in a multi-instance architecture
(You may have more than one broker instance running at any one time for high availability for example, all utilising a single database).
What will you need?
? A Pact Broker image running tag `2.119.0` or later
? A PostgreSQL Database
? A multi-instance setup of the Pact-Broker deployed somewhere
? Follow the docs linked above
For additional context, see the following pull requests
? Feature - https://github.com/pact-foundation/pact_broker/pull/672
? Docs - https://github.com/pact-foundation/pact-broker-docker/pull/183
If you can help us out, I?ll be sure to send out some Pact stickers!
fabio.rodrigues
2024-05-13 09:05
Hi there,
When trying to publish a openapi spec , I'm getting this error:
```-----
ProviderName is: bi-publish-service
NameError - uninitialized constant Pactflow::Client::ProviderContracts::Publish::OpenStruct
##[error]Bash exited with code '1'.```
fabio.rodrigues
2024-05-13 09:24
I think i get where the error came:
https://github.com/pact-foundation/pact_broker-client/blob/5cfb353d68122c0d87fdbb506db09f447076ba51/spec/lib/pact_broker/client/cli/broker_publish_spec.rb#L13
You need to add the necessary require:
```require 'ostruct'```
yousafn
2024-05-13 09:39
ty, can you try with previous release tag ( not latest, which went out on Friday iirc)
fabio.rodrigues
2024-05-13 09:40
```
docker run --rm \
-w ${{parameters.SwaggerPactOutputFolder}} \
-v ${{parameters.SwaggerPactOutputFolder}}:${{parameters.SwaggerPactOutputFolder}} \
-e PACT_BROKER_BASE_URL \
-e PACT_BROKER_TOKEN \
pactfoundation/pact-cli:latest \
pactflow publish-provider-contract \
$(UpdatedOpenApiFilePath) \
--provider $providerName \
--provider-app-version ${{parameters.ProviderVersion}} \
--branch $FINALBRANCH \
--content-type application/yaml \
--verification-exit-code=0 \
--verification-results dummy-successful-test-result.xml \
--verification-results-content-type text/plain \
--verifier trustme```
yousafn
2024-05-13 09:49
odd that openstruct is used 13 times in the code but only required in three files, and looking at the history, it doesn?t seem to have been added prior and removed :thinking_face:
matt.fellows
2024-05-13 09:54
That's a spec file, shouldn't be used at all in the real CLI invocation. Hmmm
yousafn
2024-05-13 10:11
Ok so I can recreate this on `pactfoundation/pact-cli:latest` but not on the previous tag `pactfoundation/pact-cli:1.1.0.0`
yousafn
2024-05-13 16:41
so it looks it is affecting others too
https://github.com/fastlane/fastlane/issues/21944
passing the following env var
```-e RUBYOPT="-rostruct"```
fixes it
```docker run -v $PWD:/home --rm -it -e PACT_BROKER_TOKEN -e PACT_BROKER_BASE_URL -e RUBYOPT="-rostruct" pactfoundation/pact-cli:latest pactflow publish-provider-contract /home/example/provider-contracts/oas.yml --provider foo --provider-app-version foo1 --content-type application/yaml ```
yousafn
2024-05-13 16:49
it?s been raised here
https://github.com/pact-foundation/pact-ruby-cli/issues/131
Yes that would need to be tested, it?s could be a regression in ruby, as nothing material has changed in our code from previously working versions (we?ve just bumped the ruby version and taken steps to get our image to build)
yousafn
2024-05-13 16:49
bit of a longer tail that, so at least letting you know how you can get sorted for now (other than pinning to the last tag)
yousafn
2024-05-13 16:59
np, bizarrely just adding ruby 3.3 into the matrix of pact_broker-client results in the same error (which is good, in a way in helping track it down)
https://github.com/pact-foundation/pact_broker-client/actions/runs/9066772247/job/24910432241
bear in mind this job was previously passing three months ago, with no code changes.
daniyum21
2024-05-13 18:02
I just joined the group just for this?Sounds like i?m not the only one with issues! Thanks
yousafn
2024-05-13 18:02
release going out now that should hopefully sort it
https://github.com/pact-foundation/pact-ruby-cli/actions/runs/9067576567
daniyum21
2024-05-13 18:04
thank you! I was going to add target pact-cli:1.1.0.0, or pass in -e RUBYOPT=?-rostruct?, sounds like I?ll just wait then!
Thank you so much!
yousafn
2024-05-13 18:19
if you pull the latest image and try, that should be sorted
`docker pull pactfoundation/pact-cli:latest`
mbieganski.infomatt
2024-05-14 12:00
Hey. I have a question regarding `contract_requiring_verification_published` webhook running on `gitlab` and how to use `${pactbroker.providerVersionNumber}` . I?m using commits to version participants. Gitlab doesn?t have functionality to trigger pipeline against specific commit i.e `${pactbroker.providerVersionNumber}` . If I understand documentation correctly webhook should trigger job for selected `${pactbroker.providerVersionBranch}` and then inside the actual job should checkout `${pactbroker.providerVersionNumber}` and execute tests against it ?
mbieganski.infomatt
2024-05-14 14:39
@matt.fellows does it fully replaces `contract_content_changed` ?
Per documentation:
```contract_requiring_verification_published: when a pact is published, triggered once for each unique provider version that is either the latest from the main branch of the provider, or is currently deployed or released.```
so It doesn?t work for feature branches? i.e consumer contract change on `feat-a` branch trigger provider webhook for `feat-a` , main and deployed/released
rana
2024-05-15 07:24
Hi guys, question regarding environments.
When recording deployment, I can state which environment to publish the pact to.
When a consumer publishes pacts, there is no variable which I can pass in order to let it know which ENV I would like it to publish to.
So if I have a service `X` which has contract version `1.0.0` in `production` environment, and I have published a contract version `2.0.0` in `test` environment, how can I publish pacts and have it trigger verification for the `test` environment contract?
Thanks
fabio.rodrigues
2024-05-15 09:38
Hey there team
We were setting up webhooks for several teams, and when we started to see those hooks triggering the verification pipelines, we started to see a anormalous behaviour:
https://outsystems.pactflow.io/settings/webhooks/d69Q-dhp6eCBtQ3z-oIvSQ/triggered-webhooks
For example for one of our sevices
alanbos
2024-05-15 10:24
Hi - does the pact-broker REST API offer a way to discover what versions of a given pacticipant have been "recorded for release"?
I'd like to housekeep releases by calling `record-support-ended` in a semi-automated fashion but first I need to know what releases have been recorded.
matt.fellows
2024-05-15 22:41
Same problem as https://pact-foundation.slack.com/archives/CLS16AVEE/p1713350416015579. When a consumer publishes a pact and you use that event, it will trigger a verification *for each provider version* that covers the main branch, and any deployed environments. You need to checkout the different version on the CI environment to verify them.
The provider for that consumer has been deployed to 4 environments, and has a main branch - hence the total of 5 triggered webhooks
```[2024-05-15T10:07:46Z] DEBUG: Webhook context {"base_url":"https://outsystems.pactflow.io","consumer_version_branch":"main","build_url":null,"consumer_version_tags":[],"event_name":"contract_requiring_verification_published","provider_version_number":"v1.315.416","provider_version_branch":"main","provider_version_descriptions":["deployed in dev","deployed in test"]}```
```[2024-05-15T10:07:42Z] DEBUG: Webhook context {"base_url":"https://outsystems.pactflow.io","consumer_version_branch":"main","build_url":null,"consumer_version_tags":[],"event_name":"contract_requiring_verification_published","provider_version_number":"v1.315.411","provider_version_branch":"refs/heads/main","provider_version_descriptions":["deployed in stage"]}```
```[2024-05-15T10:07:40Z] DEBUG: Webhook context {"base_url":"https://outsystems.pactflow.io","consumer_version_branch":"main","build_url":null,"consumer_version_tags":[],"event_name":"contract_requiring_verification_published","provider_version_number":"v1.315.401","provider_version_branch":"refs/heads/main","provider_version_descriptions":["deployed in ga"]}```
```[2024-05-15T10:07:37Z] DEBUG: Webhook context {"base_url":"https://outsystems.pactflow.io","consumer_version_branch":"main","build_url":null,"consumer_version_tags":[],"event_name":"contract_requiring_verification_published","provider_version_number":"v1.315.406","provider_version_branch":"refs/heads/main","provider_version_descriptions":["deployed in osrd","deployed in osall","deployed in ea"]}```
```[2024-05-15T10:07:33Z] DEBUG: Webhook context {"base_url":"https://outsystems.pactflow.io","consumer_version_branch":"main","build_url":null,"consumer_version_tags":[],"event_name":"contract_requiring_verification_published","provider_version_number":"v1.315.418","provider_version_branch":"main","provider_version_descriptions":["latest from main branch"]}```
matt.fellows
2024-05-16 02:02
it doesn?t trigger provider branches, no, unless those branches are deployed.
matt.fellows
2024-05-16 02:03
Not at this stage, but perhaps start by checking/requesting it here: https://pact.canny.io/
It makes sense to have
matt.fellows
2024-05-16 02:04
You don?t deploy contracts, you deploy applications. Hence why you record a deployment for an application.
You associate a version of your application with a contract. But the association of application and versions, we can work out compatibilities.
matt.fellows
2024-05-16 02:05
> So if I have a service `X` which has contract version `1.0.0` in `production` environment, and I have published a contract version `2.0.0` in `test` environment, how can I publish pacts and have it trigger verification for the `test` environment contract?
so the premise is wrong.
replace ?contract version? with ?application version?. PactFlow manages the versions of contracts separately (and hidden) from users to not expose this detail. Some contracts don?t change between application versions, we essentially version the changes.
matt.fellows
2024-05-16 02:05
mbieganski.infomatt
2024-05-16 05:21
@matt.fellows is it recommended to also use it in combination with `contract_content_changed` for feature branches or provider has to ?manually? run the verification? e.g
Provider has branches `feat-x,` `main` and deployment `test`
Consumer changes contract on `feat-x`
`contract_requiring_verification_published` -> triggers provider on `main` and `test` (if different than main)
`contract_content_changed` -> triggers feature ?
matt.fellows
2024-05-16 05:42
no, that?s not how that other webhook event works, neither of them trigger branches.
Best to read https://docs.pact.io/pact_broker/webhooks#the-contract-content-changed-event for how they work
fabio.rodrigues
2024-05-16 09:56
can you add this behavior to the documentation. Or, if it's already there, make it more visible. I think , imho, this is a important thing to be very clear. especially for companies with different tests environments (like ring architectures and so on). This makes that teams need to thing on how they tests things, the costs involved with 3,4,5 pipelines runs at the same time and so on
fabio.rodrigues
2024-05-16 09:57
i wasn't aware of this for some time. It makes sense now that you clarified this to me, just that it changes things
alanbos
2024-05-16 11:53
Thanks @matt.fellows I've added https://pact.canny.io/feature-requests/p/rest-api-support-for-discovering-pacticipant-releases.
matt.fellows
2024-05-17 04:24
No worries! I agree, it is confusing - the PactFlow UI is not making this any easier (there has been a bug in the pact broker which also exists in PactFlow that is not returning the Provider version in that table). I?m going to get that prioritised for fix in the next sprint or two.
> can you add this behavior to the documentation. Or, if it?s already there, make it more visible.
Any thoughts on how you would reword this to make it clearer: https://docs.pact.io/pact_broker/webhooks#the-contract-requiring-verification-published-event
matt.fellows
2024-05-17 04:24
btw we do have our new UI in beta if you?d like to try it out. Give this a :+1: if you are interested, and I can hook you up
fabio.rodrigues
2024-05-17 09:31
well it's well written, just we need maybe to add a notice box, and give a concrete example
fabio.rodrigues
2024-05-17 09:38
```This event is supported from version 2.82.0 of the Pact Broker. It is a much smarter implementation of the contract_content_changed event, designed specifically for the recommended Pact webhook workflow. It triggers once for each of the following provider versions that are missing a verification result for the newly published pact:
the latest version from the provider's main branch
any version currently deployed to an environment
The provider versions are de-duplicated by version number, so that if the same provider version is the head, and/or deployed to multiple environments, the webhook will only trigger once for each provider version. The template parameter ${pactbroker.providerVersionDescriptions} will contain a description of which branch/stages that particular provider version number pertains to. eg. "latest from main branch, deployed in test"
-->
/info
Please then take notice that because of this several pipeline calls *will* be made to the provider service. For example in a provider service that is deployed in 3 environments (let's say dev, test, prod) and the same version of service is in 2 of them (dev and test for example) it will trigger 3 times. One for main branch, 1 for the version that is in dev/test and another for prod.
So, is our advice to use our template parameters to properly check against the necessary versions, have your test setup able to accommodate testing different versions and the necessary test execution setup and agents to run several pipelines at the same time
/info
<-- ```
fabio.rodrigues
2024-05-17 11:06
quick question, why can't i change group assigment on Pactflow for a user, even when i am a admin of it?
Logged in in my account, that has admin role, and when i try to change a user to also have a admin role (so he can change webhook auth credentials correctly) i got the error saying i don't have the necessary permissions? Is that intended?
aisha.balogun
2024-05-17 19:35
I'm running into a similar issue as above where various actions are giving me a permission error
alanbos
2024-05-20 13:25
Hi - I'm using pact-broker `2.96.0.0` and have hit an error trying to delete an integration between 2 pacticipants via the broker UI:
```Could not delete resources due to error: An error has occurred. The details have been logged with the reference QkphWxELnm
Error reference: QkphWxELnm```
I'm looking in the pact broker logs for some matching reference but can't see anything.
I've not had a problem deleting integrations before. Any clues as to how to investigate further would be most welcome.
matt.fellows
2024-05-20 23:43
hmm strange, it should be in the logs. There are no errors in your Pact Broker logs at all?
alanbos
2024-05-21 07:05
I'm running pb in k8s with log level set to debug, but after a flurry of logging (sql, properties dump) on startup there's hardly anything in the logs at all. Feels like I'm missing something in setup.
alanbos
2024-05-21 07:08
I guess I could also uprev to latest pb version, providing its not going to drop any data.
matt.fellows
2024-05-21 07:35
It shouldn't. But also the logs should be there unless you happen to be very unluckily on a version that had some bug (I don't recall but it's possible)
alanbos
2024-05-21 08:03
These are logs - almost all of the activity is from startup and issuing further requests from the pact broker UI don't seem to trigger any further logging activity.
alanbos
2024-05-21 08:05
And this is the configuration setup in the YAML::
```spec:
containers:
- env:
- name: DATASOURCE_HOST
value: ****
- name: DATASOURCE_PORT
value: "5432"
- name: DATASOURCE_USERNAME
valueFrom:
secretKeyRef:
key: postgres_username
name: postgres-secrets
- name: DATASOURCE_PASSWORD
valueFrom:
secretKeyRef:
key: postgres_password
name: postgres-secrets
- name: PACT_BROKER_DATABASE_URL
value: postgres://$(DATASOURCE_USERNAME):$(DATASOURCE_PASSWORD)@$(DATASOURCE_HOST):$(DATASOURCE_PORT)/pact-broker
- name: PACT_BROKER_WEBHOOK_HOST_WHITELIST
value: ***
- name: PACT_BROKER_DISABLE_SSL_VERIFICATION
value: "true"
- name: PACT_BROKER_LOG_LEVEL
value: DEBUG
image: dius/pact-broker:2.96.0.0
imagePullPolicy: IfNotPresent
resources:
requests:
cpu: 9m
memory: 1372Mi```
matt.fellows
2024-05-21 08:07
You?re right, definitely an older version. So strange there are _no_ logs after the initial boot. There should be a lot more, IIUC
matt.fellows
2024-05-21 08:08
An upgrade is worth doing, provided two things:
1. You have an up-to-date snapshot of the DB
2. You have a way to resurrect it and deploy the previous broker back on top of it
charlan.bettiol
2024-05-21 12:25
Hello everyone, everything good? I need to integrate keycloak with pact-broker for access by my company's teams, has anyone done this or something similar?
alanbos
2024-05-21 13:42
OK I discovered (indirectly) that this was probably a sql db timeout; upping `PACT_BROKER_DATABASE_STATEMENT_TIMEOUT` from the default (15) to 120 removed the error; seems like whatever an integration deletion is doing, when the tables get big enough it can struggle.
alanbos
2024-05-21 13:45
... I think that if the integration is the last one in which a given pacticipant appears, the broker also removes the pacticipant. That may explain some of the extra effort going on behind the scenes.
matt.fellows
2024-05-21 23:32
I remember somebody attempting it in the past. You might find something in the search history here: https://www.linen.dev/s/pact-foundation
I don?t recall any implementation being made public though
matt.fellows
2024-05-21 23:33
Have you considered something like PactFlow instead to save all of this kind of effort?
matt.fellows
2024-05-21 23:34
ah, that makes some form of sense - the cascade delete could be quite big if there are a lot of rows
alanbos
2024-05-22 08:28
Is there a safe way to prune some of the faster-growing tables?
I've noticed that `webhook_executions` and `triggered_webhooks` are getting pretty big, and I'm not sure of the utility of keeping an ever-growing record of those things. But I would not be so foolhardy as to just remove rows at the SQL level.
Also having the ability to prune undeployed versions from `deployed_versions` in bulk would be good.
And without knowing the inner workings of the pb, the issues with SQL timeouts when deleting a "busy" pacticipant might be due to a combination of ever-growing tables and a lack of suitable SQL indexes, but that's just speculation on my part.
charlan.bettiol
2024-05-22 10:50
Good morning, yes we consider it, but as we are in the pact testing phase in general we need to consolidate the contract testing technique and then migrate to the paid tool.
abhishek.lamba
2024-05-22 15:30
Hello everyone, Could someone let me me know which api end point I can use to get pact broker version?
taha.shakibania
2024-05-24 14:01
Hi everyone
I have a scenario that I don't know how to solve. So imagine service A is a consumer and service B is a provider. A-feat is an updated version of A that has a contract that B does not support yet, so the pipeline for A fails. After a few days, B creates a patch that fixes this issue and verifies A-feat in its pipeline. Now, how am I supposed to send a notif to A to resume its pipeline and deploy?
matt.fellows
2024-05-25 05:16
You could send a status update back to your CI system or just retriggger a build. Personally I'm not sure how useful it is, usually merging is a manual step - especially if it passes asynchronously
taha.shakibania
2024-05-27 08:10
Thank you for your reply. Yes, I think it's redundant as you mentioned :+1:
salisburysai28
2024-05-31 16:09
Why is the pact broker cli strongly recommended over the broker api for downloading and uploading contracts?
matt.fellows
2024-06-01 00:36
Because once you work out how to upload contracts, you'll want to use many of the other capabilities like can I deploy, recording deployments, creating webhooks etc.
The CLI saves you having to build all of that. You can use the API of course, it's up to you.
What problem do you have with the CLI?
diferdin
2024-06-03 08:12
Hello all! I am struggling to create webhooks towards a Prometheus server, I was wondering if anyone here has ever done it and could chare some knowledge? Better to create them visually on the broker or via the broker CLI? What do you put in the body? Thank you in advance
diferdin
2024-06-03 08:39
the big picture is to see broker events in a Grafana dashbaord. What I understand is that I need to pass through Prometheus, whereas the broker sends HTTP requests to Prometheus and this latter to Grafana. So I want to create webhooks that send events to the Prometheus server -- hope it is clear
diferdin
2024-06-03 12:20
Right now I am running everything local using Docker. I have Prometheus in one container (localhost:9090) and the broker on another container (localhost:9292). I use the broker UI to create the webhook as in the first image attached. I don't understand where I need to pass the event name, and when I try I get a simple _0 error_ as outcome (see second image). No idea where to dig deeper for what is wrong...
matt.fellows
2024-06-04 03:40
hmm not sure what inspired you to send a POST request to the root path - what were you expecting to happen there? The Pact Broker has a number of APIs and uses the HAL convention for hypermedia. The `/` (root) resource will provide you links to follow to other resources
matt.fellows
2024-06-04 03:40
See https://docs.pact.io/pact_broker/webhooks#events for general advice, I?d start by using the CLI
matt.fellows
2024-06-04 03:40
You can add the `--verbose` command to that to see what requests it actually makes.
If you really need the API, there is some basic docs here: https://docs.pact.io/pact_broker/api/webhooks
matt.fellows
2024-06-04 03:41
We at PactFlow actually also publish a more formal version of that API here: https://smartbear.portal.swaggerhub.com/pactflow/default/pactflow_saas_api#/webhook/post_webhooks
_(just be careful looking at the rest of the APIs because a bunch of them are PactFlow specific and won?t apply to the OSS Pact Broker)_
diferdin
2024-06-04 07:48
Thank you for the links. I went for a POST because since I am pushing content from the broker to another server a GET seemed counter-intuitive. and I choose the root path because I didn't have any other path to choose from in Prometheus. I already did take a look at the events link above, but that doesn't really tell me anything around how to create webhooks correctly -- which is currently my issue. And, I deliberately avoided looking into PactFlow exactly because I didn't want to run into something that the OSS broker does not support. I guess I'll change strategy and do not use Prometheus/Grafana in the end -- thank you in any way
matt.fellows
2024-06-04 08:04
The screenshot you showed above is sending a non-get request to Pact Broker - not to prometheus. It should be possible to create a webhook in the Pact Broker that fires a request to prometheus
matt.fellows
2024-06-04 08:04
I?d use the CLI for now.
Do you know the shape of the request (and headers etc. needed) to send a request to prometheus? I could help you write the CLI command that should get you on the way
diferdin
2024-06-04 14:03
Thank you. Can you please point me at where I can get into around using the CLI to create webhooks? And just to be clear: I need the pact broker to push notifications to another component...
matt.fellows
2024-06-04 23:31
Link to CLI here: https://docs.pact.io/implementation_guides/cli#pact-broker-cli
matt.fellows
2024-06-04 23:32
> And just to be clear: I need the pact broker to push notifications to another component
yep, that?s how webhooks will work here so you?re on the right track
charlan.bettiol
2024-06-06 13:09
Hello everyone, everything good? about the problem with pact and keycloak, i made a solution including the OAUTH2-proxy under nginx, the oauth2 receive the request and verify the keycloak session, case this ok is redirect to pact-broker, else redirect for the login page, i have a poc for this if anyone wants i commit im github
diferdin
2024-06-06 14:35
Thanks. I am looking at the CLI as you suggested, but description is pretty poor and therer are things I still do not get. I gather the line below tells the broker to send an event to a target defined in the URL parameter, is that the case? Also, do I have to specify the body of the request? How do I do it in that case? Do I also need to specify the event type in the body?
Thank you for your help, as I said above documentation is pretty poor and I cannot find much around...
```pact-broker create-webhook URL -X, --request=METHOD -b, --broker-base-url=BROKER_BASE_URL```
diferdin
2024-06-07 08:59
A bit of an update. I started using the CLI as you suggested, and after a bit of search I drafted a request in this way:
```docker run --rm --network="host" pactfoundation/pact-cli:latest pact-broker create_webhook http://localhost:8080/notifications -X POST -b http://localhost:9292/webhooks -u pactBrokerUsername -p pactBrokerUserPassword -d "{\"description\":\"Sendnotification-test\",\"provider\":{\"name\":\"bm\"},\"events\":[{\"name\":\"contract_content_changed\"}],\"request\":{\"method\":\"POST\",\"url\":\"http:localhost:8080/notifications\",\"headers\":{\"Accept\":\"application/json\"}}}" --contract-published```
Now when I fire this, i get:
```PactBroker::Client::hal::ErrorResponseReturned - Error making request to http://localhost:9292/webhooks status=401```
Not sure why I get a 401, I am providing the broker's credentials and the recipient app does not need any credentials. Also, I am using something similar to publish and verify a PACT and do not have any auth issues
ashley.gautama
2024-06-07 09:21
Hello, is there a way in the pact broker ui/hal browser to download a specific pact to your file system. Or possibly is there a cli command/tool we can use?
tim.vahlbrock
2024-06-10 09:32
Hey there, I'm currently setting up the GitLab Pipeline configuration for Pact Integration. However, I encountered the issue that recommended way to select consumer branches to verify is to look for a branch with a matching name. However, the branches in our repositories will often include the number and name of the team-specific task to implement that feature and therefore usually will not share the same name. Now I'm thinking about how the developers could easily specify, which branch to verify against. Are there any preexisting solutions/concepts for this? I was thinking about including a section in the merge requests template where the merge request or branch name of the consumer repository could be linked. The pipeline would then extract this section, resolve the branch name and pass it to pact. Maybe someone has already done something similar?
alanbos
2024-06-10 11:42
Hi - I'm in the process of migrating to the `contract_requiring_verification_published` webhook and following the instructions https://docs.pact.io/pact_broker/webhooks#when-the-consumer-makes-a-change to understand how to drive a contract verification build triggered by this webhook.
In particular the webhook is sending the URL of the changed pact, sourced from the `pactbroker.pactUrl` property.
But when I pass this URL as the value of the `pact.filter.pacturl` argument when running a Pact-JVM verification test, it seems to have no effect i.e. all contracts from all consumers are verified, rather than the one specified by the pact URL.
(I'm using version 4.5.6 of the pact jvm dependencies).
Could I be driving this wrong?
mbieganski.infomatt
2024-06-10 11:50
@alanbos I have opened a ticket with exact same issue. Please take a look at https://pact-foundation.slack.com/archives/C9UN99H24/p1717400574261109. Waiting for JVM maintainer input.
adonay.berhe
2024-06-10 14:41
Hey all, I wanted to know if anyone has used PactFlow as a traditional broker between two RESTful BE services? If so, what that looked like and/or any pain points? Thank you!
alanbos
2024-06-10 17:18
Hi @mbieganski.infomatt my problem was more basic; it was to do with ensuring that the right consumer contracts were being verified in my tests, rather than whether the verification results were being published (which is not to rule out that also being an issue).
In my scenario I had neglected to do a couple of rather critical things in my implementation:
? Annotate my provider contract test with `AllowOverridePactUrl`
? Specify _both_ `pact.filter.pacturl` and `pact.filter.consumers` when running the tests
Once I made those corrections, the expected verifications ran, and the verification results were published.
P.S. I am using pact broker rather than pactflow.
mbieganski.infomatt
2024-06-10 18:13
Hmm I?m using pact broker as well. @alanbos would you mind sharing properties that you are setting for verification task? I have above also set but for some reason I don?t see results In broker
alanbos
2024-06-10 18:23
These are the settings I'm passing to the verification test:
pact.verifier.publishResults=true
pact.filter.pacturl=<URL received from webhook>
pact.filter.consumers=<consumer received from webhook>
pact.provider.version=<version received from webhook>
pactbroker.url=<set appropriately>
pact.provider.tag=develop
matt.fellows
2024-06-10 22:13
What do you mean by this, exactly?
It's a tool for housing contracts of applications you've described
mbieganski.infomatt
2024-06-11 05:25
are you using pact plugin and pactVerify task or normal tests with these properties? I?m setting exact same properties but I?m using branches instead of tags maybe there is some issue. Also are you on V4 ?
alanbos
2024-06-11 07:15
I'm using junit based tests with the requisite pact annotations, and not the pact maven plugin. This is all with pact v4.5.6 of JVM dependencies.
mbieganski.infomatt
2024-06-11 07:18
hmm I?m on 4.6.9. Have to check if it supports V4 and branches and will try to rollback and test again. Thanks for the info!
alanbos
2024-06-11 07:33
No problem - I'll try moving to a later v4 and see if it causes any problems. Let me know how it goes!
adonay.berhe
2024-06-11 08:40
Hi Matt, I?m speaking from the BE: I?ve completed a milestone integration between FE/BE providing Cypress/ OpenAPI spec respectively - would this be the same if we were using PactFlow for pact tests between two BE microservices both of whom provide OpenAPI specs? It seems the answer is yes, but just making sure!
mbieganski.infomatt
2024-06-11 11:06
it?s confusing bumped provider to 4.6.10 setting below as sys properties and running test locally can verify they are falling for changed contract as expected
```'pact.provider.branch'
'pactbroker.providerBranch'
'pact.provider.version'
'pact.verifier.publishResults'
'pact.filter.pacturl'
'pact.filter.consumers' ```
but nothing is published.. I have even updated pact broker to latest
alanbos
2024-06-11 11:11
Maybe its worth dialing up the logging to max, if you havent already done so.
alanbos
2024-06-11 16:16
Do you not see anything like this in the logs? (provider=_foo_, consumer=_bar_)
```2024-06-11 16:25:11.827 INFO [foo,,,] 1486 --- [ main] a.c.d.p.p.DefaultVerificationReporter : Published verification result of 'Ok(interactionIds=[d5cc8d9fede4eb865d4afbcf13e9a649657b4754, ...])' for consumer 'Consumer(name=bar)'```
mbieganski.infomatt
2024-06-11 16:38
so I was debugging and found interesting thing. Verification results are published only when all contracts are verified. For some reason Passed test is still marked as `unverifiedInteractions` so this condition will not be met. It happens for `V4 Asynchronous Message`
```val unverifiedInteractions = unverifiedInteractions(pact, interactionResults)
return if (unverifiedInteractions.isEmpty()) {
logger.debug {
"All interactions for Pact ${pact.provider.name}-${pact.consumer.name} have a verification result"
}
val result = if (verificationReporter.publishingResultsDisabled(propertyResolver)) {```
But have no idea why everything work for standard provider verification?.
mbieganski.infomatt
2024-06-11 16:59
and here `unverifiedInteractions` still shows 3 interactions even though they were verified. Nothing to do with broker
alanbos
2024-06-11 17:02
It might not be relevant but all my pacts are essentially http/REST based, whereas it looks like yours are message-based. Could the tests be ending prematurely before all async interactions have been processed?
mbieganski.infomatt
2024-06-11 17:07
They are mixed async, rest and gRPC. I don?t think so since they are passing. When I run standard provider verification not webhook everything is published
alanbos
2024-06-11 17:50
Do those 2 triggers result in the same variables & values being passed to the tests? (and the same state change handlers being exercised)
matt.fellows
2024-06-11 23:29
hmmm so PactFlow?s bi-directional contract testing feature supports OpenAPI specs, but the open source Pact Broker doesn?t.
Is that what you?re asking?
matt.fellows
2024-06-11 23:29
Pact + Pact Broker = Pact testing only (which supports RESTful services, EDAs etc. but does _not_ support using OAS as the contract)
PactFlow = Pact + BDCT
diferdin
2024-06-12 07:35
Hello, I am re-posting here what I had already asked above and on StackOverflow without any reply, in an attempt to get some answers from more expert people here. Thank you in advance for any help:
I am preparing a demo on the PACT workflow, and as part of it I would like to demonstrate the concept of webhooks.
To this extent I created a container with the pact-broker running, I can use the CLI to publish and verify a PACT successfully. Then I can make verification fail introducing a breaking change in the API spec, regenerating objects and re-running the provider app with the breaking changes. Everything works well up to that point.
In the last part I would like to enrich the demo showing how to create webhooks to notify a recipient about contract content changed. To this extend I created a small SpringBoot app that exposes a
`/notifications` endpoint that I want to use as recipient for the webhook. My current issue is with creation of the webhook, and specifically that attempts at creating the webhook return 401 with the execution line below:
```docker run --rm --network="host" pactfoundation/pact-cli:latest pact-broker create_webhook http://localhost:8080/notifications -X POST -b http://localhost:9292/webhooks -u pactBrokerUsername -p pactBrokerUserPassword -d "{\"events\":[{\"name\":\"contract_content_changed\"}],\"request\":{\"method\":\"POST\",\"url\":\"http:/localhost:8080/notifications\",\"headers\":{\"Content-Type\":\"application/json\"},\"body\":{\"some\":\"json\"}}}" --contract-published```
In the line above:
? http://localhost:9292 is the URL for the PACT broker
? http://localhost:8080 is the URL for the recipient of the webhook, the simple app that I want to receive notifications.
I formed this line looking at the PACT documentation, however I find quite a lot of what is being said there confusing so evidently something is misplaced or missing. I would appreciate some help with this from whoever has created webhooks before.
alanbos
2024-06-12 08:39
Hmm I'm out of (possibly not) useful suggestions at this point I'm afraid; sounds like someone who knows the pact jvm codebase is needed to explain why those 3 interactions are still in the unverified collection, unless you can figure out via the debugger where in the code interactions are removed from that collection (which might provide further clues).
adonay.berhe
2024-06-12 09:13
I see the confusion, yes, I?m aiming to use PactFlow for BDCT between two RESTful BE services
yousafn
2024-06-12 09:31
the pact broker cli knows the subpath, the docs state provide the base url, not the url to the webhook endpoint
mbieganski.infomatt
2024-06-12 09:46
Look like I got it solved. And I was missing override url annotation on class which I was sure was extending class with annotation. This was causing 1 test using different contract url which was causing pact to calculate different calculateInteractionHash :melting_face:
alanbos
2024-06-12 09:48
Good news! I'm not sure why that annotation has to exist TBH; can't see under what circumstances you would want to switch off URL overriding.
mbieganski.infomatt
2024-06-12 09:50
yep wondered about the same thing. I guess there needs to be some reason :wink:
fabio.rodrigues
2024-06-12 14:15
Hey there team
in the new UI, where we can see the got response, aka why it failed?
I can see the expected response and the request made, but not the response and why it failed. As a QA tool this is a big no no.
ben.brugman
2024-06-12 16:02
Hi all,
We tried to set-up a webhook to trigger an Azure devops pipeline. we used the template found here https://docs.pact.io/pact_broker/webhooks/template_library#azure-devops---trigger-build.
Now we want to test the webhook, we tried it via the broker CLI the HAL browser and postman, but in al cases we get this error from Azure.
``` "body": {
"$id": "1",
"innerException": null,
"message": "A value for the 'provider_app_version' parameter must be provided.",
"typeName": "Microsoft.Azure.Pipelines.WebApi.PipelineValidationException, Microsoft.Azure.Pipelines.WebApi",
"typeKey": "PipelineValidationException",
"errorCode": 0,
"eventId": 3000
}```
How do we sent this data when making a test call?
ben.brugman
2024-06-12 17:05
This is how the webhook looks like in the HAL browser
```"request": {
"method": "POST",
"url": "https://azure/_apis/pipelines/1/runs?api-version=7.1-preview.1",
"headers": {
"Content-Type": "application/json",
"Authorization": "**********"
},
"body": {
"resources": {
"repositories": {
"self": {
"ref_name": "refs/heads/master"
}
}
},
"template_parameters": {
"pact_consumers": "${pactbroker.consumerName}",
"pact_url": "${pactbroker.pactUrl}",
"provider_app_version": "${pactbroker.providerVersionNumber}",
"provider_name": "${pactbroker.providerName}"
}
},```
matt.fellows
2024-06-12 22:23
I guess temporarily you could fill in real values in for the test button, and replace with the templated ones once you?re happy?
matt.fellows
2024-06-12 22:24
@phanindra.srungavarap do you know if the template values are replaced with ?fake? ones during the test execution?
diferdin
2024-06-13 07:09
Thank you. The documentation link below says explicitly "To create a webhook, send a `POST` request to `/webhooks` with the body described below. You can also do a `PUT` to `/webhooks/{uuid}`"
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown
If that is not true then maybe somebody should change it?
matt.fellows
2024-06-14 04:45
Reading the code, it looks like it tries to use the latest pact and verification as the source for data: https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/webhooks/trigger_service.rb#L31-L41
fabio.rodrigues
2024-06-14 08:37
I was showing this to a team lead, and he asked where I could see the error ( like in current UI) and we couldn't
yousafn
2024-06-14 08:39
got you :) i?m out in Berlin at the moment, have pinged the team. but will check when i am back
khawase.shrinivas
2024-06-14 09:18
hey :wave:
I noticed this from https://docs.pact.io/pact_broker/advanced_topics/provider_verification_results
> Something to note is that if the content of your contract has not changed since the previous verification, then the contract will be ?pre-verified? with the results of the last verification. This means that most of the time, you should be able to go straight from the consumer test/package phase into the deploy phase.
Is there a way to know using an event if pact contract has changed ( which does not care about the consumer version but only if the contract has changed)
I have tried to use `contract_content_changed` but looks like tags and consumer versions are considered while returning this event.
yousafn
2024-06-14 09:39
matt.fellows
2024-06-14 09:52
I think it's just a bug Fabio. I noticed there is a version of .NET where the verification results format is different to what we're expecting and I think that's why (I know you folks use .NET).
I'll get it prioritised and come back to you so you can share internally
stan196
2024-06-14 22:51
Hey folks, a question on webhooks. Normally `contract_requiring_verification_published` webhook is triggered when the pact is published. Is it possible to also trigger it from `can-i-deploy` if verification result is missing? The reason for that is that if for whatever reason the original webhook (from publish time) didn't go through (e.g. webhook receiver service was down or something) and we're missing verification results it would be good to try again come deploy time rather than just failing right away.
Is there a way to re-trigger this event manually?
matt.fellows
2024-06-17 04:10
There is a ?hidden? feature of the `pact-broker` command that checks if a verification is required. You could potentially run that on a ?cron? like build, but probably it wouldn?t solve your problem as you?d need to run it for each deployed version and for main - a bit messy.
But just in case, this is how we run it in our build pipeline (you can hopefully extrapolate here):
``` docker run --rm \
-e PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL \
-e PACT_BROKER_TOKEN=$PACT_BROKER_TOKEN \
-e PACT_BROKER_FEATURES="verification_required" \
-it \
pactfoundation/pact-cli:$PACT_CLI_VERSION \
broker verification-required \
--pacticipant pactflow-application-saas \
--version ${RELEASE_VERSION} \
--pacticipant ${CONSUMER_NAME} \
--version ${CONSUMER_VERSION_NUMBER} \
--verbose```
You could use that to determine whether or you need to run a verification and if so, kick it off
ruth.bassindale
2024-06-17 06:53
Hi,
I am trying out the https://docs.pact.io/pact_broker/advanced_topics/wip_pacts from pact broker. So far it works well, the only problem I have is the date.
I do appreciate that it is there to prevent 3 year old versions to be verified, but I was wondering why this is an actual date and not a time frame?
Because now you aways have to adapt this date, or am I understanding something wrong?
matt.fellows
2024-06-17 07:21
you can make it a timeframe. Simply add a dynamic timestamp into into it and :boom: .
The reason a date is used, is that if you?ve previously verified pacts then the timestamp need not move - old pacts don?t get re-verified. At least, that?s my memory of that
ruth.bassindale
2024-06-17 07:31
I see, so for me that sounded like the pacts get re-verified. but if that is not the case that would mean the verification of all old non-verified pacts would happen only once? Then I understand less why there is a date at all :sweat_smile:
ruth.bassindale
2024-06-17 07:33
and what is a dynamic timestamp? how would I for example say `30 days ago`?
I can only find javascript references to that :sweat_smile:
matt.fellows
2024-06-17 07:35
> I see, so for me that sounded like the pacts get re-verified. but if that is not the case that would mean the verification of all old non-verified pacts would happen only once? Then I understand less why there is a date at all
fair point. There is probably some additional logic that comes with using that property, I?m not entirely across that.
Personally, I think you?d be fine with a sliding window as above.
I also do have some vague recollection of that ?pre-verification? logic changing, but can?t remember why now. Probably there is a breadcrumb / history trail on GitHub though
tim.vahlbrock
2024-06-21 13:22
Hello, I'm seeing some strange behavior in the Pact Broker. On the main page the verification status is yellow, with a note that the pact has changed since the last verification. However if I open the matrix and show all versions the latest versions are listed as "pre-verfied" as they had identical content. Is this intended or did I do something wrong?
dbunker
2024-06-25 15:46
Hi community--I?ve searched the archives for info about the `/metrics` endpoint and didn?t see any answers to my questions, so I?m asking here.
I have a self-hosted pact broker, and I created an application that polls the broker?s `/metrics` endpoint and sends these metrics in to New Relic, where I?ve built a dashboard to show the metrics over time. This polling request happens from 2 different kubernetes pods (HA-setup), every 60 seconds (probably overkill). My new relic query simply selects the latest metrics hit and displays that number. I would expect the `/metrics` numbers to reflect the total accumulated since the database was created, and therefore always be increasing over time. But that?s not the case, as I?m seeing a chart like this:
dbunker
2024-06-25 15:47
the visualization on the left shows the most recent hit. The chart on the right shows the max number for each time bucket.
dbunker
2024-06-25 15:48
My question is this: what would explain the metrics number going _down_ over time?
dbunker
2024-06-25 15:49
is this verification success metric a counter that tracks from the moment the db is created? or does it get reset ever, such as during db cleanup jobs?
dbunker
2024-06-25 16:04
It looks like https://github.com/pact-foundation/pact_broker/blob/8cd9697445eadca35803617e78d011c39da87a2e/lib/pact_broker/metrics/service.rb#L36, so if the cleanup job cleans up the database, that might explain it, but I have my cleanup job running every day and `PACT_BROKER_DATABASE_CLEAN_OVERWRITTEN_DATA_MAX_AGE` is set to `30`, and `PACT_BROKER_DATABASE_CLEAN_KEEP_VERSION_SELECTORS` has the `max_age` property set to `120`, so I just don?t understand how the number could go down within a week (I haven?t had this even running since 30 days ago)
dbunker
2024-06-25 16:05
looking at my clean job logs, I do see some verification results were deleted:
```"Results (0 seconds)","payload":{"pact_publications":{"deleted":0,"kept":156},"verification_res ?
? ults":{"deleted":9,"kept":238},"pact_versions":{"deleted":0,"kept":69},"triggered_webhooks":{"deleted":0,"kept":0}}}```
I think this is the cause, I?ll take a look at my cleanup job configs
dbunker
2024-06-25 16:20
I double checked my database verifications table and saw that the oldest entry is indeed over 120 days. Mystery explained!
yousafn
2024-06-25 16:30
Excellent rubber duckying there my friend!
The dashboard looks :chefkiss:
Would you be interested in sharing some details about your setup, and experiences with Pact in a blog post sometime. No pressure but I am sure it would be beneficial to others
matt.fellows
2024-06-26 09:50
Yes, this is one of the problems with the current ?metrics? implementation. We don?t have a separate data store for historical reporting, so it?s only reporting on the live info. We are looking at addressing this in PactFlow, but it?s likely to involve additional infrastructure for housing the data, so unlikely it will be ported to the Pact Broker.
That being said, what are the key metrics you?re interested in?
diferdin
2024-06-27 12:45
Hello, I have an issue while trying to receive a webhook notification from the broker. I start the Docker container for the broker using the following configuration:
```pact-broker:
image: pactfoundation/pact-broker:latest
ports:
- "9292:9292"
depends_on:
- postgres
environment:
PACT_BROKER_PORT: '9292'
PACT_BROKER_DATABASE_URL: ""
PACT_BROKER_LOG_LEVEL: INFO
PACT_BROKER_SQL_LOG_LEVEL: DEBUG
PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "5"
PACT_BROKER_BASE_URL: 'https://localhost http://localhost http://localhost:9292 http://pact-broker:9292 https://host.docker.internal http://host.docker.internal http://host.docker.internal:9292'
PACT_BROKER_BASIC_AUTH_ENABLED: true
PACT_BROKER_BASIC_AUTH_USERNAME: 'pactBrokerUsername'
PACT_BROKER_BASIC_AUTH_PASSWORD: 'pactBrokerUserPassword'
PACT_BROKER_WEBHOOK_SCHEME_WHITELIST: 'https, http'
PACT_BROKER_WEBHOOK_HOST_WHITELIST: 'localhost'```
Then, I start anothe rdocker container with a simple Spring Boot app that accepts POST at http://localhost:9300. I also create a webhook using the following line:
```docker run --rm -v ${PWD}:${PWD} --network="host" pactfoundation/pact-cli broker \
create-or-update-webhook http://localhost:9300/notifications --uuid "1662acf91d16ed1951da4b67a9ea8f37a844bbe3" \
--request POST --broker-base-url=http://localhost:9292 \
--broker-username pactBrokerUsername --broker-password pactBrokerUserPassword \
--data '{ "event_type": "provider_verification_failed","client_payload": { "pact_url": "http://localhost:9292", "sha": "sha", "branch":"master" , "message": "Provider verification failed!" } }' \
--header 'Content-Type: application/json' 'Accept: application/json' \
--provider "bm" --provider_verification_failed \
--description "Provider verification failed!"```
Everything goes smooth until I lead a verification to fail, in which case I can see the webhook retrying with the following error:
```[2024-06-27T12:17:35Z] DEBUG: Webhook context {"base_url":"http://localhost:9292","build_url":null,"provider_version_tags":["eescp_openapi_gradle"],"event_name":"provider_verification_failed"}
[2024-06-27T12:17:35Z] INFO: HTTP/1.1 POST http://localhost:9300/notifications
[2024-06-27T12:17:35Z] INFO: accept: application/json
[2024-06-27T12:17:35Z] INFO: user-agent: Pact Broker v2.110.0
[2024-06-27T12:17:35Z] INFO: content-type: application/json
[2024-06-27T12:17:35Z] INFO: {"event_type":"provider_verification_failed","client_payload":{"pact_url":"http://localhost:9292","sha":"sha","branch":"master","message":"Provider verification failed!"}}
[2024-06-27T12:17:35Z] ERROR: Error executing webhook 1662acf91d16ed1951da4b67a9ea8f37a844bbe3 Errno::ECONNREFUSED - Failed to open TCP connection to localhost:9300 (Connection refused - connect(2) for "localhost" port 9300)
[2024-06-27T12:17:35Z] INFO: Retrying webhook in 10 seconds```
I cannot figure out why I am getting ECONNREFUSED, the app is running correctly at port 9300 and I can access the endpoint via both Postman and curl. I'll appreciate any help on this...
matt.fellows
2024-06-27 13:29
Are you sure localhost:9300 refers to the same localhost within the docker network the broker is running? I'd need to remind myself of the docker networking options, but on the surface this doesn't look like a pact problem, but rather a docker networking issue. The broker seems to be firing the webhook but it can't connect to the target
dbunker
2024-06-27 13:50
@yousafn thanks! yeah, blog post sounds interesting--I?ll have to check adobe policies on that. I?m heading out on sabbatical next week, so i?ll circle back after that.
@matt.fellows that makes sense--we?re interested in tracking this over time so that?s why we?re exporting to new relic (and actually we?re eating our own dog food and sending to Adobe Analytics where we track our own service using our own product :face_with_cowboy_hat: ). Tracking all the metrics from `/metrics` (especially verification successes and failures) will help give us (and upper management) an idea of *how worth it* it was to spend engineering resources to implement contract testing throughout the org.
matt.fellows
2024-06-28 01:25
Are you planing on using `can-i-deploy` and `record-deployment` as well? I wonder if those metrics would be additionally useful?
alanbos
2024-06-28 10:32
Apologies for cross-posting this with #pact-js but I'm not sure whether its a client or server thing (or both):
I'm publishing contracts from a Nodejs consumer running `@pact-foundation/pact: 12.5.2` and using the `--auto-detect-version-properties` switch when using the pact-broker publish command.
This is running in a BitBucket Cloud pipeline.
The docs say this flag:
```Automatically detect the repository commit, branch and build URL from known CI environment variables or git CLI```
When I look in the `branch_versions` table I can see a new row with the expected branch name and underlying version number, but:
? The associated row of `versions` has blank `build_url` and `repository_ref` columns (I'm assuming the former should contain the "build URL" described above
? I'm not sure where the "repository commit" alluded to above would crop up in the pact broker DB, so I'm not sure where to check for that.
Should I expect repository commit and build URL to be recorded in the DB somewhere? If they should be, any advice for how to track down why they are not appearing?
yousafn
2024-06-28 10:52
Hey Alan,
It should pick up the following env vars
https://github.com/pact-foundation/pact_broker-client/blob/cb2e41145d320190642349c2790cb6acb35eab4c/lib/pact_broker/client/git.rb#L5
https://github.com/pact-foundation/pact_broker-client/blob/cb2e41145d320190642349c2790cb6acb35eab4c/lib/pact_broker/client/git.rb#L31
It _may_ be that these have changed in BK so I would probably start with checking if they are set
What output do you see when publishing with the pact-broker publish command? You can also running it in verbose for a bit of extra logging.
alanbos
2024-06-28 10:55
Thanks @yousafn - I will check those envVars in my pipeline.
I do have `--verbose` set on the call to publish - is there anything in particular I should be looking for in there?
yousafn
2024-06-28 10:58
`Created GoAdminService version bf65b7406bec6dd9a15569ec1441649ea19a51c0 with branch master`
You should see something like the above, with version <version> being the commit (if it has been picked up).
it actually wont let you publish without a commit version
yousafn
2024-06-28 10:59
so just wondering if you have the correct commit, we can then check the build url
alanbos
2024-06-28 11:02
It reports this:
`Created foo version 285bd2d-featurepact-use-branch-not-tag+285bd2d with branch feature/pact-use-branch-not-tag and tags feature/pact-use-branch-not-tag`
The version is calculated using `npx absolute-version`, and the only slight oddity is the removal of the `/` character present in the branch from the version.
yousafn
2024-06-28 11:04
okay, so the removal of the / might be an absolute-version thing, as i can publish with a version foo/bar.
i assume the short hash, corresponds with the start of your git commit?
if you do auto detect version properties and then the consumer app version, the user provided version takes precendence
alanbos
2024-06-28 11:08
This is the whole cmdline:
```pact-broker publish ./pacts --consumer-app-version=<ab-ver> --auto-detect-version-properties --tag-with-git-branch --verbose --broker-base-url=<broker-url>```
where `<ab-ver>` is the output `285bd2d-featurepact-use-branch-not-tag+285bd2d` from absolute-version.
alanbos
2024-06-28 11:24
fyi - just dumping out the env Var info in the pipeline this time
Firstly, these are the variables that BB reports that it has set:
``` BITBUCKET_BRANCH
BITBUCKET_BUILD_NUMBER
BITBUCKET_CLONE_DIR
BITBUCKET_COMMIT
BITBUCKET_GIT_HTTP_ORIGIN
BITBUCKET_GIT_SSH_ORIGIN
BITBUCKET_PIPELINE_UUID
BITBUCKET_PROJECT_KEY
BITBUCKET_PROJECT_UUID
BITBUCKET_REPO_FULL_NAME
BITBUCKET_REPO_IS_PRIVATE
BITBUCKET_REPO_OWNER
BITBUCKET_REPO_OWNER_UUID
BITBUCKET_REPO_SLUG
BITBUCKET_REPO_UUID
BITBUCKET_SSH_KEY_FILE
BITBUCKET_STEP_RUN_NUMBER
BITBUCKET_STEP_TRIGGERER_UUID
BITBUCKET_STEP_UUID
BITBUCKET_WORKSPACE```
alanbos
2024-06-28 11:26
Of the above I think only `BITBUCKET_BRANCH` and `BITBUCKET_COMMIT` appear in that list of envVars you sent me; in particular there's nothing to match anything in the `BUILD_URL_ENV_VAR_NAMES` list.
yousafn
2024-06-28 11:27
mmm yeah, sorry I mis-read as buildkite :facepalm: , noted the same that actually that list of env vars bb provides doesn't provide one for a url to the job
alanbos
2024-06-28 11:27
I just see:
```BITBUCKET_BRANCH = feature/pact-use-branch-not-tag
BITBUCKET_COMMIT = 91b019b1b56126b3af0925f22eb30f3b4f55b79c```
yousafn
2024-06-28 11:27
I know circleci was the same as I had to create the url, from a project id env var
alanbos
2024-06-28 11:30
Ah that's interesting - so I could just set `BUILD_URL` from some of the available bits as outlined in the s/o above.
I'll give that a try - many thanks for your help!
yousafn
2024-06-28 11:31
pleasure my friend, if that works, we could probably add that into the pact broker client, although it will break at some point as the ci provider will invariably change their api.
alanbos
2024-06-28 12:46
Just to confirm, setting the envVar `BUILD_URL` to `https://bitbucket.org/${BITBUCKET_REPO_FULL_NAME}/pipelines/results/${BITBUCKET_BUILD_NUMBER}` prior to calling _publish_ from the BitBucket pipeline results in the `versions.build_url`being populated in the database,
alanbos
2024-07-01 08:34
Hi - I'm reading the material on https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors (henceforth _cvs_) and just wanted to check some basic points of understanding that I couldn't glean from the docs...
First really basic thing; if I pass an array of cvs via the _rawjson_ property when running verification tests which looks like this:
`[ selector_1, selector_2, ..., selector_n ]`
where each `selector_i` represents an individual cvs (e.g. `{ "tag": "develop", "latest": true }`) then are these selectors logically OR'd together or AND'd together or is it not as simple as that?
My assumption is that its a disjunction (logical OR) but the first example on this page confused me:
```consumerVersionSelectors: [
{
mainBranch: true, // (recommended) - Returns the pacts for consumers configured mainBranch property
},
{
deployedOrReleased: true, // (recommended) - Returns the pacts for all versions of the consumer that are currently deployed or released and currently supported in any environment.
},
{
environment: 'test', // Normally, this would not be needed, as it is recommended to verify the pacts for all currently deployed/currently supported released versions.
},
{
environment: 'production', // Normally, this would not be needed, as it is recommended to verify the pacts for all currently deployed/currently supported released versions.
},
]```
where the explanation is that this will target:
> ? any pacts for the consumer associated with their configured `mainBranch` property
> ? any pacts for the consumers, deployed to `any` environment
> ? This if (sic) filtered by only pacts `deployed` or `released` to the `test` / `production` environments.
> ? If this consumer/provider pair, has an additional environment `staging`, it would not be picked up, due to the named `test` / `production` environments. Removing these conditions, will return any pacts, deployed or released to any environment, which is the recommended setup for the majority of cases. (coupled with enabling pending pacts.)
It looks like cvs #1 and #2 are expressing a disjunction (_either_ the pact is associated with the main branch of the consumer _or_ the pact is deployed or support-released)
However cvs #3 and #4 then appear to be used as additional mandatory subcriteria on #2 (i.e. not only does the pact have to be deployed, the deployment has to be to either `test` or `production`).
This has confused me; if the cvs's are logically OR'd together then the above example seems to be saying return all pacts that are either on main branch, or deployed and released, or deployed to `test`, or deployed to `production`. Under those criteria we would get pacts deployed to `staging` because they would satisfy the 2nd cvs.
I was expecting the desired filter to be expressed in pure disjunctive form
```consumerVersionSelectors: [
{
// pacts for consumers configured mainBranch property
mainBranch: true,
},
{
// pacts currently released and supported
released: true
},
{
// pacts currently deployed to test
deployed: true,
environment: 'test'
},
{
// pacts currently deployed to production
deployed: true,
environment: 'production'
},
]```
where the cvs's are logically OR'd together (disjunction) and with each csv, its predicates are logically AND'd together (conjunction).
yousafn
2024-07-01 14:19
Hey hey,
Sorry that example is pretty poor, most would probably have the following, you are correct that `deployedOrReleased` would also include for example staging.
```consumerVersionSelectors: [
{
mainBranch: true, // (recommended) - Returns the pacts for consumers configured mainBranch property
},
{
deployedOrReleased: true, // (recommended) - Returns the pacts for all versions of the consumer that are currently deployed or released and currently supported in any environment.
}
]```
if I wanted to qualify just deployedOrReleased to test/prod (excluding any other envs that may exist) I believe I can do
```consumerVersionSelectors: [
{
// pacts for consumers configured mainBranch property
mainBranch: true,
},
{
// pacts currently deployedOrReleased to test
deployedOrReleased: true,
environment: 'test'
},
{
// pacts currently deployedOrReleased to production
deployedOrReleased: true,
environment: 'production'
},
]```
yousafn
2024-07-01 14:21
from the docs they are deduped, so on the first example you got from the page. the latter two are superfluous, as they would also be picked up by deployedOrReleased which isn?t scoped to any particular env (and therefore would get them all).
Happy to remove those from the examples, if they are just confusing and mean you can?t just copy pasta from the page
``` {
deployedOrReleased: true, // (recommended) - Returns the pacts for all versions of the consumer that are currently deployed or released and currently supported in any environment.
},
{
environment: 'test', // Normally, this would not be needed, as it is recommended to verify the pacts for all currently deployed/currently supported released versions.
},
{
environment: 'production', // Normally, this would not be needed, as it is recommended to verify the pacts for all currently deployed/currently supported released versions.
},```
alanbos
2024-07-01 14:25
Thanks @yousafn - I think TBH that example is currently doing more harm than good there :slightly_smiling_face: as it completely confused me.
I think an equivalent example like the one you described above would be useful, and if my assumptions are correct (cvs elements are OR'd together, but attribute value predicates within a cvs are AND'ed together) then it would be super useful to state that uprfront, as I think once that's understood everything else slots nicely into place.
yousafn
2024-07-01 14:32
I have to check the code in the pact_broker to be able to answer that with certainty.
Especially as I assumed it would be AND'd I believe when I wrote this.
> - any pacts for the consumers, deployed to `any` environment
> - This if filtered by only pacts `deployed` or `released` to the `test` / `production` environments.
> - If this consumer/provider pair, has an additional environment `staging`, it would not be picked up, due to the named `test` / `production` environments. Removing these conditions, will return any pacts, deployed or released to any environment, which is the recommended setup for the majority of cases. (coupled with enabling pending pacts.)
Will give it a test and will update the docs.
Do you think it is also worth removing the comments from the code snippets? there is an explainer at the top.
`// (recommended) - Returns the pacts for all versions of the consumer that are currently deployed or released and currently supported in any environment.`
alanbos
2024-07-01 14:36
Thanks - yes if there's any doubt about what rules the broker is following best to check first, but I think it would be of huge help in the docs to state whatever those rules are clearly in general form before getting to any examples.
(and yes I think the comments are best removed if they just repeat what the explainer has already covered, on the DRY principle)
yousafn
2024-07-01 14:58
okay here is a first pass at pulling out the comments and cleaning up the code examples and the confusing statement/sample
https://github.com/pact-foundation/docs.pact.io/pull/333/files
alanbos
2024-07-02 13:03
Hi - having got my pact publishing and verification info to include the buildUrl, the obvious next question is where (if anywhere) does this info appear in the pact broker UI.
I'm on a pretty old version of pactbroker right now (`2.96.0.0`) but am a bit nervous about going to the very latest as I'm not sure of the implications for the data already in that DB if I uprev. But if anyone knows at which point if any the pactbroker UI started to include support for build URL I'd be grateful.
matt.fellows
2024-07-02 22:55
I have a feeling it?s not shown in the OSS pact broker at all, Alan. Let me check for you
martin.konir
2024-07-04 08:37
Hello :ralph-wave:
I have a question regarding triggering provider verification from the OSS pactbroker. For our CI, we use GitHub actions. I am curious about how you handle authorization for triggering GitHub actions from pactbroker. It can be done easily with a dispatch event and setting a JWT token in the header. We set up a webhook in the Pact Broker following way
```{
....
"request": {
"method": "POST",
"url": "https://api.github.com/repos/oracle/customer-service/dispatches",
"headers": {
"Authorization": "Bearer GITHUB_TOKEN"
},
"body": {
"event_type": "contract_requiring_verification_published",
....```
However, I am interested in where exactly you get that Authorization token. The only option that seems possible is to use some sort of GitHub CI account and generate a token for it that is valid indefinitely. But for several reasons, we don't want to use this option.
I would say that normally, this situation would be handled by creating a GitHub application and dynamically generating a token before every request to github, but if I'm not mistaken, pactbroker does not support this.
How do you handle this situation?
matt.fellows
2024-07-04 13:57
Unfortunately we require a PAT at this stage, which could either be from an individual user or service / CI account
matt.fellows
2024-07-05 01:46
This is the template I think that would render the pact page: https://github.com/pact-foundation/pact_broker/blob/ff3f84e2a620346e95a52a3cab2f62bd47946d02/lib/pact_broker/api/renderers/html_pact_renderer.rb#L81
I don?t think it?s shown there. It doesn?t look like the verification data is available to that page anyway, so only the consumer build URL would be available
eran.bergman560
2024-07-08 17:12
In the past I've asked about https://pact-foundation.slack.com/archives/C9UN99H24/p1710532710280309?thread_ts=1709326714.615869&cid=C9UN99H24 (running a very large monolithic application with 1000+ APIs) but didn't really get an answer to how I can run multiple sets of tests for the same provider in parallel
Since I'm using Java + Spring + Maven I was thinking of running multiple dedicated test of my provider and "namespace" them differently:
? "MyProvider-A" - to test subset A of the APIs the provider offers
? "MyProvider-B" - to test subset B of the APIs the provider offers
? etc,
this is not ideal though because it means that the consumers will need to know under which name the provider manages (subsets) the APIs - essentially treating it as a different provider so I'm looking for a better way to do this
I was thinking that maybe I could download the pacts from Pact Broker myself and split them myself as I see fit + use the `@Folder` for different test instances to pick up different parts of the verifications but from what I can tell the communication with Pact Broker is all done within the Pact Provider tooling
I looked at the https://github.com/pact-foundation/pact_broker-client but I can only see a list-latest-pact-versions function there without the ability to obtain the actual pacts
is there an easy way to obtain all pacts for a specific provider?
kilian.jimenez
2024-07-09 09:40
Hello ! Is it currently possible to use a `record-deployment` through API like it's possible in pact-cli ? I can't find any `/record-deployment` or similar endpoint in the API documentation or the https://docs.pact.io/pact_broker/recording_deployments_and_releases . Maybe this action is added behind another endpoint but I can't find it anyway.
Thank you in advance.
P.S: I know pact-cli is highly recommended but as I found some difficulties in my current project to use docker and podman and I wanted to push my poc of a full pact flow in ci/cd I decided to continue using the API.
siim.mardus
2024-07-10 06:52
X-posting: https://pact-foundation.slack.com/archives/C02BXLDJ7JR/p1720594229156169
What is the general approach for not publishing verification results on local runs, but publishing them in case of CI/CD runs?
matt.fellows
2024-07-10 11:19
Just in case, we publish _some_ of the APIs here: https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started
A lot of these are the same as what?s in the OSS Pact Broker, but some are PactFlow specific. They should be obvious enough which ones are PactFlow only
stan196
2024-07-11 00:45
Hi folks,
I've noticed a weird behavior in one of our repos, where we publish an identical pact, but still trigger a webhook:
```Events detected: contract_published (pact content is the same as previous versions with tags and no new tags were applied), contract_requiring_verification_published (pact content is the same as previous versions with tags and no new tags were applied)```
Is there a way to see what was the logic that the broker used to decide that `contract_requiring_verification_published` event happens? What should I look for in the logs?
matt.fellows
2024-07-11 01:04
it?s possible _a version_ of a provider needs to verify the pact, even though one has verified it (such as the main branch build).
In the logs of the webhook, it should have a JSON blob at the top of it that shows the actual reason (e.g. because it?s deployed to an environment or is the main branch)
stan196
2024-07-11 01:09
the logs of the webhook say that it's deployed in the environment and that's why it's verified.
What doesn't make sense is that the contract hasn't changed in months, yet the webhook is still triggered. Like if I publish the contract that's exactly the same as before, it shouldn't trigger a webhook, right?
matt.fellows
2024-07-11 01:11
My guess is that version _never_ verified the contract. Even though you may have webhooks setup to verify changes, if that version never verified it it will continually show up in the triggered webhooks until it does
matt.fellows
2024-07-11 01:12
It?s a bit confusion, I?ll admit, but the intent makes sense once you think about it.
Most people (understandably) don?t checkout specific commit versions when the webhook triggers, and just run the latest of the main branch to verify the pact that is changed
matt.fellows
2024-07-11 01:13
> My guess is that version _never_ verified the contract.
or rather, if this isn?t the case, there is a bug somewhere
stan196
2024-07-11 01:14
That doesn't seem to be the case, it is being verified successfully.
The consumer in question is weird, though, so I'm wondering if this could lead to any interesting behavior.
We have two repos where we experimented with using pact for self-testing. Each has a consumer test between a `fake-consumer` and itself.
The test isn't changing in months, so the contract should be the same between every push. But when we publish this contract, we use the provider version for the `fake-consumer` so in the broker we basically have two separate versions for `fake-consumer` published against different providers from different repos.
And occasionally such publish triggers a webhook. Sometimes it doesn't though. But the contract is the same.
Idk if the above makes sense :smile:
stan196
2024-07-11 01:15
I gotta run now, but will come back to this tomorrow and see if I can track a specific version verification history, like if it was published, was it considered verified right away, and if not, at which point it becomes verified
stan196
2024-07-11 01:16
I might be missing a broken verification step somewhere, which I hope is the culprit
stan196
2024-07-11 01:18
but do I understand correctly, that if I publish a new consumer version where the contract contents itself hasn't changed, the provider should be considered verified automatically?
stan196
2024-07-11 01:19
I'm wondering if there's a race condition somewhere, where we publish consumer version X and provider version X at roughly the same time (cause they're in the same repo)? But it should still be ok, since the contents of the pact hasn't changed
matt.fellows
2024-07-11 01:20
> but do I understand correctly, that if I publish a new consumer version where the contract contents itself hasn?t changed, the provider should be considered verified automatically?
yes, generally
matt.fellows
2024-07-11 01:21
if v1 of a provider has verified pact for consumer v1 with hash abc-123, if consumer v2 publishes a pact with the same contents, and v1 of the provider has already verified pact with hash abc-123, then it?s considered pre-verified
matt.fellows
2024-07-11 01:24
(the pact file itself is versioned internally to the broker and separately from the consumer version. There are relationships to the consumer and provider versions to the pact version and verification results to make this determination)
stan196
2024-07-11 21:51
what's really confusing is this message:
```contract_requiring_verification_published (pact content is the same as previous versions with tags and no new tags were applied)```
which says that contract requiring verification published, but pact content is the same as previous version. Is this normal/expected?
stan196
2024-07-11 22:06
ok, I've figured out what's happening, and it indeed is the result of us using this "fake" consumer. Let me try to summarize
stan196
2024-07-11 22:15
? there are two services - service-a and service-b;
? each has a "self-test" between a "fake-consumer" and itself
? service-a builds, a contract between `fake-consumer` version `a1` and `service-a` is published. `a1` is the latest version of a fake consumer on `master` as far as pact-broker is concerned
? service-b builds, a new version of `fake-consumer` is published - `b1` , which does not have a contract with `service-a` , only with `service-b`.
? at this point if you hit the `pacts/provider/SERVICE-A/for-verification` the broker returns an empty list, saying there are no pacts to verify - because the latest version of the `fake-consumer` does not have a contract with `service-a`.
? now `service-a` builds and runs a provider test; it doesn't find any contracts for verification because of the above
? now `service-a` publishes it's `fake-consumer` version `a2` which at this point is considered a new contract, triggering a webhook.
? the issue is that `a2` is not materially different from `a1` , but because there was a `b1` between them, it's considered new I guess.
I was able to verify the behavior of `/for-verification` endpoint by publishing a new version of `fake-consumer` and checking whether `service-a` or `service-b` has pacts for verification. Once I pushed `a2` manually, it triggered a webhook, even though there was an older version with an identical contract.
So all in all, while this is something that can be fixed on the broker side, it is an edge case that stems from us using an unconventional approach. This will still happen if the team deletes a contract against a provider in version 2 and the reverts it in version 3, but that's probably very rare.
I'm going to try to change self-tests from `fake-consumer` to using the service name itself like `service-a` and this should not lead to any webhooks anymore.
matt.fellows
2024-07-11 23:32
Interesting - thanks for sharing. I need to wrap my head around it a bit further, but does seem like an edge case has been discovered and if I understand correctly, this isn?t the intent of that trigger
stan196
2024-07-11 23:35
yeah, I don't think this is something urgent that needs fixing really, just an interesting edge case.
stan196
2024-07-12 01:51
looking at this made me notice that if you explicitly use ProviderVerifier.verify in pact-go (presumably the same in other languages), it will verify the pact even if it was pre-verified.
I wonder if there's a way to tell your provider verifier code to skip pre-verified pacts; and I'm also not sure if I want to :slightly_smiling_face:
devin.woods
2024-07-19 16:55
Is it possible to only verify certain pacticipants in a `can-i-merge` CLI call? I am having trouble, not sure if I am using the flags wrong or if there is misconfiguration. I can point to my consumer like this
```--pacticipant SOS --version 00f1dbc4```
and I've tried to point to one specific provider like this
```--pacticipant DASHBOARD --latest (results in " Unknown switches "--latest" ")
AND
--pacticipant DASHBOARD --branch mainline (results in " Unknown switches "--branch" ")
AND
--pacticipant DASHBOARD --branch mainline --latest (results in " Unknown switches "--branch", "--latest" ")```
but none of those combos work. Is it expected to get the unknown switches message? The usage seems to suggest that I am using it right...
```The version must be specified using `--version VERSION`, `--branch BRANCH` `--latest`, `--latest TAG`, or `--all TAG` for pacticipant DASHBOARD```
matt.fellows
2024-07-22 03:19
That might be an issue with the error printing. The switches in the help command are:
```Usage:
pact-broker can-i-merge -a, --pacticipant=PACTICIPANT -b, --broker-base-url=BROKER_BASE_URL
Options:
-a, --pacticipant=PACTICIPANT # The pacticipant name. Use once for each pacticipant being checked.
-e, [--version=VERSION] # The pacticipant version. Must be entered after the --pacticipant that it relates to.
-o, [--output=OUTPUT] # json or table
# Default: table
[--retry-while-unknown=TIMES] # The number of times to retry while there is an unknown verification result (ie. the provider verification is likely still running)
# Default: 0
[--retry-interval=SECONDS] # The time between retries in seconds. Use in conjuction with --retry-while-unknown
# Default: 10
[--dry-run], [--no-dry-run], [--skip-dry-run] # When dry-run is enabled, always exit process with a success code. Can also be enabled by setting the environment variable PACT_BROKER_CAN_I_MERGE_DRY_RUN=true. This mode is useful when setting up your CI/CD pipeline for the first time, or in a 'break glass' situation where you need to knowingly deploy what Pact considers a breaking change. For the second scenario, it is recommended to use the environment variable and just set it for the build required to deploy that particular version, so you don't accidentally leave the dry run mode enabled.
# Default: false
-b, --broker-base-url=BROKER_BASE_URL # The base URL of the Pact Broker
-u, [--broker-username=BROKER_USERNAME] # Pact Broker basic auth username
-p, [--broker-password=BROKER_PASSWORD] # Pact Broker basic auth password
-k, [--broker-token=BROKER_TOKEN] # Pact Broker bearer token
-v, [--verbose], [--no-verbose], [--skip-verbose] # Verbose output.
# Default: false
Description:
Checks if the specified pacticipant version is compatible with the configured
main branch of each of the pacticipants with which it is integrated.```
matt.fellows
2024-07-22 03:21
I get the following if I used `--latest`
```Unknown switches "--latest"
This is a warning rather than an error so as not to break backwards compatibility. To raise an error for unknown options set PACT_BROKER_ERROR_ON_UNKNOWN_OPTION=true```
matt.fellows
2024-07-22 03:22
Where are you getting that output that suggestions you can use other versions?
jonatan.jaworski
2024-07-25 01:07
Hey team, is there any way to remove deployments registered in the Pact Broker? There are ways of recording deployments and ways of recording undeployments (e.g: in a rollback situation), but is there any way of removing some of these altogether? I've got a team who has been recording a few by mistake and would like to fix that. It's a service that hasn't been deployed yet, so the alternative is to remove the integration (or the app altogether) and start over from a clean state.
matt.fellows
2024-07-25 01:32
Yep, there is a `record-undeployment` command on the `pact-broker` CLI you can use
alanbos
2024-07-25 10:43
Hi - I'm getting confused about how pact broker figures out what the "latest" version of a pacticipant on a branch is.
I had a situation where I was running pact verification tests using `[{"branch":"develop", "consumer": "foo"}]` as my consumer version selector, and the verification test indicated that it was using version `2.37.0` of the pact as the "latest version" from the `develop` branch of pacticipant `foo`.
However if I ran this query against the pact broker db:
```select p.name, b."name", v."number" from branch_heads bh
inner join pacticipants p on p.id = bh.pacticipant_id
inner join branches b on b.id = bh.branch_id
inner join versions v on v.id = bh.version_id
where p."name" = 'foo'
and b."name" = 'develop' ```
it returned me the value `2.37.0-develop+5.cb7bd044`. (this was what I expected, as it represents the absolute-version of the latest commit on that branch, i.e. 5 commits on from the commit tagged with `2.37.0`)
Would the pact broker be using some different logic internally when being asked for latest version on a branch that could explain this discrepancy?
If I then republished the pacts again from the head of the branch, then the consumer version selector correctly returned `2.37.0-develop+5.cb7bd044`
matt.fellows
2024-07-25 11:17
I don?t know if this helps, but posting here just in case: https://docs.pact.io/getting_started/versioning_in_the_pact_broker#version-ordering
alanbos
2024-07-25 11:18
It's a version that getting a bit long in the tooth TBH - `dius/pact-broker:2.96.0.0`
alanbos
2024-07-25 11:21
Thanks for the link - that has reminded me of the fact that its all about when the version is created rather than any inherent ordering implied by e.g. output from `absolute-version`.
matt.fellows
2024-07-25 11:21
Yes. I recall at some stage, the ordering was either configurable or used a ?semver? like ordering scheme
matt.fellows
2024-07-25 11:22
Given you?re using `absolute-version` , if it _were_ semver ordered then I could imagine it might be expected to work differently (possibly)
alanbos
2024-07-25 11:22
And everything observed kind of follows on from that principle, except the SQL query gets its "right" (at least from the semver ordering perspective).
matt.fellows
2024-07-25 11:23
It would be worth querying the relevant versions table to check the publication dates on the versions, that might make things a bit clearer
alanbos
2024-07-25 11:27
Just to explain a bit more - the version is a ""retrospective" release version, which happens when a previous git commit is tagged with `2.37.0`. At this point `absolute-version` reports the version to be `2.37.0` as expected and my release pipeline publishes the pacts from that commit with this version.
Of course, due to the way `absolute-version` works, this in effect _changes_ the version of the pacts currently at the "head" of the develop branch, because everything is calculated as an offset from the last release-tagged commit.
e.g. if the version representing the head was `2.36.5+11`, and the release tag `2.37` is applied to the commit with version `2.36.5+7`, then the current head becomes "re-versioned" to `2.37+4`.
matt.fellows
2024-07-25 11:27
This is what I was looking for (there is a config to set it to order by date or semver, now deprecated)
alanbos
2024-07-25 11:29
So, while I'm not surprised some part of the system thinks `2.37.0` is the latest, I guess I was offered false encouragement that SQL returns me what I really wanted as the latest `2.37.0-develop+5`.
That feels to me that something inside the pact broker is calculating the latest in a different way.
alanbos
2024-07-25 11:32
Dealing with the consequences of "retrospective" release tagging and the way `absolute-version` works is something of a headache; from what you are saying the move is away from anything other than date-ordering on versions, so it feels like whatever I do has to live in that world.
matt.fellows
2024-07-25 11:33
yes, probably. I can?t tell you the queries it uses but IIRC there are either tables or columns that calculate ?heads? and ?latest? things (and also there is this https://github.com/pact-foundation/pact_broker/commit/935cd349863349a3ae3332acc5b07052b5423518 around ordering).
So it?s probably more complicated.
To find out what it?s doing, set the pact broker log level to TRACE (I think, let me confirm). It will log all SQL queries, so be warned, but you could try it out for a few minutes with a local broker or something to see the query
alanbos
2024-07-25 11:39
Thanks - the fundamental problem I think here is that `absolute-version` doesn't guarantee _immutable_ versioning due to its offset-related behaviour, in that the same git commit can map to different versions over time as previous commits are tagged.
So I guess I'm faced with two possible ways forward:
? come up with some versioning scheme that is immutable, or;
? continue to use `absolute-version`, but when a commit is retrospectively tagged with a release, come up with some way of telling the pact-broker "hey, what you thought was version X is now version Y"
On the latter approach, I guess just republishing the pacts at the head of the branch after a retrospective tagging would suffice.
But it would be interesting to know what others do who rely on `absolute-version`.
matt.fellows
2024-07-25 11:49
Yeah, that?s an interesting point. I think it?s a use case the original author of the library probably didn?t consider (not surprisingly). I can?t remember why semver was deprecated (probably there is some information in a commit/PR somewhere), but it probably was for good reasons - usually these things get deprecated because it creates sharp and pointy edge cases, code/performance more complex etc.
But that?s just a guess. You could potentially enable it to see if it addresses the problem (but I would agree with assuming it?s not a great idea to switch)
alanbos
2024-07-25 11:50
Yeah I think that, given that semver ordering is deprecated, would be the equivalent of switching to a train that was headed in the wrong direction.
dranidis
2024-07-26 12:20
Hello, I used the pact-broker cli `delete-branch` as documented in https://docs.pact.io/blog/2024/02/21/deleting-branches-automatically. It did delete the branches, but it does not delete the published verifications. My matrix is still full with all verifications; just the branch names do not appear.
Is this normal? If it i, what is the rational? Is there a way to delete the verifications as well?
dranidis
2024-07-26 14:27
I have already checked the documentation about deleting resources: https://docs.pact.io/pact_broker/administration/deleting_resources. The routes: `/pacts/provider/{provider}/consumer/{consumer}/branch/{branch}` do not exist.
dranidis
2024-07-26 14:30
I have also found out that the CLI help notes:
```Deletes a pacticipant branch. Does not delete the versions or pacts/verifications associated with the branch, but does make the pacts inaccessible for verification via consumer versions selectors or WIP pacts.```
So, I guess this is the "expected" behavior. Still, what do we do with all these pacts and verifications in the matrix from branches that do not exist any more?
matt.fellows
2024-07-29 00:35
Yes, this is ?expected? but probably not expected by the end users.
There is this endpoint which I noticed has a bug the other day, I believe this is intended to delete the associated resources: https://github.com/pact-foundation/pact_broker/issues/628
We?ll be adding it to our backlog for review.
matt.fellows
2024-07-29 00:36
May I ask, what?s the _actual_ problem that you?re seeing with the additional pacts/verifications hanging around - is it just making it harder to see what?s happening in the UI?
By deleting the branch resources, it actually improves the performance of other queries, but the associated versions are still around.
What I think most people want, is to delete the branch, and also any associated versions that are _not_ associated with other branches etc.
Also, if an associated version was deployed, we?d need to think about that - what would be the right thing to do?
dranidis
2024-07-29 10:30
Apart from the UI clutter I don't see any other problem with having the pacts/verifications hanging around. I was curious if there is any "use case" for their existence?
dranidis
2024-07-29 10:31
Concerning the released pacts, I would guess that these are usually merged into main/master, but there might be other use cases as well.
dranidis
2024-07-29 10:34
We are going to use for the first time `can-i-deploy` in a project under development. Currently there is nothing yet in production. Nothing is deployed yet. Neither from the consumer, nor from the producer side. I guess that for the first `can-i-deploy` to work, something needs to be manually recorded as a deployed version. What is the recommended practice? Record a consumer deployment or a provider deployment, as the first deployment?
matt.fellows
2024-07-29 10:36
Doesn't really matter. But usually it's easier to get the provider there first
matt.fellows
2024-07-29 10:44
Yep. I'd like to address the issue, I'll report back on the above linked issue as we work through it
jain.007piyush
2024-07-30 13:19
I have locally setup Pact Broker and I am generating PACT file on my local system , I can push it on my Broker by API like this
jain.007piyush
2024-07-30 13:20
var config = new PactConfig
{
PactDir = @"c:\contractDemoNew\pacts",
Outputters = new[]
{
new XunitOutput(output)
},
DefaultJsonSettings = new JsonSerializerOptions
{
PropertyNamingPolicy = JsonNamingPolicy.CamelCase,
PropertyNameCaseInsensitive = true,
Converters = { new JsonStringEnumConverter() }
},
LogLevel = PactLogLevel.Debug
};
bas
2024-07-30 13:28
Hey @jain.007piyush , this is better suited for #pact-net I guess.
And no, I don?t think you can. It doesn?t really matter, because publishing the contract is better suited to be a step that is separated from running tests.
To make things easier, there?s https://github.com/pact-foundation/pact_broker-client for local and CI use
jain.007piyush
2024-07-30 14:40
Hi @bas: I have a running on the local machine (Docker). I can push the pact with the API . I am using Pact NET 4X. and Do I need to setup https://github.com/pact-foundation/pact_broker-client as well? with Pact-Net 2X there was a way to publish it like :
var pactPublisher = new PactPublisher("http://<YOUR_BROKER>.http://pactflow.io",
new PactUriOptions("<TOKEN>"));
pactPublisher.PublishToBroker("/pact/to/pacts/dir",
Environment.GetEnvironmentVariable("GIT_COMMIT"));
jain.007piyush
2024-07-30 14:41
Is this not available or can be done by https://github.com/pact-foundation/pact_broker-client only?
bas
2024-07-30 14:44
I don?t know. I wasn?t aware that this class existed in older versions. If it?s not there in Pact .Net 4.x the change logs will probably tell you if and why it was removed.
I?ve not seen any examples using `PactPublisher` that I can remember.
matt.fellows
2024-07-30 21:57
We recommend using the pact CLI tools for this job.
We made a decision a few years ago to not support all of the CLI functions in each language because it's just added maintenance work
fvivas.dev
2024-08-01 08:48
Hi everyone,
We are developing and testing several Pacts, and we have used this table like example.
https://docs.pact.io/getting_started/conceptual_overview#branches--environments
We think It is useful for understanding how to match consumer-provider and afterwards we ca explain better our workmates how to PactBroker works.
However, we have realised that Pact Version does not apear on the PactBroker,
Is there some reason that this field is not available?
I would like to request that Pact Version appears on PactBroker as information field.
Thanks
matt.fellows
2024-08-01 10:34
The pact version is not exposed in any other part of the system, as far as I'm aware (it's an implementation detail as it's calculated by the broker)
Why do you think that version will be helpful?
fvivas.dev
2024-08-01 16:31
In order to create/publish/record is enough, but, when i have more pacts and several consumers with theirs environments, I find hard to track all of them, imho.
p.ex. I am doing some test and i show a real case:
case 1:
? I published a wrong pact then i fixed it and publish the correct one.
? How to detect it in the matrix, i would like to delete it...
case 2:
? I guess that each time that i record a deployment/release, this pact is binded with the consumer-provider version
? In the future, p.ex. next year, if i publish new pacts, i would like to know what pacts are deployed or released previously.
case 3:
? Finally, It is easier to talk to anyone and teach them how to matrix works (like the example does) :wink:
ben.brugman
2024-08-06 12:17
Hi, we want to encrypt our broker webhook payload with SHA-1, is there anything in place for this?
Or is this not possible in the current set-up?
2024-08-06 19:44
This message was deleted.
matt.fellows
2024-08-07 03:56
ashley.gautama
2024-08-13 13:41
Hi, in postman before the request is sent, you can create a script like the below for encrypting your payload via key. Does the open source broker support such as thing? So i add my secret 'somewhere' in the broker and it will do the encrypting? Or can we inject codeblocks to extend functionality? The context for this question is for the webhook. So basically we want to encrypt our request payload in webhook payload. Thanks :slightly_smiling_face:
```const payload = pm.request.body.raw;
const key = 'secret';
var hmacSha = CryptoJS.algo.HMAC.create(CryptoJS.algo.SHA1, key);
var hashBytes = hmacSha.update(payload).finalize();
var signature = CryptoJS.enc.Hex.stringify(hashBytes);
pm.request.headers.add({
key: 'X-myapp-signature',
value: signature,
headerFormat: "RFC3986"
});```
2024-08-13 13:41
Please try and format your code to aid readability. You can use ``` on a new line each side of your code to achieve this. Or use the Code Block option available in Slack's message formatting toolbar
matt.fellows
2024-08-13 23:16
what?s the need to encrypt it - what system are you planning on calling?
lachlan.newman
2024-08-14 04:00
Quick Question. is there a data retention policy in the pact broker? How long does it store verify results for ?
siim.mardus
2024-08-14 11:47
Hi! I am having trouble creating a webhook.
For context - we are using Dockerized pact broker. I am following the pact nirvana guide and I'm currently at the https://docs.pact.io/pact_nirvana/step_6, where I'm implementing can-i-deploy to PR pipelines.
I've created a separate CI job (_in Jenkins, TWIMC_), and I got to the https://docs.pact.io/pact_nirvana/step_6.
I tried two methods:
1- https://github.com/pact-foundation/pact_broker-client
`pact-broker create-webhook http://www.google.com -X POST --broker-base-url=https:// --contract-content-changed --broker-username= --broker-password= --verbose`
2- curl/postman
`curl --location --request POST 'https:///webhooks/consumer/' \`
`--header 'Authorization: Basic '`
Both options eventually give me 401 unauthorized. I have double-checked the credentials and they are good. IDK what I am doing wrong here and the issues found online about 401 issues mostly suggest using tokens instead of basic auth, which we do not have as we're using the self-hosted broker. https://github.com/pact-foundation/pact_broker-client/issues/50 simply said "already fixed" :sweat_smile:
siim.mardus
2024-08-14 11:52
:duck: Found a similar thread... https://pact-foundation.slack.com/archives/C9VPNUJR2/p1718177748656929
siim.mardus
2024-08-14 11:58
I tried now to add `--data="{'foo': 'bar'}"` to the CLI command, but no luck, still 401
yousafn
2024-08-14 11:58
```pact-broker create-webhook http://www.google.com -X POST --broker-base-url=http://localhost:9292 --contract-content-changed --verbose```
returns
```Error creating webhook. response status=400 body={"errors":{"request.url":["is not a valid URL eg. http://example.org"]}}```
yousafn
2024-08-14 11:59
```pact-broker create-webhook https://www.google.com -X POST --broker-base-url=http://localhost:9292 --contract-content-changed --verbose```
returns
```Webhook "POST http://www.google.com" created```
siim.mardus
2024-08-14 12:00
```pact-broker create-webhook https://www.google.com -X POST --broker-base-url=https://<broker_url> --contract-content-changed --broker-username=user --broker-password=pass --verbose```
`Error creating webhook. response status=401`
yousafn
2024-08-14 12:05
hmm just setup the latest oss docker image with basic auth, and was able to send it fine :thinking:
```pact-broker create-webhook https://www.google.com -X POST --broker-base-url=http://localhost:9292 --contract-content-changed --verbose --broker-username test --broker-password test```
yousafn
2024-08-14 12:07
just a `docker-compose up` in https://github.com/pact-foundation/pact-broker-docker
after adding these env vars in in the `pact-broker` service
```PACT_BROKER_BASIC_AUTH_USERNAME: test
PACT_BROKER_BASIC_AUTH_PASSWORD: test```
is there any other infra set up between your broker at all?
is the webhooks endpoint say blocked as at reverse proxy layer?
siim.mardus
2024-08-14 12:08
I'll ask our infra guys and check the broker logs to investigate deeper. Thx for at least confirming that I was on the correct path with the webhook creation myself
yousafn
2024-08-14 12:10
s?all good Siim. Good luck on the path to pact nirvana :+1:
ps. I would very much recommend this webhook `contract_requiring_verification_published` event over the `contract_content_changed`
https://docs.pact.io/pact_broker/webhooks#the-contract-requiring-verification-published-event
siim.mardus
2024-08-14 12:11
Yea, I was looking at that indeed. Just wanted to create any webhook as a start to fiddle around
yousafn
2024-08-14 12:12
Yeah totally understand.
I did add a section for testing out broker webhooks locally in our pact-js workshop, which may be worth a look at
https://github.com/pact-foundation/pact-workshop-js/tree/step12#step-12---using-webhooks
to give you a nice playground outside of your production broker :+1:
siim.mardus
2024-08-14 12:16
Before coming here with my question I stumbled upon this page as well :smile: But seeing "step 12" and already having been through the PoC phase good amount of time ago, I figured I'll keep chipping at our current setup instead of investing time in the workshop right now.
siim.mardus
2024-08-14 13:01
The funniest and most classical dev blunder had happened.
For some reason, somewhere, somehow, the special characters got URL decoded. I have no idea where in the process this happened.
So our gibberish password, something like
`kr#wREWre$wqRtT&wqe`
I had somehow turned into
`kr%23wREWre%24wqRtT%26wqe`
And I had no idea what I was doing wrong and kept pasting the wrong password :joy:
ashley.gautama
2024-08-14 16:05
Hey Matt, thanks for the response. Basically the (security) policies of the company i work for, means i have to use the solution our cloud provider comes with in running pipelines with (verify) tests from our provider api's --> incoming webhooks.
However this 'incoming webhook' from the cloud provider is reachable/possible to execute from *every* network/everywhere on the internet, which is obviously not wat we want. DDOS attacks and such.
So to circumvent that you can use a 'key' with the incoming webhook, which kind of fulfills the role of authorization in this case.
But this would mean this encryption part with the key would need to be done on a per request basis in the broker, which i now understand there is currently no functionality for.
rana
2024-08-15 06:40
Hi team,
Lately I have ran into 2 instances where a service that had performed a `record-deployment` in the past, no longer has the `env: production` tag in `can-i-deploy` matrix, which causes `can-i-deploy` to return a false answer although verification succeeded.
There were no merges/new deployments (no new recordings), and in the pact broker the `latest` version is compatible with the version that should be the latest. Only the `env: production` tag is gone.
Is there anything else other then `record-deployment` that can cause the tag to be gone?
Thanks
siim.mardus
2024-08-15 06:49
I have a question about configuring the webhook which kicks off the provider verification build on pact change.
? _as per: https://docs.pact.io/pact_nirvana/step_6#add-can-i-deploy-webhook-to-pact-broker_
It says: _"and use https://docs.pact.io/pact_broker/webhooks/dynamic_variable_sub to pass the URL of the changed pact to the build along with the provider branch and provider sha (git commit)."_
Passing the pact url makes perfect sense..., but what is the purpose of passing along the provider branch and commit to the verification build? Isn't the point to run the verification build on master anyway, so the branch and commit would be fetched within the build itself?
ashley.gautama
2024-08-15 07:08
we are now thinking of having nginx behind the broker to encrypt the payload
siim.mardus
2024-08-15 07:24
Additional follow-up question, related to webhooks, namely authenticating webhook request.
We are using Jenkins CI, and when we define a webhook for pact broker to trigger a build, we also need to provide Jenkins credentials along with the request. What is the best way for doing that?
1. If we make the credentials available to the pact-broker service via env variables, is there a way to use those in the request (similarly to https://docs.pact.io/pact_broker/webhooks/dynamic_variable_sub)?
2. Should we perhaps approach this differently and create/update webhook on every consumer build via https://github.com/pact-foundation/pact_broker-client?tab=readme-ov-file#create-or-update-webhook script in Consumer CI, (_where we have Jenkins credentials available_), and provide the tokens alongside it?
a. _Although it already seems silly as I put it into words, as the token could be later exposed when fetching the webhooks_ :shrug:_._
siim.mardus
2024-08-15 07:37
I feel like I should be able to use something like this for (1)?
```...
"request": {
"method": "POST",
"url": "https:///job/buildWithParameters",
"headers": {
"Accept": "application/json",
"Authorization": "\$JENKINS_TOKEN\"
}
}
...```
When I have JENKINS_TOKEN environment variable configured in pact-broker service?
yousafn
2024-08-15 07:49
you want tp verify the pact against the head of providers main branch plus deployed and released versions. you do that by checking out the version of code deployed or released to any env
siim.mardus
2024-08-15 07:52
Ah okay. I guess it depends on the setup then. For us, code only reaches master once it's in production. But I understand that for many other people, there are separate release branches etc.
Makes sense, ty!
yousafn
2024-08-15 07:52
not in the open source broker i?m afraid you?ll need to store the token in the webhook
siim.mardus
2024-08-15 07:54
I wonder if making modifications to pact-broker to support using env variables in webhook requests would be difficult :thinking_face:
yousafn
2024-08-15 07:54
i stop get reqs to /webhooks to avoid them being shown to casual users.
pactflow supports encrypted secrets and variable substitution
siim.mardus
2024-08-15 07:56
> i stop get reqs to /webhooks to avoid them being shown to casual users.
That's an idea indeed.
yousafn
2024-08-15 07:57
i did some work in the past but it never saw the light of day
https://github.com/pact-foundation/pact_broker/pull/262
along with Beth to introduce secrets, although she approached it in a different way in PactFlow.
siim.mardus
2024-08-15 08:02
Looking at the work that @bethskurrie did with secrets.
So basically this would be the solution to this issue, right? We could store our CI credentials in a secret and somehow we could use the secret ID in our webhook and pact-broker would substitute it when making the request?
matt.fellows
2024-08-15 08:48
That's the idea, although the secrets capability is only available in Pactflow.
I forgot about that PR Yousaf!
siim.mardus
2024-08-15 08:49
> although the secrets capability is only available in Pactflow
currently or is it meant to be like that for the forseeable future as a selling point for pactflow (not judging)?
siim.mardus
2024-08-15 08:51
I just think that being able to provide secrets/env variables securely into dynamic requests, in this case webhooks, would be a very welcome addition to the open-source solution.
matt.fellows
2024-08-15 08:52
Best bet is to check logs to see if any versions have been deleted or undeployments recorded
If you use Pactflow you should be able find it in the audit trail
siim.mardus
2024-08-15 08:52
Currently we'll need to resort to the provided workaround of storing secrets in webhooks, and cutting the access to them :shrug:
Granted the token, aside from being behind stricter access rules, will also have extremely specific permissions... it's still a secret
matt.fellows
2024-08-15 09:03
Yeah it was added to Pactflow as part of the initial SaaS offering. There's no plans to add it to the OSS broker at this stage
yousafn
2024-08-15 09:08
The work was implemented in a different way in PactFlow and supported by the commercial project. Due to time/support constraints, the work on secrets was never completed in the OSS broker.
Controlling access to your broker in your own infra isn?t something maintainers can control, and therefore it is anticipated that appropriate steps are taken to control access to your broker. (various mechanisms for doing this)
We probably wouldn?t stop a PR from going ahead to introduce this functionality coming into the pact broker, but would expect its implementation to be of sufficient quality, have appropriate documentation and be supported for some time by the author, in case of issues. We would also need to check for compatibility with the pactflow broker, but that is something we can do on the PactFlow side during review
Beth?s previous branch would be a good starting point, but there are some changes to the pact-broker codebase now, that would require some rework of that existing branch
siim.mardus
2024-08-16 08:46
When verifying a single pact via URL (_during consumer side changes -> webhook -> provider verification CI run for single pact_), do I need to provide `enable_pending` (:point_left: _*main question*_) and `consumer_version_selectors` (_probs not, as I'm already targeting specific pact_) as well?
yousafn
2024-08-16 08:53
just the url. other options are referred to dynamically fetched pact options.
yousafn
2024-08-16 08:54
>> Note that the pending feature is only applicable to the main provider release pipeline, not the provider build that gets triggered by the contract_requiring_verification_published webhook.
siim.mardus
2024-08-16 09:14
What tells pact verifier to fetch pacts from a particular consumer?
So far we've had one consumer and one provider. Call them "consumer-service" and "provider-service".
As an experiment, I re-published consumer under a different name "consumer-service-a".
I ran provider verification with the following options:
```%{
branch: <provider-branch>,
host: "localhost",
name: <provider-service>,
pact_source_opts: %{
broker_password: <password>,
broker_username: <username>,
broker_url: <broker-root-url>,
consumer_version_selectors: "[{\"mainBranch\":true}]",
enable_pending: 1
},
port: "1234",
skip_publish: 0,
state_change_url: "http://localhost:1234/state_change",
version: <provider-version-sha>
}```
... and it fetched latest pact from "consumer-service", even though nowhere in the code I mention anything about the consumer name. Should I? Did I miss something? If we add a legit second consumer in the future, how do I specify it?
siim.mardus
2024-08-16 09:17
> If we add a legit second consumer in the future, how do I specify it?
I assume I can use `consumer` property in consumer version selectors? :thinking_face:
https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors#properties
Still the question remains, how did it decide to use `"consumer-service"`
in my experiment? Some internal logic picks a random one? Should it?
siim.mardus
2024-08-16 09:20
:duck:
> I assume I can use `consumer` property in consumer version selectors?
Yup, just verified that
yousafn
2024-08-16 09:39
the consumer version selectors be sent to the broker for it to determine which pacts to return
here it should be the latest pact on the mainBranch for any consumer who relies on your provider service
if both consumers specify that provider, and they both have a mainBranch specified it should pick them.
the output should state why a pact was selected
siim.mardus
2024-08-16 10:01
Ah okay, interesting.
So previously I did not have master branch on the second consumer, that's why it verified only the first one.
Now that I specified master branch on the second one as well, it actually ran verifications for both.
Okay great, all works nicely! :+1:
konstantinos.kotsos
2024-08-20 09:09
Hi all, I have a question about next steps list provided by pact-broker publish command:
View the published pact at https://xxx.pactflow.io/pacts/provider/provider-app/consumer/consumer-app/version/xxx
Events detected: contract_published, contract_requiring_verification_published
Next steps:
* Add Pact verification tests to the provider-app build. See https://docs.pact.io/go/provider_verification
* Configure separate provider-app pact verification build and webhook to trigger it when the pact content changes. See https://docs.pact.io/go/webhooks
Why are the next steps needed?
Are they required for the ci/cd to work correctly?
konstantinos.kotsos
2024-08-20 09:54
I have red them but they are a bit confusing and I asked here for having an answer from an expert, that could make things a bit more clear to me.
What I understand from the docs is that we need to extract a provider verification build to a post endpoint, and create a webhook to use that endpoint and be triggered on contract_requiring_verification_published event. That will try to verify provider for published changed consumer contracts. Is that right, and have I missed anything here?
yousafn
2024-08-20 11:33
you need two provider builds
https://docs.pact.io/pact_nirvana/step_4#verifying-pacts
one is ideally triggered by a webhook so it can be orchaestrated by the broker, whenever a pact changes and can trigger versions of your provider code depending on which versions of your provider are deployed or released as well as on the main branch which makes sure your newly created unverified pact gets validated against all the relevant providers
cyrus.devnomad
2024-08-22 07:45
How can I configure a webhook in Pact broker that ends up with athorization in the header like this:
```{
"uuid": "xxxxxxxxxxxxxxxxxxxxxxx",
"description": "Trigger Azure DevOps pipeline on pact change",
"enabled": true,
"request": {
"method": "POST",
"url": "https://dev.azure.com/xxxxxxx/xxxxxxx/_apis/build/builds?api-version=6.0",
"headers": {
"Content-Type": "application/json",
"Accept": "application/json",
"Authorization": "Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
"body": {
"definition": {
"id": 124
},
"sourceBranch": "refs/heads/xxxxxxxxxxxxxxxxxxx"
}
},
"events": [{
"name": "contract_content_changed"
}],
"updatedAt": "2024-08-22T07:35:01+00:00",
"createdAt": "2024-08-22T07:33:25+00:00"
}```
Rather than with username/password properties configured like this:
```{
"uuid": "xxxxxxxxxxxxxxxxxxxxxxxxx",
"description": "Trigger Azure DevOps pipeline on pact change",
"enabled": true,
"request": {
"method": "POST",
"url": "https://dev.azure.com/xxxxxxxxxx/xxxxxxxxxxxx/_apis/build/builds?api-version=6.0",
"headers": {
"Content-Type": "application/json"
},
"body": {
"definition": {
"id": 124
},
"sourceBranch": "refs/heads/xxxxxxxxxxxxxxxxxx"
},
"username": "xxxxxxxxxx",
"password": "**********"
},
"events": [{
"name": "contract_content_changed"
}],
"updatedAt": "2024-08-22T07:38:46+00:00",
"createdAt": "2024-08-21T17:09:42+00:00"
}```
I'm asking this because I was successful with the former type of requests against Azure DevOps API but not with the latter type of requests.
matt.fellows
2024-08-23 11:08
Don't use the username/password options in the webhook and instead, manually add the authorisation header?
cyrus.devnomad
2024-08-23 15:10
Not manually but via API request using pact CLI tool. Is it possible? Because using the Pactflow GUI it seems to be possible to configure a webhook that ends up with that Authorization property in the header but using the Pact Brokers API request to create or update a webhook that is sent by the docker based pact CLI tool, its not clear to me how to create a webhook like that. To be more clear I mean how to create/update a webhook with the Authorization part in the header using this pact tool:
```docker pull pactfoundation/pact-cli:latest
docker run pactfoundation/pact-cli:latest pact-broker create-or-update-webhook https://dev.azure.com/xxxxxxxx/xxxxxxxx/_apis/build/builds?api-version=7.0 --description "Trigger Build-Service-CIRS.API pipeline whenever ConsumerX to ProviderX pact changes" --request POST --header "Content-Type: application/json Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" --data '{"definition": {"id": 124}, "sourceBranch": "${pactbroker.consumerVersionBranch}", "parameters": "{\"pact_url\": \"${pactbroker.pactUrl}\"}"}' --consumer="ConsumerX" --provider="ProviderX" --user=Username:$AzureToken --contract-content-changed --broker-base-url=$PactBrokerBaseUrl --broker-username=$PactBrokerUsername --broker-password=$PactBrokerPassword --uuid=xxxxxxxxxxxxx```
The command above for example creates a webhook like this for example:
```...
"headers": {
"Content-Type": "application/json Authorization: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
},
...```
As opposed to a header like the following that I could successfully test against Azure DevOps API:
```...
"headers": {
"Content-Type": "application/json",
"Accept": "application/json",
"Authorization": "Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
}
...```
But in the meantime this is no longer an issue for me, because I was successful to authenticate against Azure DevOps API with a webhook request looking like this:
```{
"uuid": "xxxxxxxxxxxxxxxxxxxxxxx",
"description": "Trigger Providerx pipeline whenever ConusmerX to ProviderX pact changes",
"consumer": {
"name": "ConsumerX"
},
"provider": {
"name": "ProviderX"
},
"enabled": true,
"request": {
"method": "POST",
"url": "https://dev.azure.com/xxxxxxx/xxxxxxx/_apis/build/builds?api-version=7.0",
"headers": {
"Content-Type": "application/json"
},
"body": {
"definition": {
"id": 124
},
"sourceBranch": "${pactbroker.consumerVersionBranch}",
"parameters": "{\"pact_url\": \"${pactbroker.pactUrl}\"}"
},
"username": "Username",
"password": "**********"
},
"events": [{
"name": "contract_content_changed"
}],
"createdAt": "2024-08-22T17:29:29+00:00"
}```
siim.mardus
2024-08-26 11:41
Is it possible to record deployments and undeployments via curl?
If yes - how? If no, it would be very nice to not have to install the entire CLI for that simple action in CD pipelines.
matt.fellows
2024-08-26 11:47
Yep! see https://smartbear.portal.swaggerhub.com/pactflow/default/pactflow_saas_api#/record-deployment/post_pacticipants__pacticipantName__versions__versionNumber__deployed-versions_environment_environmentId
What about other CLI calls like publishing pacts, or calling can-i-deploy?
siim.mardus
2024-08-26 12:13
> Yep! see
Neat! Does it also work for open source pact broker?
I wanted to test it out manually, but I get
```{
"error": "The requested document was not found on this server."
}```
I am providing the consumer name, consumer version and an existing environment as path parameters.
`https://<broker_url>/pacticipants/<consumer-name>/versions/<consumer-version>/deployed-versions/environment/test`
> What about other CLI calls like publishing pacts, or calling can-i-deploy?
We are running various stages in different containers. So far we had to install the CLI in one container during the build, to publish pacts and run can-i-deploy, but publishing the build to environments happens in another container, where we'd have to install it again. :slightly_smiling_face: Just peculiarities of our pipeline.
siim.mardus
2024-08-26 13:06
Can I record undeployment via API though? :thinking_face:
Don't see it in the https://smartbear.portal.swaggerhub.com/pactflow/default/pactflow_saas_api
siim.mardus
2024-08-26 13:11
Even though the docs states, that recording undeployment is generally not needed, because reocrding the next deployment overrides pervious one, that's not what we need it for.
We need to record undeployment if the deployment fails or gets aborted.
1. Deploy to testing environement. record deployment for `test`
2. Deploy to beta environment. record deployment for `beta`
3. Deployment gets aborted for any reason, this triggers automatic rollbacks for beta and test
In those automatic rollbacks is where we would like to run pact undeploy.
Is this the expected approach or is there an alternative way to go about this?
siim.mardus
2024-08-26 13:14
If this is not possible, perhaps we can record deployment with environment "rollback" or something :shrug:
eran.bergman560
2024-08-26 19:49
I'm trying to use the dockerized Pact Broker CLI for my POC and I'm trying to figure out what is supported by the https://github.com/pact-foundation/pact_broker-client and what isn't
my use case:
I am using the REST interface: for (1) `http://localhost:8500/pacts/provider/inventory_provider/latest` to see which are the latest pacts targeting my provider `inventory_provider`
this gives me the list of the latest versions of consumers so I picked one of them and called: (2) `localhost:8500/pacts/provider/inventory_provider/consumer/inventory_consumer1/version/1.1.2` which gives the pacts for `inventory_provider` defined by `inventory_consumer1` of version `1.1.2` - this gives me the actual pact
the https://github.com/pact-foundation/pact_broker-client documentation lists only the more "procedural" operations of pushing pacs, managing environments and deployments etc. but is there a Pact CLI command that allows me to perform operations such as (1) and (2) or are these only supported via the REST interface?
matt.fellows
2024-08-26 21:56
Yeah I don?t think those are commonly use operations, so presumably that?s why they aren?t there.
You could always submit a PR to that project to add them, but first - what?s the use case you?re trying to establish here?
eran.bergman560
2024-08-26 23:12
I'm working with a very large application running as a `@SpringBootTest` - takes several minutes to spin up and state setup calls may take a long time so over all long execution time
I want to see if I would be able manage the downloading of the pacts from Pact Broker myself and basically replace `@PactBroker` with `@PactFolder` and potentially even spread the pacts across multiple instances/invocations of the test class so it could be run in parallel on multiple machines in parallel
eran.bergman560
2024-08-26 23:48
https://pact-foundation.slack.com/archives/C9UN99H24/p1710532710280309?thread_ts=1709326714.615869&cid=C9UN99H24 is an older question I had along those lines as `@PactBroker` doesn't really let me get involved in the execution/verification phase, it just points to where to get the pacts from and which pacts to fetch (version, tag, environment etc.)
matt.fellows
2024-08-28 06:07
Use the CLI command to perform an undeployment with the `--verbose` command, and then use that info to determine how to proceed (it will show the verb, path, headers and payload)
siim.mardus
2024-08-28 06:58
I tested the undeployment out, but it seems like it does not really work with rollback. Here is our flow.
1. Deploy version 123 to `test`
2. Deploy version 123 to `beta`
3. Deploy version 123 to `prod`
4. Deployment complete
At this point, the versions should be as follows, right?
? test - 123
? beta - 123
? prod - 123
Now someone makes another deployment
1. Deploy version 456 to `test`
2. Deploy version 456 to `beta`
3. _uh-oh, the developer noticed a bug. Aborting the deployment, rolling back_
4. Rolling back version 456 in `beta`
5. Rolling back version 456 in `test`
What I expected to happen, is that the versions in pact broker would be as follows:
? test - 123
? beta - 123
? prod - 123
... since they all rolled back..
What happened, when using record-undeployment though, was:
? prod - 123
there were no versions marked with `test` or `beta` anymore in pact broker...
siim.mardus
2024-08-28 07:01
:duck: - I guess when we roll back, we can get the version we are rolling back _*to*_ ourselves and just record another deployment on top of it
stan196
2024-08-30 00:24
A question on webhooks variable substitution: https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution
`${pactbroker.providerVersionDescriptions}` is a string, but it seems on the broker side it's actually a list?
Like in my webhook logs I can see that originally it's a list: `"provider_version_descriptions":["latest from main branch"]`
but then when my webhook is called it's converted to a string: `"provider_version_descriptions":"latest from main branch"`.
My webhook was created with `"provider_version_descriptions": "${pactbroker.providerVersionDescriptions}"` as parameter.
So the questions are:
? can there be more than one version description? I'd guess if the same version is deployed in prod and is also the latest master, it would be a list?
? is it possible to pass it as a list to the webhook endpoint, like can I just specify smth like `"provider_version_descriptions": ["${pactbroker.providerVersionDescriptions}"]` as a parameter?
matt.fellows
2024-08-30 01:07
that?s an interesting question, I don?t know actually.
I know that multiple webhooks will fire, once per version that needs to be verified
matt.fellows
2024-08-30 01:07
But these are de-duplicated, so one webhook firing may have multiple reasons (descriptions) for firing
matt.fellows
2024-08-30 01:09
If I read this correctly, it will send it as a comma delimited list: https://github.com/pact-foundation/pact_broker/blob/e84de4f482acac06bfc7fc145a326ab08af92afc/lib/pact_broker/webhooks/pact_and_verification_parameters.rb#L181
stan196
2024-08-30 01:38
yeah, I was aware of deduplication logic, just wasn't sure how the reasons will be presented. And testing it is a little heavy, since it needs publishing couple of versions and some verification results.
Thanks! :slightly_smiling_face:
stan196
2024-09-06 22:59
Hey folks, can you please review this one-liner PR?
https://github.com/pact-foundation/pact_broker/pull/722
I haven't tested it tbh, but just copied the way https://github.com/pact-foundation/pact_broker/blob/7588de6777b3a4ba54d2f60f033e4eb9048c08e1/lib/pact_broker/tasks/delete_overwritten_data_task.rb#L3 has it setup.
It's a bit scary for us to run cleanup tasks without seeing what's gonna get deleted.
siim.mardus
2024-09-12 07:10
We are using `curl` instead of CLI for making `can-i-deploy` checks.
Benefit of CLI is that it has the nice retry logic baked in.
Does anyone have any good examples of implementing the retry logic themselves without the use of CLI?
siim.mardus
2024-09-12 09:28
We did something like this:
```#!/bin/bash
set -ex
PACT_BROKER_BASE_URL="..."
CONSUMER_APP_NAME="..."
ENVIRONMENT=${ENVIRONMENT:-prod}
MAX_RETRIES=30
RETRY_INTERVAL=10
for ((i=1; i<=MAX_RETRIES; i++)); do
response=$(curl --location "$PACT_BROKER_BASE_URL/can-i-deploy?environment=$ENVIRONMENT&pacticipant=$CONSUMER_APP_NAME&version=$CONSUMER_VERSION" \
--header 'Content-Type: application/json')
echo "$response" | jq
deployable=$(echo "$response" | jq -r '.summary.deployable')
if [[ "$deployable" == "true" ]]; then
echo "Deployment is allowed, see above for details."
exit 0
else
echo "Deployment is not allowed, see above for details."
fi
if [[ $i -lt $MAX_RETRIES ]]; then
echo "Retrying in $RETRY_INTERVAL seconds... ($i/$MAX_RETRIES)"
sleep $RETRY_INTERVAL
fi
done
echo "Max retries reached. Deployment is not allowed."
exit 1```
sergey.ledniov
2024-09-12 13:22
Hi everyone,
I'm working on adding pact to a CI/CD pipeline that has `semantic-release` usage.
Consumer pipeline steps:
? yarn lint
? yarn test
? npx semantic-release (this step increments version and commits changes to package.json)
? pact-broker publish (publish pacts with the actual version of the consumer from package.json)
? pact-broker can-i-deploy
Provider pipeline steps:
? yarn lint
? yarn test (runs unit tests, no pact verifications)
? yarn test-integration (runs integration tests, no pact verification)
? npx semantic-release (this step increments the version and commits changes to package.json)
? yarn pact:verify (runs pact verification and publishes verification results to broker)
? pact-broker can-i-deploy
With the consumer pipeline, all seems fine because all tests are performed before the `semantic-release` invocation (https://semantic-release.gitbook.io/semantic-release/usage/ci-configuration#run-semantic-release-only-after-all-tests-succeeded).
However, with the provider pipeline, I have to invoke the pact verification only after the `semantic-release` invocation to have the correct version assigned to verification results published to the broker.
This bugs me because technically there might be a new version of the application that doesn't pass `pact:verify` command (in other words - it breaks the consumer). Ideally, I would like to increment versions only for stable application versions (even for dev builds like `1.2.3-dev.3`).
There is an obvious workaround for this - invoke `pact:verify` with `publishVerificationResult=false` before `semantic-release` step, and then invoke with `publishVerificationResult=true`. But the disadvantage is also obvious - the step is executed twice in the pipeline which adds up to total time.
Am I doing something wrong here?
Are there any best practices available regarding the usage of pact together with `semantic-release`?
iancrowl
2024-09-12 17:30
Hello, I am working with a dev team to utilize pact broker. I do not know much about he it will be used but I am part of the infra team to help create the underlying infra to host it?
at the moment, we have pact-broker running in an azure container instance with a back end postgres db. All load fine.
I have two issue.
The instance being hosted in azure container instance is accessible via http and not https. it is currently publicly accessible because difference environments will call into it. (cant be on the same network so cant run container instance on a private network.
does anyone know how to secure the url/ip using azure container intance
the other thing I have tried is to run pact-broker in an azure app service. I built it, linked to the docker image (using the container setting in the config. and added the same environment variables. I can not seem to get it working. has anyone successfully got this working with an azure app service and the postgres db.
please let me know if there are any docs out there to achieve these.
matt.fellows
2024-09-13 01:48
I think you?re looking for Azure specific advice, we don?t have any guide for that but if you do figure things out, we?d appreciate a PR to our docs to help others.
matt.fellows
2024-09-13 01:49
> The instance being hosted in azure container instance is accessible via http and not https. it is currently publicly accessible because difference environments will call into it. (cant be on the same network so cant run container instance on a private network.
This doc might be helpful when you do get it running. Often times the SSL is terminated at a load balancer and the app isn?t aware it?s running on `https`. These headers/configs might be useful
stan196
2024-09-17 00:21
Hi folks, what's the release schedule of the https://github.com/pact-foundation/pact-broker-docker? We're looking forward for this PR in the docker: https://github.com/pact-foundation/pact_broker/pull/722
yousafn
2024-09-17 08:52
Hey bud, we tend to release on demand post a change. I can see 11 commits since the last so I?ll set it in motion now ( gem needs releasing then consuming in the docker project )
yousafn
2024-09-17 09:47
update gems wf kicked off, which will trigger the image to be built and released
https://github.com/pact-foundation/pact-broker-docker/actions/runs/10900522030
yousafn
2024-09-17 09:50
release wf for image
https://github.com/pact-foundation/pact-broker-docker/actions/runs/10900615989
will take about 45 mins :snail: (because arm/arm64 emulation)
elliott.jacobsen-watt
2024-09-23 16:02
Hello :wave: - we're working on implementing Pact for iOS and Android consumers. We've been discussing pact versioning and release deployment / recording relative to our branching strategy. I'm hoping this community can give us some feedback if we're approaching this the right way.
:evergreen_tree: *Branching:* We use a trunk-based branching strategy. We have one `main` line of code from which we derive `feature/*` and `bug/*` branches. To work on stories, we use `feature/` branches and commit them back. The `feature/` branches are only committed back to `main` once the feature is complete.
:truck: *Environments:* While in development, the debug versions of the mobile apps can communicate with any environment - prod, prod-europe, prod-asia, staging, dev, localhost.
:1234: *Question about versioning:*
? Since we have a number of engineers, it's conceivable that multiple engineers working on the same parts of the app could alter (thus version) a pact. Does it make sense for us to continue using the SHA for each version, rather than tying it to a version of the app itself (e.g.: `1.0.3-`)?
:playground_slide: *Questions about environments + deployment/release recording:*
? We understand the concept mentioned in the documentation about having multiple versions in production, possibly forever. Google Play and the App Store control the availability of the apps. *To us it makes sense to `record-release` when we release a new app to the app stores. Is this best practice?* Deployments are a little more nuanced. As mentioned above, we have a number of branches going at any given time, so we're not as sure when to `record-deployment`. *Any advice here is appreciated.*
? Since our mobile apps can point to any environment while in development, it seems like a given version is deployed simultaneously to each environment, in contrast to a service which makes its way sequentially through local -> dev -> staging -> prod. *In that case, would it make sense to essentially record a new deployment with every push to a branch?*
matt.fellows
2024-09-24 21:06
? Branching: :white_check_mark:
? Environment: see below
? Versioning: Either of those are fine really, the main point is that it?s deterministic and easy to connect a version in PactFlow to a version of code in your VCS. SHA is usually the easiest though
? Deployments/releases
? `record-release` is the usual practice for mobile applications pushing to the app store, yes
? I think you?ll really need to test that for yourself. I can see why you?d do it, but in theory I worry that it could place too much constraint on your provider as it needs to satisfy n versions of your mobile applications in that environment. But if you did, yes, a deployment would be the way to do it (rather than a release)
elliott.jacobsen-watt
2024-09-24 21:28
Thanks for the feedback!
? *Versioning:* We'll stick with SHA for the time being.
? *Deployment/releases:* We settled on *releasing* only in prod environments as a final post-build step when we ship the final release candidate to Google Play or the App Store. We are only *deploying* in non-prod environments once the code is merged back to `mainline`. The result (hopefully) is that providers only need to verify against only a limited number of deployments in the non-prod environments and the releases that are still supported in prod.
jack.middleton183
2024-09-25 09:25
Hey - I am trying to run can-i-deploy in my ADO pipeline using the Docker container version of the CLI, however, it is telling me that I am setting both the `--version` and `--latest` flags, which I am not (that I know of).
This is my pipeline code:
``` - script: |
docker run --rm \
-e PACT_BROKER_BASE_URL=$(PACT_BROKER_BASE_URL) \
-e PACT_BROKER_TOKEN=$(PACT_BROKER_TOKEN) \
pactfoundation/pact-cli:latest \
broker can-i-deploy \
--pacticipant $(PACTICIPANT_NAME) \
--version 0.0.test \
--to-environment test \
--branch $(Build.SourceBranchName)
displayName: 'can-i-deploy Test'```
What am I doing wrong? Where is `--latest` being set?
matt.fellows
2024-09-25 10:01
I think you don't need the branch flag, just on mobile but that might be inferring latest on a branch
matt.fellows
2024-09-25 10:01
You're specifying a version anyway that you're deploying so no need to specify the branch (that should already be associated with a particular version)
iancrowl
2024-09-25 19:45
@matt.fellows I was able to get the pact broker service running in an app service running in Azure.
I am happy to update the docs but I do not have a clue where to do this. can you link me/provide instructions?
matt.fellows
2024-09-25 22:50
You can clone this project: https://github.com/pact-foundation/docs.pact.io
amaans
2024-09-27 05:46
Hey team,
I need some help with the webhook flow. While creating a webhook is there a way to specify that for which environment I am creating the webhook? Thanks.
iancrowl
2024-09-27 19:25
Question about the database needed for pact-broker. does it need a postgres database. could another DB try work.
the reason for my question is very specific. As I posted earlier, I am working on deploying this in azure. I have a successful deployment using an azure container instance service and running in an Azure Web App.
In my environment, we try to make sure all resources are on a private network. We have a hub and spoke virtual network model.
Resource that can natively connect to the vNet are, like a Virtual machine. or using vNet integration with the Web app. However resource like a key vault or postgres can be connected with a private endpoint resource.
I am running into issues applying the private endpoint resource to the postgres resource.
I have had success with private endpoint connections with cosmos, or azure sql, etc... Can you use another database for a production workload of pact-broker?
yousafn
2024-09-27 21:40
only postgres and sqlite are supported with the latter not recommended for production. mysql was once supported but we?ve since dropped official support
elliott.jacobsen-watt
2024-10-01 17:32
@matt.fellows, to follow up: Does mobile _need_ to use `record-deployment` in our non-prod environments if our providers are using best practices to ask for the latest version of a pact?
We understand that `record-release` is useful for when we deploy to production environments so providers can test against all the released versions.
rabrosimov
2024-10-02 15:17
Hi. Perhaps someone knows if it possible to switch from new UI design Pact broker to previous one?
thanks
yousafn
2024-10-02 15:20
I assume you are talking about PactFlow? you should use #pactflow-ama or the #pactflow channel, this channel is for the open source Pact Broker.
For the new PactFlow UI
yousafn
2024-10-02 15:38
let me check the release notes, the new design may have been GA?d and the switch button needs to be removed.
yousafn
2024-10-02 16:03
Have you provided your feedback as to what you want to see from the old UI, in the new UI?
At some point in the not too distant future, we will be fully switching over, and the old UI will be retired. The innovations the team have made behind the scenes as well as what you can see, so we will see QoL improvements for end users and our teams developers alike, but appreciate there will be some teething pains
matt.fellows
2024-10-02 22:00
If you've completed the survey we'll have the feedback but if not we would love it.
For now there may be a bug in the toggle we need to I fix ASAP
amaans
2024-10-03 05:19
Apologies for replying so late, I had a misconception around how the environments work but I read through the documentation and the query has been resolved. Thanks for the response though.
yousafn
2024-10-03 09:03
Hey @rabrosimov, we?ve resolved the bug and you can utilise the old UI again.
There will be comms with a date for a full switch-over when we have a new date in mind.
thanks for raising
matt.fellows
2024-10-04 06:47
> @matt.fellows, to follow up: Does mobile _need_ to use `record-deployment` in our non-prod environments if our providers are using best practices to ask for the latest version of a pact?
What do you mean by ?latest version? of a pact here? Latest could be latest altogether or latest for a branch. Usually we discourage ?latest? because it?s not clear
matt.fellows
2024-10-04 06:47
I think it?s good practice in general to record a deployment though, as it clarifies the state of the system
elliott.jacobsen-watt
2024-10-04 15:39
> What do you mean by ?latest version? of a pact here?
I'm using latest in the same way the https://docs.pact.io/getting_started/versioning_in_the_pact_broker#version-ordering describe it: ""latest pact" for an integration is available at the URL `/pacts/provider/{provider}/consumer/{consumer}/latest`, and refers to pact for the most recently created _pacticipant version_."
> Usually we discourage ?latest? because it?s not clear
Good to know. As mobile *consumers*, I am less familiar with the provider side of the equation. If Pact discourages use of "latest", does the provider specify a consumer version and keep changing it?
> I think it?s good practice in general to record a deployment though, as it clarifies the state of the system
Heard. Our current setup has us recording a deployment from `mainline` whenever we merge feature, bug, or story branch back into it. In this way, `mainline` serves as our non-prod environment(s).
sergey.ledniov
2024-10-08 09:55
Hi,
I'm trying to understand if I don't have any misunderstanding of the provider pipeline.
Let's review the example of provider pipeline (very simplified, only pact invocations):
? `pact verify` (verify consumers according to selectors)
? `pact can-i-deploy` (check if this provider version is safe for deploy)
If `pact verify` step fails when the provider breaks one of it's consumers and the pipeline invocation is interrupted - does it actually make sense to have `pact can-i-deploy` as the next step at all?
Is it a false assumption that both commands either pass or fail together?
bas
2024-10-08 10:22
No, that makes sense. Failing verification means there?s a potential integration issue and you?ll likely want to investigate and resolve that before you deploy.
Also don?t forget the `record-deployment` or `record-release` step after successful deployment to update your broker with the latest versions in your target environment.
sergey.ledniov
2024-10-08 13:09
Does it mean that `can-i-deploy` is mostly for the consumer, whereas provider is guarded by failing `verify` task?
matt.fellows
2024-10-09 00:26
yep, that?s mostly true Serhii.
There are some nuances to it, however.
If your provider build verifies both production consumers and main branches (or others) and fails, it may still be safe to release to production.
e.g. if your provider verification has the https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors#recommended or default selectors, or default selectors, and all but the `deployedOrReleased` pacts are passing, you may still decide to deploy to production.
This is where you need to map it onto your workflow.
But as a general rule, you want your verification task to be green before deploying. We also recommend running `can-i-deploy` directly prior to release, in case of any race conditions between steps where the situation on the consumer side has changed.
stan196
2024-10-09 06:12
Hey folks, can you please review this PR? It adds the `--ignore` flag support to `can-i-merge` command which we use in our workflow
https://github.com/pact-foundation/pact_broker-client/pull/174
matt.fellows
2024-10-09 10:44
Will take a look later this week, I might need to refer to a colleague who can properly confirm though
grufino
2024-10-09 15:49
Hi,
I am attempting to configure environments for our deployed Pact Broker using the Pact Broker CLI. I built a docker image of the Pact CLI and have a script that creates the environments if they don't exist. When I make the call using http, the command works. When we switched the Pact Broker to https, I get this error: "NoMethodError - undefined method `request_uri' for an instance of URI::Generic". This happens for both the pact broker list-environments and create-environment commands. I have passed the url as a hard-coded value and as a env variable. Not sure why Ruby isn't picking up the https.
stan196
2024-10-09 20:57
Builds on ruby 2.7 are failing because I've added `ruby-lsp-rspec` package for vs code support, and that one only works with 3.0+; I'll remove that package and update the PR.
matt.fellows
2024-10-10 03:09
mind sharing a bit more about how you run the command? Ideally, a call with `--verbose`? That will help us dive a bit deeper
grufino
2024-10-10 13:46
`PACT_BROKER_BASE_URL is set to: https://some-website.domain.com`
`PACT_BROKER_USERNAME is set to: pactbroker`
`PACT_BROKER_PASSWORD is set to: ***`
`Listing environments`
`Standard Output:`
`opening connection to http://some-website.domain.com:443...`
`opened`
`starting SSL for http://some-website.domain.com:443...`
`SSL established, protocol: TLSv1.2, cipher: ECDHE-ECDSA-CHACHA20-POLY1305`
`GET /? HTTP/1.1\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nAuthorization: [redacted]\r\n`
`HTTP/1.1 200 OK\r\n`
`Date: Thu, 10 Oct 2024 03:17:21 GMT\r\n`
`Content-Type: application/hal+json;charset=utf-8\r\n`
`Content-Length: 4720\r\n`
`Connection: keep-alive\r\n`
`Set-Cookie: ARRAffinity=b08b793703ed90c29d190499db3bc194822d9b232329810c8844678e66822c18;Path=/;HttpOnly;Secure;Domain=http://some-website.domain.com\r\n`
`Vary: Accept\r\n`
`X-Pact-Broker-Version: 2.106.0\r\n`
`X-Content-Type-Options: nosniff\r\n`
`CF-Cache-Status: DYNAMIC\r\n`
`Set-Cookie: ARRAffinitySameSite=b08b793703ed90c29d190499db3bc194822d9b232329810c8844678e66822c18;Path=/;HttpOnly;SameSite=None;Secure;Domain=http://some-website.domain.com\r\n`
`Set-Cookie: _cfuvid=vUFJsISOdU05_yMkz4LL4Jjbxoy.lGgOOC78dp2.TgY-1728530241177-0.0.1.1-604800000; path=/; domain=.http://domain.com; HttpOnly; Secure; SameSite=None\r\n`
`Server: cloudflare\r\n`
`CF-RAY: 8d0374f488e907a8-IAD\r\n`
`\r\n`
`reading 4720 bytes...`
`{`
`"_links": {`
`"self": {`
`"href": "http://some-website.domain.com",`
`"title": "Index",`
`"templated": false`
`},`
`"pb:publish-pact": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/consumer/{consumer}/version/{consumerApplicationVersion}",`
`"title": "Publish a pact",`
`"templated": true`
`},`
`"pb:publish-contracts": {`
`"href": "http://some-website.domain.com/contracts/publish",`
`"title": "Publish contracts",`
`"templated": false`
`},`
`"pb:latest-pact-versions": {`
`"href": "http://some-website.domain.com/pacts/latest",`
`"title": "Latest pact versions",`
`"templated": false`
`},`
`"pb:tagged-pact-versions": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/consumer/{consumer}/tag/{tag}",`
`"title": "All versions of a pact for a given consumer, provider and consumer version tag",`
`"templated": false`
`},`
`"pb:pacticipants": {`
`"href": "http://some-website.domain.com/pacticipants",`
`"title": "Pacticipants",`
`"templated": false`
`},`
`"pb:pacticipant": {`
`"href": "http://some-website.domain.com/pacticipants/{pacticipant}",`
`"title": "Fetch pacticipant by name",`
`"templated": true`
`},`
`"pb:latest-provider-pacts": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/latest",`
`"title": "Latest pacts by provider",`
`"templated": true`
`},`
`"pb:latest-provider-pacts-with-tag": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/latest/{tag}",`
`"title": "Latest pacts for provider with the specified tag",`
`"templated": true`
`},`
`"pb:provider-pacts-with-tag": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/tag/{tag}",`
`"title": "All pact versions for the provider with the specified consumer version tag",`
`"templated": true`
`},`
`"pb:provider-pacts": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}",`
`"title": "All pact versions for the specified provider",`
`"templated": true`
`},`
`"pb:latest-version": {`
`"href": "http://some-website.domain.com/pacticipants/{pacticipant}/latest-version",`
`"title": "Latest pacticipant version",`
`"templated": true`
`},`
`"pb:latest-tagged-version": {`
`"href": "http://some-website.domain.com/pacticipants/{pacticipant}/latest-version/{tag}",`
`"title": "Latest pacticipant version with the specified tag",`
`"templated": true`
`},`
`"pb:webhooks": {`
`"href": "http://some-website.domain.com/webhooks",`
`"title": "Webhooks",`
`"templated": false`
`},`
`"pb:webhook": {`
`"href": "http://some-website.domain.com/webhooks/{uuid}",`
`"title": "Webhook",`
`"templated": true`
`},`
`"pb:integrations": {`
`"href": "http://some-website.domain.com/integrations",`
`"title": "Integrations",`
`"templated": false`
`},`
`"pb:pacticipant-version-tag": {`
`"href": "http://some-website.domain.com/pacticipants/{pacticipant}/versions/{version}/tags/{tag}",`
`"title": "Get, create or delete a tag for a pacticipant version",`
`"templated": true`
`},`
`"pb:pacticipant-branch-version": {`
`"href": "http://some-website.domain.com/pacticipants/{pacticipant}/branches/{branch}/versions/{version}",`
`"title": "Get or add/create a pacticipant version for a branch",`
`"templated": true`
`},`
`"pb:pacticipant-version": {`
`"href": "http://some-website.domain.com/pacticipants/{pacticipant}/versions/{version}",`
`"title": "Get, create or delete a pacticipant version",`
`"templated": true`
`},`
`"pb:metrics": {`
`"href": "http://some-website.domain.com/metrics",`
`"title": "Get Pact Broker metrics"`
`},`
`"pb:can-i-deploy-pacticipant-version-to-tag": {`
`"href": "http://some-website.domain.com/can-i-deploy?pacticipant={pacticipant}&version={version}&to={tag}",`
`"title": "Determine if an application version can be safely deployed to an environment identified by the given tag",`
`"templated": true`
`},`
`"pb:can-i-deploy-pacticipant-version-to-environment": {`
`"href": "http://some-website.domain.com/can-i-deploy?pacticipant={pacticipant}&version={version}&environment={environment}",`
`"title": "Determine if an application version can be safely deployed to an environment",`
`"templated": true`
`},`
`"pb:provider-pacts-for-verification": {`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/for-verification",`
`"title": "Pact versions to be verified for the specified provider",`
`"templated": true`
`},`
`"beta:provider-pacts-for-verification": {`
`"name": "beta",`
`"href": "http://some-website.domain.com/pacts/provider/{provider}/for-verification",`
`"title": "DEPRECATED - please use pb:provider-pacts-for-verification",`
`"templated": true`
`},`
`"curies": [`
`{`
`"name": "pb",`
`"href": "http://some-website.domain.com/doc/{rel}?context=index",`
`"templated": true`
`},`
`{`
`"name": "beta",`
`"href": "http://some-website.domain.com/doc/{rel}?context=index",`
`"templated": true`
`}`
`],`
`"pb:environments": {`
`"title": "Environments",`
`"href": "http://some-website.domain.com/environments",`
`"templated": false`
`},`
`"pb:environment": {`
`"title": "Environment",`
`"href": "http://some-website.domain.com/environments/{uuid}",`
`"templated": true`
`}`
`}`
`}`
`read 4720 bytes`
`Conn keep-alive`
`NoMethodError - undefined method `request_uri' for an instance of URI::Generic`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/hal/http_client.rb:49:in `create_request'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/hal/http_client.rb:25:in `get'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/hal/link.rb:41:in `get'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/hal/link.rb:45:in `get!'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/environments/list_environments.rb:17:in `environments_resource'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/environments/list_environments.rb:24:in `result_message'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/environments/list_environments.rb:13:in `do_call'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/base_command.rb:25:in `call'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/base_command.rb:13:in `call'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/cli/environment_commands.rb:60:in `execute_environment_command'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/cli/environment_commands.rb:45:in `list_environments'`
`/usr/lib/ruby/gems/3.3.0/gems/thor-1.3.2/lib/thor/command.rb:28:in `run'`
`/usr/lib/ruby/gems/3.3.0/gems/thor-1.3.2/lib/thor/invocation.rb:127:in `invoke_command'`
`/usr/lib/ruby/gems/3.3.0/gems/thor-1.3.2/lib/thor.rb:538:in `dispatch'`
`/usr/lib/ruby/gems/3.3.0/gems/thor-1.3.2/lib/thor/base.rb:584:in `start'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/lib/pact_broker/client/cli/custom_thor.rb:34:in `start'`
`/usr/lib/ruby/gems/3.3.0/gems/pact_broker-client-1.76.1/bin/pact-broker:10:in `<top (required)>'`
`/usr/bin/pact-broker:25:in `load'`
`/usr/bin/pact-broker:25:in `<main>'`
`Standard Error:`
`Exit Status:`
`1`
grufino
2024-10-10 13:48
The script:
`#!/usr/bin/env ruby`
`require 'open3'`
`def environment_exists?(name)`
`puts "PACT_BROKER_BASE_URL is set to: #{ENV['PACT_BROKER_BASE_URL']}"`
`puts "PACT_BROKER_USERNAME is set to: #{ENV['PACT_BROKER_USERNAME']}"`
`puts "PACT_BROKER_PASSWORD is set to: #{ENV['PACT_BROKER_PASSWORD']}"`
`stdout, stderr, status = Open3.capture3("pact-broker list-environments --verbose")`
`stdout.include?(name)`
`end`
`def create_environment_if_not_exists(name, display_name, options)`
`if environment_exists?(name)`
`puts "Environment #{name} already exists."`
`else`
`puts "Creating environment #{name}, ruby implementation"`
`system("pact-broker create-environment --verbose --name #{name} --display-name \"#{display_name}\" #{options}")`
`end`
`end`
`# Create Environments if they do not exist`
`create_environment_if_not_exists("dev1", "dev1", "--no-production")`
`create_environment_if_not_exists("dev2", "dev2", "--no-production")`
`create_environment_if_not_exists("stg-us", "stg-us", "--no-production")`
`create_environment_if_not_exists("stg-de", "stg-de", "--no-production")`
`create_environment_if_not_exists("prod-us", "prod-us", "")`
`create_environment_if_not_exists("prod-ca", "prod-ca", "")`
`create_environment_if_not_exists("prod-de", "prod-de", "")`
`create_environment_if_not_exists("prod-uk", "prod-uk", "")`
grufino
2024-10-10 14:39
I have figured it out. We set our PACT_BROKER_BASE_URL on the pact broker deployment to "http://some-website.domain.com" instead of "https://some-website.domain.com".
matt.fellows
2024-10-10 22:39
Yes, you can see that this is the problem because the first request works, it fetches the HAL resource but all of the links were missing the protocol
matt.fellows
2024-10-10 22:40
For future reference https://docs.pact.io/pact_broker/configuration/features#when-the-base-url-configuration-is-supported-v2460-and-later might be a relevant resource
stan196
2024-10-15 18:58
Hi folks, is the following behavior as designed?
Assume we have a service X with version vX which has not yet been published to the pact broker.
If I run `can-i-deploy` or `can-i-merge` for that version with `--retry-while-unknown` flag it behaves differently depending on whether the service is a consumer-only or if it has provider tests:
? if the service has consumer tests only, the command will not retry and will exit immediately
? if the service has provider tests (in my case it was provider tests only), it will retry as specified by flags
stan196
2024-10-15 19:01
Seems like this is governed by whether there's `unknown` in the result returned by the broker.
What's the logic behind the `unknown` field, like when is it populated?
matt.fellows
2024-10-16 05:16
I?d need to follow up with somebody who?s closer to the code, but the `--retry-while-unknown` is orthogonal to the application?s role, although in practice I think it means a verification result has not yet been populated for the target _version_ to be deployed/merged.
e.g. if you wanted to do `can-i-deploy -a X -v vX` then it would lookup `vX` in the broker, check for any related contracts and verification results associated with them. If there are any results not published, I think this would produce an `unknown` value for that, and wait.
I think what you _might_ be saying is that you?ve created version `vX` in the broker, but have yet to publish a contract associated with it and it?s not waiting?
stan196
2024-10-16 07:58
I've checked that the version in question isn't present in the broker in either case. Can the broker make a decision based on a previously published versions or smth?
stan196
2024-10-16 07:59
when I looked closely at the results, I noticed that in the case when it was waiting, the `provider` object under `matrix` had `name` set to `X` but `version` to `null`
stan196
2024-10-16 08:02
i think what might be happening is that there is a consumer pact published which calls out provider `X` as a dependency, but `vX` was never verified against that consumer pact. However in case of a service that's consumer-only, there is no contract in the broker that calls it a dependency, so it just exits?
adrien.devillers
2024-10-18 09:56
Hi Everyone,
I couldn?t find an answer to my question in the chat, so apologies If my question has already been asked...
I? m searching in the Pact Broker API (pactfoundation/pact-broker:2.115.0) a way to retrieve the pacticipants version by environment
I couldn?t find something helpful with ruby CLI either
is there a way to do that?
thanks
adrien.devillers
2024-10-18 14:36
I found something to work with
`/environments/{env-uuid}/deployed-versions/currently-deployed`
I was rather looking for a view by pacticipant, so if you have a better endpoint I?ll take it ! Anyway I?ll make do with that for the moment
ramon.saraiva
2024-10-18 20:00
I have this to get the latest version by participante and branch, may there is some similar:
```/pacticipants/{participant}/branches/{BRANCH}/latest-version```
matt.fellows
2024-10-18 21:36
No API / CLI currently exists for that. You could consider creating a PR for it if interested? The data is all there it would just need an API route
matt.fellows
2024-10-18 21:37
Hmmmm no version in the broker, I'd expect the command to fail with a "not found" type error. Do you have any example output to review?
marcus
2024-10-21 17:23
Hey there!
I am trying to extract the network graph from the broker, but the steps described in the https://docs.pact.io/pact_broker/network_graph don?t seem to work. Does anyone know how to make this work?
Thank you!
adrien.devillers
2024-10-22 08:01
Thanks for your answers, I have a workaround, but I?ll try to find time to add a route as I think it will be useful for the project :+1:
marcus
2024-10-22 14:04
I tried with an application I have in my instance, but the script does not return anything as well. I tried both PactFlow and the local pact broker.
matt.fellows
2024-10-22 22:23
It might just be that the commands are linux or Mac specific. The APIs haven?t changed, so hopefully you can modify the script to produce a valid dot file etc.
marcus
2024-10-22 22:39
I mean, should the `curl` command return something, right? Does it work for you with any instance you may have?
matt.fellows
2024-10-22 23:06
```curl -v -u 'dXfltyFMgNOFZAxr8io9wJ37iUpY42M:O5AIZWxelWbLvqMd8PkAVycBJh2Psyg1' https://test.pactflow.io/pacts/latest
* Trying 3.33.170.218:443...
* Connected to http://test.pactflow.io (3.33.170.218) port 443
* ALPN: curl offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* (304) (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN: server accepted h2
* Server certificate:
* subject: CN=*.http://pactflow.io
* start date: Jul 9 00:00:00 2024 GMT
* expire date: Aug 8 23:59:59 2025 GMT
* subjectAltName: host "http://test.pactflow.io" matched cert's "*.http://pactflow.io"
* issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M02
* SSL certificate verify ok.
* using HTTP/2
* Server auth using Basic with user 'dXfltyFMgNOFZAxr8io9wJ37iUpY42M'
* [HTTP/2] [1] OPENED stream for https://test.pactflow.io/pacts/latest
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: http://test.pactflow.io]
* [HTTP/2] [1] [:path: /pacts/latest]
* [HTTP/2] [1] [authorization: Basic ZFhmbHR5Rk1nTk9GWkF4cjhpbzl3SjM3aVVwWTQyTTpPNUFJWld4ZWxXYkx2cU1kOFBrQVZ5Y0JKaDJQc3lnMQ==]
* [HTTP/2] [1] [user-agent: curl/8.4.0]
* [HTTP/2] [1] [accept: */*]
> GET /pacts/latest HTTP/2
> Host: http://test.pactflow.io
> Authorization: Basic ZFhmbHR5Rk1nTk9GWkF4cjhpbzl3SjM3aVVwWTQyTTpPNUFJWld4ZWxXYkx2cU1kOFBrQVZ5Y0JKaDJQc3lnMQ==
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/2 200
< date: Tue, 22 Oct 2024 23:06:22 GMT
< content-type: application/hal+json;charset=utf-8
< content-length: 451843
< vary: Accept,Origin,Accept-Encoding
< cache-control: no-cache
< server: Webmachine-Ruby/2.0.1 Rack/1.3
< x-content-type-options: nosniff
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< x-pact-broker-git-sha: 87669c36
< x-pactflow-git-sha: b70992554
< x-pact-broker-version: 2.112.0
< x-request-id: ddd2c4462357324444262e5083bf697c
<
{"pacts":[{"createdAt":"2024-10-22T15:16:05+00:00","_embedded":{"consumer":{"name":"actions-consumer","_embedded":{"version":{"number":"2b4e9b508f6b0eb9db3350562c3adc1a75977161","_links":{"self":{"title":"Version","name":"2b4e9b508f6b0eb9db3350562c3adc1a75977161","href":"https://test.pactflow.io/pacticipants/actions-consumer/versions/2b4e9b508f6b0eb9db3350562c3adc1a75977161"}}}},"_links":{"self":{"href":"https://test.pactflow.io/pacticipants/actions-consumer"}}},"provider":{"name":"actions-provider","_links":{"self":{"href":"https://test.pactflow.io/pacticipants/actions-provider"}}}},"_links":{"self":[{"href":"https://test.pactflow.io/pacts/provider/actions-provider/consumer/actions-consumer/latest"},{"href":"https://test.pactflow.io/pacts/provider/actions-provider/consumer/actions-consumer/version/2b4e9b508f6b0eb9db3350562c3adc1a75977161"}]}},{"createdAt":"2024-09-04T07:28:48+00:00","_embedded":{"consumer":{"name":"ad-service","_embedded":{"version":{"number":"0.0.1-SNAPSHOT","_links":{"self":{"title":"Version","name":"0.0.1-SNAPSHOT","href":"https://test.pactflow.io/pacticipants/ad-service/versions/0.0.1-SNAPSHOT"}}}},"_links":{"self":{"href":"https://test.pactflow.io/pacticipants/ad-service"}}},"provider":{"name":"campaign-service","_links":{"self":{"href":"https://test.pactflow.io/pacticipants/campaign-service"}}}},"_links":{"self":[{"href":"https://test.pactflow.io/pacts/provider/campaign-service/consumer/ad-service/latest"},{"href":"https://test.pactflow.io/pacts/provider/campaign-service/consumer/ad-service/version/0.0.1-SNAPSHOT"}]}},{"createdAt":"2023-07-19T16:11:21+00:00","_embedded":{"consumer":{"name":"AdamConsumerTest","_embedded":{"version":{"number":"0.0.0","_links":{"self":{"title":"Version","name":"0.0.0","href":"https://test.pactflow.io/pacticipants/AdamConsumerTest/versions/0.0.0"}}}},"_links":{"self":{"href":"https://test.pactflow.io/pacticipants/AdamConsumerTest"}}},"provider":{"name":"AdamProviderTest","_links":{"self":{"href":"https://test.pactflow.io/pacticipants/AdamProviderTest"}}}},"_links":{"self":[{"href":"https://test.pactflow.io/pacts/provider/AdamProviderTest/consumer/AdamConsumerTest/latest"},{"href":"https://test.pactflow.io/pacts/provider/AdamProviderTest/consumer/AdamConsumerTest/version/0.
....```
stan196
2024-10-23 05:46
friendly ping on this, I've responded to the comments :slightly_smiling_face:
matt.fellows
2024-10-23 06:09
Thanks Stan - I do apologise, you?re on the list, I?m just working my way down the pile! :sonic:
marcus
2024-10-23 14:18
Yeah, the `curl` returns something; sorry for the misunderstanding. I meant that the `jq` commands don?t seem right (at least for my installation). For instance, it filters `select(.consumer.name | contains("AWSSummiteer"))`, but I don?t see any `AWSSummiteer` element being returned. Anyway, I could fix it by removing the `| contains("AWSSummiteer")` from the expression, and it worked for me :shrug:
Thank you!
matt.fellows
2024-10-25 03:02
basically, you can drop the contains or narrow it to the application ecosystem you want to see.
fvivas.dev
2024-10-29 11:58
I have some doubts with the pact-broker api.
I would like to to get all pacts via api for a consumer on one hand and then I would like to get all the pacts via api for a provider onther other hand.
How should I do it?
If try this way, with this url:
https//pactbroker-base-url/pacticipants/pacticipant-name-consumer/versions/number-consumer
i get a response with this schema where I can get all the pacts related (?).
{
...
*pb:pact-versions: [{*
*title: "...",*
*name: "...",*
href: "https://pactflow.scrm.lidl/verification-results/consumer/pacticipant-name-consumer/version/number-consumer/latest"
*}, ...]*
*...*
}
BUT if i try the same url with a pacticipant as provider
https://pactbroker-base-url/pacticipants/pacticipant-name-provider/versions/number-provider
i get a response without "pb:pact-version" on this schema and I cannot get all the pacts related. (x)
{
...
~*pb:pact-versions: [{}] not exists*~
*...*
}
thank you!
fvivas.dev
2024-10-30 16:30
Hi Matt,
I would like to develop a Backstage-plugin for PactFlow with React.
My idea is to build a frontend plugin like your dashboard (but simpler).
This react-app will be a Tab on Backstage where any user can click on a pact (given a pacticipant) to go to PactBroker and get the final information,
antonio.blandon
2024-10-30 16:38
Hi everyone, Could someone help me with the bellow question ... I have a monorepo and just one CI pipeline. What is the right way to reference the pacticipant for can-i-deploy and record-deployment, taking in mind I have a lot of API's?
dienguyen
2024-11-01 08:43
Hi everyone, I have issue when using pact_verifier_cli with version:
pact verifier version : v1.1.4
pact specification : v4.0
models version : v1.2.4
When I run with config as below:
```pact_verifier_cli \
--provider-name Product \
--hostname "${PACT_PROVIDER_HOSTNAME}" \
--broker-url "${PACT_BROKER_BASE_URL}" \
--user "${PACT_BROKER_USERNAME}" \
--password "${PACT_BROKER_PASSWORD}" \
--publish \
--provider-version "${VERSION}"```
I received failures: *"Failed to prepare interaction for verification - Failed to prepare the request: Did not find an interaction that matches the given key 'e3cbd123*". Can anyone help me to resolve this problem ?
yousafn
2024-11-01 11:58
can you provide the pact, a screenshot isn?t particular usable to recreate.
which version lib created it?
the key field was removed in later versions of the pact core. can you try removing the key field manually
siim.mardus
2024-11-01 13:43
Hello! I have a question about `can-i-deploy` checks.
*Currently I have set up as follows:*
_Consumer CI pipeline:_
1. Run contract tests & publish pacts
2. (if `contract_requiring_verification`, also run provider verification via webhook)
3. can-i-deploy checks for beta & productions envs
_Consumer Deploy pipeline_
1. Run contract tests & publish pacts
2. can-i-deploy checks for beta
3. _Deploy to beta_
4. record-deployment for beta
5. _Deploy to production_
6. record-deployment for production
Provider CI/CD is pretty much the same, besides provider verification job step.
*However, I ran into an issue...*
I wanted to change a Provider state setup. To do that I first added a _new_ provider state, then deployed it to production. This _new_ provider state is not yet used at this point.
Then I wanted to deploy Consumer to make an existing test use this new improved provider state, but Step (3) of Consumer CI pipeline fails, because `There is no verified pact between version between version x of consumer and version of provider currently in beta` ...
What can I do to resolve this? Should I not run can-i-deploy checks in some conditions? Does solution to this situation have something to do with pending or wip pacts (I have pending pacts enabled, but not wip)?
yousafn
2024-11-01 15:01
I?m a bit confused.
> Then I wanted to deploy Consumer to make an existing test use this new improved provider state, but Step (3) of Consumer CI pipeline fails,
What was the result of the verification triggered by the webhook in step 2, this should have triggered for main line and deployed/released versions of that provider
dienguyen
2024-11-01 15:14
Yeah, I will check again version lib created the pact, many thanks:star-struck:. This is my pact file as below
yousafn
2024-11-01 16:33
Hey thanks for that, okay so its the latest version of pact-jvm
``` "pact-jvm": {
"version": "4.6.15"
}```
If I remove the key it works for me
yousafn
2024-11-01 16:35
It was removed in pact-reference/rust as part of this issue
https://github.com/pact-foundation/pact-reference/issues/264#issuecomment-1556582681
pact-jvm has its own core engine and does not use the rust core, so I think you may need to raise an issue against pact-jvm, and state you would expect the key not to be there in a generated pact in the latest version of pact-jvm, as it causes issues with interop with pact-rust based libraries
Ron is the main maintainer of both, so he should be able to sort
dienguyen
2024-11-01 16:52
Thank you for your respond, I will raise this issue to group pact-jvm to improve the latest version:wink:
dienguyen
2024-11-02 05:17
Hi @yousafn, I tried to remove the key in my pact manually but it still not working and displays error as below. Do you know this issue ?
yousafn
2024-11-02 13:27
have you configured the transport option for grpc?
https://github.com/pact-foundation/pact-reference/tree/master/rust/pact_verifier_cli#command-line-interface
dienguyen
2024-11-02 13:49
Ya, this is my mistake:face_with_hand_over_mouth:. I have not configured the transport option for grpc :sweat_smile:, thanks
dienguyen
2024-11-02 14:28
@yousafn This issue (*verify the request: transport error*) is still happening when I added config --transport=grpc :smiling_face_with_tear:. Please see the attached config image
matt.fellows
2024-11-03 02:17
there are a few APIs documented here: https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started
The `/integrations` endpoint might be a helpful starting point to navigate the hierarchy
siim.mardus
2024-11-04 07:25
> What was the result of the verification triggered by the webhook in step 2
It succeeded and reported that this pact is verified.
siim.mardus
2024-11-04 07:29
> this should have triggered for main line and deployed/released versions of that provider
Oh so what you are saying is that the second step should trigger provider verification jobs between my new consumer version and all environments? So if I have beta and production environment, it should run 2 (or 3) jobs.
? with version currently in beta
? with version currently in prod
? (_maybe also with version currently in master, which I currently do_)
yousafn
2024-11-04 07:34
yeah so if you have 2 envs, and the versions are diff from provider main branch i would expect 3 webhooks. your ci would need to checkout the correct version of the code ( which is why we recommend the sha as part of the consumer version number - but whichever way works to identify the versions released/deployed and how to get the codebase in that state ) - if you didn?t check out the correct version, its likely that all three verifications would run against your main branch ( and as they publish results, they would only publish for that version )
https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event
siim.mardus
2024-11-04 07:38
Ah okay I am starting to understand what is the issue now. We have actually multiple integrations already that have worked flawlessly and this started occurring with the latest provider service we added.
the reason it has worked for the previous ones is that the provider version was same across all envs. That's why triggering one job was sufficient. Ideally it will be the same.
Something is off with the new provider CD pipeline that has an incosistent versioning and environment tagging. Since ACTUALLY the version is the same across all envs currently, it should work when running provider verification against this.
elliott.jacobsen-watt
2024-11-04 16:38
Question about mobile consumers: Is it necessary for mobile apps to *`record-deployment`* in non-prod environments, or can we just perform *`record-release`* in production environments?
Context:
We have several providers that were only running `can-i-merge` as part of their CI pipelines because they figured as long as the mainline build was passing, they could roll out to prod without issue. This was fine until mobile consumers needed those providers to verify against version*s* (plural) in prod. Now, they need to run `can-i-deploy` at least in those production envs.
I work on the Mobile consumer team. I initially implemented `can-i-deploy` (every pipeline run, all envs) and `record-deployment` (only for non-prod envs when merging back to our `mainline`) steps in our pipeline, but now thinking about it, I don't know how much sense that makes, since consumers are running against our mainline with `can-i-merge` anyway.
So the updated pipelines would be:
? For story and feature branches:
? `publish`
? `can-i-merge`
? For `release/` branches:
? `publish`
? `can-i-deploy`
? Post-release to App Store and Google Play: `record-release`
matt.fellows
2024-11-06 05:26
what does ?deployed? (or ?released?) look like in non-prod environments? With web apps or APIs, you would usually deploy them to an environment to play with. But I?m guessing it?s a bit different with mobile?
yousafn
2024-11-07 10:57
Can you try with debug or trace logs?
I notice two things aren?t really recommended in your config, but may not be related to your issue.
1. Your provider version shouldn?t be randomly generated, it should only change when your provider code changes, and be related to an artefact you will deploy into an environment, so that you can query this later with the can-i-deploy tool
2. You are retrieving pacts from the pact broker, but not providing any consumer version selectors, meaning you will be verifying the latest pact for that provider, meaning you will probably miss verifications. recommendation is https://docs.pact.io/provider/recommended_configuration#if-using-branchesenvironments.
Can you try with `--file` and pass it the pact-file you have shared with me, and remove `broker-url` / `user` / `password` and `publish` for the time being?
It will mean the logs will be a bit less noisy when we try and ascertain what the issue is. The debug/trace logs should possibly shed some more light
elliott.jacobsen-watt
2024-11-07 15:48
> what does ?deployed? (or ?released?) look like in non-prod environments?
Good question. We have a fairly large team that deals with 2-6 projects at the same time. Most projects use feature branches comprised of story branches that get merged back to `mainline` when the project is complete. A debug version of our apps can point to any combination of region + environment, but the app doesn't get deployed to an environment the same way an API or web app does. Testers can choose to download any version of the app from github that's been built, rather than the latest built version superseding the rest. So the deployment metaphor doesn't really fit.
In an https://pact-foundation.slack.com/archives/C9VPNUJR2/p1727107374912829 question, I said:
> Our current setup has us "recording a deployment" from `mainline` whenever we merge feature, bug, or story branch back into it. In this way, `mainline` serves as our non-prod environment(s).
But since most of our `providers` are using `can-i-merge`, they'd just be testing against mainline anyways.
stan196
2024-11-07 19:14
apologies, this slipped through the cracks.
Above is the response of `/can-i-deploy?pacticipant=cc-useless-service&version=non-existent&environment=stag` API call via HAL,
this is a provider service (ie there are consumers present and deployed that depend on it)
stan196
2024-11-07 19:14
If you run `can-i-deploy` cli for this, it will retry as specified via --retry flags
stan196
2024-11-07 19:15
Here's the response for a different service, which is consumer only (there are no other consumers depending on it)
```{
"summary": {
"deployable": false,
"reason": "No pacts or verifications have been published for version non-existent of cc-pointless-service",
"success": 0,
"failed": 0,
"unknown": 0
},
"notices": [{
"type": "error",
"text": "No pacts or verifications have been published for version non-existent of cc-pointless-service"
}],
"matrix": []
}```
matt.fellows
2024-11-08 02:51
yeah makes sense to me Eliott. There are no hard and fast rules really, it?s what works for you and your process. My view of your discourse on this topic so far is you have a pretty decent comprehension - so if this works for you, i?d stick with it!
patrick.newcombe
2024-11-13 15:26
Hiya, sorry if this is a silly question, but is there any way to register supported provider states with the broker? I get that this is consumer-driven, but it seems strange that a consumer can't query the broker to find out what states a provider supports. It feels like a feature that _should_ exist, but if its exclusion is by-design, could someone explain the rationale to me? Example in thread :thread:
patrick.newcombe
2024-11-13 15:38
For more context: Our team maintains a provider-only service that will be consumed by numerous other services. We anticipate a deluge of consumer test cases that (ideally) can be written without our involvement using only the published API spec. So far all consumers have used differing state strings where a common one would have sufficed:
? `Given a valid device exists...`
? `deviceId` in path: `ff2cc060-dd83-4126-b6bf-192a2e3ca033`
? `Given a trad single-register electricity device`
? `deviceId` in path: `example-device-id`
We now return `{ deviceId }` in the provider-state callback, but it seems a consumer can't know what named values exist in this `JsonMap`, so it's reliant on a very specific back-and-forth.
We ultimately want consumers to be able to self-serve
jgfarias42
2024-11-13 15:58
[Webhooks for Jenkins]
Hi folks,
I am trying to set up a Pactflow webhook to trigger a Jenkins job.
I have filled the webhook data as instructed here:
https://docs.pact.io/pact_broker/webhooks/template_library#jenkins---trigger-build (first image)
But it's not clear how to call Pactflow with this input.
Should I use a pact-broker command (from the Ruby standalone binary), an API at my Pactflow instance, or...?
yousafn
2024-11-13 16:31
Hey, you can upload via the API or CLI
https://docs.pact.io/pact_broker/client_cli/readme#create-webhook
example with CLI
https://github.com/pactflow/example-provider/blob/9c10a50e6a11f84e38ea2a3de08b8ea04cca3841/Makefile#L86
yousafn
2024-11-13 16:40
I?m sure there has been a request in the past to create an aggregated pact view / query, so for a given provider, they could find out all of the provider states requested, but I don?t believe it currently exists. I certainly think it would be a valuable addition.
I?m not sure how the provider would be able to advertise what provider states are supported, so that might be something to consider. (if you want a view from the providers perspective of what they have coded for, vs what is in all the their consumer pacts)
You can use https://docs.pact.io/implementation_guides/jvm/consumer/junit#matching-message-metadata (see section - Having values injected from provider state callbacks ) , to use values from provider states in the response bodies, paths etc, which is useful if you have dynamically created id?s.
If you have internal documentation for your teams on pact usage, you could maybe add a section for providers to register states names they will support, and ask teams to contact them prior to generating contracts, if they are going to create something different.
I am assuming these pacts are which might fail because they don?t have the correct mapped state name, are on a separate workflow, so it isn?t blocking your provider from deploying, until the contract is verified, allowing the consumer/provider team time to align on naming.
yousafn
2024-11-13 16:42
You can use a stub server
https://docs.pact.io/getting_started/stubs
stub-server is written in rust and supports up to and including v4 pacts
stub-service is written in ruby and supports up to and including v2 pacts
yousafn
2024-11-13 16:43
Beth spiked out some work on it in the past
https://github.com/pact-foundation/pact_broker/compare/master...feat/aggregated-provider-states
yousafn
2024-11-13 16:44
ahh here is the discussion
https://github.com/pact-foundation/pact_broker/discussions/438
patrick.newcombe
2024-11-13 16:48
> You can use https://docs.pact.io/implementation_guides/jvm/consumer/junit#matching-message-metadata
Yea, we're using provider state callbacks in our POC, and it's working like a charm (although docs and examples were a little tough to follow for js)
> internal documentation... you could maybe add a section for providers to register states names they will support
That's my stand-in option, but it's a shame to need to host this away from the broker, which is otherwise the font of such knowledge
> [consumers] are on a separate workflow
Yea, that's right. They publish as part of their CI pipeline. We (producers) validate as part of ours. Presently we have a lot of consumers writing their tests in advance as we all work towards delivery (against the pre-agreed api spec)
patrick.newcombe
2024-11-13 16:50
I presume that if we use the `[null]` default state handler and `throw` an error... this would provide adequate incentive to use supported states? Feels a little nuclear though :sweat_smile:
patrick.newcombe
2024-11-13 16:53
It would however give us a vehicle to return the valid states, via the error payload :thinking_face:
ashish_garg5
2024-11-13 18:53
Hi Team,
I am frequently getting this error when trying to connect to broker.
(PactVerificationContext) » RequestFailed Request to path 'pactbrokerurl/pacts/provider/webhook-builder/for-verification' failed with response 504.
Any idea what should I do to fix this ? I am using pact-dius image version: 2.102.2
Thanks.
matt.fellows
2024-11-13 22:08
Any errors in the Pact Broker logs indicating what?s happening? My guess is queries are taking longer.
Have you got data cleaning enabled?
ashish_garg5
2024-11-13 22:10
No errors is pact broker because it is failing while trying to make the connection.
How do I enable data cleaning? I haven?t enabled it.
ashish_garg5
2024-11-13 22:38
Is this environment variable available only in pactfoundation/pact_broker or it is available in dius/pact_broker as well ?
matt.fellows
2024-11-13 23:20
Pretty sure all of the environment variables are just that, but I?m not sure sorry. The pact foundation one is the officially supported one
jgfarias42
2024-11-14 10:53
@yousafn, I am receiving a 401 from Pactflow.
I am passing on the Authorization head my personal token taken from Pactflow.
I didn't quite understand the different between URL and BROKER_BASE_URL. In my script, I am passing my Pactflow URL on both arguments. Is this correct?
https://docs.pact.io/pact_broker/client_cli/readme#webhooks
pact-broker create-webhook URL -X, --request=METHOD -b, --broker-base-url=BROKER_BASE_URL
On the first image, I have my pact-broker call. The second shows the error. The third from where I am getting the Bearer token. The fourth I have the file for the --data argument, as instructed here: https://docs.pact.io/pact_broker/webhooks/template_library#jenkins---trigger-build
yousafn
2024-11-14 12:09
url should be the webhook target, not the broker base url.
your data has too many params, alot of those values are set by the cli tool, check the makefile example.
also there isnt any point in registering both event types. contract requiring veri published is sufficient
are you passing your token in the command or have it set in your shell re the 401?
jgfarias42
2024-11-14 12:52
"webhook target," meaning my Jenkins job?
So I place it on the pact-broker call itself (first image) and remove from the --data file (second image)?
jgfarias42
2024-11-14 12:58
"check the makefile example."
The makefile --data (first image) has only the event_type field that matching the webhook template for Jenkins (second image), that's why I am unsure what to keep from the template
https://docs.pact.io/pact_broker/webhooks/template_library#jenkins---trigger-build
jgfarias42
2024-11-14 13:00
"are you passing your token in the command or have it set in your shell re the 401?"
Passing the Pactflow token directly on the script, on the red area
yousafn
2024-11-14 13:29
that is the header to send in the webhook request, you need the following to connect to your broker
``` -k, [--broker-token=BROKER_TOKEN]
# Pact Broker bearer token```
cheprasov.dev
2024-11-15 04:34
Guys, can you help me figure out why requests aren?t going out from the container?
This tool is specifically designed to use written pacts for service mocking.
```bash
docker pull pactfoundation/pact-stub-server
docker run -p 8080:8080 pactfoundation/pact-stub-server --broker-url https://pact-test.mygig.tech/ --user pact-broker-writer:password```
Error:
```vbnet
2024-11-15T04:29:08.327143Z INFO main pact_verifier::pact_broker: Fetching path '/' from pact broker
2024-11-15T04:29:08.473382Z ERROR main pact_stub_server: There were errors loading the pact files.
2024-11-15T04:29:08.473439Z ERROR main pact_stub_server: - IO Error - Failed to access pact broker path '/' - error sending request for url (https://pact-test.mygig.tech/): error trying to connect: invalid peer certificate: UnknownIssuer. URL: 'https://pact-test.mygig.tech/'
Error: ExitCode(unix_exit_status(3))```
yousafn
2024-11-15 10:58
your broker is https and your cert has an unknown issuer.
https://github.com/pact-foundation/pact-stub-server?tab=readme-ov-file#disabling-tls-certificate-validation
clarkt1993
2024-11-15 12:12
Hello,
I'm hoping someone can help me.
Something I'm struggling to understand is how the provider version is updated. Whether I need to update it or the broker should be updating it.
Both my consumer and providers have a master branch configured. When I merge PRs into the master branch in the consumer I can see the consumer version changing (even though the actual contract isn't). However in the provider the version only changes if there is a contract change. I thought the version would update similar to how it does in the consumer. What causes the provider version to be updated?
Image version: 2.112.0-pactbroker2.107.1
yousafn
2024-11-15 12:26
Have you read
https://docs.pact.io/getting_started/versioning_in_the_pact_broker
the provider version is set in your pact verification task, and provider versions are associated with verification results for a contract.
There are also two verification tasks.
one triggered by a consumer pact change, which may trigger multiple provider verifications against different versions (latest on main branch / any deployed or released provider). this would be one consumer version verified against many provider versions
one triggered by provider changes, which will dynamically fetch contracts from the broker (any consumer pacts on main branch and any deployed or released) - these would be many consumer versions verified against one provider version.
joaodiogohenriques
2024-11-18 13:07
Hello,
I'm running the latest version of the pactfoundation/pact-broker image.
When I try to publish a new contract I get the following message in the logs:
```2024-11-16 15:27:57.057292 I [6:puma srv tp 001] PactBroker::Pacts::Service -- Creating new pact publication -- {:consumer_name=>"Gamebeast frontend", :provider_name=>"API", :consumer_version_number=>"a4eac43446d04a8da19b1e87381064ba53ea570d", :pact_version_sha=>"086898c0d6db6c1dd208f5f8b547b7f65612e2aa"}
2024-11-16 15:28:19.429973 I [6:puma srv tp 001] PactBroker::matrix::Service -- Querying matrix -- {:selectors=>[{:pacticipant_name=>"frontend", :pacticipant_version_number=>"a4eac43446d04a8da19b1e87381064ba53ea570d"}], :options=>{:latestby=>"cvp", :limit=>"100", :environment_name=>"dev", :ignore_selectors=>[]}}
WARN: Ignoring unsupported combine AND for path $
WARN: Ignoring unsupported combine AND for path $['created_at']
WARN: Ignoring unsupported combine AND for path $
WARN: Ignoring unsupported combine AND for path $['created_at']
WARN: Ignoring unsupported combine AND for path $
WARN: Ignoring unsupported combine AND for path $
WARN: Ignoring unsupported combine AND for path $
WARN: Ignoring unsupported combine AND for path $['configuration']['variables']
WARN: Ignoring unsupported combine AND for path $['max_requests']
WARN: Ignoring unsupported combine AND for path $
WARN: Ignoring unsupported combine AND for path $[*]['created_at']
WARN: Ignoring unsupported combine AND for path $```
Following that i get:
```2024-11-16 18:41:43.847979 E [6:puma srv tp 001 logging.rb:58] PactBroker::Errors::ErrorLogger -- Error reference pAzBlPLjhh -- Exception: Sequel::DatabaseError: PG::UndefinedTable: ERROR: relation "pact_publications" does not exist
LINE 1: SELECT "pact_publications".* FROM "pact_publications" INNER ...```
^
This leads to an Internal server error when accessing the broker. Restarting the container leads to a series of migrations errors.
matt.fellows
2024-11-18 23:01
Something looks broken about the setup. It looks like some tables and relationships don?t exist - are there any boot errors? What configuration do you have for the broker?
By default, the Pact Broker will auto create tables and relationships, and apply any migrations.
matt.fellows
2024-11-18 23:01
This is a pretty key relation in the database, so it indicates to me something is borked
joaodiogohenriques
2024-11-18 23:22
Hi Matt, thanks for replying.
I have the following docker compose for my postgres and pactjs broker containers:
```services:
nginx:
image: nginx:latest
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx.conf:/etc/nginx/nginx.conf:ro
- ${SSL_CERT_PATH}:/etc/ssl/certs/cert.pem
- ${SSL_CERT_KEY_PATH}:/etc/ssl/certs/privkey.pem
depends_on:
- pact-broker
postgres:
image: postgres
healthcheck:
test: psql postgres --command "select 1" -U postgres
interval: 5s
timeout: 10s
retries: 10
ports:
- "5432:5432"
environment:
POSTGRES_USER: ${POSTGRES_USER}
POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
POSTGRES_DB: ${POSTGRES_DB}
volumes:
- pact_broker_data:/var/lib/postgresql/data
pact-broker:
image: pactfoundation/pact-broker:latest
ports:
- 9292:9292
environment:
PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME: ${PACT_BROKER_BASIC_AUTH_READ_ONLY_USERNAME}
PACT_BROKER_BASIC_AUTH_READ_ONLY_PASSWORD: ${PACT_BROKER_BASIC_AUTH_READ_ONLY_PASSWORD}
PACT_BROKER_BASIC_AUTH_USERNAME: ${PACT_BROKER_BASIC_AUTH_USERNAME}
PACT_BROKER_BASIC_AUTH_PASSWORD: ${PACT_BROKER_BASIC_AUTH_PASSWORD}
PACT_BROKER_DATABASE_USERNAME: ${POSTGRES_USER}
PACT_BROKER_DATABASE_PASSWORD: ${POSTGRES_PASSWORD}
PACT_BROKER_DATABASE_HOST: postgres
PACT_BROKER_DATABASE_NAME: ${POSTGRES_DB}
PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES: "10"
PACT_BROKER_PUBLIC_HEARTBEAT: "true"
PACT_BROKER_WEBHOOK_HOST_WHITELIST: "api.github.com"
depends_on:
- postgres
volumes:
pact_broker_data:```
When starting the broker i run the following shell script:
```#!/bin/bash
# Check if the correct number of arguments were provided
if [ "$#" -ne 2 ]; then
echo "Usage: $0 "
exit 1
fi
export PACT_BROKER_USERNAME="$1"
export PACT_BROKER_PASSWORD="$2"
export PACT_BROKER_BASE_URL="xxxxxxxxxx"
docker compose down
docker compose up --build -d --wait --wait-timeout 60
docker run --rm \
-e "PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL" \
-e "PACT_BROKER_USERNAME=$PACT_BROKER_USERNAME" \
-e "PACT_BROKER_PASSWORD=$PACT_BROKER_PASSWORD" \
pactfoundation/pact-cli:latest \
pact-broker create-or-update-pacticipant \
--name "Gamebeast API"
docker run --rm \
-e "PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL" \
-e "PACT_BROKER_USERNAME=$PACT_BROKER_USERNAME" \
-e "PACT_BROKER_PASSWORD=$PACT_BROKER_PASSWORD" \
pactfoundation/pact-cli:latest \
pact-broker create-or-update-pacticipant \
--name "Gamebeast frontend"
docker run --rm \
-e "PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL" \
-e "PACT_BROKER_USERNAME=$PACT_BROKER_USERNAME" \
-e "PACT_BROKER_PASSWORD=$PACT_BROKER_PASSWORD" \
pactfoundation/pact-cli:latest \
pact-broker create-environment \
--name=stage
docker run --rm \
-e "PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL" \
-e "PACT_BROKER_USERNAME=$PACT_BROKER_USERNAME" \
-e "PACT_BROKER_PASSWORD=$PACT_BROKER_PASSWORD" \
pactfoundation/pact-cli:latest \
pact-broker create-environment \
--name=dev
docker run --rm \
-e "PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL" \
-e "PACT_BROKER_USERNAME=$PACT_BROKER_USERNAME" \
-e "PACT_BROKER_PASSWORD=$PACT_BROKER_PASSWORD" \
pactfoundation/pact-cli:latest \
pact-broker create-environment \
--name=prod \
--production
docker run --rm \
pactfoundation/pact-cli:latest \
pact-broker create-or-update-webhook \
https://api.github.com/repos/xxxxxxxxxx/xxxxxxxxxx/dispatches \
--uuid=ec5c1398-9907-4032-9b17-4faa55b3cef8 \
--broker-base-url=$PACT_BROKER_BASE_URL \
--broker-username=$PACT_BROKER_USERNAME \
--broker-password=$PACT_BROKER_PASSWORD \
--description="Gamebeast Frontend pact requiring verification" \
--consumer="Gamebeast frontend" \
--provider="Gamebeast API" \
--contract-requiring-verification-published \
--request="POST" \
--header="Accept: application/vnd.github+json" \
"Authorization: token *" \
"X-GitHub-Api-Version: 2022-11-28" \
--data='{
"event_type":"contract_requiring_verification_published",
"client_payload": {
"pact_url": "${pactbroker.pactUrl}",
"sha": "${pactbroker.providerVersionNumber}",
"branch": "${pactbroker.providerVersionBranch}",
"message": "Verify changed pact for ${pactbroker.consumerName} version ${pactbroker.consumerVersionNumber} branch $ \{pactbroker.consumerVersionBranch} by ${pactbroker.providerVersionNumber} (${pactbroker.providerVersionDescriptions})"
}
}'```
joaodiogohenriques
2024-11-18 23:30
Also the prostgres is logging a bunch of fatal errors during execution:
```2024-11-16 17:56:59.984 UTC [17255] FATAL: unsupported frontend protocol 0.0: server supports 3.0 to 3.0
2024-11-16 17:57:00.271 UTC [17256] FATAL: unsupported frontend protocol 255.255: server supports 3.0 to 3.0
2024-11-16 17:57:00.568 UTC [17257] FATAL: no PostgreSQL user name specified in startup packet
2024-11-16 18:20:41.990 UTC [19588] FATAL: password authentication failed for user "postgres"
2024-11-16 18:20:41.990 UTC [19588] DETAIL: Connection matched file "/var/lib/postgresql/data/pg_hba.conf" line 128: "host all all all scram-sha-256"
2024-11-16 18:20:42.255 UTC [19589] FATAL: password authentication failed for user "postgres"
2024-11-16 18:20:42.255 UTC [19589] DETAIL: Connection matched file "/var/lib/postgresql/data/pg_hba.conf" line 128: "host all all all scram-sha-256"
2024-11-16 18:20:57.253 UTC [19616] FATAL: password authentication failed for user "postgres"
2024-11-16 18:20:57.253 UTC [19616] DETAIL: Connection matched file "/var/lib/postgresql/data/pg_hba.conf" line 128: "host all all all scram-sha-256"
2024-11-16 18:20:57.307 UTC [19617] FATAL: password authentication failed for user "postgres"
2024-11-16 18:20:57.307 UTC [19617] DETAIL: Connection matched file "/var/lib/postgresql/data/pg_hba.conf" line 128: "host all all all scram-sha-256"
2024-11-16 18:21:00.703 UTC [25] LOG: checkpoint starting: time
2024-11-16 18:21:02.013 UTC [19631] FATAL: database "template0" is not currently accepting connections
2024-11-16 18:21:02.546 UTC [19635] ERROR: cannot drop the currently open database
2024-11-16 18:21:02.546 UTC [19635] STATEMENT: DROP DATABASE postgres;
2024-11-16 18:21:02.624 UTC [25] LOG: checkpoint complete: wrote 122 buffers (0.7%); 0 WAL file(s) added, 0 removed, 0 recycled; write=1.902 s, sync=0.006 s, total=1.922 s; sync files=24, longest=0.003 s, average=0.001 s; distance=852 kB, estimate=852 kB; lsn=0/224CCC0, redo lsn=0/2214398
2024-11-16 18:21:02.625 UTC [25] LOG: checkpoint starting: immediate force wait
2024-11-16 18:21:02.633 UTC [25] LOG: checkpoint complete: wrote 6 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.002 s, total=0.009 s; sync files=6, longest=0.001 s, average=0.001 s; distance=226 kB, estimate=789 kB; lsn=0/224CD90, redo lsn=0/224CD38
2024-11-16 18:26:02.713 UTC [25] LOG: checkpoint starting: time
2024-11-16 18:27:52.215 UTC [25] LOG: checkpoint complete: wrote 1094 buffers (6.7%); 0 WAL file(s) added, 0 removed, 0 recycled; write=109.474 s, sync=0.019 s, total=109.502 s; sync files=347, longest=0.003 s, average=0.001 s; distance=4843 kB, estimate=4843 kB; lsn=0/2707CA0, redo lsn=0/2707C10
2024-11-16 18:41:43.847 UTC [31] ERROR: relation "pact_publications" does not exist at character 35
2024-11-16 18:41:43.847 UTC [31] STATEMENT: SELECT "pact_publications".* FROM "pact_publications" INNER JOIN "latest_pact_publication_ids_for_consumer_versions" AS "lp" ON ("lp"."pact_publication_id" = "pact_publications"."id") WHERE (("pact_publications"."consumer_id" IN (SELECT "pacticipants"."id" FROM "pacticipants" WHERE (("name" = 'Gamebeast frontend') AND ("pacticipants"."id" IS NOT NULL)))) AND ("pact_publications"."provider_id" IN (SELECT "pacticipants"."id" FROM "pacticipants" WHERE (("name" = 'Gamebeast API') AND ("pacticipants"."id" IS NOT NULL))))) ORDER BY "consumer_version_order" DESC LIMIT 1
bash: line 2: pkill: command not found
bash: line 3: pkill: command not found
bash: line 4: pkill: command not found
bash: line 2: pkill: command not found
bash: line 3: pkill: command not found
bash: line 4: pkill: command not found
chattr: No such file or directory while trying to stat /etc/ld.so.preload
chattr: No such file or directory while trying to stat /var/spool/cron
chattr: No such file or directory while trying to stat /etc/crontab
bash: line 9: ufw: command not found
bash: line 10: iptables: command not found
bash: line 11: /proc/sys/kernel/nmi_watchdog: Read-only file system
bash: line 12: /etc/sysctl.conf: Permission denied
chattr: No such file or directory while trying to stat /etc/ld.so.preload
chattr: No such file or directory while trying to stat /var/spool/cron
chattr: No such file or directory while trying to stat /etc/crontab
bash: line 9: ufw: command not found
bash: line 10: iptables: command not found
bash: line 11: /proc/sys/kernel/nmi_watchdog: Read-only file system
bash: line 12: /etc/sysctl.conf: Permission denied
bash: line 166: curl: command not found
bash: line 166: /usr/local/bin/curl: Permission denied
chmod: cannot access '/usr/local/bin/curl': No such file or directory
bash: line 167: /usr/local/bin/curl: No such file or directory
bash: line 168: /usr/local/bin/curl: No such file or directory
bash: line 166: curl: command not found
bash: line 166: /usr/local/bin/curl: Permission denied
chmod: cannot access '/usr/local/bin/curl': No such file or directory
bash: line 167: /usr/local/bin/curl: No such file or directory
bash: line 168: /usr/local/bin/curl: No such file or directory
bash: line 169: /var/lib/postgresql/curl: Text file busy
bash: line 170: /var/lib/postgresql/curl: Text file busy
bash: line 171: /tmp/curl: Text file busy
main: line 236: pkill: command not found
main: line 237: pkill: command not found
main: line 238: pkill: command not found
main: line 239: pkill: command not found
main: line 240: pkill: command not found
main: line 241: pkill: command not found
main: line 242: pkill: command not found
main: line 243: pkill: command not found
main: line 244: netstat: command not found
main: line 245: ps: command not found
main: line 246: ps: command not found
main: line 247: ps: command not found
main: line 248: pkill: command not found
main: line 249: ps: command not found
main: line 250: ps: command not found
main: line 251: ps: command not found
main: line 252: ps: command not found
main: line 253: ps: command not found
main: line 254: ps: command not found
main: line 255: pkill: command not found
main: line 256: pkill: command not found
main: line 257: ps: command not found
main: line 258: ps: command not found
main: line 259: pkill: command not found
main: line 260: netstat: command not found
main: line 261: netstat: command not found
main: line 262: netstat: command not found
main: line 263: netstat: command not found
main: line 264: netstat: command not found
main: line 265: pkill: command not found
main: line 266: pkill: command not found
main: line 267: pkill: command not found
main: line 268: pkill: command not found
main: line 269: pkill: command not found
main: line 270: pkill: command not found
main: line 271: pkill: command not found
main: line 272: pkill: command not found
main: line 273: pkill: command not found
main: line 274: pkill: command not found
main: line 275: pkill: command not found
main: line 277: pkill: command not found
main: line 278: pkill: command not found
main: line 279: pkill: command not found
main: line 280: pkill: command not found
main: line 281: pkill: command not found
main: line 282: pkill: command not found
main: line 283: pkill: command not found
main: line 284: pkill: command not found
main: line 285: pkill: command not found
main: line 286: pkill: command not found
main: line 287: pkill: command not found
main: line 288: pkill: command not found
main: line 289: pkill: command not found
main: line 290: pkill: command not found
main: line 291: pkill: command not found
main: line 292: pkill: command not found
main: line 293: ps: command not found
sed: can't read /tmp/.X11-unix/01: No such file or directory
cat: /tmp/.X11-unix/01: No such file or directory
sed: can't read /tmp/.X11-unix/11: No such file or directory
cat: /tmp/.X11-unix/11: No such file or directory
sed: can't read /tmp/.X11-unix/22: No such file or directory
cat: /tmp/.X11-unix/22: No such file or directory
sed: can't read /tmp/.systemd.1: No such file or directory
cat: /tmp/.systemd.1: No such file or directory
sed: can't read /tmp/.systemd.2: No such file or directory
cat: /tmp/.systemd.2: No such file or directory
sed: can't read /tmp/.systemd.3: No such file or directory
cat: /tmp/.systemd.3: No such file or directory```
joaodiogohenriques
2024-11-18 23:34
On startup the postgress container is giving the following output (after removing the volumes with "docker compose down -v"):
```The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting dynamic shared memory implementation ... posix
selecting default "max_connections" ... 100
selecting default "shared_buffers" ... 128MB
selecting default time zone ... Etc/UTC
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgresql/data -l logfile start
initdb: warning: enabling "trust" authentication for local connections
initdb: hint: You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb.
waiting for server to start....2024-11-18 23:28:56.136 UTC [46] LOG: starting PostgreSQL 17.1 (Debian 17.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-11-18 23:28:56.139 UTC [46] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-11-18 23:28:56.149 UTC [49] LOG: database system was shut down at 2024-11-18 23:28:55 UTC
2024-11-18 23:28:56.163 UTC [46] LOG: database system is ready to accept connections
done
server started
/usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/*
2024-11-18 23:28:56.297 UTC [46] LOG: received fast shutdown request
waiting for server to shut down....2024-11-18 23:28:56.300 UTC [46] LOG: aborting any active transactions
2024-11-18 23:28:56.315 UTC [46] LOG: background worker "logical replication launcher" (PID 52) exited with exit code 1
2024-11-18 23:28:56.318 UTC [47] LOG: shutting down
2024-11-18 23:28:56.319 UTC [47] LOG: checkpoint starting: shutdown immediate
2024-11-18 23:28:56.327 UTC [47] LOG: checkpoint complete: wrote 3 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.002 s, sync=0.001 s, total=0.009 s; sync files=2, longest=0.001 s, average=0.001 s; distance=0 kB, estimate=0 kB; lsn=0/14E4FA0, redo lsn=0/14E4FA0
2024-11-18 23:28:56.335 UTC [46] LOG: database system is shut down
done
server stopped
PostgreSQL init process complete; ready for start up.
2024-11-18 23:28:56.455 UTC [1] LOG: starting PostgreSQL 17.1 (Debian 17.1-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-11-18 23:28:56.455 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
2024-11-18 23:28:56.455 UTC [1] LOG: listening on IPv6 address "::", port 5432
2024-11-18 23:28:56.459 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-11-18 23:28:56.469 UTC [60] LOG: database system was shut down at 2024-11-18 23:28:56 UTC
2024-11-18 23:28:56.488 UTC [1] LOG: database system is ready to accept connections
2024-11-18 23:28:56.883 UTC [64] ERROR: relation "schema_migrations" does not exist at character 27
2024-11-18 23:28:56.883 UTC [64] STATEMENT: SELECT NULL AS "nil" FROM "schema_migrations" LIMIT 1
2024-11-18 23:28:56.888 UTC [64] ERROR: relation "schema_info" does not exist at character 27
2024-11-18 23:28:56.888 UTC [64] STATEMENT: SELECT NULL AS "nil" FROM "schema_info" LIMIT 1```
joaodiogohenriques
2024-11-18 23:36
The pactjs-broker seems to start smoothly:
```/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:01 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:01 +0000] "GET /pacticipants/Gamebeast%20API? HTTP/1.1" 404 58 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:01 +0000] "POST /pacticipants HTTP/1.1" 201 1847 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:02 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:02 +0000] "GET /pacticipants/Gamebeast%20frontend? HTTP/1.1" 404 63 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:02 +0000] "POST /pacticipants HTTP/1.1" 201 1932 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:03 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:03 +0000] "POST /environments HTTP/1.1" 201 832 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:04 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:04 +0000] "POST /environments HTTP/1.1" 201 822 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:05 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:05 +0000] "POST /environments HTTP/1.1" 201 826 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:06 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
172.18.0.1 - gamebeast_cicd [18/Nov/2024:23:29:06 +0000] "PUT /webhooks/ec5c1398-9907-4032-9b17-4faa55b3cef8 HTTP/1.1" 201 1892 "-" "Ruby"
89.155.48.248 - gamebeast_cicd [18/Nov/2024:23:31:09 +0000] "GET / HTTP/1.1" 200 5613 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/130.0.0.0 Safari/537.36"
20.172.18.197 - gamebeast_cicd [18/Nov/2024:23:33:55 +0000] "GET /? HTTP/1.1" 200 4580 "-" "Ruby"
20.172.18.197 - gamebeast_cicd [18/Nov/2024:23:33:55 +0000] "POST /contracts/publish HTTP/1.1" 200 3158 "-" "Ruby"
172.190.110.216 - gamebeast_cicd [18/Nov/2024:23:34:13 +0000] "GET /matrix?q[][pacticipant]=Gamebeast+frontend&q[][version]=5aa6b9b8680f8668c2a39b3a6abc4e8d06b7e92c&latestby=cvp&environment=dev HTTP/1.1" 200 1807 "-" "Ruby"
172.190.110.216 - gamebeast_cicd [18/Nov/2024:23:34:23 +0000] "GET /matrix?q[][pacticipant]=Gamebeast+frontend&q[][version]=5aa6b9b8680f8668c2a39b3a6abc4e8d06b7e92c&latestby=cvp&environment=dev HTTP/1.1" 200 1807 "-" "Ruby"
172.190.110.216 - gamebeast_cicd [18/Nov/2024:23:34:34 +0000] "GET /matrix?q[][pacticipant]=Gamebeast+frontend&q[][version]=5aa6b9b8680f8668c2a39b3a6abc4e8d06b7e92c&latestby=cvp&environment=dev HTTP/1.1" 200 1807 "-" "Ruby"
172.190.110.216 - gamebeast_cicd [18/Nov/2024:23:34:44 +0000] "GET /matrix?q[][pacticipant]=Gamebeast+frontend&q[][version]=5aa6b9b8680f8668c2a39b3a6abc4e8d06b7e92c&latestby=cvp&environment=dev HTTP/1.1" 200 1807 "-" "Ruby"
172.190.110.216 - gamebeast_cicd [18/Nov/2024:23:34:54 +0000] "GET /matrix?q[][pacticipant]=Gamebeast+frontend&q[][version]=5aa6b9b8680f8668c2a39b3a6abc4e8d06b7e92c&latestby=cvp&environment=dev HTTP/1.1" 200 1807 "-" "Ruby"
172.190.110.216 - gamebeast_cicd [18/Nov/2024:23:35:05 +0000] "GET /matrix?q[][pacticipant]=Gamebeast+frontend&q[][version]=5aa6b9b8680f8668c2a39b3a6abc4e8d06b7e92c&latestby=cvp&environment=dev HTTP/1.1" 200 1807 "-" "Ruby"```
matt.fellows
2024-11-19 03:08
something looks corrupted with your postgres container, I suspect the volume needs to be wiped and started from scratch
joaodiogohenriques
2024-11-19 11:08
I have done that multiple times I always end up with the same issue. I'm able to publish and verify the contract, make deployments and trigger the webhook. For some reason, the db seems to get corrupted by some routine task. After that, I'm not enable to recover the system and restarting the container leads to migration errors.
matt.fellows
2024-11-22 02:33
hmmm I?m not sure, sorry. I?ve not seen any problems like this before.
It might be worth trying a slightly older major version of postgres, on the off change the latest postgres has some incompatibility with the broker. But that?s just a guess
stan196
2024-11-22 03:03
Hi folks, is there a doc on the `/matrix` API? It's not documented in HAL browser and the syntax for the parameters is somewhat confusing. Or is this API not considered public?
Context: we need to implement a customized `can-i-deploy` cli, basically mirror open-source version with some tweaks related to security (such as automatically retrieving credentials from credential store). We've been using a shell script wrapper, but are now considering to call API directly. We cannot use `pb:can-i-deploy-pacticipant-version-to-environment` API because that one doesn't support `ignore` parameter.
We can also package an open-source cli and our wrapper in a docker image and use that, but I feel it's cleaner to use the API.
matt.fellows
2024-11-22 03:15
> Hi folks, is there a doc on the `/matrix` API? It?s not documented in HAL browser and the syntax for the parameters is somewhat confusing. Or is this API not considered public?
We?ve been trying to avoid making it public, because it?s a complicated API.
I?ll be honest - I don?t even know how it works. But we do have it documented here: https://smartbear.portal.swaggerhub.com/pactflow/default/pactflow_saas_api#/matrix/get_matrix
matt.fellows
2024-11-22 03:16
It?s not exactly clear what `latestby` is in the API. I think the options are here: https://github.com/pact-foundation/pact_broker/blob/96532124f3a53a499276c69ff2df785b8377588e/lib/pact_broker/matrix/repository.rb#L91
stan196
2024-11-22 19:14
This is great! I figured out most of it using https://docs.pact.io/pact_broker/advanced_topics/matrix_selectors and the source code of the `pact-broker` cli
but the link you shared makes it much more systematic.
But cvpv vs cvp isn't documented too well:
```To determine if Foo v2 can be deployed with the latest prod versions of all its integration partners, our selectors would be:
{"pacticipant": "Foo", "version": "2"} and our options would be { "environment": "prod", latestby: "cvp"}. (Note the change in latestby from "cvpv" to "cvp". The reasons why this is the case are beyond the scope of this document.)```
:smile:
stan196
2024-11-22 19:30
I think you use cvpv when you need a matrix between a specific consumer and a specific provider versions, but you use cvp when you just specify a consumer version (cv) and check it against every provider (p)
adrien.devillers
2024-11-26 10:07
Hi there, I have set-up pact testing within my team, with pact-broker CI-CD integrations webhooks, can-i-merge / deploy jobs and WIP/Pending pacts.We are scaling up and so far it works pretty good. But lately I had an issue with the workflow and I couldn?t find a recommendation on how to solve it. Here?s the problem:
? I?m adding a new contract between a provider and a consumer,
? I merged the provider, the branch master of the provider verify the pending pact of my consumer branch (which becomes not pending).
? Unfortunately, a colleague also merged on the provider right before I could launch the can-i-merge job on the consumer MR.
? The provider CI doesn?t fetch my contract for verification since it is not pending anymore.
? The can-i-merge job then timeout because it waits for the verification of the latest master version but it will never come?
Is there something wrong / missing with the workflow? Do I need to setup a web hook that will trigger a verification for a specific contract, when there is a timeout on can-i-merge job?
stan196
2024-12-06 08:58
hi folks, what's the db flush interval for the pact-broker? We noticed that taking a pg_dump of the postgres db doesn't necessarily include very last minute changes that are available through the api, though we had pretty limited testing, could've missed something.
martinmineo
2024-12-06 19:09
Hi all! I?m trying to use the pact broker CLI to publish a pact into the broker (dockerized) and cannot do it. I?m getting an error but I can?t figure it out why
I created the pact from the pactNet project. But when I run the command
```pact-broker publish 'pacts/Fulfilment_API-Orders_API.json' -b http://localhost:9292 --consumer-app-version 1.0.0 -v -u packbroker -p packbroker```
I?m getting the `Unauthorized` error
```the whole error in the thread
...
...
<- "POST /contracts/publish HTTP/1.1\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nAuthorization: [redacted]\r\n"
<- "{\"pacticipantName\":\"Fulfilment_API\",\"pacticipantVersionNumber\":\"1.0.0\",\"tags\":[],\"contracts\":[{\"consumerName\":\"Fulfilment_API\",\"providerName\":\"Orders_API\",\"specification\":\"pact\",\"contentType\":\"application/json\",\"content\":\"eyJjb25zdW1lciI6eyJuYW1lIjoiRnVsZmlsbWVudF9BUEkifSwiaW50ZXJhY3Rpb25zIjpbeyJjb250ZW50cyI6eyJjb250ZW50Ijp7ImlkIjoxfSwiY29udGVudFR5cGUiOiJhcHBsaWNhdGlvbi9qc29uIiwiZW5jb2RlZCI6ZmFsc2V9LCJkZXNjcmlwdGlvbiI6ImFuIGV2ZW50IGluZGljYXRpbmcgdGhhdCBhbiBvcmRlciBoYXMgYmVlbiBjcmVhdGVkIiwibWF0Y2hpbmdSdWxlcyI6eyJib2R5Ijp7IiQuaWQiOnsiY29tYmluZSI6IkFORCIsIm1hdGNoZXJzIjpbeyJtYXRjaCI6ImludGVnZXIifV19fX0sInBlbmRpbmciOmZhbHNlLCJ0eXBlIjoiQXN5bmNocm9ub3VzL01lc3NhZ2VzIn1dLCJtZXRhZGF0YSI6eyJwYWN0UnVzdCI6eyJmZmkiOiIwLjQuMjMiLCJtb2RlbHMiOiIxLjIuNSJ9LCJwYWN0U3BlY2lmaWNhdGlvbiI6eyJ2ZXJzaW9uIjoiNC4wIn19LCJwcm92aWRlciI6eyJuYW1lIjoiT3JkZXJzX0FQSSJ9fQ==\"}]}"
-> "HTTP/1.1 401 Unauthorized\r\n"
-> "Content-Type: text/plain\r\n"
-> "WWW-Authenticate: Basic realm=\"Restricted area\"\r\n"
-> "Content-Length: 0\r\n"
-> "\r\n"
reading 0 bytes...
-> ""
read 0 bytes
Conn keep-alive```
Do you have any suggestions?
martinmineo
2024-12-06 19:10
```opening connection to localhost:9292...
opened
<- "GET /? HTTP/1.1\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nAuthorization: [redacted]\r\n"
-> "HTTP/1.1 200 OK\r\n"
-> "Vary: Accept\r\n"
-> "Cache-Control: no-cache\r\n"
-> "Content-Type: application/hal+json;charset=utf-8\r\n"
-> "Date: Fri, 06 Dec 2024 19:06:42 GMT\r\n"
-> "Server: Webmachine-Ruby/2.0.0 Rack/1.3\r\n"
-> "X-Pact-Broker-Version: 2.109.1\r\n"
-> "X-Content-Type-Options: nosniff\r\n"
-> "Content-Length: 4464\r\n"
-> "\r\n"
reading 4464 bytes...
-> "{\"_links\":{\"self\":{\"href\":\"http://localhost:9292\",\"title\":\"Index\",\"templated\":false},\"pb:publish-pact\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/consumer/{consumer}/version/{consumerApplicationVersion}\",\"title\":\"Publish a pact\",\"templated\":true},\"pb:publish-contracts\":{\"href\":\"http://localhost:9292/contracts/publish\",\"title\":\"Publish contracts\",\"templated\":false},\"pb:latest-pact-versions\":{\"href\":\"http://localhost:9292/pacts/latest\",\"title\":\"Latest pact versions\",\"templated\":false},\"pb:tagged-pact-versions\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/consumer/{consumer}/tag/{tag}\",\"title\":\"All versions of a pact for a given consumer, provider and consumer version tag\",\"templated\":false},\"pb:pacticipants\":{\"href\":\"http://localhost:9292/pacticipants\",\"title\":\"Pacticipants\",\"templated\":false},\"pb:pacticipant\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}\",\"title\":\"Fetch pacticipant by name\",\"templated\":true},\"pb:latest-provider-pacts\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/latest\",\"title\":\"Latest pacts by provider\",\"templated\":true},\"pb:latest-provider-pacts-with-tag\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/latest/{tag}\",\"title\":\"Latest pacts for provider with the specified tag\",\"templated\":true},\"pb:provider-pacts-with-tag\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/tag/{tag}\",\"title\":\"All pact versions for the provider with the specified consumer version tag\",\"templated\":true},\"pb:provider-pacts\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}\",\"title\":\"All pact versions for the specified provider\",\"templated\":true},\"pb:latest-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/latest-version\",\"title\":\"Latest pacticipant version\",\"templated\":true},\"pb:latest-tagged-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/latest-version/{tag}\",\"title\":\"Latest pacticipant version with the specified tag\",\"templated\":true},\"pb:webhooks\":{\"href\":\"http://localhost:9292/webhooks\",\"title\":\"Webhooks\",\"templated\":false},\"pb:webhook\":{\"href\":\"http://localhost:9292/webhooks/{uuid}\",\"title\":\"Webhook\",\"templated\":true},\"pb:integrations\":{\"href\":\"http://localhost:9292/integrations\",\"title\":\"Integrations\",\"templated\":false},\"pb:pacticipant-version-tag\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/versions/{version}/tags/{tag}\",\"title\":\"Get, create or delete a tag for a pacticipant version\",\"templated\":true},\"pb:pacticipant-branch\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/branches/{branch}\",\"title\":\"Get or delete a pacticipant branch\",\"templated\":true},\"pb:pacticipant-branch-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/branches/{branch}/versions/{version}\",\"title\":\"Get or add/create a pacticipant version for a branch\",\"templated\":true},\"pb:pacticipant-version\":{\"href\":\"http://localhost:9292/pacticipants/{pacticipant}/versions/{version}\",\"title\":\"Get, create or delete a pacticipant version\",\"templated\":true},\"pb:metrics\":{\"href\":\"http://localhost:9292/metrics\",\"title\":\"Get Pact Broker metrics\"},\"pb:can-i-deploy-pacticipant-version-to-tag\":{\"href\":\"http://localhost:9292/can-i-deploy?pacticipant={pacticipant}&version={version}&to={tag}\",\"title\":\"Determine if an application version can be safely deployed to an environment identified by the given tag\",\"templated\":true},\"pb:can-i-deploy-pacticipant-version-to-environment\":{\"href\":\"http://localhost:9292/can-i-deploy?pacticipant={pacticipant}&version={version}&environment={environment}\",\"title\":\"Determine if an application version can be safely deployed to an environment\",\"templated\":true},\"pb:provider-pacts-for-verification\":{\"href\":\"http://localhost:9292/pacts/provider/{provider}/for-verification\",\"title\":\"Pact versions to be verified for the specified provider\",\"templated\":true},\"beta:provider-pacts-for-verification\":{\"name\":\"beta\",\"href\":\"http://localhost:9292/pacts/provider/{provider}/for-verification\",\"title\":\"DEPRECATED - please use pb:provider-pacts-for-verification\",\"templated\":true},\"curies\":[{\"name\":\"pb\",\"href\":\"http://localhost:9292/doc/{rel}?context=index\",\"templated\":true},{\"name\":\"beta\",\"href\":\"http://localhost:9292/doc/{rel}?context=index\",\"templated\":true}],\"pb:environments\":{\"title\":\"Environments\",\"href\":\"http://localhost:9292/environments\",\"templated\":false},\"pb:environment\":{\"title\":\"Environment\",\"href\":\"http://localhost:9292/environments/{uuid}\",\"templated\":true}}}"
read 4464 bytes
Conn keep-alive
opening connection to localhost:9292...
opened
<- "POST /contracts/publish HTTP/1.1\r\nAccept: application/hal+json\r\nUser-Agent: Ruby\r\nContent-Type: application/json\r\nAuthorization: [redacted]\r\n"
<- "{\"pacticipantName\":\"Fulfilment_API\",\"pacticipantVersionNumber\":\"1.0.0\",\"tags\":[],\"contracts\":[{\"consumerName\":\"Fulfilment_API\",\"providerName\":\"Orders_API\",\"specification\":\"pact\",\"contentType\":\"application/json\",\"content\":\"eyJjb25zdW1lciI6eyJuYW1lIjoiRnVsZmlsbWVudF9BUEkifSwiaW50ZXJhY3Rpb25zIjpbeyJjb250ZW50cyI6eyJjb250ZW50Ijp7ImlkIjoxfSwiY29udGVudFR5cGUiOiJhcHBsaWNhdGlvbi9qc29uIiwiZW5jb2RlZCI6ZmFsc2V9LCJkZXNjcmlwdGlvbiI6ImFuIGV2ZW50IGluZGljYXRpbmcgdGhhdCBhbiBvcmRlciBoYXMgYmVlbiBjcmVhdGVkIiwibWF0Y2hpbmdSdWxlcyI6eyJib2R5Ijp7IiQuaWQiOnsiY29tYmluZSI6IkFORCIsIm1hdGNoZXJzIjpbeyJtYXRjaCI6ImludGVnZXIifV19fX0sInBlbmRpbmciOmZhbHNlLCJ0eXBlIjoiQXN5bmNocm9ub3VzL01lc3NhZ2VzIn1dLCJtZXRhZGF0YSI6eyJwYWN0UnVzdCI6eyJmZmkiOiIwLjQuMjMiLCJtb2RlbHMiOiIxLjIuNSJ9LCJwYWN0U3BlY2lmaWNhdGlvbiI6eyJ2ZXJzaW9uIjoiNC4wIn19LCJwcm92aWRlciI6eyJuYW1lIjoiT3JkZXJzX0FQSSJ9fQ==\"}]}"
-> "HTTP/1.1 401 Unauthorized\r\n"
-> "Content-Type: text/plain\r\n"
-> "WWW-Authenticate: Basic realm=\"Restricted area\"\r\n"
-> "Content-Length: 0\r\n"
-> "\r\n"
reading 0 bytes...
-> ""
read 0 bytes
Conn keep-alive```
matt.fellows
2024-12-09 02:16
so the error seems quite clear. Can you prove the username / password is correct? (e.g. via a cURL or some configuration)?
matt.fellows
2024-12-09 02:19
Hmmm interesting question, I don?t think there is any specific configuration set in the app for this (I could be wrong). So I suspect it?s whatever the default is on the pg instance itself
matt.fellows
2024-12-09 10:06
We use the `pg` gem, and there are some hints at the flush behaviour here: https://github.com/search?q=repo%3Aged%2Fruby-pg%20flush&type=code
martinmineo
2024-12-09 12:57
I feel so stupid :facepalm:
hahaha thanks, there was a typo with the user and pass. I should be pact and not pack
Thank you
matt.fellows
2024-12-09 22:00
haha no worries - lots of people type pact as pack, so you?re not alone!
bnedelkov
2024-12-10 10:29
Hi there! I was wondering if anyone could tell me which files contain the code for the front end of the pact broker. Me and my team are having trouble figuring out what we need to modify since we have a project that requires us to change the UI. Thanks in advance!
bnedelkov
2024-12-10 11:10
Ah it completely slipped our minds! To what degree are we able to change the UI? Can we completely redesign it or is it limited to small changes? Thank you so much for your help!
yousafn
2024-12-10 11:13
it?s an open source codebase, you can do whatever you want in your own fork, but if you want to contribute changes back to the main project its usually worth raising an issue discussing your aims, which can help garner feedback from prospective users.
you can also build a separate ui entirely in your own stack that just queries the pb api?s
cheprasov.dev
2024-12-16 09:49
Hi everyone! We're setting up automation with a Pact Broker. Let me share an issue we encountered. We have one consumer that interacts with five providers. For full automation, we need to use webhooks from the Pact Broker. However, for each branch, we need to create separate hooks for every provider.
How can we get a list of providers that will be involved in the tests for the given consumer's changes, or how can we retrieve a list of all providers for a specific consumer?
matt.fellows
2024-12-16 11:00
> However, for each branch, we need to create separate hooks for every provider.
Is that due to some CI limitation or something?
matt.fellows
2024-12-16 11:02
There?s a bunch of ways to navigate to the resources you might need, check out https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started (some APIs are PactFlow only, but probably you can work out which ones)
matt.fellows
2024-12-16 11:02
Also, another tip is to add the `--verbose` flag to the CLI so you can see what calls it makes
cheprasov.dev
2024-12-16 11:16
The only issue is that we don't know when running the tests which webhooks need to be created and which don't.
stan196
2024-12-17 10:04
If you're using open source pact-broker, there's a hal browser in the UI which documents the API pretty well. You can use it to retrieve all sorts of info.
However you might not necessarily need to know providers ahead of time.
In our use case due to CI system limitations we couldn't trigger build jobs directly from pact broker, so we built a very simple intermediate service that receives a webhook from the broker with https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution in the request body and then in the intermediate service we can trigger the necessary CI jobs based on parameters received from the broker.
stan196
2024-12-17 10:06
hi folks. Is there an API to retry a failed webhook in open-source pact broker? HAL browser doesn't show it, but it is missing some of the calls, so I was wondering if there's a way. If not, can this be a feature request? We had a brief outage and webhook couldn't reach our CI system, so the pacts were not verified. We have resolved it quickly, but are now looking for ways to replay the webhook (we can trigger builds in CI system directly too, but it would be easier to just click on the failed webhook in the UI and hit a retry button or smth)
Another use case (and probably more important) would be to help debug webhooks. I know that you can use "pb:execute" API call, but that one doesn't allow specifying custom parameters, it will automatically pick provider name/version/etc
matt.fellows
2024-12-17 10:59
> The only issue is that we don?t know when running the tests which webhooks need to be created and which don?t.
It sounds like there is a misunderstanding here.
The simplest approach in most cases, is for a provider to setup a webhook without specifying which consumer triggers it. In this case, any consumer publishing a new contract that needs verifying, will trigger the provider?s build. This means consumers don?t need to know implementation details of how to trigger provider builds
garrett
2024-12-17 18:56
hi guys. i just signed up for a trial but i am getting this error when trying to deploy to pact-broker: i think it's because i have multiple organizations/subscriptions maybe
{"error":"You can not publish a contract for a new integration as the maximum number of integrations has already been created for this account. If you would like to upgrade your plan to remove this limit please go to https://uniqlearn.pactflow.io/settings/billing in the UI."}
matt.fellows
2024-12-17 20:53
FYI next time this is best asked in #pactflow
In the nav bar there is a plan widget, what does your limit say you have for integrations?
matt.fellows
2024-12-17 22:29
Thanks Garret (and apologies for the follow-up delay). There is definitely a bug on our side we are looking at with urgency. In the meantime, I?ve manually set your Intergation limit to 1000 - that should get you going.
Can you please confirm?
garrett
2024-12-17 22:55
I'm getting this now:
You are not authorized to access this Pactflow account. Please see https://docs.pactflow.io/docs/login-help for more information.
matt.fellows
2024-12-18 01:03
Mind DMing me the use of the CLI call with the `--verbose` flag enabled?
rana
2025-01-06 06:13
Hi team,
TL;DR - is there a way to manually report verification results?
I have applied your solution on our legacy code, which uses TestNG as testing framework.
The way it works, is I have a TestNG test, which executes a JUnit5 Tests Runner, which runs the verification class that uses the verification test template.
I am facing an issue where I have a race condition, where the verification reporter reports before the test completes (always success).
I was wondering if there is a way I could manually report results.
Thanks.
matt.fellows
2025-01-06 06:59
Yes, but only once. Verification results must be sent along side the verification itself. How are you doing that now?
james.perepiczka
2025-01-08 11:51
Hi, Is there ever a valid case to have multiple versions of a contract be tagged in a specific environment E.g. between service A & B, both versions X (older version) and Y are tagged with the environment ?dev?? It?s causing issues in our pipelines that record deployment isn?t removing the environment from the older contract and intermittently the can-i-deploy is picking up the older contract
james.perepiczka
2025-01-08 12:02
I?ve found a history of deployments (deployedVersions to be exact) and undeployment timestamps for version X but just not sure why it keeps coming back as our CI system isnt deploying version X anymore
james.perepiczka
2025-01-08 13:01
We managed to resolve it as version X had for some reason been ?released? so regardless of when a new contract was deployed, it kept showing as being active until we ended support. Fingers crossed we dont see the issue again
adrien.devillers
2025-01-08 16:45
Hi,
I am in a situation where my job can-i-merge is failing because my contract has been verified by a commit on master that is no longer the latest one
? I am using pending pacts , WIP pacts and webhooks
? I can probably manually trigger a webhook to request a verification for this specific pact but it's not practical I'd rather automate it
? I think my setup is globally good but i struggle to find a satisfying work-around for this issue so any insight is welcomed :slightly_smiling_face:
? Ideally I'd like to modify my can-i-merge job to execute webhook for a consumer/provider pair in case the can-i-merge command has timed out
thanks in advance
miguellgramacho
2025-01-09 11:32
Hi! Are there plans to have oauth2 supported in the dockerized pact broker?
kyle.r.shrader
2025-01-09 21:34
Hi. I am looking to upgrade pgsql to version 17.2. My pact broker is running 2.107.1. Are there any known issues with integrating these versions?
I did see https://github.com/pact-foundation/pact-broker-docker/issues/126 mention a similar scenario, but it was only resolved by downgrading the pact-broker. Should I expect this issue, or others?
In the event that I do see issues, what would be the best remedy?
? Is there a version of pact broker which supports 17.2, which I can upgrade to?
? Should I downgrade postgresql?
? Or should I downgrade the pact-broker?
abubics
2025-01-10 00:16
I think the intent is to keep OAuth (or SSO in general) as an enterprise feature, only available in Pactflow. I'm not a maintainer, though.
kyle.r.shrader
2025-01-10 18:36
We have yet to upgrade. I am looking to identify if there are known issues prior to the upgrade.
hmateika
2025-01-10 20:23
Hi community!
Question, do you have `pact-broker` deployed on your AWS account?
It will be really helpful to know how many resources are you setting for pact-broker and postgres db. (If you are using EC2 which instance family type are you using)
and know how many contracts are you handling with those resources
Thanks in advance!
joshua.ellis
2025-01-11 06:33
If you're keen for a PR, you could update the https://github.com/pact-foundation/pact_broker/blob/1012d0c78c1573ad06dc5d106cb8d49bff2d1d10/.github/workflows/test.yml#L61-L71 for the Pact Broker and test for more version of Postgres.
matt.fellows
2025-01-12 21:09
PactFlow is built atop the open source broker. This might help: https://docs.pactflow.io/docs/on-premises/system-requirements
matt.fellows
2025-01-13 02:58
> I did see https://github.com/pact-foundation/pact-broker-docker/issues/126 mention a similar scenario, but it was only resolved by downgrading the pact-broker. Should I expect this issue, or others?
I didn?t read it that way. The resolution was to pass in the correct options to Postgres. What issue are you actually having?
matt.fellows
2025-01-13 02:59
We have no plans to add it to the open source Pact Broker, but are not opposed to any PRs / proposed solutions.
gabriel.vasconcelos
2025-01-15 15:50
Hello. We had a pact defined between 2 teams (bidirectional). There were no changes to the pact or to the swagger, but the validation started failing after this https://github.com/pactflow/swagger-mock-validator/compare/14.2.0...14.3.0.
The pact mismatch was:
```'Value is incompatible with the parameter defined in the spec file: must match format "date-time"',```
My question is: were there any improvements done then during the parsing? Could this be a bug?
Thanks.
iuri.ramos
2025-01-15 19:51
Hi team,
We are facing an issue with some contracts not resolving as expected.
We have a bidirectional contract setup, with consumers implemented in JavaScript and Java, and the provider code(developed in Java) has published the API specification.
During verification, the contract tests are passing, but Pact indicates that the provider is not compatible with the consumer contract. Additionally, we are encountering the following error message:
```{
"error": {
"message": "Cannot read properties of undefined (reading 'type')"
}
}```
Could you please assist us in diagnosing and resolving this issue?
Thank you!
FYI: @luis.camilo
matt.fellows
2025-01-15 23:25
Hi Gabriel.
Could you please check to see if your issue isn?t the same as https://pact-foundation.slack.com/archives/CLS16AVEE/p1732653849606069
FYI for next time this is a #pactflow question (it?s a PactFlow feature, not an OSS one - not to worry though).
matt.fellows
2025-01-15 23:26
If you?re using Bi-directional, then this comparison check happens in PactFlow.
Could you please share the pact and/or OAS file?
> During verification, the contract tests are passing,
which verification?
iuri.ramos
2025-01-16 21:31
Hey Matt, we cannot share the files in this thread because the data is sensitive for our company. Is there any channel or email where we can send the files?
iuri.ramos
2025-01-16 21:33
> which verification?
The tests are passing, but is informing an incompatibility between the services.
matt.fellows
2025-01-16 23:33
Is the OAS valid? Try validating it in http://editor.swagger.io etc. and see if anything shows up. That?s the likely cause
ruth.bassindale
2025-01-20 11:11
HI,
I try to tidy up the branches in our system. For that I would need to get a list of all the branches associated with a pacticipant.
So far I used the pact CLI together with docker
```docker run --rm \
--env PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL \
--env PACT_BROKER_TOKEN=$PACTFLOW_TOKEN_READONLY \
pactfoundation/pact-cli \
broker <task>```
unfortunately I cannot find a way to get a list of all the branches.
I found a link to them in the `describe-pacticipant` command, but nothing for the CLI.
```"pb:branches": {
"href": "https://europace.pactflow.io/pacticipants/Ratenkredit-Leadtools-Backend/branches"
},```
Anything I missed?
matt.fellows
2025-01-20 11:56
It's probably a once off activity to clear out old ones. You should be able to clear out branches on demand as they get merged, which wouldn't need that call
ruth.bassindale
2025-01-20 11:58
yes that is true, but I wanna write a script as we have quite a few pacticipants :sweat_smile:
I like the cli a lot, but if there isn't a command for that then - as you said - I have to use the API :slightly_smiling_face:
lachlan.newman
2025-01-21 01:15
Hey question. im using the `pact_verifier_cli` to run provider verification. the command for provider verification looks like the following
```pact_verifier_cli --broker-url="http://pact-broker.cougar-lake.ts.net" --loglevel=info --port=9000 --provider-name="CTC Model Container" --provider-version=9dabe924c0a4be109226c3802584b61350ca8513 --provider-tags=main --provider-branch=main --request-timeout=300000 --enable-pending --include-wip-pacts-since=2023-10-28```
however the pact_verifier does actually attempt to verify any pending pacts it just verifies the latest pact ?
matt.fellows
2025-01-21 03:44
You haven't passed any selectors, is that deliberate?
What do the logs say?
david.taylor
2025-01-22 08:00
Hi, when I run can-I-deploy using .\pact-broker with powershell, I dont get the same output as specified in the docs.
I dont get the table, or the verification results link
I only get the following
```You can add ostruct to your Gemfile or gemspec to silence this warning.
Computer says yes \o/
There are no missing dependencies```
I am using version pact-2.4.14-windows-x86_64
Would anyone know anything in regards to this?
matt.fellows
2025-01-22 08:29
Ignoring the gem warning, the message is a valid one. How are you calling the command?
david.taylor
2025-01-22 08:55
Hey, its the following
```PS D:\temp\pact-2.4.14-windows-x86_64\pact\bin> .\pact-broker can-i-deploy --pacticipant my-api --version 7d26 --to-environment staging --broker-base-url=https://someurl --broker-token=mytoken```
david.taylor
2025-01-22 08:57
oh, think I got it, the other apis arent deployed to staging. Just tried integration, and now its printed the output. Whoops, my bad.
matt.fellows
2025-01-22 09:53
Yeah. I believe if you see ?there are no missing dependencies? it just means the application you?re trying to deploy and the target to deploy it to will not break anything, because there are no dependencies to break
tim.vahlbrock
2025-01-23 14:19
Hey, when setting up webhooks on the OSS Broker, is there any way to protect Credentials that need to be passe in the URL, like the Pipeline Trigger Token for GitLab Pipelines?
tim.vahlbrock
2025-01-23 14:23
The only thing to be protect so far that I found is the password of the basic auth
tim.vahlbrock
2025-01-23 14:43
I found that credentials in the headers are also redacted, and that there has been a pull request to redact parts of an url a few years ago (https://github.com/pact-foundation/pact_broker/pull/262) but the later was closed in favor of something else, but I haven't been able to figure out of what.
tim.vahlbrock
2025-01-23 14:50
ah. seems like beth wanted to implement a separate 'secrets management' feature, but the branch was never merged.
yousafn
2025-01-23 17:19
she ended up approaching it a different way which ended up becoming part of PactFlow
iuri.ramos
2025-01-27 20:41
@matt.fellows Thank you for the support.
We discovered that the issue was the lib that we were using to generate the api specification.
thomas.ks
2025-01-28 14:22
Hi! I want to migrate to use `contract_requiring_verification_published` in the Pact-Broker's webhooks as I am working on multiple environments (main branch, integration, stage, prod). I am using Gitlab trigger tokens which trigger a pipeline only running the `pactVerify` job (which is a Gradle talk of my project executing the Java PactProviderTest).
As Gitlab only accepts branches and *tags* as reference (`ref`), I don't know how I can pass the right revision to the `ref` as my `pactbroker.providerVersionNumber` returns a combination of my Gradle project version + the respective Git short SHA (e.g. _1.0.0-a6d33b7a_). My tags in Gitlab are named in format _v1.0.0._ I was thinking about parsing the version and do string manipulation to reach my desired format, but this seems not be possible within a webhook. Alternatively I thought about setting the `providerVersionsTags` and use them to pass to the `ref` . But this seems to be a complex (and probably dirty) workaround which I am not even sure about if it would work as expected.
Do you have any idea?
adrien.devillers
2025-01-28 14:52
I don't know about your git workflow, but if all your versions deployed in integration stage and prod environnement are tagged then you should modify your Pact Verifier so that when publishing verification results from the CI it sets your tag (gitlab-ci env var = $CI_COMMIT_TAG) as your provider branch. Then you can use pactbroker.providerVersionBranch as your ref in webhooks and it will trigger the verification on the right commit
worked for me
thomas.ks
2025-01-28 22:02
Hmm interesting idea. Thanks for the quick reply! But I wonder if there will be webhooks triggered for each environment as it is done with versions. Do you know if there is any difference?
Also I have to think it through as we are also working with feature branches and even a service which is a provider and a consumer at the same time. I wonder if the fact that the branch name information would get lost might cause issues...
adrien.devillers
2025-01-29 09:25
yes webhooks are triggered for each environment with the right branch/tag.
But yeah with your workflow I don't know.
I suppose It could work if you have a specific pipeline for tags that deploy to various env and also be consistent with the branch naming when publishing and verifying
About 'providerVersionsTags' I'll let someone from pact confirm it but I think tags is bound to be dropped
hmateika
2025-01-30 13:53
Hi community!
Anyone is handling secrets in open-source version?
If so, could you share your experience and how you do it?
thanks in advance!
plourded
2025-01-30 16:26
Hello, we have been experiencing this error with our broker for a few days:
_?Failed to load pact from ?https://pact-broker.****.com?: Error with the content of a HAL resource - Expected either a ?_? or path identifier in path expression ?$.query.$? at index 8"*
We have tried to understand what it means, but we haven?t found a solution.
2025/01/30 11:25:36 [INFO] package libpact_ffi found
2025/01/30 11:25:36 [INFO] checking version 0.4.26 of libpact_ffi against semver constraint >= 0.4.0, < 1.0.0
2025/01/30 11:25:36 [INFO] package libpact_ffi is correctly installed
Thank you for your help.
plourded
2025-01-30 19:39
Update, we got the error ?Expected either a ?*? or path identifier in path expression ?$.query.$? at index 8" only when we use on of those selector:
? DeployedOrReleased
? Environment
? Deployed
matt.fellows
2025-01-31 03:06
I don't think it's a broker issue but I dud pact file (see other thread)
dranidis
2025-01-31 10:42
Hi, I am searching for a way to get all versions of a pacticipant that are currently in an environment, e.g. `production`. I did not find anything in the pact-broker CLI or in the Pact-broker API. Is there a way?
dranidis
2025-01-31 10:50
I guess I missed: `/environments/VERSION/released-versions/currently-supported` and `/environments/VERSION/deployed-versions/currently-deployed`
paul.beigang
2025-01-31 12:52
Hi there, are there any infos how much resources needed when self hosting the Pact Broker?
What resources does it need?
How much space should I plan for the database?
thanks!
yousafn
2025-01-31 13:02
It completely depends on your requirements, but we provide guidance based on our own setup at PactFlow for those that self-host. You can use these as a decent guideline
https://docs.pactflow.io/docs/on-premises/system-requirements
yousafn
2025-01-31 13:06
Pleasure! We don?t try too hard to push people into the PactFlow docs from the Pact docs, but there is info that is kind of applicable to both spread about.
It?s always okay to ask if you get stuck navigating!
matt.fellows
2025-01-31 13:15
More info on some of the endpoints can be found here: https://smartbear.portal.swaggerhub.com/pactflow/default/pactflow_saas_api
thomas.ks
2025-02-04 10:47
Hi Adrien, sorry for the late reply. In the meantime we tried some stuff and I guess it could work with putting tags into the branch variable.
Currently we are *not* running our deployment jobs on tag pipelines but on the main, which means that we have to run the Pact-related jobs after the tag creation (and also the release of artefacts) in order to be able to assign the correct tag to the new Pact contract version.
As long as we do not deploy the artefacts when the Pact contract breaks, it should be fine. But we are currently using the `can-i-merge` function before we are merging the feature branches into the main pipeline. This we could not use anymore since we don't have main branches tagged, which the `can-i-merge` would check against, but only tags.
But as we are directly deploying to integration environment after the tag has been published, we wouldn't really need that functionality anyways. Or what do you think? Checking `can-i-deploy` three times (integration, stage, prod) should be good enough?
As an alternative we thought about creating a second tag in Gitlab which equals the pact pacticipant version so that instead of the branch variable, we could just send the `pactbroker.providerVersionNumber` to the Gitlab trigger token `ref` ...
vvargas
2025-02-05 08:01
hey folks how are you? I would like to know when running the CI if an application is a consumer or a provider.
Is there any endpoint that given a pacticipant we get its interactions such as the one that offers Pactflow?
GET https://myorg-xxxx.pactflow.io/pacticipant/myapp/network
Thanks in advance :dancer:
matt.fellows
2025-02-05 08:42
The Pactflow API docs are a superset of these.
See
https://smartbear.portal.swaggerhub.com/pactflow/default/getting-started for more
vvargas
2025-02-05 09:26
awesome, I something working already.
Unless I specify the opposite, there is no pagination in this endpoint right?
matt.fellows
2025-02-05 11:15
Specify the opposite? Sorry I'm not sure what that means.
There is pagination though:
vvargas
2025-02-05 11:37
I mean, pagination always happens by default or is it something that me as API consumer I have to specify in the request?
matt.fellows
2025-02-05 11:47
You need to specify. There is a section in the wider API documentation on how it works
vvargas
2025-02-05 11:47
I'm good then, I don't want pagination at the moment :smile: Thanks for the quick responses
tim.vahlbrock
2025-02-06 10:07
Hello, is it correct that the OSS Broker does not fire the `contract_requiring_verification_published` event when no provider has ever verified a contract from this consumer? So if I want to trigger the pipeline for a brand new interface I also need to add the `contract_content_changed` event to the webhook configuration?
matt.fellows
2025-02-06 10:11
I think that?s right. I can?t remember _why_ it doesn?t fire it - probably because it doesn?t have any _provider version_ to say ?this version needs to verify the pact?
matt.fellows
2025-02-06 10:13
but I wouldn?t add the second webhook for triggering the provider exactly once
tim.vahlbrock
2025-02-06 10:47
Yeah, that absolutely makes sense. Just realized that those would need to be separate webhooks anyway, because the contract_content_changed doesn't seem to have access to the variables that the other does, which confirms your guess.
tim.vahlbrock
2025-02-06 10:48
> but I wouldn?t add the second webhook for triggering the provider exactly once
Oh yeah right, especially because whatever this pipeline runs will likely fail anyway because it's impractical for the provider to setup their contract tests before the consumer did (and published their first contract)
tim.vahlbrock
2025-02-06 11:06
Hm. Strange. The contract was verified (not on the main branch though), pushed a modified version and the webhook still isn't triggered (not failed to trigger, but just not trigged, also reportely like that by broker UI).
gabriel.vasconcelos
2025-02-07 11:01
Hello.
Is there a way to get an error from the broker when a pact or swagger gets published to a non-existent pacticipant?
yousafn
2025-02-07 11:06
it will automatically create the pacticipant for the pact ( consumer ) or openapi ( provider )
yousafn
2025-02-07 11:06
what is your exact scenario, what behaviour are you seeing and what do you expect to see?
gabriel.vasconcelos
2025-02-07 11:08
We're trying to use the broker as a source of truth. In that scenario, we have a pipeline that creates pacticipants depending on the asset's needs.
To protect it as a source of truth, I'm looking for a way to prevent the accidental creation of new pacticipants, so it would be nice to have a setting or flag that changes the permissive behavior of the broker.
matt.fellows
2025-02-07 12:20
A few things
1. Pact broker doesn't really support swagger (you could technically publish one but not as a provider)
a. Did you mean PactFlow here?
2. Similarly, there is no RBAC in the open source broker (but PactFlow does have this)
chris.speck
2025-03-11 06:11
Good afternoon. How do I get the list of released consumer versions from a self-hosted pact broker?
I.e. the list of versions marked by `pact-broker record-release`?
Also, how do we bulk `record-support-ended` them?
matt.fellows
2025-03-11 10:48
> Good afternoon. How do I get the list of released consumer versions from a self-hosted pact broker?
See https://smartbear.portal.swaggerhub.com/pactflow/default/pactflow_saas_api#/record-deployment/get_environments__environmentId__deployed-versions_currently-deployed (and the ?released? variant)
If you?re up for a PR, it should be added to https://github.com/pact-foundation/pact_broker-client. It seems a common enough use case.
> Also, how do we bulk `record-support-ended` them?
Probably will need a script for that and loop through the list
ksawery.karwacki
2025-03-17 17:48
Tags are generally considered deprecated. But are there any plans to delete them? I am building workflow where I promote artifacts (docker images) to specific environments. I use commit id for pact version (as recommended) but I do not have an easy way to get commit id from docker tag (semver). I planned to tag contracts and verifications with semver version and use api to get version from tag and then run can I deploy against it. But if I lose tags in near future it will all fall apart. Is there any reasonable way to do it any other way instead of having external system tracking matching between semver and pact version?
matt.fellows
2025-03-17 23:57
they are just deprecated for the purposes of identifying branches being worked on, and releases/deployments
abubics
2025-03-18 02:42
Yeah, that's a good distinction. You can still use them for other freeform metadata purposes.
ghsouza89
2025-04-03 18:16
:wave: Hello, team!
someone can help to clarify how can I publish an example-consumer into pact-broker?
ghsouza89
2025-04-03 22:03
I'm trying to use CLI option (pact broker command), but Im bit confusing about it:
? what do I need to install?
? just run the command: pact-broker publish /path/to/pacts/consumer-provider.json --consumer-app-version 1.0.0 --branch main --broker-base-url https://test.pactflow.io --broker-token SomeToken
? I already have my url and token
matt.fellows
2025-04-03 23:07
The CLI, it?s linked from the page above (goes here: https://github.com/pact-foundation/pact_broker-client)
matt.fellows
2025-04-03 23:07
There are 3 options
1. Ruby gem (most people don?t use this)
2. ?Standalone? some use this
3. Docker - we use this in all of our example projects
junyiiiiii
2025-04-10 03:03
Hi team,
I?m looking for some advice on our current Provider's CI/CD setup with Pact Broker. We have two separate branches: `staging` and `production`, which may contain different code as features are tested in staging before being rolled out to production.
1. Would it make sense to maintain separate sets of Pact stages for each branch?
2. I've observed that when a webhook is triggered, the verification always runs against the main branch (staging), regardless of which branch initiated the process. This could potentially cause issues when the branches diverge.
Any suggestions on how we can improve this setup or handle branch-specific verification more effectively?
Thanks!
matt.fellows
2025-04-10 04:48
> Would it make sense to maintain separate sets of Pact stages for each branch?
I?m not sure I entirely follow. The concept of ?branches? are there to map changes for a given branch. Are you using `pact-broker record-deployment` when you deploy to each environment?
> I?ve observed that when a webhook is triggered, the verification always runs against the main branch (staging), regardless of which branch initiated the process. This could potentially cause issues when the branches diverge.
When a webhook fires, it specifies in the payload which _version_ (and branch/environment) that it needs to check against. Your webhook target should read the value of that body, and checkout the correct code accordingly.
See also https://docs.pact.io/pact_broker/webhooks#using-webhooks-with-the-contract_requiring_verification_published-event
raess.simon
2025-04-17 09:10
According to https://docs.pact.io/getting_started/versioning_in_the_pact_broker the commit SHA should be used as version. I understand the reasoning behind that, but what I don't understand how this plays together later with can-i-deploy. When deploying, I do not use a commit SHA, but a real version (e.g. 1.1.10). I would need to know the commit SHA when doing the can-i-deploy. I guess I could look it up from Git, but then need Git access at that moment (which I currently don't have).
yousafn
2025-04-17 09:42
you can use your semantic versions and your commit sha. you require the commit sha in order to effectively checkout the provider code for deployed/released versions when new contracts requiring verification are published.
if you are using BDCT, you will just have a provider contract in each environment which means you technically don?t need to replay the consumer interactions against the deployed/released provider versions. PactFlow would perform a cross compat check of the consumer contracts vs the deployed/released provider contracts
have you setup webhooks or looked at them?
raess.simon
2025-04-17 09:47
how should I use both? Yes, we have webhooks configured for verification and there we just do it with a Git tag. No need for the SHA. BDCT?
yousafn
2025-04-17 09:50
git tags might work, you get a payload in the webhook with the provider version, in your case it would be a tag you would checkout.
BDCT is bi-directional contract testing, a pactflow only feature whereby the comparison is done by comparing consumer pact files against a provider description, such as an OpenAPI Document, rather than using the Pact framework to replay the interactions against a locally running provider. I mentioned this as you asked about it in PactFlow channel
raess.simon
2025-04-17 10:25
to pick this up one last time: you suggest to use a version in the form 1.2.13-<sha>? This could actually work across all use cases.
yousafn
2025-04-17 14:50
correct, that follows our best practise guidelines as well,
https://docs.pact.io/getting_started/versioning_in_the_pact_broker#guidelines
yousafn
2025-04-17 14:50
> *For git, it is ideal if you either use the git commit sha (short or long), or include the git commit sha in your version number (for example 0.0.10+76a39e5)*
junyiiiiii
2025-05-13 09:05
According to the https://docs.pact.io/pact_broker/tags, using tags is no longer the recommended approach for managing versions. Instead, branches are preferred.
However, the Pact CLI (as shown in the attached) still requires specifying a `--latest` when retrieving the latest published pact version for a consumer/provider, which implies using tags like `--latest <branch_name>`.
Given this shift in recommendation, how can I retrieve the *latest published pact version* for a pacticipant *based on the branch name*, without relying on tags? Is there a recommended way to achieve this using the Pact Broker CLI?
matt.fellows
2025-05-13 10:44
that?s a good point. I?d guess it?s not that common a use case via the CLI (given you?re the first to ask of it). It should be noted, that a _version_ does not necessarily have a related _pact_ (contract) associated with it
You could query the latest https://developer.smartbear.com/pactflow/default/pactflow_saas_api#/pacticipant-version/get_pacticipants__pacticipantName__branches__branchName__versions. If you want the latest published contract relating to a specific integration, you might want https://github.com/pact-foundation/pact_broker/blob/d8c7ee657a17018c03980c0fe42bb1543007dfd6/lib/pact_broker/api.rb#L72. Hopefully these pointers help?
Officially, you might want to ask on the related GH project as an issue if you?d like it in the CLI.
junyiiiiii
2025-05-14 02:35
Since my current CI/CD implementation uses the Pact CLI to interact with the Pact Broker?handling tasks like creating versions and recording deployments?I was hoping to also use the CLI to retrieve the latest version for a given branch.
However, it seems that retrieving the latest version by branch isn't fully supported via the CLI at this time. As a result, I'll use the Pact Broker API directly for this specific case?when a consumer triggers a pact verification and I need to look up the latest version on a particular branch.
junyiiiiii
2025-05-15 02:53
My goal is to build a seamless CI/CD pipeline for the provider, integrating contract testing with Pact and using the commit SHA as the version identifier.
The pipeline includes a configuration-only stage that updates deployment settings without triggering a build or test. This presents a challenge when the pipeline is triggered by the Pact Broker?since it attempts to verify against the latest commit SHA, which hasn?t actually produced a build or been published to the Pact Broker.
As a result, I need a reliable way to retrieve the most recent published version from the Pact Broker for the correct verification to occur, rather than relying on the latest commit in the repository.
isaac.richardson
2025-05-20 13:30
Hey, is there a way to target a provider branch other than main when running: `pact-broker can-i-deploy` ?
I'd like to test using a webhook on a separate branch but is recording a deployment in test environment and then targeting that the best approach or can I target a provider branch specifically?
isaac.richardson
2025-05-20 13:48
On top of that, is there a way to delete webhooks from the broker? I can't see anything in the CLI docs
yousafn
2025-05-20 14:18
can i deploy using versions not branches, targeting environments
can i merge is also available for targeting branches, again it uses versions
junyiiiiii
2025-05-21 08:09
When setting up your webhook (e.g., `https://<repo_url>/api/v4/projects/<project_id>/ref/${pactbroker.providerVersionBranch}`), the provider branch will be selected based on your version, as the consumer tests against the deployed version of the provider.
thomas.ks
2025-05-22 12:27
Hey folks,
in our company we are self-hosting the Pact-Broker and want to put it behind a Cloudflare Zerotrust tunnel and disable the Pact-Broker's own basic auth. This means that we have to send custom headers for authorization (`CF-Access-Client-Id` and `CF-Access-Client-Secret` with the calls to the Pact-Broker.
In our pipeline we are using the Pact CLI tool which is only sending basic auth token as far as we understood. Same goes for Pact JVM for our unit tests which are communicating with the Pact-Broker.
Do you have any idea how one could solve this issue or is there a feature planned to be able to send custom headers as well?
matt.fellows
2025-05-22 13:14
Makes sense. There are no plans I?m aware of, but might be worth searching the relevant GitHub repos to see if there are any feature requests already.
I don?t see why we wouldn?t allow such a support. This is the relevant repo: https://github.com/pact-foundation/pact_broker-client (assuming no changes needed to comms to the broker as it terminates at the gateway?)
thomas.ks
2025-05-28 09:32
Thanks for your reply, Matt.
I see that there is a request on the Pact Broker Client but no reply yet:
https://github.com/pact-foundation/pact_broker-client/issues/185
Same for the Pact JVM, where someone was able to modify the @PactBroker annotation to make it work:
https://github.com/pact-foundation/pact-jvm/issues/1835
I was hoping that these changes might be in progress already. As long as that is not the case I have to see if we are able and have the time to customize them
matt.long
2025-06-17 08:37
Hi all, I'm attempting to build in a webhook trigger to a Jenkins multibranch pipeline on the provider. My challenge is that the multibranch-webhook-trigger only wants to build branches with changes, which during provider validation is unlikely the case. Has another faced this challenge, and any tips to resolve? Have spent a few hours down rabbit holes of documentation to no luck thus far. Appreciate any help :pray:
ashish_garg5
2025-06-19 12:52
Hi Team,
Do we have binaries available for pact-foundation/pact-cli ? I can only see docker image.
I have upgraded pact-go from v1 to v2 and looks like we have to use pact-cli now for publishing the pacts.
Can anyone please confirm. Appreciate any help.
Thanks.
yousafn
2025-06-19 13:15
part of the pact ruby standalone releases
https://docs.pact.io/implementation_guides/overview#cli-tooling
stan196
2025-06-21 00:30
Hey folks, what's the recommended way to deal with monorepos and webhooks? We have a monorepo which hosts services like my-service and other-service. Whenever a webhook triggers, we get the `my-service` as a name, but I don't think there's a way to map it to a git repo - other than using an external datastore or a service, but nothing built into pact-broker. Is that correct, or am I missing some metadata?
matt.fellows
2025-06-22 22:50
I must admit it?s not something I?ve spent a lot of time doing (monorepo).
Perhaps you could use one of the https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution (e.g. `${pactbroker.providerLabels})`) to add some additional mapping in the broker?
You could also lookup the git repo using that name. Thehttps://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/index/pacticipants.markdown resource has a `repositoryUrl` property to store this sort of thing.
stan196
2025-06-23 16:05
Thanks! How do you set the `repositoryUrl` field when creating or updating a pacticipant?
stan196
2025-06-23 16:31
I've tried using a rest API directly and it works. I don't think default pact cli supports it, but we can use the rest api directly.
stan196
2025-06-23 16:39
ah, nvm - you can use pact-broker cli to set repository url directly, sweet. I missed that part. So what we can do in our webhook processor service is to fetch provider details by name, extract repository url. @awang this is likely the best solution for us
stan196
2025-07-01 20:26
Just to circle back here. We have a small microservice that accepts webhooks and triggers CI builds. Originally written to bypass some API limitations of our CI system. In there we've added a call to the broker to read the repositoryUrl from the broker once webhook is received and use that information to trigger a CI build. So it was a pretty easy change to make. One improvement would be if the webhook payload already included all the pacticipant information for both provider and the consumer, like repositoryUrl and others, but it's not a huge deal.
matt.fellows
2025-07-02 02:36
That should be be doable. I'll raise a feature request to flesh it out further
priyaranjanmudliar
2025-07-09 14:03
Is there a way I can check in the pact broker OSS version, which interaction verification failed for a pacticipant
kay.scheerer
2025-07-24 09:06
Hi
Could anyone point me to documentation for recording deployments but with HTTPS? I can only find the CLI commands, but they need to communicate via HTTPS in the end anyways so there must be a way, right?
(Out of multiple unreleated reasons, using the pact_broker_cli is a lot more effort compared to a curl call)
ruud.welling
2025-07-24 11:32
You can use the HAL explorer in your browser to see the options (and I thnk you can cupy them as curl from the dev console)
matt.fellows
2025-07-24 12:12
Yep, that's one way!
You can see our API docs here too
https://developer.smartbear.com/pactflow/default/pactflow_saas_api#/record-deployment/get_pacticipants__pacticipantName__versions__versionNumber__deployed-versions_environment_environmentId
kay.scheerer
2025-07-28 07:52
I couldn't find in the HAL explorer. The website proved very helpful, thanks!
james.perepiczka
2025-07-30 14:03
Hi,
Question about the Pact Broker/publishing to the broker. If you have a contract that has been verified for a particular version (and say you tagged it with some metadata), if you were to re-run that verification again with no tags, would it take away the tags from the published verified version in the broker?
jan.mekota
2025-07-31 11:44
Hi guys :wave:
may I ask please what is the purpose of the `--build-url` parameter in the `publish` command?
When I use it, where in pactbroker is it used?
https://docs.pact.io/pact_broker/client_cli/readme#publish
We are using Pact Broker OSS.
yousafn
2025-07-31 11:56
It is used in webhook template parameters
original inclusion
https://github.com/pact-foundation/pact_broker/commit/9b79b33f336cf2200f8eeee0f77a843423e1a663
so can be used in your slack notifications to provide a link back to the build that generated that contract (on publish), or from a build that verified the contract (on verification)
It looks like the dynamic variable sub docs were not updated at the time
https://docs.pact.io/pact_broker/webhooks/dynamic_variable_sub#dynamic-variable-substitution
main source is here
https://github.com/pact-foundation/pact_broker/blob/master/lib/pact_broker/doc/views/webhooks.markdown#dynamic-variable-substitution
it would probably be worthwhile closing those documentation gaps
yousafn
2025-07-31 11:58
each verification is distinct, so you will have a new verification result number.
I would anticipate that the first would have a tag, but the second wouldn?t.
The 2nd would be the latest verification result, the 1st, would be the latest tagged verification result
james.perepiczka575
2025-08-11 08:08
Hi, Is it possible to generate an adhoc PACT_URL? So if I wanted to verify a particular contract, can I generate the URL to run the provider verification? Rather than it be generated just when the webhook fires
matt.fellows
2025-08-12 10:40
If you publish a pact, it should print the URL after
e.g. https://matt.pactflow.io/pacts/provider/SomeProvider/consumer/SomeConsumer/version/SomeVersionProbablyAGitSHA-1234
matt.fellows
2025-08-12 10:41
Why do you want to do this though? As soon as it gets to the broker, the webhook will trigger within a few seconds anyway?
james.perepiczka575
2025-08-12 10:47
There are instances where can-i-deploy fails in higher environments due to missing verifications between versions. In those instances, we use a combination of provider version, consumer name/tag to trigger a custom verification so that we dont block pipelines but are validating the correct interaction. I wondered rather than capturing this information, if we can just pass a pact url for this verification but I've no idea where it comes from/how I would be able to generate a url for say Consumer A needs to verify against Provider X, there is no pre-verified pact so here is a URL, trigger the webhook (or at least give a url that we can pass into our pipeline to fulfil the missing verification
matt.fellows
2025-08-12 11:04
rightyo. I?m assuming you?re checking out the various provider versions (i.e. different verification targets) when the webhook fires, and not just testing against mainline each time?
matt.fellows
2025-08-12 11:35
So I think you could
Run the `can-i-deploy` command with the `--json` output, and then grab the version of the failing consumers. From there, you could construct the Pact URLs
matt.fellows
2025-08-12 11:37
Alternatively, you could also just run a verification build with specific selectors (e.g. the environment you want to check against) - it will pull down any pacts you need to verify, and then you can re-run `can-i-deploy`
james.perepiczka575
2025-08-12 13:17
So if I choose option one (getting the json from can-i-deploy), the url I'm looking to build looks like this `<base_url>/pacts/provider/<provider_name>/consumer/<consumer_name>/pact-version/<pact_version>/metadata/<metadata_encoded>`
Assuming I can get the pact version from the can-i-deploy output
How do I get the metadata encoded part?
tim.vahlbrock
2025-09-02 10:53
Hello,
we're currently having with the OSS Pact Broker. Several pipelines report, that there are no pacts to verify, even if there are. The UI of the broker gives conflicting information. When I configure the matrix to show all contract versions on the 'main' branch of the consumer, it shows a several entries. However, when I configure it to only show the latest contracts of the main branch there are no entries at all. Does anyone know how this can be?
We do have a script running each night that removes branches from the broker that are no longer existent in the repository, but calling the branch deletion endpoint shouldn't delete any contracts that are still on other branches, right? (I already tried this out with a local broker instance and that doesn't seem to be the case).
tim.vahlbrock
2025-09-02 11:06
Oh yeah: the list of contracts on the main branch shows all of the branch tags greyed out, hovering on a tooltip says that this means that there is a more recent version of a contract, but that isn't listed.
tim.vahlbrock
2025-09-02 11:09
The latest version of the participant endpoint is a version from a feature branch. (might be intended though?)
tim.vahlbrock
2025-09-02 11:18
Oh man I think I got it. The last consumer contract test run on the default branch failed (due to an infrastructure failure), however the provider contract tests succeeded. This means that the broker knows of a newer pacticipant version, but has no contract belonging to it. Is it intended to run provider tests only when the consumer tests succeeded?
yousafn
2025-09-02 11:36
> The last consumer contract test run on the default branch failed (due to an infrastructure failure),
did this publish a pact with new version? or did it fail before?
> however the provider contract tests succeeded. This means that the broker knows of a newer pacticipant version
if you have enablePending set to true, the providers build won?t fail because of the failing pact on the consumers main branch
https://docs.pact.io/pact_broker/advanced_topics/pending_pacts#with-the-pending-pacts-feature-enabled
this stops the provider being blocked unnecessarily, if the consumer has never has a successful verification of the contract on their main branch (as the provider has never verified that they can honour it)
tim.vahlbrock
2025-09-02 11:39
> did this publish a pact with new version? or did it fail before?
It failed before.
tim.vahlbrock
2025-09-02 11:39
> this stops the provider being blocked unnecessarily, if the consumer has never has a successful verification of the contract on their main branch (as the provider has never verified that they can honour it)
I know, we have pending pacts enabled, but the contract has been verified before.
tim.vahlbrock
2025-09-02 11:40
I just restarted the failed consumer job and after the contract was uploaded, the problem was gone.
yousafn
2025-09-02 11:42
ie the provider job picked up the new pact to verify (or it was self verified because the content didn?t change)?
are we talking about a provider verification triggered by webhook, or by a provider change?
tim.vahlbrock
2025-09-02 11:45
The problem was that Pacticipant A failed its consumer job before being able to upload any contract. However, Pacticipant A did upload its own verification results. Pacticipant B, which is a provider to Pacticipant A, tried to verify it's compliance with the lastest contract from Pacticipant B, but the latest version didn't include any contracts, because Pacticipant A's consumer contract job failed.
ashish_garg5
2025-10-07 17:35
Hi Team,
I am using this pact broker image : https://github.com/pact-foundation/pact-broker-docker
Recently I started getting intermittently 504 error when trying to connect to the broker.
[ERROR] ExternalInstanceProviderPactTest.pactVerificationTestTemplate(PactVerificationContext) » RequestFailed Request to path 'pact-broker-url' failed with HTTP response 504.
Is there anything I can do to fix this? I have the cleanup cron job already configured.
Thanks in advance.
yousafn
2025-10-07 19:29
i haven?t seen that issue before. can you enable verbose logging and check the application logs?
yousafn
2025-10-07 22:07
I don't think so, I was just trying to get a picture of your setup.
I haven't seen anything raised recently that is similar
yousafn
2025-10-07 22:50
Did it co-incide with a recent pact-broker upgrade?
Would you possibly be able to pin an earlier version and see if it shows up? We can then look at the delta between versions and see if any change could indicate.
I would advise adding verbose logging and seeing if that throws up any more info when the error crops up
matt.fellows
2025-10-08 00:48
How long did the request take before it timed out? Do you know what API call failed? What do the logs say?
matt.fellows
2025-10-08 00:49
A gateway timeout indicates a slow API response, my guess is that the verification selectors are causing a slow DB query. Can you please share what you are using in that verification job?
You may want to check the settings for ?wip? pacts - if that?s set to some far time in the past, that could be to blame. Also worth ensuring you delete old/defunct branches
ashish_garg5
2025-10-08 00:58
[ERROR] LayoutGenerationTests.pactVerificationTestTemplate(PactVerificationContext) » RequestFailed Request to path 'pact-broker-url/pacts/provider/repo-name/for-verification' failed with HTTP response 504
[ERROR] ProviderTests.pactVerificationTestTemplate(PactVerificationContext) » RequestFailed Request to path 'pact-broker-url/pacts/provider/repo-name/for-verification' failed with HTTP response 504
