has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

Hey guys, Kudos to the team for such a great initiative :slightly_smiling_face: I have a question about `MockProviderServer` Taking the reference from https://github.com/jbwheatley/pact4s/blob/main/scalatest-pact/src/test/scala/pact4s/scalatest/MessagePactVerifierScalaTestSuite.scala#L6, I've added pact4s-scalatest dependency. However, I'm unable to import *pact4s.MockProviderServer* (looks like it doesn't exist or Am I missing something?)

you probably not need that `MockProviderServer` is in *pact4s repo to run mocked server, you must have own*

but here it is https://github.com/jbwheatley/pact4s/blob/main/shared/src/test/scala/pact4s/MockProviderServer.scala

has joined #pact4s

if you need to message me you can message this account, the other one is a duplicate. i will try to close the other one at some point

Yeah, Dmitry is quite right. You should make a mocked version of your own http server supplied with mock dependencies, that pact4s will use to run the requests from the pacts against. If you need to initialise state during any of your pact tests, you can add a route for setting up and tearing down state, which you supply the endpoint of to your pact4s setup. In the MockProviderServer that we are using for pact4s' internal tests, that route is called /`setup` :slightly_smiling_face:

has joined #pact4s

hi! i have a quesstion about WIP pacts i?m using ? [info] welcome to sbt 1.5.2 (Alpine Java 15.0.3) ? val pact4s = ?io.github.jbwheatley? %% ?pact4s-scalatest? % ?0.0.15? ? val pact4sCirce = ?io.github.jbwheatley? %% ?pact4s-circe? % ?0.0.15" ? *x-pact-broker-version:* 2.81.0 i?ve set ``` 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(providerTagFromBranch), selectors = consumerList ) ).withPort(8080)``` looks like everything needed from https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/ but in broker logs i have only ```2021-08-11 19:13:12.679944 I [8:puma threadpool 005] pact-broker -- Creating verification 7343 for pact_id=4387 -- {"providerApplicationVersion"=>"420a9da1", "success"=>true, "verifiedBy"=>{"implementation"=>"Pact-JVM", "version"=>"4.2.7"}, "wip"=>false}``` note - ?false? am i missing something for using WIPs ?

that should be it from the `pact4s` side

i?m assuming `Some(System.currentTimeMillis().millis - 7.days)` returns a finite duration

it will pick up non WIP pacts as well though, maybe that?s the case for that pact

there must be https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/#technical-details , so quite a bit must be picked

so i hope, this must pick up to 7 days old all non-verified pacts

it should

did you had a chance to use WIP ?

we use it here yeah

has been working fine for us

is there something must be set from consumer side ? ( iirc not, but just in case )

what is your setting in includeWipPactsSince ?

we use a 30 day window

but really it could probably be longer, like a year

depends mostly on when you started using pact vs when you started using WIP

i?m confused by this question https://pact-foundation.slack.com/archives/C02ACMH759Q/p1628713763008900?thread_ts=1628710148.008300&cid=C02ACMH759Q

do you set that differently ?

that field expects a `FiniteDuration` type

ours is read from configuration

`Some(Duration.fromNanos(config.getDuration(PactConfigKeys.pactFeaturesWorkInProgressPactsSince).toNanos))`

and `pactFeaturesWorkInProgressPactsSince` is ?

?30d?

and what `config.getDuration(PactConfigKeys.pactFeaturesWorkInProgressPactsSince)` returns ?

a java Duration of 30 days

hmm

to nanos

yeah, that?s just for creating a scala Duration from nonoseconds

maybe you should try creating a duration for ?7 days? instead of involving the system current time

> includeWipPactsSince.foreach(since => options.put(?includeWipPactsSince?, new Date(since.toMillis)))

toMillis

yes, that?s what the underlying pact-jvm library needs, but that shouldn?t concern you

i have a feeling you made it 1k times longer

:stuck_out_tongue:

mine is only for constructing a duration

it?s the same amount of time in the pact4s library, just a different unit

> 1628111689346 milliseconds

