now only debug the pact-js native-verifier

#105 chore: update workflow to point to the .github repo Pull request opened by Ilia This updates the comment create trigger and adds a better comment on the issue which has more meaningful comment when Jira ticket is created and is aligned with other triggers. pact-foundation/pact-broker-docker GitHub Actions: test ✅ 1 other check has passed 1/2 successful checks

#600 Security Vulnerabilities with the latest docker image Issue created by Yogesh-BK The latest docker image for pact-broker contains security vulnerabilities. I have already (please mark the applicable with an

x

): ☑︎ Upgraded to the latest Pact Broker OR ☑︎ Checked the CHANGELOG to see if the issue I am about to raise has been fixed ☐ Created an executable example that demonstrates the issue using either a: • Dockerfile • Git repository with a Travis or Appveyor (or similar) build Software versions • pact-broker docker version: eg latest • OS: e.g. Mac OSX 13.1 Expected behaviour Docker image with no security vulnerabilities Actual behaviour Docker image which contains security vulnerabilities (including high and medium) Steps to reproduce

1. Install a tool named [trivy](<https://github.com/aquasecurity/trivy>) which is used to scan docker images for security vulnerabilities.
 2. Scan the pact broker image for vulnerabilities with the below command

trivy image pactfoundation/pact-broker:latest

3. This will give the vulnerabilities

Scan Result | Security Vulnerabilities pact-foundation/pact_broker

#106 Vulnerability issues with pact-broker-docker:latest and 2.106.0.1 Issue created by nick130589 Pre issue-raising checklist I have already (please mark the applicable with an

x

): ☑︎ Confirmed this is the right place to raise the issue - only issues related to the Dockerization of the Pact Broker should be raised here. Issues related to the Pact Broker application itself should be raised in the Pact Broker project. ☑︎ Upgraded to the latest Pact Broker Docker image OR ☑︎ Checked the </CHANGELOG.md|CHANGELOG> to see if the issue I am about to raise has been fixed ☑︎ Read the Troubleshooting page Software versions • pact-broker gem version: 2.106.0.1 • pact-broker docker version: 2.106.0.1 Expected behaviour The image doesn't contain critical, high and medium vulnerabilities Actual behaviour The following non-operating system vulnerabilities were found: Critical: CVE-2022-37434 - Package zlib 1.1.0 - /usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec High: CVE-2018-25032 - Package zlib 1.1.0 - /usr/local/lib/ruby/gems/2.7.0/specifications/default/zlib-1.1.0.gemspec High: CVE-2020-36327 - Package bundler 2.1.4 - /usr/local/lib/ruby/gems/2.7.0/specifications/default/bundler-2.1.4.gemspec High: CVE-2021-43809 - Package bundler 2.1.4 - /usr/local/lib/ruby/gems/2.7.0/specifications/default/bundler-2.1.4.gemspec Medium: VULNDB-219586 - Package psych 3.1.0 - Fix: psych 3.2.0 Steps to reproduce Perform scan docker image by https://sysdig.com/ scanner Relevent log files N/A pact-foundation/pact-broker-docker

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 @Viet Anh Tran ran the same command I send to him and it’s working on his laptop. Does anyone have some ideas?

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?

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?

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-url<https://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?

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?

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!

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 the documentation 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 Swagger documentation, 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.

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 👍

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 ?

#579 SQL exception for an invalid query is thrown during pact broker data purge Issue created by sosnowst Introduction 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. I have already: ☑︎ Upgraded to the latest Pact Broker ☑︎ Checked the CHANGELOG to see if the issue I am about to raise has been fixed Expected behaviour Data that is not included in the selector will be cleared Actual behaviour SQL exception for an invalid query is thrown and the data is not cleared:

ERROR: each UNION query must have the same number of columns

Steps to reproduce 1. Enable pact broker data purge 2. Add one of the below selectors

"[{\"max_age\": 15}, {\"max_age\": 30, \"branch\": \"main\"}]"

"[{\"branch\": \"main\", \"latest\": true}, {\"max_age\": 15}]"

Relevant log files selector logs:

