From 123aec7a86b521781393d491a4fe2fc9151c7d24 Mon Sep 17 00:00:00 2001 From: Keith Lawrence Date: Mon, 13 May 2024 16:48:13 +0100 Subject: [PATCH] Add note about pact tests --- source/manual/pact-testing.html.md | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/source/manual/pact-testing.html.md b/source/manual/pact-testing.html.md index 86b90d1befe..93757d4f8de 100644 --- a/source/manual/pact-testing.html.md +++ b/source/manual/pact-testing.html.md @@ -109,3 +109,14 @@ different applications. When an application calls an API directly, not via GDS API Adapters, this application will be the consumer. For example, Publishing API is the consumer in the pact tests between it and Content Store, since it makes [direct calls to Content store](https://github.com/alphagov/publishing-api/blob/main/app/adapters/content_store.rb). + +## How GDS API Adapters retrieves tests from the Providers + +Each provider defines some details of its tests in the `.github/workflows/pact-verify.yml` file. This workflow is used by both +the provider and the consumer (gds-api-adapters), and behaves differently based on the value of the pact_artifact input. If +the pact_artifact variable is missing (run from the provider), the artifact is retrieved from Github. If the pact_artifact variable +is present (run from the consumer), the artifact will be retrieved from the pact broker - in which case the value of the +pact_artifact_file_to_verify input is important. This can be a source of confusion - we're retrieving the artifact from two +different places, and using autogenerated names in one case and explicitly set names in the other case. You should be careful +that the names in the pact_helper.rb files in both the provider and consumer match, and that the value of pact_artifact_file_to_verify +is "gds_api_adapters-.json", where the provider_id is the name from the pact_helper file in snake case.