> maybe you should try creating a duration for ?7 days? instead of involving the system current time will try

as those `1628111689346` are 18K days :smile:

probably it?s subtracting 7 from current millis (since epoch)

haha

and goes loco

wondering aint it even wants `-7 days`

but if 30 days are ok ¯\_(?)_/¯

a duration is a time period, so ?7 days? instead of ?7 days ago?

word `since` in `includeWipPactsSince` is pointing to something more different

one more thing also bothers me https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/#how-is-wip-pacts-different-from-the-webhook-triggered-verifications ```The WIP pacts feature ensures that the changed pact is automatically verified each time the provider's release pipeline runs, even if it is not one of the pacts explicitly configured for verification.```

well ultimately at the API layer it is a date

> provider?s release pipeline is it meant CI as such?

yeah, ?deployment pipeline?

best practice is to not enable WIP in CI

hmm, why ?

there?s not really a benefit to it, and it can also cause problems

i would have to look back at that long thread to find details

problem is - if pact changed in branch , c-i-d will say `no` , and provider?s trunk doesnt know anything about that consumer?s branch

even if it is compatible with that

so exact WIP case

that?s where matching branches or configuration comes in

the provider needs to ?opt-in? to the new pact somehow

but if provider did his job long time ago ¯\_(?)_/¯

create dummy prov branch just for verification ? kinda overkill

well if WIP is enabled for CD, every provider build that merges to the main branch would pick up the WIP pacts and verify them

``` only: - master``` could help a bit

the general pattern is: consumer creates pact, provider verifies it, provider deploys, consumer deploys

sounds like you are talking about a different pattern

yeah, in perfect world

some part of consumer were done, or not all parts of consumer were pact-ified

if you are creating a consumer pact for something the provider already supports, you will have to run the provider build against master and have it pick up the consumer pact, either via WIP or via configuration

so - wip, or manually adding consumer tag to selectors

yep, that?s what we do

you can also use matching branches

(for the CI part)

tried webhooks, but for 2 monorepos it makes _*a lot*_ noise in ci

i haven?t done any webhooks yet

2 monorepos? stereorepo

more like chameleon

lol

2, but not stereo

> 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.

> so you can explicitly select that one. > thats a sad manual job :disappointed:

that?s why we don?t use WIP in CI

well you can also do the matching branches, if you don?t want to update configuration

you could also turn off WIP everywhere and always use configuration

thing is WIP is not turned on :D

we have done it both ways

i have a feeling, that i miss something small

what is in your ```selectors = consumerList``` ?

by default, just the ?stable? tags: `master`, `testing`, `production`

```val consumerList = List( ConsumerVersionSelector(tag = Some( providerTagFromBranch)), ConsumerVersionSelector(tag = Some("testEnv")) )```

why there is no provider tag for matching branches ?

oh yeah, and the git branch tag

forgot that one

https://github.com/pact-foundation/pact-jvm/issues/1407 should something like this created for pact4s or it will appear automagically ?

hi! back to WIP question i?ve added WIP to js project and it works, I?m still concerning about `includeWipPactsSince` non of them trigger WIP checks ```includeWipPactsSince = Option.when(isCI)(System.currentTimeMillis().millis - 7.days),``` ```includeWipPactsSince = Option.when(isCI)(7.days),``` still in JS ``` includeWipPactsSince: isCI ? new Date(Date.now() - 7 * 24 * 60 * 60 * 1000).toISOString().split("T")[0] : undefined,``` which results in `includeWipPactsSince:"2021-08-05"` which complies with https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/ ```You should enable the work in progress pacts feature by setting includeWipPactsSince (or equivalent for your language) in the provider verification configuration to the date from which you want the changed pacts to start being included (eg. `2021-06-12` ) ``` and broker logs WIP checks straight away

```final class FiniteDuration(val length: Long, val unit: TimeUnit) extends Duration { ... "Duration is limited to +-(2^63-1)ns (ca. 292 years)")```

`+-` ?

can anyone make an example, how this must look for WIP for 7 days old pacts?

