#603 Support alternative contract types in /contracts/publish endpoint Issue created by mefellows The

contracts[].specification

property in the publish contracts endpoint currently only supports

pact

. In order to support an ecosystem of other contract testing tools - such as case - we should allow other contract types to be submitted. I'm not quite sure of the plans for this field and the validation requirements for it, so I can't comment just now if we should allow a user-defined value, a predefined list or just "other". Given it's a relatively minor change to add new contract types, adding support for the immediate use case of

case

might be a reasonable starting point to avoid relaxing any constraints. P.S. We should create a different GitHub issue template for features :) pact-foundation/pact_broker

Within the past few days we’ve started getting an SSL error hitting our pact broker API. (We used the dius/pact-broker). Am i correct in assuming that the problem is probably our client images upgrading OpenSSL such that they’re no longer compatible with the (presumably outdated) TLS version used by the dius/pact-broker?

Question about the create version tag functionality with the pact-broker cli. Our pipeline correctly tagged in our dev environment with no issues. We had a failing pipeline task in our CI/CD for create version tag stating that our version did not exist in the broker when deploying to both our preprod and prod. When I looked at the broker however, the tags had been successfully applied. Is there any retrying of assigning tags or does it try just once? The dev deploy and preprod/prod stages were a day apart so there werent any timing issues

Hi team, do you have any plans to make

can-i-deploy

work with

mainBranch

concept? something like

can-i-deploy -to-main-branch

Context: some of our projects use

master

as a default branch, and some

main

.

can-i-deploy -to master

fails for the latter, so we additionally tag contracts with

master

tag if their default branch is

main

. It looks hacky, and it might be an option on

can-i-deploy

instead.

Hey all, I'm hitting an issue running pact cli in github actions. Locally this all works fine, but in github I get:

...
latest: Pulling from pactfoundation/pact-cli

... (all looks fine)

