Merge pull request pactflow#35 from B3nnyL/chore-update-link

Update README.md

README.md

@@ -43,7 +43,7 @@ To ensure that a verification is also run whenever a pact changes, we create a w
     * The target `create_or_update_contract_requiring_verification_published_webhook` creates the Pactflow webhook that will trigger a build of the provider when any of its consumers publishes a pact with changed content.
     * To call the Github API that triggers the build, the webhook uses a bearer token that is stored in a Pactflow secret called `${user.githubToken}`. The secret can be created using the `create_github_token_secret` target, or through the Pactflow UI.
 
-* In [src/product/product.pact.test.js](src/product/product.pact.test.js):
+* In [src/product/product.providerChange.pact.test.js](src/product/product.providerChange.pact.test.js):
   * When the `$PACT_URL` is not set (ie. the build is running because the provider changed), the provider is configured to fetch all the pacts for the 'example-provider' provider which belong to the latest consumer versions associated with their main branch and those currently deployed to an environment. This ensures the provider is compatible with the latest changes that the consumer has made, and is also backwards compatible with the production/test versions of the consumer.
   * When the `$PACT_URL` is set (ie. the build is running because it was triggered by the ['contract requiring verification published'](https://docs.pact.io/pact_broker/webhooks#the-contract-requiring-verification-published-event) webhook, we just verify the pact at the `$PACT_URL` against the head, test and production versions of the provider.
   * Pact-JS has a very flexible verification task configuration that allows us to use the same code for both the main pipeline verifications and the webhook-triggered verifications, with dynamically set options. Depending on your pact implementation, you may need to define separate tasks for each of these concerns.