We will need to update pact4s

hi! can you share output of this ? ```Some(Duration.fromNanos(config.getDuration(PactConfigKeys.pactFeaturesWorkInProgressPactsSince).toNanos))```

from run, that initiated wip pact checks

not at the moment

i will create a ticket to track

I think pact-jvm just expects us to pass it a string, but we are passing it a Date

so I?ll try to fix that

why doesn?t that throw an error -_-

i guess it just ignores the option?

it is working with your stuff though?

i?m not sure, we are in the middle of transitioning from scala-pact to pact4s

so maybe it?s broken now

:sweat_smile:

looks like it wants a String though

yep

probably should just use the `FiniteDuration` to get a date in the past, and convert it to a string in the format it wants

that?s what I?m gonna do :simple_smile:

sorry @dimundo i am doing too many things right now

(we also have some teams that use configuration only, so WIP doesn?t impact them)

@dimundo v0.0.16 is in the pipeline with a (hopeful) fix, can you give it a go when you get a chance and report back? You shouldn?t have to change anything about your set-up

may be 10-15 mins until it hits maven

slight hiccup, bear with

good ol scaladocs

once we have CI checks we should stick a `compile:doc` in there

yes I?ve just discovered you can only link to things in your own project

i?ll add it to the commitCheck command at the very least for now

by default yeah. it?s super annoying

can it be turned on?

this helps https://github.com/ThoughtWorksInc/sbt-api-mappings

but it?s still not perfect

ah nice, thanks

I?ll take a look at that

we also needed to add `-no-link-warnings`https://github.com/DavidGregory084/sbt-tpolecat/issues/36#issuecomment-846263768

right, lets try this again

so, can i try 0.0.16 ?

Yeah, give it a go

looks like it works, but a bit strange :slightly_smiling_face:

> 2021-08-12 21:55:24 2021-08-12 18:55:24.669112 D [8:puma threadpool 001] [wip] pact-broker -- Potential WIP pacts for provider tag(s) feature/B-335-WIP-3 created after 1970-01-08T01:00:00+01:00 by latest_by_consumer_branch (none)

epoch start looks scary :slightly_smiling_face:

for > includeWipPactsSince = Option.when(isCI)(7.days),

ah, so

1970-01-08 actually is 1970-01-01 + 7 days :slightly_smiling_face:

lol

date/times are hard

this is fine

Yep, includeWipPactsSince is still time since epoch

So your original impl will work

today- 7 days, right

Yup

need a docs for foot shooters :)

:taco: @kflo

i still think it makes more sense intuitively for it to be a ?since? because it takes a finite duration

:taco: @jackbwheatley

or just a date string i guess

:taco: @bethskurrie for a WIP as such :slightly_smiling_face:

date as string also is hard

doing all that woodo

or maybe we can even bury it under just ?enableWip? and obfuscate away the since date for most cases

but you have 30 days

i have 7 days

I'm forcing some cats-effect-ness by having it be FiniteDuration, thats what they use for their Clock impl

someone will have 1 day

but

We should add some overloads so dates can be provided instead

i think my impl now would be ?30 days from epoch?

this one asks for date string https://docs.pact.io/pact_broker/advanced_topics/wip_pacts/

maybe lets do as in docs ?

so effectively like 50 years

lol

yes the API itself wants a date string

i guess the question is what is the most common use case

do people want a floating range? or a hard-coded one?

?everything in the past year? vs ?everything since 2020-01-01"

if you want to skip own docs wrighting - implement same as in docs

But we have the benefit of strong typing, so it makes sense to provide an actual date for correctness, rather than a string that can easily be wrong

> includeWipPactsSince:?2021-08-05?

perhaps we should use `LocalDate` then

duration implies to me a time period

maybe we can support both

alright i gotta run and get some food

that one taco wasn?t enough

Yeah, probably make the default LocalDate then add some overloads