Digest: sha256:2fea54e304c20faeae4febe8fa2fd9480b738b4783ea17bf892e542cfd6ba0fa
Status: Downloaded newer image for pactfoundation/pact-cli:latest
bundler: failed to load command: /pact/bin/pact (/pact/bin/pact)
/usr/lib/ruby/3.1.0/uri/rfc3986_parser.rb:67:in `split': bad URI(is not URI?): "\\"***\\"" (URI::InvalidURIError)

Does anyone have any ideas what might be going wrong there?

Hey all (using a different thread for this 2nd issue I'm having): trying to publish a provider spec with:

docker run --rm \
  -w ${PWD} \
  -v ${PWD}:${PWD} \
  -e PACT_BROKER_BASE_URL=$PACT_BROKER_BASE_URL \
  -e PACT_BROKER_TOKEN=$PACT_BROKER_TOKEN \
  pactfoundation/pact-cli:latest \
  pactflow publish-provider-contract \
  oas/openapi.yaml \
  --provider my-provider \
  --provider-app-version 1.0.0 \
  --branch my-branch \
  --content-type application/json \
  --verification-exit-code=0 \
  --verification-results result/report.md \
  --verification-results-content-type application/yaml \
  --verifier "github-actions"

...but I'm constantly getting

Error making request to <https://okta-poc.pactflow.io//contracts/provider/pact-demo-api1/version/1.0.0> status=404 {"error":"The requested document was not found on this server."}

As far as I can see I've set everything up correctly (those variables are correct and the oas / results files are at those paths). I'm a bit stumped, any ideas?

Hi 🙂 is there a way to: 1. Remove a webhook via CLI? 2. List all webhooks via CLI? 3. Edit webhooks via UI? Thanks!

Hi All. I have this pactPublish command specified on my jenkinsfile: "./gradlew -Pversion='${buildVersion}' -Duser.home=${script.env.HOME} pactPublish -PpactBrokerBranch='${script.env.BRANCH_NAME}'". The pact is published on the pact broker but it does not show the "Branch" info on the matrix. Could anyone please let me know what went wrong? We use pact gradle plugin. Thanks.

Hi there, I found in this thread that the

dius/pact-broker

image is going to be deprecated. Is that still the case? There are some benefits that I would benefit from. Thanks 🙂

If you want to run the container as a standalone instance, then the dius/pact-broker image which uses Phusion Passenger may serve you better, as Passenger will restart any crashed processes.

#605 docs(publish-contracts): Correct example response field 'level' -> 'type' Pull request opened by TimothyJones While working on a broker client, I noticed the response documentation was partially incorrect - the broker returns

"type"

not

"level"

to indicate the notice type. This PR corrects that. While we're on the subject, what are the notice levels

"prompt"

and

"danger"

for? I wasn't sure how to handle those, so I just mapped them to

info

and

error

. pact-foundation/pact_broker ✅ All checks have passed 9/9 successful checks

Question about this documentation

"verificationResults": [
    {
      "key": "the key from the pacts for verification response",

^ What’s the key here? I don’t have anything called

key

in my pacts for verification response. Is it the pact-version hash?

Hi 🙂 We have Pact integrated with some of our applications, and also with our CI/CD pipelines using the Pact Broker. And we are quite happy about it. But we are gonna migrate our CI and CD systems from Travis & Spinnaker to GitHub Actions. That means that we need to create another Webhook to trigger the needed provider builds using the

contract_requiring_verification_published

. Once we have done this, both Webhooks will be triggered by any contract change, resulting in requests to both CI systems. During the migration process, we expect that every repository is either using one CI system or the other mainly, and not using both other than for initial migration tests. Taking that into account, that would made the Webhook execution information shown in the Borker UI not ideal, because it will probably stay as "Retrying" some time, and then shown as "Failed" because it will not be able to trigger one od the CI's executions. Do you know if there is a way to get a "smother" migration, and hence not get that feedback from the UI? I mean seeing Webhook executions failed because it will try to trigger both Webhooks, and we expect one to always fail.

#121 chore(deps): bump sqlite3 from 1.6.1 to 1.6.2 in /pact_broker Pull request opened by dependabot[bot] Bumps sqlite3 from 1.6.1 to 1.6.2. Release notes Sourced from sqlite3's releases.

1.6.2 / 2023-03-27

Dependencies

Vendored sqlite is updated from v3.41.0 to v3.41.2.

Packaging

• Allow compilation against system libraries without the presence of

mini_portile2

, primarily for the convenience of linux distro repackagers. #381 (Thank you, `@​voxik`!)

Changelog Sourced from sqlite3's changelog.

1.6.2 / 2023-03-27

Dependencies

Vendored sqlite is updated from v3.41.0 to v3.41.2.

Packaging

• Allow compilation against system libraries without the presence of

mini_portile2

, primarily for the convenience of linux distro repackagers. #381 (Thank you, `@​voxik`!)

Commits • `69c9fa7` version bump to v1.6.2 • `866795a` Merge pull request #385 from sparklemotion/flavorjones-update-sqlite3-3.41.2 • `4c369b6` dep: update libsqlite3 to 3.41.2 • `0643ead` update CHANGELOG • `013f90f` Merge pull request #381 from voxik/optional_miniportile • `ff5f574` test: system libs can be compiled against without mini_portile2 • `193c5e0` Load 'mini_portile2' only when needed. • 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

#122 chore(deps): bump ruby from 2.7.7-alpine3.16 to 2.7.8-alpine3.16 Pull request opened by dependabot[bot] Bumps ruby from 2.7.7-alpine3.16 to 2.7.8-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 ✅ All checks have passed 5/5 successful checks

Hi all, just had a question around how to delete/modify webhooks that I've created in the Pact Broker? I can't find anything in the documentation about how to edit them, and when I try to delete a webhook using DELETE .../webhook/{uuid}, I just get a 405 NOT ALLOWED returned. Does anyone know how to do this/point me to the right place?

#124 [Snyk] Security upgrade pact_broker from 2.106.0 to 2.106.0 Pull request opened by mefellows This PR was automatically created by Snyk using the credentials of a real user. Snyk has created this PR to fix one or more vulnerable packages in the

rubygems

dependencies of this project. Changes included in this PR • Changes to the following files to upgrade the vulnerable dependencies to a fixed version: • pact_broker/Gemfile.lock Vulnerabilities that will be fixed With an upgrade: (*) Note that the real score may have changed since the PR was raised. Check the changes in this PR to ensure they won't cause issues with your project. * * * Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open fix PRs. For more information: https://camo.githubusercontent.com/1965c1ae6c35174e8d4b3c118ab60ad330b1a514f5face35bda2ed428e1df590/68747470733a2f2f6170692e7365676d656e742e696f2f76312f706978656c2f747261636b3f646174613d65794a33636d6c305a55746c65534936496e4a79576d785a634564485932527954485a7362306c596430645563566734576b4652546e4e434f5545774969776959573576626e6c746233567a535751694f694a6c4d32526b4d5445775a4331684e5756684c54526c5a6a5174596d4d33597931684d4441794d7a413159545a6a59544d694c434a6c646d567564434936496c425349485a705a58646c5a434973496e42796233426c636e52705a584d694f6e736963484a4a5a434936496d557a5a4751784d54426b4c5745315a5745744e47566d4e433169597a646a4c5745774d44497a4d4456684e6d4e684d794a3966513d3d 🧐 View latest project report 🛠️ Adjust project settings 📚 Read more about Snyk's upgrade and patch logic * * * Learn how to fix vulnerabilities with free interactive lessons: 🦉 Learn about vulnerability in an interactive lesson of Snyk Learn. pact-foundation/pact-broker-docker ✅ All checks have passed 3/3 successful checks

#123 Multi manifest build - arm64/arm (new) + amd64 (current) Pull request opened by YOU54F closes #30 create and publish arm64 + arm versions of pact cli and pact broker docker images for use in raspberry Pi's / mac m1/2 etc. currently publishing to personal docker hub acc for testing • https://hub.docker.com/r/you54f/pact-broker Related • pact-foundation/pact-ruby-cli#51 • https://hub.docker.com/r/you54f/pact-cli • pact-foundation/pact-ruby-cli#98 Have spun up the images briefly but would warrant some decent testing Have spun up the images briefly on an m1 pro macbook but would warrant some decent testing - I have several pi's (3b+ and 4) so will give them a whirl Fancy giving it a test, try

docker pull you54f/pact-broker

and let us know how you get on it the thread. Testing I have tested now across 32 bit rasp pi / arm64 macos + plus various arm64 linux vm's. Only one issue found so far, has been

nokogiri

gem failing to load, under alpine for arm, easily reproducible by clicking on the example api and it blew up when viewing the network graph. Turns out we needed the

gcompat

library adding. sparklemotion/nokogiri#2414 (comment) pact-foundation/pact-broker-docker ✅ All checks have passed 3/3 successful checks

Hi, I'm just about to update the Postgres dependency version for the Pact Broker Helm Chart to version 15 of Postgres, but I just wanted to double check if the Pact Broker is compatible with version 15 of Postgres before I did the change.

Hello again. I'm seeing an issue on my end when I run can-i-deploy. It seems that the answer is always no. My consumer has already published its pacts to the branch and the pact tests themselves are passing on both the consumer and the provider, but my output looks similar to the following:

Computer says no ¯\_(ツ)_/¯

CONSUMER                | C.VERSION  | PROVIDER                 | P.VERSION | SUCCESS? | RESULT#
------------------------|------------|--------------------------|-----------|----------|--------
foo-consumer            | git-hash.. | bar-provider             | ???       | ???      |        

WARN: It is recommended to specify the environment into which you are deploying. Without the environment, this result will not be reliable.
There is no verified pact between the latest version of foo-consumer (git-hash) and version git-hash of bar-provider

Hello! I'm trying to setup pact broker in a development environment. I would like for the end users to be able to access the UI via a reverse proxy, and have the publication/verification instructions from services execute internal to the reverse proxy. I've noticed that the initial publication request by a service (PactBroker:Client:PublicationTask) uses the locally defined pact_broker_base_url initially, but it is eventually replaced by the base_url defined in the Pact Broker configuration. I've poked around and this definitely appears to be the desired behavior. This is presenting a problem. The publication task needs to use the internal URL to publish, but the UI needs to use the external URL provided by the reverse proxy. And it seems as though either the UI js will break (see attached), or the publication task will break. Now, if we mount pact-broker to the root path of the service, and remove the base_url variable from the pact-broker configuration, then everything works! However, this isn't a good option for a variety of reasons (Authentication/other desired routing). If/when we get this running in CI, this probably won't be an issue as both the UI and publication requests will both originate from outside of the reverse proxy. But for development work this is pretty annoying. If we are defining the publication URL in each service, why would this get overridden by a configuration in the broker? Thanks! cc @Andy Jenness

#125 chore(deps): bump nokogiri from 1.14.2 to 1.14.3 in /pact_broker Pull request opened by dependabot[bot] Bumps nokogiri from 1.14.2 to 1.14.3. Release notes Sourced from nokogiri's releases.

1.14.3 / 2023-04-11

Security

• [CRuby] Vendored libxml2 is updated to address CVE-2023-29469, CVE-2023-28484, and one other security-related issue. See GHSA-pxvg-2qj5-37jqGHSA-pxvg-2qj5-37jq for more information.

Dependencies

• [CRuby] Vendored libxml2 is updated to v2.10.4 from v2.10.3.

* * *

sha256 checksums:

```

