Pact with empty interaction array will successfully pass judge-dredd validation. It is very difficult to realize that such situation happened and might lead to false negative and in consequence to deployment of API with breaking change.

Judge-d-js should exit with an error when there are no interactions in pact file.

🚨 The automated release from the main branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the main branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

• Usage documentation
• Frequently Asked Questions
• Support channels

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.

No npm token specified.

An npm token must be created and set in the NPM_TOKEN environment variable on your CI environment.

Please make sure to create an npm token and to set it in the NPM_TOKEN environment variable on your CI environment. The token must allow to publish to the registry https://registry.npmjs.org/.

Good luck with your project ✨

Your semantic-release bot 📦🚀

Right now judge-d-js handles publishing and verifying pacts for consumer only. To make its functionality complete within judge-dredd ecosystem it needs to handle publishing swagger files generated by provider.

Problem: if package B is a dependency of application A, and package B makes a request to a external API service, then we want this interaction to be included in contracts of application A.

Solution proposal:

package B declares contracts for its interactions:

1. pact file is generated during build process, without consumer field
2. reference to this pact files is defined via new pacts field in package.json
3. generated pact file in included in the tarball published to the npm registry (for example using files property)

Example:

// package.json
{
  "name": "package-b",
  "pacts": ["dist/user-settings-pacts.json"],
  "files": ["dist"]
}

application A declares "package B" at its dependency:

// package.json
{
  "name": "application-a",
  "dependencies": {
    "package-b": "1.0.0"
  }
}

judge-d-js command when executed in application A root directory with new --include-dependencies-pacts flag
1. look at application A dependencies list from package.json
2. read each dependency package.json files and check if it contains pacts field
3. if it does, then read those pacts, set consumer field to the one passed as serviceName, a publish with the rest of the contracts

judge-d publish --serviceName application-a --serviceVersion 2.0.0 --include-dependencies-pacts  --pactsDir some/path --url https://example.com

Potential drawback

• Application A will always publish contracts for all interactions implemented in package B, even if only a subset of functionality and interactions of package B is imported in the application