long time no see posts about WIP :smile: > Verifying a pact between Client (a81e995f) and API [PENDING] > 1) The pact at ? is being verified because it is a ?work in progress? pact (ie. it is the pact for the latest version of Client tagged with ?B-510? and is still in pending state). Read more at https://docs.pact.io/go/wip > 2) This pact is in pending state for this version of API because a successful verification result for a version of API with tag ?fix/typo-fix? 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 > Verification Failed - No annotated methods were found for interaction ?b.State?. You need to provide a method annotated with @PactVerifyProvider(?b.State?) on the classpath that returns the message contents. > [info] - Verify pacts for provider `API` *** FAILED *** what is wrong here ? `If this verification fails, it will not cause the overall build to fail.` -> FAIL :disappointed:

so it was working properly, until some contract were added to the existing pact

one more finding > * @param includeWipPactsSince is a [[scala.concurrent.duration.FiniteDuration]], and represents the duration since the EPOCH. Should not be set if [[enablePending]] is set to false. > * @see also https://github.com/pact-foundation/pact_broker/issues/338 which is a bit strange. if i don?t want pending pacts, but want WIP? ( issue doesn?t made it clearer )

maybe this is a proper comment, but still https://github.com/pact-foundation/pact-jvm/issues/1131#issuecomment-649422153

any ideas https://pact-foundation.slack.com/archives/C02ACMH759Q/p1629191351053300 ? or poking in #pact-jvm is right choice ?

what is the problem?

maybe you are running into this issue? https://github.com/pact-foundation/pact-jvm/issues/1260

we will probably want some support for that in `pact4s` as well, but we don?t have it yet

nope, not using states

it is in the error message above

> Verification Failed - No annotated methods were found for interaction ?b.State?. You need to provide a method annotated with @PactVerifyProvider(?b.State?) on the classpath that returns the message contents.

? consumer adds one message contract to pact in branch ? provider (not knowing about it) runs test against test env tag + wip enabled expected ? verification passes, disregarding that wip part fails observed ? verification fails as wip part fails

and pending pacts enabled?

pending pacts is the part that makes the build not fail

wip doesnt work w/o pending, as we know ;) and as wip branch is taken for verification - everything is correct in setup

pending off makes build green, but doesnt check wip branch ( which is sad, but expected )

can you post a different error message then? because the one above is about state

`b.state` is just message naming - > interaction ?b.State?.

and it is known that missing state will fail the build, even for wip + pending

ok, so it?s trying to verify a message that doesn?t exist?

yep

that might be another case where it will fail the build

ah, correct, new message, not field

> that might be another case where it will fail the build why ? :scream_cat:

that question would best be asked for #pact-jvm first

`If this verification fails, it will not cause the overall build to fail.` - it?s a lie then ?

seems like potentially a bug

well, that message is from the broker

not the implementation

lets wait for the answer ¯\_(?)_/¯

Hey folks :wave: In the next Pactflow POST, I?d like to make a call out to all of the amazing work happening across languages to get alignment to the v3 specification. `pact4s` is one of those, and all ya?ll (am saying that right?) are amazing.

The idea is to build awareness of the work, drum up some extra feedback and community adoption, which ultimately will move us all forward.

Are you OK with us adding it into our newsletter, and if there is any particular feedback you?d like to get, please let me know (e.g. a short sentence to include in the post)

Also, I've created #libpact_ffi-users - since there's quite a bit of discussion about the rust pact ffi bindings in the different language channels, but the discussions cover quite a bit of the same ground. Please join if this is useful or of interest to you!

Sounds good to me. I think the library is at the point where most of the core features are now implemented.

@matt.fellows, yes very happy to be mentioned in the newsletter :grin: The more members of the Scala community we can get picking up pact4s the better, especially as we?re all still learning Pact best-practices as we go along!

awesomte

anything in particular you?d like us to focus on?

I?ll probably just drive people to this channel and to wave at you folks

maybe which testing framework they use?

i think the only major one we don?t currently support is `specs2`

@abhi.nandan964 :wave:

has joined #pact4s