9cc53dd8d92868a0f5bcee44396357a19f95e32d8b9754092622a25bc954c60c nokogiri-1.14.3-aarch64-linux.gem

320fa1836b8e59e86a804baee534893bcf3b901cc255bbec6d87f3dd3e431610 nokogiri-1.14.3-arm-linux.gem

67dd4ac33a8cf0967c521fa57e5a5422db39da8a9d131aaa2cd53deaa12be4cd nokogiri-1.14.3-arm64-darwin.gem

13969ec7f41d9cff46fc7707224c55490a519feef7cfea727c6945c5b444caa2 nokogiri-1.14.3-java.gem

9885085249303461ee08f9a9b161d0a570391b8f5be0316b3ac5a6d9a947e1e2 nokogiri-1.14.3-x64-mingw-ucrt.gem

997943d7582a23ad6e7a0abe081d0d40d2c1319a6b2749f9b30fd18037f0c38a nokogiri-1.14.3-x64-mingw32.gem

58c30b763aebd62dc4222385509d7f83ac398ee520490fadc4b6d7877e29895a nokogiri-1.14.3-x86-linux.gem

e1d58a5c56c34aab71b00901a969e19bf9f7322ee459b4e9380f433213887c04 nokogiri-1.14.3-x86-mingw32.gem

