has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

I've set the default encoding for all the executables in the standalone package to UTF-8. This should quash all those encoding bugs. The latest standalone version is now 1.33.1

awesome - thanks Beth. I?ll run the Windows build with encodings later to see if it works

I've been thinking of writing a little script that will raise an issue to upgrade the standalone in all the wrapper implementations when there is a new release. Worth it?

I was thinking exactly the same thing

well, maybe not _exactly_

A long-term potential would be to have proper build pipelines

It might be possible now with Travis, I?m not sure. But if a minor/micro standalone goes out, it could trigger build of downstream projects to auto-build (if not also release)

I'm not sure that python/.net/... are using a full automated release process yet, but the js one probably could now/soon?

perhaps

Also, that UTF-8 fix _seems_ to have done the trick: https://ci.appveyor.com/project/mefellows/pact-go/build/240

Awesome

Yeah .net is full automated release. I just create a GH release and everything auto builds and deploys.

Like a shop bought one

@neil I think beth and matt are talking about a new release for .net when a new standalone is released

@mboudreau Oh righto. Is that how the other libraries work?

No. It's all very manual at the moment.

It would be nice to have a release of the standalone trigger a build for each of the wrapper languages that pulled in the latest version and released automatically if the tests passed. But for now I'll just ping you here when there is one.

Yeah no worries. It would be great to get some more context about the changes as well, rather than just seeing there is a new release in GH.

So yeah, this channel is great :smile:

The release I just made has code to support an alpha implementation of message pact.

The v3 contract format reading and writing is incomplete, but the workflow is there.

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

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

@matt.fellows I've released a new version of the standalone. It supports an array of providerStates but only reads the first one into the domain model. You'll need to update the incoming json message to have an array of providerStates with a name attribute.

``` pact-message update '{ "description": "a test mesage", "providerStates": [ { "name": "an alligator named Mary exists" } ], "content": { "name": { "contents": "Mary", "json_class": "Pact::SomethingLike" } } } ' --consumer Foo --provider Bar --pact-dir ./tmp --pact-specification-version 3.0.0 ```

^^ That's what the call to pact-message should look like.

Not sure why the windows build is failing, but this message is on the messages screen `Build execution time has reached the maximum allowed time for your plan (60 minutes).`

It looks like we've reached a limit and will have to wait for some time period to tick over.

I've found this in the docs: > Are there any build time restrictions? > All plans have maximum build job execution time of 60 minutes. I don't understand what that means though. Per what?

Thanks Beth, hopefully my train schedule is looking good tomorrow to update it :grimacing:

i means the build took over 60 minutes and it timed out

something is locking up the build from finishing

like the process never returns

:thinking_face:

/github subscribe pact-foundation/pact-ruby-standalone commits

/github unsubscribe pact-foundation/pact-ruby-standalone deployments public commits

@cfmack @neil @matt.fellows @mboudreau @marko @andrewspinks if any of you are interested in showing the verification tests in a test framework that is native to the language instead of the rspec output, I just wanted to let you know that you can tell the verifier to output the test results in json. If your test framework allows you to dynamically create test cases (as rspec does) you could then parse this output, and use it to "report" the rspec test results in a test framework native to your language.

has joined #pact-ruby-standalone

I'm not sure if this is a thing that people would really like or not, but I wanted to let you know it was an option if you wanted to give pact verification a more native feel.

Definitely good to have that option!

The really nice feature to have would be to be able to run a single interaction using the native test suite's interface, rather than setting environment variables. That may be trickier to do however.

Yeah that would be cool. In .NET specifically it?s a pain because there is not one single test framework standard.

@bethskurrie pact-go does this now

Nice

Golang is pretty easy, because most people only use the built-in test framework, but with JS there are more test frameworks I?d need to integrate with than there are characters in this sentence

It?s possible, however

Ha

@mboudreau ^^ looks good

@bethskurrie I found an issue with pact in windows, specifically when we're not escaping the -I attribute of ruby within out shell/bat files

I've tested it locally and seems to work if I surround it in `"`

this is related to https://github.com/pact-foundation/pact-node/issues/90

which is kind of funny because all the shells are already doing it...

@mboudreau I've just tagged 1.44.2 for release. It should be out in a few minutes.

sweet!

@bethskurrie from the same issue as earlier, now I'm getting another issue, but this one seems to be related to URL parsing in the stub service

I'll look more into it tomorrow for the ruby standalone

alright, the issue is in pact-support, trying to fix it now

I can't believe something as basic as URI can't seem to escape or parse windows paths...

I think I fixed it, testing it further before adding PR to pact-support

@bethskurrie all green now, could you please merge/release and do another release of the pact standalone? thanks

OK

Standalone should be out in a few mins

I think that fixed it for windows :smile:

Oh Windows.

Strange that you had problems, because I have a Windows specific test on appveyor.

It passed.

yeah, but I'm not sure if you were testing spaces in directories

you were testing backslashes

Ah, right.

might be good to add a test in there for spaces to prevent regression

I've added some to pact-node