Am I right in thinking that pac4s doesn't yet support the pact pending feature? I've just been testing some scenarios and I can get the broker to flip between a true and false pending flag for a contract, but it always fails the provider scalatest build.

awesome. should have checked that!

I will try to get that merged soon

I've been on vacation for a bit

Any opinion on showing the messages returned by the broker with each pact in the new API? (genuinely not sure if they will help.)

Which new API?

apols. not that new. the "for-verification" API which returns "notices" with the verificationProperties

Hm, I think the messages shown now are returned from the broker. So that logic is probably in pact jvm

this PR should be ready now. @jackbwheatley FYI

has joined #pact4s

Should be fixed in v0.0.18 :grin: thanks for your help @kyle.florence

https://github.com/jbwheatley/pact4s/releases is still .17 :(

just didn?t draft a release for it in github

ah, cool, https://mvnrepository.com/artifact/io.github.jbwheatley/pact4s-scalatest

:taco: @jackbwheatley

:taco: @kflo

i?m hungry can i have another

:taco: @kyle.florence @kflo

:relieved:

hmm, slack founds two of you with same username

:laughing:

i am slowly taking over the world

2xLOC incoming!

i can?t seem to login to that account anymore lol

deprecation looks funny ```method apply in object PactBrokerWithSelectors is deprecated (since 0.0.17): Use the other apply method with the safer builder patterns pactSource = PactBrokerWithSelectors(```

and this is it :slightly_smiling_face:

what?s funny about it?

it?s trying to protect you from yourself

cut in the middle

could it be just start of stacktrace?

it?s just showing you the line that caused the deprecation warning

ah, looks like that but looks weird

``` .withPendingPactsEnabled(ProviderTags.one(providerTagFromBranch)) .withWipPactsSince(LocalDate.now().minusDays(7), ProviderTags.one(providerTagFromBranch))``` do i need both ?

> ProviderTags.one(providerTagFromBranch) looks like duplication here

you can just use `withWipPactsSince`

that was my thought :+1: nice

Hello all, interested in people?s thoughts on this https://github.com/jbwheatley/pact4s/pull/82

hi! i need to create provider test for some unique value in request resulting pact looks like this ``` "body": { "tableId": "table1", "signalId": "ddd" }, "matchingRules": { "$.body.signalId": { "match": "type" } } },``` thing is `signalId` is generated to be unique and cant be pre-configured for the provider test. so provider tests fails with 404 as trying to make request with `ddd` which isnt there there are some workarounds as request filters, but they are for headers as I understood any ideas ?

pact is created in js and looks like this ``` it("should POST to resolve signal ", async() => { const path = POST_SIGNAL_RESOLVE_URL await provider.addInteraction({ state: "2. i will resolve signal", uponReceiving: "a request to resolve signal", withRequest: { method: "POST", path, headers: { "Content-Type": "application/json" }, body: { ...tableIdBody, signalId: string("ddd") }, }, willRespondWith: { status: 200 }, }) const res = await makePostRequest(provider.mockService.baseUrl + path, { ...tableIdBody, signalId: "signalguid" }) expect(res.status).toBe(200) expect(res.ok).toBeTruthy() await provider.verify() })```

Maybe you want provider state dependency?

how does it looks like ?

There is info in the project readme

Request Filtering? this is about headers only

ah `provider state` will check

wow, looks easy , will check :+1:

hi! are there any examples around json schema validation ?

has joined #pact4s

`sbt pactPack` -> Would this command work in case of pact4s to generate the pact file?

pactPack is for merging pact files, not generating them. With pact4s, I think there's no need to merge pact files but I might be wrong.

Correct, there is no merging

That was a scala pact only feature

All pacts belonging to a consumer/provider pair will end up in a single pact file in pact4s

(the pact files themselves are generated when you run the pact tests)

Do you know if we can have multiple tests (as in multiple classes) declaring a pact between the same consumer and provider (on the consumer side) though?

I could test it.. just being lazy here :innocent:

my guess is that would not work well, because each test suite would be trying to write to the same file

I don't know what writes the pact files in pact4s, but the Ruby and the Rust core engines both support merging the pacts at write time