f0a1ed1460a91fd2daf558357f4c0ceac6d994899da1bf98431aeda301e4dc74 nokogiri-1.14.3-x86_64-darwin.gem

e323a7c654ef846e64582fb6e26f6fed869a96753f8e048ff723e74d8005cb11 nokogiri-1.14.3-x86_64-linux.gem

3b1cee0eb8879e9e25b6dd431be597ca68f20283b0d4f4ca986521fad107dc3a nokogiri-1.14.3.gem

```

Changelog Sourced from nokogiri's changelog.

1.14.3 / 2023-04-11

Security

• [CRuby] Vendored libxml2 is updated to address CVE-2023-29469, CVE-2023-28484, and one other security-related issue. See GHSA-pxvg-2qj5-37jqGHSA-pxvg-2qj5-37jq for more information.

Dependencies

• [CRuby] Vendored libxml2 is updated to v2.10.4 from v2.10.3.

Commits • `e8d2f4a` version bump to v1.14.3 • `59fbc7b` doc: update CHANGELOG for v1.14.3 • `347eacb` Merge pull request #2852 from sparklemotion/flavorjones-libxml2-2.10.4-backport • `36b0b33` dep: update libxml2 to 2.10.4 from 2.10.3 • `ac83e6e` test: update behavior of namespaces in HTML4 • `2cf4996` test: make default GC behavior "normal" • 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) You can disable automated security fix PRs for this repo from the Security Alerts page. pact-foundation/pact-broker-docker GitHub Actions: test GitHub Actions: test ✅ 1 other check has passed 1/3 successful checks

#126 Error database connection since version 2.87.0.1 Issue created by RyanCDS 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: eg 2.107.0 • pact-broker docker version: eg 2.107.0.1 • OS: Kubernetes environment with containerd • pact broker client details: NA Expected behaviour The pact broker should start correctly Actual behaviour I got an error during kubernetes deployment. For information, i did some test with different version and the changeset who broke the deployment appears with version 2.87.0.1 The logs below come from version 2.107.0.1 (it's similar issue with version 2.87.0.1).

I [7:3120] pact-broker -- Connecting to database: -- {:adapter=>"postgres", :user=>"pact_broker", :password=>"*****", :host=>"<http://ad06pg-pactbroker.cnx.cdbdx.biz|ad06pg-pactbroker.cnx.cdbdx.biz>", :database=>"pact_broker", :encoding=>"utf8", :sslmode=>"require", :sql_log_level=>:debug, :enable_caller_logging=>false, :log_warn_duration=>5.0, :pool_timeout=>5, :driver_options=>{:options=>"-c statement_timeout=15s"}, :connect_max_retries=>5}
I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 5 tries to go.
I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 4 tries to go.
I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 3 tries to go.
I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 2 tries to go.
I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 1 tries to go.
! Unable to load application: Sequel::DatabaseConnectionError: PG::ConnectionBad: connection to server at "10.10.241.33", port 5432 failed: ERROR:  Unsupported startup parameter: options

Steps to reproduce Deploy image docker v 2.107.0.1 with config below (for information, i use postgre in version 11) :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: pact-broker
  namespace: pact-broker
  labels:
    app: pact-broker
spec:
  replicas: 1
  selector:
    matchLabels:
      app: pact-broker
  template:
    metadata:
      labels:
        app: pact-broker
    spec:
      containers:
      - name: pact-broker
        image: 2.107.0.1
        resources:
          limits:
              cpu: "1"
              memory: 2048
        livenessProbe:
          httpGet:
            path: /hal-browser/browser.html
        readinessProbe:
          httpGet:
            path: /hal-browser/browser.html
        volumeMounts:
          - name: configmap
            mountPath: /run/dotnet/config
          - name: secrets
            mountPath: /run/dotnet/secrets
        envs: >-
            "PLATFORM": "$(platform)",
            "PERIMETER":"$(namespace)",
            "PACT_BROKER_PORT": "9292",
            "PACT_BROKER_DATABASE_URL":"<postgres://user:password@host/name>",
            "PACT_BROKER_DATABASE_CONNECT_MAX_RETRIES": "5",
            "PACT_BROKER_DATABASE_SSLMODE": "require",
            "PACT_BROKER_PUBLIC_HEARTBEAT": "true",
            "PACT_BROKER_LOG_LEVEL": "DEBUG",
            "PACT_BROKER_SQL_LOG_LEVEL": "DEBUG"
  service:
    ports: '[9292]'
  secretFilename: 'secret.yml'

Relevent log files Here the log file from Kubernetes during deployment ``` Puma starting in single mode... * Puma version: 5.6.5 (ruby 2.7.7-p221) ("Birdie's Version") * Min threads: 0 * Max threads: 5 * Environment: production * PID: 7 2023-04-13 093747.111467 I [7:3120] pact-broker -- Connecting to database: -- {:adapter=>"postgres", :user=>"user", :password=>"*****", :host=>"host", :database=>"name", :encoding=>"utf8", :sslmode=>"require", sql log level=&gt;debug, :enable_caller_logging=>false, :log_warn_duration=>5.0, :pool_timeout=>5, driver options=&gt;{options=>"-c statement_timeout=15s"}, :connect_max_retries=>5} 2023-04-13 093747.218007 I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 5 tries to go. 2023-04-13 093750.266645 I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 4 tries to go. 2023-04-13 093753.316706 I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 3 tries to go. 2023-04-13 093756.364629 I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 2 tries to go. 2023-04-13 093759.412661 I [7:3120] pact-broker -- Error connecting to database (Sequel::DatabaseConnectionError). Waiting 3 seconds and trying again. 1 tries to go. ! Unable to load application: Sequel:DatabaseConnectionError PG:ConnectionBad connection to server at "20.20.20.42", port 5432 failed: ERROR: Unsupported startup parameter: options bundler: failed to load command: puma (/pact_broker/vendor/bundle/ruby/2.7.0/bin/puma) /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.4.6/lib/pg/connection.rb633in `async_connect_or_reset': PG:ConnectionBad connection to server at "20.20.20.42", port 5432 failed: ERROR: Unsupported startup parameter: options (Sequel::DatabaseConnectionError) from /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.4.6/lib/pg/connection.rb761in `connect_to_hosts' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/pg-1.4.6/lib/pg/connection.rb696in `new' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/adapters/postgres.rb231in `connect' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/database/connecting.rb248in `new_connection' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/connection_pool.rb154in `make_new' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/connection_pool/threaded.rb209in `assign_connection' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/connection_pool/threaded.rb139in `acquire' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/connection_pool/threaded.rb91in `hold' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/database/connecting.rb293in `synchronize' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/database/connecting.rb302in `test_connection' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/database/misc.rb188in `initialize' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/database/connecting.rb57in `new' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/database/connecting.rb57in `connect' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/sequel-5.66.0/lib/sequel/core.rb124in `connect' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.106.0/lib/pact_broker/initializers/database_connection.rb17in `block in create_database_connection' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/pact_broker-2.106.0/lib/pact_broker/initializers/database_connection.rb31in `with_retries' from /pact_broker/vendor/bundle/ruby/2.7.0/gems/pa… pact-foundation/pact-broker-docker