@mboudreau https://ci.appveyor.com/project/pact-foundation/pact-ruby-standalone-windows-test#L139

Done

has joined #pact-ruby-standalone

god damnit, I had just released a new version of pact with 1.47.1!

:smile:

Script it.

probably could with a git webhook, but that means having write access to the github repo

I mean, just have a script that you can run locally that updates the number and runs the tests and commits.

I have release scripts for all my repos.

They automatically bump the version, generate the changelog and tag.

A release is out in seconds.

oh, don't get me wrong, my release process is seconds as well, just need to update the pact-standalone number, increment version and tag it with a message

it's a non-issue really, I just found it annoying that I had literally just deployed and boom, new version just came out :stuck_out_tongue:

Another day, another version :wink:

@bethskurrie the mock service does seem to log some things to stderr which doesn?t seem correct

run this: ``` pact-mock-service -p 1234 2> /tmp/stderror 1> /tmp/stdout cat /tmp/stderror # you should see stuff cat /tmp/stdout # you shouldn't see anything yet ```

I can raise e a bug against the mock server a bit later today

Interesting. I'm not sure if I can fix that or not, as it's the Webrick startup doing that. I'll have a go though.

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

Morning @bethskurrie @matt.fellows can I have a question. I see that we have a --retry-while-unknown argument in can-i-deploy. I wonder do we have it for pact-broker as well

pact-broker what?

can you give an example @franklin.huynh?

I mean pact-broker publish, pact-broker create-version-tag @bethskurrie

and what would you retry on?

a bit of context, yesterday in our CI, it failed because of the internal issue from broker that we could not tag our environment after deployed. When we rerun it, it passed

tagging and publishing already retry

as in, they retry when there is an error.

`--retry-while-unknown` is different because there is no actual http error - it's just a certain state of data that we suspect will change soon, so we wait around to see if it will change.

I believe publish and tag try 3 times with a 5 second wait

so the broker must be down for 15s

``` Tagging pact service ServiceName with tag Staging for version 79ced33178615e509b18351c38568c594f519bf5 05-Jun-2019 19:38:35 D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/base_client.rb:86:in `rescue in handle_response': Internal Server Error (PactBroker::Client::Error) 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/base_client.rb:76:in `handle_response' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/versions.rb:29:in `tag' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/create_tag.rb:35:in `block (2 levels) in call' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/retry.rb:22:in `while_error' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/create_tag.rb:34:in `block in call' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/create_tag.rb:31:in `each' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/create_tag.rb:31:in `call' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/create_tag.rb:19:in `call' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/cli/broker.rb:75:in `create_version_tag' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/vendor/ruby/2.2.0/gems/pact_broker-client-1.18.0/lib/pact_broker/client/cli/custom_thor.rb:15:in `start' 05-Jun-2019 19:38:35 from D:/bamboo-home/xml-data/build-dir/8060929-223281161/pact-latest/pact/lib/app/pact-broker.rb:28:in `<main>' ```

are you talking about pactflow? We did have a production outage for a few minutes last night. That typically doesn't happen however, and I'm not sure if you'd want to retry for more than a minute under normal circumstances.

yes, it is pactflow

that's what I got

was it the time we have the outage?

i.e. 05-Jun-2019 19:38:35

Have a look at the #pact-broker channel. There is an outage notification. It should show the time in your local time.

Here is the retry code for tagging https://github.com/pact-foundation/pact_broker-client/blob/master/lib/pact_broker/client/create_tag.rb#L34

Yes, it's 3 times with a 5 second sleep.

We could potentially expose those settings in the CLI, however, I don't think it would have helped you last night.

We're very sorry that your CI was interrupted - we take our uptime very seriously, as we know peoples CI is dependent on it.

thanks @bethskurrie for your information. all good for now. I understand that

I'll explain to our developers about that :smile:

I think we should have a better way to announce the problem

do you guy have a status page or something?

What I can do is increase those defaults so it retries for longer - but as I said, it was a genuine outage last night, and I'm not sure you'd want to try for as long as it was out for. The retries are meant to handle intermittent network issues.

Yes - http://status.pact.dius.com.au/

I want to have a webhook for push a message to our slack channel

thanks

I think you can!

fair enough

:+1:

all good now

has joined #pact-ruby-standalone

Hi there. I would like to implement some (or all) v3 features for pact-php. I just learned that the ruby-standalone server does not support those features yet. What are the plans for v3 here?

I don't have time to pick it up, but if someone is willing to help out, I can work with them.

There are a few things implemented already like the changed json format and the multiple provided states.

It's the new matchers that are missing.

Well, I have never done anything in ruby before. But if you show me the file where matchers are defined and handled I would take a look at it. I tried to find the file this morning, but I was not successful

It's in pact support

There's not "a file".

When the pact is deserialised, a tree is built of the structure.

Each matcher gets turned into an object that contains the logic for working out if something matches or not.

Is there a particular feature you're interested in?