You have to clear them out before the tests, though (otherwise removed interactions persist)

pact-jvm does it

I think it also supports merging, not sure about for concurrent tests

has joined #pact4s

Hi there! I?ve written an HTTP request/response consumer and provider that passes successfully in my local environment. Now I?m trying to figure out why the consumer doesn?t seem to be creating the pact file during CI build. I was wondering if it has to do with the fact that I?m pushing both consumer and providers under the same branch. Anyone has experienced something similar? Let me know if there is any useful context I can provide since this could actually be so many things I wouldn?t know what to show exactly. But for starters I?m getting this message. ```Specified pact file 'target/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.[Container] 2022/04/19 15:44:20 Command did not exit successfully pact-broker publish "target/pacts" \ --broker-base-url="$PACT_BROKER_URL" \ --broker-token="$PACT_BROKER_TOKEN" \ --consumer-app-version="$BUILD_VERSION" \ --tag="$BRANCH_NAME" exit status 1```

has joined #pact4s

hi Martin. Are you able to confirm that the pact files are not being written to any directory during CI? It may just be that `target/pacts` is not pointing the brokerCLI to where the files are being written - `./target/pacts` or `yourModule/target/pacts` maybe?

has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

@tjones has left the channel

has joined #pact4s

has joined #pact4s

has joined #pact4s

Hi team, does anyone have experience connecting a pact4s provider with the pactflow broker? Much appreciated :pray:

Do you mean specifically with pactflow or any broker?

Last time I used Pact in Scala, I used scala-pact SBT integration to publish pacts to the broker.

Unfortunately publishing pacts is out of scope of pact4s.

Hi Gaël! Thanks for your response. I meant pactflow specifically, although any broker would do. I?m mostly interested on how the provider side verifies against pactflow. For context, I have drafted the PoC for a pact4s consumer and provider implementation in different services. While they both run successfully, only the consumer publishes its pacts to pactflow, but the provider verification never shows

I don't have more to share then but curious to know how your consumer publish its pacts? Is there another solution than scala-pact?

We do it in 3 separate steps on a github workflow, 1. Upload Pacts to Pactflow, 2. Generate Pactflow Github App token, and 3. Trigger provider service verification pipeline Step 0 before all of these would be running the tests on the consumer side These steps in the workflow simply run the curls against pactflow (steps 1 and 3, step 2 uses https://github.com/tibdex/github-app-token to generate the token). For step 1 we use Pactflow?s own read & write token, for step 3 we use the token generated in step 2

Thanks for the feedback

has joined #pact4s

hi! any plans about supporting deployedOrReleased ? ( or maybe it is done already ? ) https://docs.pact.io/pact_broker/recording_deployments_and_releases#pact-client-support-for-the-deployedorreleased-selector

hmm, by https://github.com/jbwheatley/pact4s/issues/68, looks like this should work already :)

this is available through this https://github.com/jbwheatley/pact4s/blob/648e2e5ac8c42df1b8047f011a24fa29e519b438/models/src/main/scala/pact4s/provider/ConsumerVersionSelectors.scala#LL61

yeah, already found. looks like docs must be updated

Hi there! Does anyone have experience setting up their pact4s code under their project?s test folder instead of src? Currently exploring this option with my team but we?re not sure how this would affect the dependencies

has joined #pact4s

has joined #pact4s

has joined #pact4s

has joined #pact4s

Hiya folks, I was wondering if I could pester for some help here. I'm currently writing a Kafka consumer test, but there doesn't appear to be any matching. I also can't see any in the pact4s example. I've got a successful typescript consumer test already which utilises `like` but I can't see anything like that. Does matching need to come from an alternate library?

I've solved this now by importing the following library `import http://au.com.dius.pact.consumer.dsl.PactDslJsonBody` This seems to be a very inactive channel, but if anyone has questions, I'll try and answer them.

Yup, overall when working with pact4s, you can look for help or documentation about pact Java/JVM

Pact4s is mostly a wrapper of pact java