#606 chore: Remove dead code that is triggering security warnings Pull request opened by vwong CVE-2020-25613 is being triggered by this obsoleted spec. Since the spec has been disabled since 2021, let's just remove it. pact-foundation/pact_broker GitHub Actions: rubocop ✅ 8 other checks have passed 8/9 successful checks

I am having issues setting up pact broker with aws ecs with the pact-foundation/pact-broker docker image I have a load balancer with https listener that forwards to my TargetGroup that points to my ecs service container at port 9292

TargetGroup:
    Type: AWS::ElasticLoadBalancingV2::TargetGroup
    Properties:
      Name: pact-target-group
      Port: ${param:brokerPort}
      Protocol: HTTP
      VpcId: ${param:VpcId}
      TargetType: ip
      HealthCheckIntervalSeconds: 60
      HealthCheckPath: /diagnostic/status/heartbeat
      HealthCheckTimeoutSeconds: 30
      HealthyThresholdCount: 3
      UnhealthyThresholdCount: 2
  Listener:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref LoadBalancer
      Port: 443
      Certificates:
        - CertificateArn: ${cf(ap-southeast-2):scale-certificates.MultiRegionDomainCertificate, ''}
      Protocol: HTTPS
      SslPolicy: ELBSecurityPolicy-TLS13-1-2-2021-06
      DefaultActions:
        - Type: forward
          TargetGroupArn: !Ref TargetGroup
  ListenerHttp:
    Type: AWS::ElasticLoadBalancingV2::Listener
    Properties:
      LoadBalancerArn: !Ref LoadBalancer
      Port: 80
      Protocol: HTTP
      DefaultActions:
        - Type: 'redirect'
          RedirectConfig:
            Protocol: 'HTTPS'
            Port: 443
            Host: '#{host}'
            Path: '/#{path}'
            Query: '#{query}'
            StatusCode: 'HTTP_301'