pactdbcleanup-pact-broker-1 | 2022-11-08 09:51:00.718470 I [23:4420] pact-broker -- Connected to database pack_broker pactdbcleanup-pact-broker-1 | 2022-11-08 09:51:00.722276 I [23:4420] pact-broker -- Deleting oldest 500 versions, keeping versions that match the configured selectors -- [#<PactBroker::DB::Clean::Selector:0x00007efc058d21a8 @source_hash={"max_age"=>15}, @max_age=15>, #<PactBroker::DB::Clean::Selector:0x00007efc058d0c90 @source_hash={"max_age"=>30, "branch"=>"main"}, @branch="main", @max_age=30>, #<PactBroker::DB::Clean::Selector:0x00007efc058726e0 @source_hash=nil, @deployed=true>, #<PactBroker::DB::Clean::Selector:0x00007efc05872618 @source_hash=nil, @released=true>]

sql query

2022-11-08 09:51:01.099 UTC [31] STATEMENT: SELECT * FROM "versions" WHERE ("id" NOT IN (SELECT * FROM (SELECT * FROM (SELECT * FROM (SELECT "id" FROM "versions" WHERE ("versions"."created_at" >= '2022-10-24') 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-09'))) 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 500

error:

2022-11-08 09:51:01.099 UTC [31] ERROR: each UNION query must have the same number of columns at character 181

pact-foundation/pact_broker

#107 chore(deps): bump actions/checkout from 2 to 3 Pull request opened by dependabot[bot] Bumps actions/checkout from 2 to 3. Release notes Sourced from actions/checkout's releases.

v3.0.0

• Updated to the node16 runtime by default

• This requires a minimum Actions Runner version of v2.285.0 to run, which is by default available in GHES 3.4 or later.

v2.6.0

What's Changed

• Add backports to v2 branch by `@​cory-miller` in actions/checkout#1040

• Includes backports from the following changes: actions/checkout#964, actions/checkout#1002, actions/checkout#1029

• Upgraded the licensed version to match what is used in v3.

Full Changelog: actions/checkout@v2.5.0...v2.6.0

v2.5.0

What's Changed

• Update

@​actions/core

to 1.10.0 by `@​rentziass` in actions/checkout#962

Full Changelog: actions/checkout@v2...v2.5.0

v2.4.2

What's Changed

• Add set-safe-directory input to allow customers to take control. (#770) by `@​TingluoHuang` in actions/checkout#776

• Prepare changelog for v2.4.2. by `@​TingluoHuang` in actions/checkout#778

Full Changelog: actions/checkout@v2...v2.4.2

v2.4.1

• Fixed an issue where checkout failed to run in container jobs due to the new git setting

safe.directory

v2.4.0

• Convert SSH URLs like

org-<ORG_ID>@github.com:

to

<https://github.com/>

- pr

v2.3.5

Update dependencies

v2.3.4

• Add missing `await`s

• Swap to Environment Files

v2.3.3

• Remove Unneeded commit information from build logs

• Add Licensed to verify third party dependencies

v2.3.2

Add Third Party License Information to Dist Files

v2.3.1

Fix default branch resolution for .wiki and when using SSH

... (truncated) Changelog Sourced from actions/checkout's changelog.

Changelog

v3.1.0

• Use `@​actions/core` `saveState` and `getState`

• Add `github-server-url` input

v3.0.2

• Add input `set-safe-directory`

v3.0.1

• Fixed an issue where checkout failed to run in container jobs due to the new git setting `safe.directory`

• Bumped various npm package versions

v3.0.0

• Update to node 16

v2.3.1

• Fix default branch resolution for .wiki and when using SSH

v2.3.0

• Fallback to the default branch

v2.2.0

• Fetch all history for all tags and branches when fetch-depth=0

v2.1.1

• Changes to support GHES (here and here)

v2.1.0

• Group output

• Changes to support GHES alpha release

• Persist core.sshCommand for submodules

• Add support ssh

• Convert submodule SSH URL to HTTPS, when not using SSH

• Add submodule support

• Follow proxy settings

• Fix ref for pr closed event when a pr is merged

• Fix issue checking detached when git less than 2.22

v2.0.0

• Do not pass cred on command line

• Add input persist-credentials

• Fallback to REST API to download repo

Commits • `ac59398` Fix comment typos (that got added in #770) (#1057) • `3ba5ee6` Add in explicit reference to private checkout options (#1050) • `8856415` Implement branch list using callbacks from exec function (#1045) • `755da8c` 3.2.0 (#1039) • `26d48e8` Update

@​actions/io

to 1.1.2 (#1029) • `bf08527` wrap pipeline commands for submoduleForeach in quotes (#964) • `5c3ccc2` Replace datadog/squid with ubuntu/squid Docker image (#1002) • <https://github.com/actions/checkout/commit/1f9a0c22da41e6ebfa534300ef65665… pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

#108 chore(deps): bump sqlite3 from 1.6.0 to 1.6.1 in /pact_broker Pull request opened by dependabot[bot] ⚠️ Dependabot is rebasing this PR ⚠️ Rebasing might not happen immediately, so don't worry if this takes some time. Note: if you make any changes to this PR yourself, they will take precedence over the rebase. * * * Bumps sqlite3 from 1.6.0 to 1.6.1. Release notes Sourced from sqlite3's releases.

1.6.1 / 2023-02-22

Dependencies

• Vendored sqlite is updated to v3.41.0.

* * *

sha256 checksums:

```

99d334b06d81edf5ab112c5025908d4228afa8031c19117ab21e9dd7752094cd sqlite3-1.6.1-aarch64-linux.gem

d286563c448269489b2be5655ac8330e522aa3e2c3088b612c1bc533ec2b6319 sqlite3-1.6.1-arm-linux.gem

a877b19ddabd30960e22aa79a0f4a4126f87f51df4be88050034e71293d7477a sqlite3-1.6.1-arm64-darwin.gem

46c262f07dae7057e817519f030cafbc2e837ee6f5730071bcd98129d5396acd sqlite3-1.6.1-x64-mingw-ucrt.gem

07f215047eec18473bbaab51a89252bea00263ab26fb7ad2766fb9c3ca69bb10 sqlite3-1.6.1-x64-mingw32.gem

ad395e8794a694140dad33aa7164968d05ed52b32cfaa579f645900c0839ef53 sqlite3-1.6.1-x86-linux.gem

074082d1fdda1f2e326b4860e2b12b35988823a31847e6b6c2d58dad0b37c1ce sqlite3-1.6.1-x86_64-darwin.gem

b36fee5821ed28b547327317a0ee63b0cb2191060dbfb1ea40d93d343dfc8f59 sqlite3-1.6.1-x86_64-linux.gem

54b8afa57e341d381b1cfcd8849aa826d87118abcd002a8159d9f4bdbf498f18 sqlite3-1.6.1.gem

```

Changelog Sourced from sqlite3's changelog.

1.6.1 / 2023-02-22

Dependencies

• Vendored sqlite is updated to v3.41.0.

Commits • `1b469ed` version bump to v1.6.1 • `0f329a0` Merge pull request #379 from sparklemotion/flavorjones-update-sqlite3-3.41.0 • `bca917d` dep: update libsqlite3 to 3.41.0 • `d18e05f` doc: add steps to CONTRIBUTING.md for upgrading libsqlite3 • `4534359` Merge pull request #380 from sparklemotion/flavorjones-2023-02-22-fix-macos-b... • `93e028c` ci: add ruby 3.2 to appveyor • `01f7d36` ci: run the suite weekly • `c705db2` dev: avoid warnings from

-Wold-style-definition

• `1c08973` ci: ensure pkg-config is installed on macos • `08dafd0` doc: document glibc requirements on linux platforms • See full diff in compare view Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

#109 chore(deps): bump ruby from 2.7.7-alpine3.16 to 3.2.1-alpine3.16 Pull request opened by dependabot[bot] Bumps ruby from 2.7.7-alpine3.16 to 3.2.1-alpine3.16. Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

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.

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

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?

If I remove the path prefix, the app works fine, but I want to use the same load balancer for all my internal services

#110 chore(deps): upgrade SuperCronic to ver 0.2.2 to fix Multiple CVE:s with severity level High due to use of SuperCronic 0.2.1 (that uses Go-lang version 1.18.3). #103 Pull request opened by jorander fix #103 SuperCronic has now upgraded the underlaying Go-lang version. pact-foundation/pact-broker-docker GitHub Actions: test ✅ 1 other check has passed 1/2 successful checks

#111 chore(deps): bump pg from 1.4.5 to 1.4.6 in /pact_broker Pull request opened by dependabot[bot] Bumps pg from 1.4.5 to 1.4.6. Changelog Sourced from pg's changelog.

v1.4.6 [2023-02-26] Lars Kanis lars@greiz-reinsdorf.de

• Add japanese README file. #502

• Improve

discard_results

to not block under memory pressure. #500

• Use a dedicated error class

PG::LostCopyState

for errors due to another query within

copy_data

and mention that it's probably due to another query. Previously the "no COPY in progress"

PG::Error

was less specific. #499

• Make sure an error in

put_copy_end

of

copy_data

doesn't lose the original exception.

• Disable nonblocking mode while large object calls. #498 Since pg-1.3.0 libpq's "lo_*" calls failed when a bigger amount of data was transferred. This specifically forced the

active_storage-postgresql

gem to use pg-1.2.3.

• Add rdoc options to gemspec, so that "gem install" generates complete offline documentation.

• Add binary Windows gems for Ruby 3.2.

• Update Windows fat binary gem to PostgreSQL-15.2 and OpenSSL-3.0.8.

Commits • `cae53b2` Bump VERSION to 1.4.6 • `6b26383` Add release notes for pg-1.4.6 • `cd249b8` Update postgresql and openssl versions for binary gems • `febe565` Use an item list for basic links in the README • `4c010e0` Fix link to rdoc page in japanese README • `0c8cc16` Use LANG=C for po4a so that the version text is language independent • `73733ac` Merge pull request #499 from larskanis/improve_copy_data • `8c91814` Merge pull request #502 from gemmaro/add/ja • `290ed40` Merge pull request #501 from larskanis/racy-tcp-gate • `10e5b12` Merge branch 'master' into racy-tcp-gate • Additional commits viewable in compare view Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

#112 chore(deps): bump peter-evans/repository-dispatch from 1 to 2 Pull request opened by dependabot[bot] Bumps peter-evans/repository-dispatch from 1 to 2. Release notes Sourced from peter-evans/repository-dispatch's releases.

Repository Dispatch v2.0.0

What's New

• Updated runtime to Node.js 16

• The action now requires a minimum version of v2.285.0 for the Actions Runner.

• If using GitHub Enterprise Server, the action requires GHES 3.4 or later.

What's Changed

• Remove workflow by `@​peter-evans` in peter-evans/repository-dispatch#95

• Update runtime to node 16 by `@​peter-evans` in peter-evans/repository-dispatch#106

• 15 dependency updates by `@​actions-bot` and `@​dependabot`

Full Changelog: peter-evans/repository-dispatch@v1.1.3...v2.0.0

Repository Dispatch v1.1.3

• Improved error message for 404 errors. These errors can also be a result of insufficient token permissions.

Repository Dispatch v1.1.2

• Dependency updates

Repository Dispatch v1.1.1

• Dependency updates

Repository Dispatch v1.1.0

• Converted action to Typescript

• Minor improvements

Repository Dispatch v1.0.1

• Dependency updates

Commits • `26b39ed` Update workflow • `b155cf1` Update readme • `faa2bf0` Update readme • `0bc97bd` Bump

@​types/node

from 16.11.11 to 18.11.11 (#134) • `8ab3ab8` Bump

@​vercel/ncc

from 0.32.0 to 0.36.0 (#133) • `defb7de` Bump eslint-plugin-github from 4.3.5 to 4.6.0 (#130) • `fb1da2a` Bump jest-circus from 27.4.2 to 29.3.1 (#132) • `ec896de` Bump prettier from 2.5.0 to 2.8.1 (#131) • `9255d35` Update workflow • `f8e700e` Add automerge workflow • Additional commits viewable in compare view Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

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.

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'

@Gazal Gafoor has left the channel

#113 chore(deps): bump ruby from 2.7.6-alpine3.16 to 2.7.7-alpine3.16 Pull request opened by dependabot[bot] Bumps ruby from 2.7.6-alpine3.16 to 2.7.7-alpine3.16. Dependabot compatibility score Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting

@dependabot rebase

. * * * Dependabot commands and options You can trigger Dependabot actions by commenting on this PR: •

@dependabot rebase

will rebase this PR •

@dependabot recreate

will recreate this PR, overwriting any edits that have been made to it •

@dependabot merge

will merge this PR after your CI passes on it •

@dependabot squash and merge

will squash and merge this PR after your CI passes on it •

@dependabot cancel merge

will cancel a previously requested merge and block automerging •

@dependabot reopen

will reopen this PR if it is closed •

@dependabot close

will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually •

@dependabot ignore this major version

will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this minor version

will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) •

@dependabot ignore this dependency

will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

#114 Fix next tag calculation for automated release Issue created by bethesque The automatic version calculation code is broken because docker hub no longer allows public API access. The code in

script/release/next-docker-tag.sh

needs to be updated to use the git tags instead. pact-foundation/pact-broker-docker

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?