Well, no. I just wanted to contribute a bit to open source. I like this project and I can use it at work (hopefully, if I can convince my colleagues) and that is why I think about investing some time if possible

There's always so much work to be done, any help is appreciated!

That's good. I invested most of my time so far in PHP. Other languages are not a black book, but I need more time

Ruby is a fairly easy one to pick up, compared to some. It's usually easy to read, but harder to write because there are so many ways of doing things!

That's why I like code reviews :wink:

has joined #pact-ruby-standalone

Using the `pact-provider-verify` command, is there any way to target *all* unverified pacts? When running the command and not supplying any specific pacts or tags or versions to verify, it only verifies the latest consumer version. This becomes an issue if we want to run verification for all pacts (independent of whether it's a feature branch or master etc).

@samuel.hodgkinson that's an interesting problem. Can you tell me more about what your situation is? What makes it necessary to verify all the versions of the pacts?

Having said that, I'm releasing some code tomorrow which will introduce the concept of "work in progress" pacts, which is basically, all unverified pacts.

So we have some automation to help with pact in Jenkinsfiles in our company, and I had a team contact me asking whether they could conditionally publish pacts to our broker only if it is on a master branch, because if a feature branch pact is published, it updates the `latest` tag. Then when they come to verify, they just verify the latest which may mean `master` pacts go unverified. I'd suggested that we recommend teams always verify all unverified pacts (from every branch) and then only gate their build on the `master` pacts, or whichever pacts they actually care about. That way everyone gets results, but the build only passes/fails based on those `master` pacts.

Do you think this is a good recommendation? Also, it does sound like the "work-in-progress" pacts would solve this issue, do you have any docs on how this works yet? Is it another kind of tag?

@bethskurrie do you have any advice on this situation?

@samuel.hodgkinson never verify just "latest". Always use a tag name.

I didn't get the wip code out, but I got all the groundwork code done. What language are you using for verifications?

If you verify all unverified pacts, your builds will be very long!

Have you read this? https://docs.pact.io/best_practices/pact_nirvana#5-allow-contracts-to-change-without-breaking-your-builds

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

Is there a way to get `pact-provider-verify` to only print out failing verifications?

Thanks to @bethskurrie in #pact-js - the answer is `--format progress` (repeated here for the viewers at home)

has joined #pact-ruby-standalone

@bethskurrie When is it expected that pact-ruby-standalone will support pact spec v3?

I don't know, sorry, @samuel.hodgkinson. We're actually hoping to move from the Ruby standalone to the rust impl (which already has v3)

Okay, no problem. Could you link me to that rust implementation please?

has joined #pact-ruby-standalone

Hi, hoping someone can help or point me in the right direction! I'm writing tests for iOS that use the ruby server as described in the swift wiki - https://github.com/DiUS/pact-consumer-swift but I am seeing some weird behaviour, and I'm not sure if it's a bug or a config issue. My first test class runs correctly and generates a PACT file as expected. The second test class, for a different API generates a PACT with the new cases as expected, but also includes all of the ones from the first API. Any suggestions?

Are you shutting down the mock after the first class runs?

Do the mocks run on different ports?

Ah yeah. I think that's the problem. You'll want different mock services for each provider

Hi @tjones. Unfortunately the iOS use case is to set the server to start and stop in the pre and post test run actions. Meaning we can't stop the server in between test classes.

It gets started at the beginning of the whole suite, then stopped at the end

This would work fine if all APIs were routed by a central access point, but not for distributed APIs

@alan.nichols Yeah, this makes sense. We cannot start and stop the mock services programatically in the test suite because the simulator doesn?t have access. One workaround might be to startup two mock services on different ports and switch which one each test uses.

This is one of the reasons why switching to the rust binary would be an advantage, we can start and stop that from the tests. Unfortunately its a big change and introduced other issues. I did spike it on a branch at one point, but its not really usable.

Can you not start two mock services?

it should be fine to fire up two different servers at startup (and close them at the end of the tests)

@andrewspinks Matt is having a go with pact js, and the changes they make to rust impl for that might make it easier for ios. See how we go.

Some of it was the way rust libs needs to be linked which forces certain compiler settings to be used by the user (and which may have cause app store approval issues - I can't remember the exact details). At least that's how it used to be.

Ugh!

Thanks @andrewspinks and @bethskurrie for the information. I'll look into options with using multiple servers on different ports and also the option of having the tests for different APIs in the same XCode Scheme but different Test Plans. It should mean I can use "build for testing", then separate runs for each test plan using Test Without Building. I'll pick whichever one is least messy given our number of APIs.

Thanks @tjones. I'll look into options around starting multiple servers in the prebuild actions and at using some xcode features to have different test schemes for each API.

We are also starting up multiple mock services on different ports in the pre-build test action. We?re using Xcode 11's Test Plans to change some environment variables for which consumer/provider we?re testing, along with providing the port number of the associated mock service. This is working out nicely to quickly test shared app code that is targeted at different server backends.

Thanks @kyle.hammond. I ended up not needing to use the test plans as we have one backend with multiple APIs. An environment / port enum and an extra line of config has sorted this. Our pre and post steps now loop through an array of ports to start up / shut down. It would be great to capture some of this stuff in the wiki I think. I assume this is a relatively common use case?

I agree documenting the Xcode setup for others would be great.

has joined #pact-ruby-standalone

Hi everyone. I have a test that is generating a PACT for a PUT request with some values in the body of the request. When I have a look at the PACT that is generated, all that is captured is the method and the path. I'm not sire if I'm doing something wrong.... Any ideas?

I saw you replied to your own message in #general. Have you sorted it out and are able to continue with your development now?

Sorry! Yes all sorted now. Will be implementing the solution today hopefully :slightly_smiling_face:

@alan.nichols has left the channel

has joined #pact-ruby-standalone

Late to the party but ran into the same issue with running PACT tests for 9 providers. Utilized `enum` for provider ports and `protocol` to force usage of the port enum in each of the Test files. The `start_services.sh` iterates through a list of ports (same count of ports as the enum holds them) and `stop_services.sh` searches for any running services and kills them all. A hopefully decent comment next to enum and protocol has been written for devs to follow the setup. Seems to be working fine for now.

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

@kyle.hammond has left the channel

has joined #pact-ruby-standalone

@bethskurrie Is there a way to get the interaction diff returned by the mock-service verification endpoint when verification fails? Like a JSON output, maybe? I?d like to expose the contents of the diff to pact-js, so that we don?t have to check the logs so often

Yes. Raise it in the mock service repo.

Done! Let me know if there isn?t enough detail: https://github.com/pact-foundation/pact-mock_service/issues/123

has joined #pact-ruby-standalone

Hello, I?m trying to get the pact publish to work for my python code and am using the official docker image here https://hub.docker.com/r/pactfoundation/pact-cli There is no `publish` command to be found. Am I missing something?

Apologies for the late response - the command you are looking for is: ```pact-broker -h```

publish is under `pact-broker publish`

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

I can put this pact on server using postman, but cannot add tags to it.. is there a way I can add tags using postman?

and how can I fix SSL issue?

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

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!

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`

[pact-foundation/pact-ruby-standalone] Issue closed by bethesque

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.49_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] Issue closed by bethesque

[pact-foundation/pact-ruby-standalone] Issue closed by bethesque

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.50_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.51_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.52_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.53_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.54_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.55_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.56_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.57_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.58_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] Pull request opened by snyk-bot

[pact-foundation/pact-ruby-standalone] Pull request opened by dependabot[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.59_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.60_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.61_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.62_ published by github-actions[bot]

[pact-foundation/pact-ruby-standalone] New release _https://github.com/pact-foundation/pact-ruby-standalone/releases/tag/v1.88.63_ published by github-actions[bot]

I don't have time right now to look in to it more, but I think 1.88.65 might be broken - we hit this in pact-js CI: https://github.com/pact-foundation/pact-js/runs/3544112550?check_suite_focus=true#step:4:901

I fixed it by rolling back to 1.88.63

I can provide more info tomorrow if you need

it appears to only affect the verifier

has joined #pact-ruby-standalone

we ran into the same issue ourselves. rolled back to 1.88.60 since we had that working last

@tjones is there a github issue already logged for this?

No, I didn't have a chance yesterday

The latest standalone (1.88.68) results in a lot of ```Error retrieving matrix. NoMethodError - undefined method `+@' for "":String``` errors when used in pact-js - see https://github.com/pact-foundation/pact-js-core/runs/3718127522

oh dear

something going on in httparty

I'll see if I can repro locally

@tjones can you see if you can work out what the exact arguments being passed in are?

I probably can, one moment

```{ pactBroker: `http://localhost:${PORT}`, pacticipants: [{ name: 'Foo', version: '4' }], }``` This is the js, one moment and I'll get you the CLI args

it's ok

I've locked httparty

new release of the standalone is in the rube goldberg machine now

amazing

Weirdly, 1.88.68 passes locally for me

Ok, that one works, thank you!

Unfortunately, our tests are now failing for a different reason - Is the broker path `/auth` new? pact-js-core has some really old broker mocks, which might need to be updated

(we ....really should use pact for that....)

Is there somewhere I can read the pact between the CLI and the broker?

hm, maybe it's a regression - the broker path in that test is `https://localhost:${port}/auth`, and the error we're getting is: ```Error making request to http://localhost:9720/auth status=404 \n<html lang="en">\n<head>\n<meta charset="utf-8">\n<title>Error</title>\n</head>\n<body>\n<pre>Cannot GET /auth</pre>\n</body>\n</html>\n```

(the broker mock does answer to `/`)

Whatever has changed, it's changed since 1.88.66

There is no path "/auth" in the Pact Broker, and there never has been.

```$ be rake pact_broker:routes[auth] Listing routes containing the term 'auth'```

Here's the pact https://github.com/pact-foundation/pact_broker-client/blob/master/spec/pacts/pact_broker_client-pact_broker.json

There is also no request to anything with the path "auth" in it that I can see in the client code https://github.com/pact-foundation/pact_broker-client/search?p=1&q=auth

Right, sorry, I wasn't clear- after first thinking it was requesting `/auth`, I realised that the broker base url includes this path, and so I started thinking it might be a regression when the broker is not running at the root

^ This one is still broken for us. I'm afraid I don't really have time to look into it at the moment, so for now I'll just pin pact-js to the last good version (1.88.66)

bugger. which error?

Same as above: ```PactBroker::Client::Hal::ErrorResponseReturned - Error making request to http://localhost:9874/auth status=404 \n<html lang="en">\n<head>\n<meta charset="utf-8">\n<title>Error</title>\n</head>\n<body>\n<pre>Cannot GET /auth</pre>\n</body>\n</html>\n'``` (that's the broker root path. It's using a mock broker, which might be the problem, but 1.88.66 works fine, so something has changed between those versions)

and which call is that?

Ah, sorry, hold on

it's pact-broker publish, with...

hm. it has changed, but it should perform the same way against a mock.

``` { pactBroker: authenticatedPactBrokerBaseUrl, pactFilesOrDirs: [ path.resolve( __dirname, 'integration/publish/publish-success.json' ), ], consumerVersion: '1.0.0', pactBrokerUsername: 'foo', pactBrokerPassword: 'bar', });```

the mock won't have the HAL links that would make it use the new API.

i'll have a dig

I suspect the mock might be wrong

but in a way where it wasn't wrong before

it makes a call to the index now that it didn't used to.

I think you'll need to stub that response.

if you give it `{_links:{}}` it should be fine.

has joined #pact-ruby-standalone

(Sorry if this is the wrong channel, it just seemed to be the most relevant) Someone on our security team pointed out that the Pact-PHP library downloading the Pact Ruby standalone installer from Github releases could be subject to a supply-chain hack (like the codecov one), and asked me if there was a way to validate that it hadn't been compromised by a bad actor. I haven't been able to find a mention of how to handle this with Pact so far, other than to pin the version and add a custom hash check in our test code (assuming the current installer is clean). If there is a better way to handle this (e.g. checking a hash you all publish independently of the installer's release) I would definitely love to know. Pact has been super helpful for our team so far and I'd hate to have to pull it :disappointed:

yep, there are checksums published in the github release

Look at the checksum files.

The pact-js impl verifies the checksum, but I don't know if the php one does.

I see, I didn't see a mention of that in the php one but I can double-check. And lemme see if I can get that person from security to verify this would be ok if it did

Yeah I'm not finding anything looking for that file in PHP. And is the process for generating that checksum fairly independent of the process of creating the installers? We had another issue recently re: composer's installer and its checksum, and our security team was ok with it given that the checksum was separately generated/hosted from the installer (at least on the face of it)

I don't understand the question - can you expand?

You can see where the checksums are created a published here https://github.com/pact-foundation/pact-ruby-standalone/blob/master/script/prepare-release-in-github-workflow.sh#L18

Got it, so if prior to this one of the packages were compromised, the checksum would be computed from that compromised package, is that somewhat accurate? Like I wouldn't be able to tell it was compromised when doing the comparison myself?

```bundle exec rake package pushd pkg; for file in *.{zip,gz}; do sha1sum -b "$file" > "${file}.checksum"; done; popd; cat pkg/*.checksum > pkg/pact-`cat VERSION`.checksum```

the package gets built, then the checksum is created in the next line. they are committed together and published to a github release.

as long as you go back to the github release for the checksum, you're safe.

Right, I guess I'm just not sure if our security team will end up being ok with that. I assume ideally they'd want the checksum computed in a totally separate procedure, so even if the installer is tainted somewhere along the line here, when we download both we'd be able to see the difference. I'll try my best to make that argument though & figure out how to do some of this checking from PHP!

I still don't know what you mean by "the installer"

Oh it says "installer" a lot in https://github.com/pact-foundation/pact-php/blob/661a2ab51d7695ad2c085f5ceb4df3d0c5142130/src/PhpPact/Standalone/Installer/Service/InstallerLinux.php, but I'm thinking now it just means the binary for the standalone mock service?

It seems like Pact-JS no longer does a checksum check afaict - https://grep.app/search?q=.%2Atar.gz.%2Achecksum.%2A&regexp=true&filter[repo.pattern][0]=pact-foundation Since the "https://github.com/pact-foundation/pact-js-core/blob/master/download-checksums.js" function no longer exists Noticed this while drafting an issue for Pact-PHP that I was going to try and make a PR for, but based on the above search it seems like none of the languages are currently using the checksum. Should I take that to mean it's up to package consumers to do the check themselves? (that seems ok to me, I just wanted to double-check before I proceed with doing that) (Also I forgot to mention it before but ty so much for all of the support around this! I really appreciate it and the moment my company needs to do real contract testing instead of just api mocking I'm definitely getting them to try out Pactflow!)

You're welcome.

:smile:

You'll need to check with the #pact-js maintainers about the checksum checking. It definitely used to happen.

We are moving away from the ruby standalone to a shared rust core, FYI.

the ruby standalone is effectively legacy now.

Yup will do! And oh nice I did not know that, very good to know.

I can't tell you when the php client will get it however.

Yeah I think that's probably fine. I actually talked w/ our head of security about this whole thing today and he was much more relaxed about it tbh...shouldn't have let that one person get me so riled up perhaps...

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

~Hiya! Does anyone have any tips for debugging `--publish-verification-results` in `pact-provider-verifier`? I think I?ve included all the necessary arguments, but it isn?t publishing and the log output doesn?t suggest it?s trying to.~ ~I?d expect it either to publish or tell me why it couldn?t, but I?m not familiar enough with Ruby to know quite what should be happening.~ OMG ignore me it?s because the consumer still uses `master` as its default branch :face_with_rolling_eyes:

The command I?m running is: ```./pact/bin/pact-provider-verifier \ --broker-username ${PACT_BROKER_USER} \ --broker-password ${PACT_BROKER_PASS} \ --provider-app-version ${GIT_COMMIT_PROVIDER} \ --provider-base-url ${APP_BASE_URL} \ --provider-version-tag ${CIRCLE_BRANCH} \ --pact-broker-base-url ${PACT_BROKER_BASE_URL} \ --provider ${PACT_PROVIDER} \ --consumer-version-tag main \ --wait 30 \ --verbose \ --publish-verification-results``` And the verbose log output is: ```opening connection to <my-broker>:443... opened starting SSL for <my-broker>: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: [redacted]\r\n" -> "HTTP/1.1 200 OK\r\n" -> "Date: Mon, 21 Feb 2022 10:11:33 GMT\r\n" -> "Content-Type: application/hal+json;charset=utf-8\r\n" -> "Content-Length: 5112\r\n" -> "Connection: keep-alive\r\n" -> "Vary: Accept\r\n" -> "Server: Webmachine-Ruby/1.6.0 Rack/1.3\r\n" -> "X-Pact-Broker-Version: 2.93.2\r\n" -> "X-Content-Type-Options: nosniff\r\n" -> "\r\n" reading 5112 bytes... -> <removed> read 5112 bytes Conn keep-alive INFO: Fetching pacts for lpa-codes from https://<my-broker> with the selection criteria: : latest for tag main opening connection to <my-broker>:443... opened starting SSL for <my-broker>:443... SSL established <- "POST /pacts/provider/lpa-codes/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" <- "{\"consumerVersionSelectors\":[{\"tag\":\"main\",\"latest\":true}],\"providerVersionTags\":[\"pact-verify\"]}" -> "HTTP/1.1 200 OK\r\n" -> "Date: Mon, 21 Feb 2022 10:11:33 GMT\r\n" -> "Content-Type: application/hal+json;charset=utf-8\r\n" -> "Content-Length: 179\r\n" -> "Connection: keep-alive\r\n" -> "Vary: Accept\r\n" -> "Server: Webmachine-Ruby/1.6.0 Rack/1.3\r\n" -> "X-Pact-Broker-Version: 2.93.2\r\n" -> "X-Content-Type-Options: nosniff\r\n" -> "\r\n" reading 179 bytes... -> "{\"_embedded\":{\"pacts\":[]},\"_links\":{\"self\":{\"href\":\"https://<my-broker>/pacts/provider/lpa-codes/for-verification\",\"title\":\"Pacts to be verified\"}}}" read 179 bytes Conn keep-alive INFO: Polling for up to 30 seconds for provider to become available at localhost:4343... INFO: Provider available, proceeding with verifications```

Resolved, the `consumer-version-tag` should have been ?master? not ?main?. This is what happens when you have a branch naming strategy but don?t actually roll it across your estate :joy:

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

@tjones has left the channel

has joined #pact-ruby-standalone

Does anyone know how I can pull from https://github.com/pact-foundation/pact-ruby-standalone/pull/73 now it has merged? I Think I need to wait until a release cut to be able to use.

Yeah it needs a release, I?ll get on it now

thx for the change

Thank you

See slack message below :the_horns: https://pact-foundation.slack.com/archives/C9WTB2JDV/p1653305273798749 Let us know how you get on. If there is anything we can add to our documentation on Linux, and you would be happy to suggest or make a PR, it would be greatly appreciated whilst your in that headspace :slightly_smiling_face: https://docs.pact.io/docker#alpine-linux

I won't be around until tomorrow to try this, but it should instantly fix the issue I was experiencing. It's really a strange one as what happened was someone got the latest alpineJS for our (non-ruby) tech, and all of a sudden env bash could not be found. Locally I can execute on the container, until a script attempts to launch another script. It'll for sure be a fun issue to solve

@yousafn Do we know if 1.88.83 -> 1.88.89 has url structure changes? I'm having some issues making a working PR for pact-php based on this release of pact-ruby-standalone. pact-php uses pact-ruby-standalone. But it looks like master fails too...

Hey hey Just about to clock off for the evening (dinner is calling) but you can check out the CHANGELOG for details pact-ruby-standalone https://github.com/pact-foundation/pact-ruby-standalone/blob/master/CHANGELOG.md most changes appear to be in, you can see the version on the gem it pulls in, and the associated changelog :mag: pact_broker-client https://github.com/pact-foundation/pact_broker-client/blob/master/CHANGELOG.md

Enjoy dinner mate. I'm going to call it a day too. The commands php runs do work when run without PHP :joy: so maybe some fun contributions ahead. If I can get master working in it's own CI again, I'll PR a scheduled build so people can get alerted if it breaks in future.

confirmed working for `pact-php` (modifying the installer constants to use `1.88.90` ), clearing `pact` (local install of standalone) and using `Lewiscowles1986:bugfix/update-pact-url` as a base branch.

has joined #pact-ruby-standalone

This now introduces a `pactflow` command for `publish-provider-contract` which can be used like ```./pact/bin/pactflow publish-provider-contract \ oas/swagger.yml \ --provider "pactflow-example-bi-directional-provider-postman" \ --provider-app-version 3a0994c \ --branch test-pactflow-command \ --content-type application/yaml \ --verification-exit-code=0 \ --verification-results newman/newman-run-report-2022-06-09-14-03-30-715-0.json \ --verification-results-content-type text/plain\ --verifier postman```

Depending on your platform Windows (bash shell) ``` curl -LO https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v1.89.00-rc1/pact-1.89.00-rc1-win32.zip && \ unzip pact-1.89.00-rc1-win32.zip && \ ./pact/bin/pactflow help``` MacOS ```curl -LO https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v1.89.00-rc1/pact-1.89.00-rc1-osx.tar.gz && \ tar xzf pact-1.89.00-rc1-osx.tar.gz && \ ./pact/bin/pactflow help``` Linux ```curl -LO https://github.com/pact-foundation/pact-ruby-standalone/releases/download/v1.89.00-rc1/pact-1.89.00-rc1-linux-x86_64.tar.gz && \ tar xzf pact-1.89.00-rc1-linux-x86_64.tar.gz && \ ./pact/bin/pactflow help```

has joined #pact-ruby-standalone

@greg.tyler has left the channel

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

The GitHub user https://github.com/bethesque has signed out. Use the following command/s to recreate subscriptions /github subscribe pact-foundation/pact-ruby-standalone

/github subscribe pact-foundation/pact-ruby-standalone

:white_check_mark: Subscribed to https://github.com/pact-foundation/pact-ruby-standalone. This channel will receive notifications for `issues`, `pulls`, `commits`, `releases`, `deployments`

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

Hi all, I?m guessing this is the place to ask about `pact-ruby-standalone` . I?m in the process of including this within an image but noticed there are are open dependabot pull requests on this project. Is this actively maintained?

It would be good to get these merged in if possible as they are being flagged by a vulnerability scanner.

It definitely is

It's likely not yet at the top of a maintenance list. What's the use case?

I?m including these binaries in a image that I use as a build agent in Jenkins, so they can be used in a neat way within pipelines

But we have to vuln scan all running images. I can see the PRs have been created by dependabot which I _think_ resolve the vulns

It's a maintained project. I'd not necessarily wait for the...

Right :rolling_on_the_floor_laughing:

2 of the dependabot updates seemingly break the build, so I'd not expect them quickly if they resolve your issues - do you know if the ones with passing builds do?

it?s mainly the rack update I think https://github.com/pact-foundation/pact-ruby-standalone/pull/92

I?m happy to work on broken ones if they are needed :simple_smile:

If you have a moment, that would be helpful for sure!

I don?t really :simple_smile: but if they cause me pain I?ll find the time

if someone could find time to get the rack one merged that would be much appreciated :pray:

Just getting dependabot to rebase so I can get fresh builds and baseline. standby

when do you schedule in new releases?

There is no specific release cadence - we have something like > 100 ?releasable? artifacts across our repositories that we manage, so it?s usually on demand, when there is something to release

understood, if it isn?t already obvious I?m looking for a new release after these PRs :grin:

yep :slightly_smiling_face:

so looking at the repo, it _is_ maintained but due to the way we distribute the CLI as a quasi-binary (via travelling Ruby) we will be constrained to support only Ruby 2.4 (that?s all it supports). This might cause issues for your scanner, so see how you go

The alternative is to just install Ruby on your base image, and `gem install <tool>` each ruby tool you need. Probably this is likely just `gem install pact_broker-client`

ok thank you for all your help, much appreciated

I?ll post back when I have a working solution

OK all the rebases are done and most of those builds are green, bar one that can?t be merged as the dep needs Ruby 2.6

Will run the release step shortly. I?ve not done it before, but will follow the guide and see what happens!

ha, perfect, thank you

I might need the maintainer to run the release sorry!

np, appreciate your efforts

@yousafn, sorry for the tag, I noticed you were in my timezone :simple_smile: is performing a release something you can do?

hold on to your butts

:wave: Just kicked it off!

what a legend! thank you very much

No worries fella! Seems some yak's need shaving for the downstream notifications, I'll sort that https://github.com/pact-foundation/pact-ruby-standalone/actions/runs/4491941252/jobs/7901148808 You based in the UK? I'm in Leeds

Yeah Cardiff. I was in Leeds for ~10years

Ahh lovely, we've got family in Neath, love a drive down over the sugar loaf mountains, and getting out and out with the wifey int camper van in North wales. Let us know how you get on with the release and would be super cool if you wanted to share some of warez with the community in a blog post or something when you are all sorted, as this sounds like something people would appreciate (a community contributor build some GitHub actions for the community too :slightly_smiling_face: ) - no pressure tho > I?m including these binaries in a image that I use as a build agent in Jenkins, so they can be used in a neat way within pipelines

Yeah will do my best to contribute back

Hmmm, The binary size is quite a big bigger than before. I've just been sorting out the homebrew build and came across a snag there, and thought I would try out the library, and on OSX at least, I am seeing the same issue with it not finding `json` gem https://github.com/pact-foundation/homebrew-pact-ruby-standalone/issues/87 thats installing the latest version via `curl -fsSL https://raw.githubusercontent.com/pact-foundation/pact-ruby-standalone/master/install.sh | bash` on my mac m1. hmmm will check it out on windows and linux boxes ,as well as an intel mac

Have you been able to run the binary successfully at all?

The json gem is there in the downloaded package

xD things are never simple :sweat_smile: Raised now, https://github.com/pact-foundation/pact-ruby-standalone/issues/94 might need to pull that release!

marked it as pre-release so it won?t get installed under the latest tag, so it can be investigated.

Oh no! what a pain, no I hadn?t gotten around to trying it yet unfortunately, hopefully today

Sorry, only just getting back to this :simple_smile: It would seem the version of rack we graded to, 2.2.6, needs ruby >=2.30, as per https://rubygems.org/gems/rack/versions/2.2.6 Any reason why `pact-ruby-standalone` is down on `2.2.10-alpine` ?

hmm, maybe that dockerfile isn?t getting used hey

Yeah I think it could be updated to 2.4 now. There might be some other reason why it hasn?t updated

Passed first time on ARM64 macOS and Linux for Pact-PHP :rocket: That is definitely a first for me :joy: Thank you https://github.com/cirruslabs/cirrus-cli

has joined #pact-ruby-standalone

@yousafn I submitted a PR to update the homebrew formula for the v2.0 packaging, also wanted to give deep thanks here, running on ARM has been a severe pain point for us until now. https://github.com/pact-foundation/homebrew-pact-ruby-standalone/pull/92

appreciate that dude, will check it out and get it merged. fingers crossed it works well for you, but there may be some gremlins hiding in the closet :sweat_smile: best getting it the hands of users and finding out

has joined #pact-ruby-standalone

Using `master` branch at https://github.com/pact-foundation/pact-ruby-standalone/commit/b8c1020f2d8a7d8a624cb23b6fb5da1639932e3f from https://github.com/pact-foundation/pact-ruby-standalone/ to install the CLI is not working any more for us, with error: ```warning: It seems your ruby installation is missing psych (for YAML output). To eliminate this warning, please install libyaml and reinstall your ruby.``` With broker version ```# PACT_BROKER_CLI: ./pact/bin/pact-broker $ echo "pact-broker version=$(${PACT_BROKER_CLI} version)" pact-broker version=1.66.1``` Looks like https://github.com/pact-foundation/pact-ruby-standalone/pull/100 contains the changes that trigger our error

Which operating system? Can you try adding `libyaml-dev`

it's on docker images

which docker images, there are many

Internal ones, but we fixed the Pact CLI version for now

it doesn't matter if they are internal, they still have a distro (distroless still need a kernel)

if they are debian based, please try my suggestion

Please understand that we want to help you, but you aren't providing enough information to be useful

:wave: Just as a heads up, we've switched the `2.0.0` release to a pre-release, so it won't be picked up by the latest install script This will pick up the release marked latest (currently `1.92.0`) ```curl -fsSL https://raw.githubusercontent.com/pact-foundation/pact-ruby-standalone/master/install.sh | bash``` You can now pin to particular versions, even if they are pre-releases, for example. this will get you the `2.0.0` version ```curl -fsSL https://raw.githubusercontent.com/pact-foundation/pact-ruby-standalone/master/install.sh | tag=v2.0.0 bash``` some details here https://github.com/pact-foundation/pact-ruby-standalone/issues/101#issuecomment-1535926311 If you do see any issues, please follow standard process and let us know via the GitHub issues, so we can track and others can see.

Replaced by https://github.com/pact-foundation/pact-ruby-standalone/pull/117

has joined #pact-ruby-standalone

has joined #pact-ruby-standalone

sorry! lots of noise. Two releases, one reverted (updated to Ruby 3.3.0 and OpenSSL 3.2.0, got some failing SSL tests). One is out though! No more bash required for pact-ruby-standalone