but im currently having issues where the ecs container is returning my health checks as status 503 can someone help?

hey folks👋 I am trying to create webhook using pact_broker-client gem (our pact broker is pactflow broker). I keep getting this error even though I use the same credentials I use in the frontend to create webhook successfully

Error creating webhook. response status=403 body=Forbidden. Either you are using a read only token for a request that requires a write token (the most likely cause), or you do not have the required permissions.

this is command I am executing. Any idea why the error? thankyou

pact-broker create-webhook <https://api.buildkite.com/v2/organizations/><org-name>/pipelines/<slug>/builds \
  --header "Authorization: Bearer <token>" \
  --request POST \
  --consumer <consumer> \
  --provider <provider> \
  --broker-base-url <pactflow-url> \
  --broker-token <admin user's token> \
  --data '{
    "branch": "branch",
    "commit": "HEAD",
    "message": "sample Consumer -> sample Provider",
    "env": {
      "PACT_URL": "${pactbroker.pactUrl}",
    }
  }' \
  --contract-content-changed \
  --team-uuid <uuid>

Hi, I wonder if I can have some clarity on what I am seeing? In my CI/CD (CircleCI) pipeline I call

pact-broker record-deployment --environment "main" --pacticipant "service" --version "74332f5"

and I get the output

Recorded deployment of service version 74332f5 to main environment in the Pact Broker

. I then call the command

pact-broker create-version-tag --pacticipant "service" --version "74332f5" --tag "main"

. This is so that we support the legacy implementation of using tags and then have a history of environments to migrate over to in the future. The problem I am seeing is that whenever I call both of these commands, the contract has a tag of main but not an environment against it. If I just call

create-version-tag

then both an environment and tag are added to the contract but I’m not sure why. Even weirder still I use this same combination of record deployment and create version tag in downstream jobs and they tag and set environment with no problem

#127 chore(dev-ex): remove docker login step from test run Pull request opened by YOU54F PR builds from contributors fail because they don't have access to secrets to login to the docker repository. Not sure why this step is needed, as we test from the image built in the CI run, and don't push it as part of this job. Maybe its due to docker licensing restrictions? 🤷🏾‍♂️ It also stops dependency update builds from running the test step, which causes more headache for maintainers, example PR actions run https://github.com/pact-foundation/pact-broker-docker/actions/runs/4675302277/jobs/8280283767#step:6:9 pact-foundation/pact-broker-docker ✅ All checks have passed 2/2 successful checks

#128 ci(dev-ex): run trivy audit as cron job so no release surpises Pull request opened by YOU54F Run the trivy audit as a cron job, so that we get alerted to issues, rather than only being run at release time Current error when running trivy against a built image https://github.com/YOU54F/pact-broker-docker/actions/runs/4735726395/jobs/8406325952

aquasecurity/trivy info checking GitHub for latest tag
aquasecurity/trivy info found version: 0.40.0 for v0.40.0/Linux/64bit
aquasecurity/trivy info installed /usr/local/bin/trivy
2023-04-18T18:28:08.143Z	INFO	Need to update DB
2023-04-18T18:28:08.143Z	INFO	DB Repository: <http://ghcr.io/aquasecurity/trivy-db|ghcr.io/aquasecurity/trivy-db>
2023-04-18T18:28:08.143Z	INFO	Downloading DB...
2023-04-18T18:28:10.786Z	INFO	Vulnerability scanning is enabled
2023-04-18T18:28:10.786Z	INFO	Secret scanning is enabled
2023-04-18T18:28:10.786Z	INFO	If your scanning is slow, please try '--scanners vuln' to disable secret scanning
2023-04-18T18:28:10.786Z	INFO	Please see also <https://aquasecurity.github.io/trivy/v0.40/docs/secret/scanning/#recommendation> for faster secret detection
2023-04-18T18:28:14.782Z	INFO	Detected OS: alpine
2023-04-18T18:28:14.783Z	INFO	Detecting Alpine vulnerabilities...
2023-04-18T18:28:14.803Z	INFO	Number of language-specific files: 1
2023-04-18T18:28:14.809Z	INFO	Detecting bundler vulnerabilities...

d87bbcb8b521 (alpine 3.16.5)
============================
Total: 0 (UNKNOWN: 0, LOW: 0, MEDIUM: 0, HIGH: 0, CRITICAL: 0)


pact_broker/Gemfile.lock (bundler)
==================================
Total: 1 (UNKNOWN: 0, LOW: 0, MEDIUM: 1, HIGH: 0, CRITICAL: 0)

┌──────────┬─────────────────────┬──────────┬───────────────────┬───────────────┬─────────────────────────────────────────────────────────────┐
│ Library  │    Vulnerability    │ Severity │ Installed Version │ Fixed Version │                            Title                            │
├──────────┼─────────────────────┼──────────┼───────────────────┼───────────────┼─────────────────────────────────────────────────────────────┤
│ nokogiri │ GHSA-pxvg-2qj5-37jq │ MEDIUM   │ 1.14.2            │ >= 1.14.3     │ Update packaged libxml2 to v2.10.4 to resolve multiple CVEs │
│          │                     │          │                   │               │ <https://github.com/advisories/GHSA-pxvg-2qj5-37jq>           │

pact-foundation/pact-broker-docker ✅ All checks have passed 2/2 successful checks

#129 chores(deps): Trivy audit fixes Pull request opened by YOU54F Updates the docker packager and bundle bases to match the bundler version used in the

./pact_broker/Gemfile.lock

Updates bundle, confirmed test run to show no audit advisories Failing run pre fix https://github.com/YOU54F/pact-broker-docker/actions/runs/4735726395/jobs/8406325952 Passing run post fix https://github.com/YOU54F/pact-broker-docker/actions/runs/4735824205/jobs/8406546081#step:6:79 pact-foundation/pact-broker-docker ✅ All checks have passed 2/2 successful checks

#130 ci(audit): Trivy audit fixes multi arch Pull request opened by YOU54F In preparation for #123 - it would be nice to audit across multiple arches for if we officially ship multi arch images pact-foundation/pact-broker-docker ✅ All checks have passed 2/2 successful checks