Fix for CI builds failing on pact tests for Dependabot #1188
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This removes the helper method and the suffix of "branch" from the pact rake task. This extra complication was needed when we had multiple rake tasks that would publish pacts however we only have one.
I've added this option as I want to enable the ability to upload pacts that have been previously generated and thus might not be in the regular pact directory. My expected use case for this is to create the Pacts, upload them to GitHub Actions as an artifact, then in a later job download them and publish them to the pact broker.
kevindew
added a commit
to alphagov/account-api
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/asset-manager
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/collections
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/email-alert-api
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/places-manager
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/link-checker-api
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/locations-api
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/whitehall
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
This was referenced Jan 31, 2023
kevindew
added a commit
to alphagov/publishing-api
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've also updated the name of the parameter "committish" to ref since, across GitHub Actions and GOV.UK usage of them, ref seems to be the more common convention. _Note: This commit message is a copy and paste across a number of repos_
kevindew
added a commit
to alphagov/frontend
that referenced
this pull request
Jan 31, 2023
This updates the pact-verify action so that it can accept from a GitHub Action as part of changes described in: alphagov/gds-api-adapters#1188 I made the pact file to be an input with a default as I noticed that across our suite of apps this filename can vary from something straight forward (gds_api_adapters-publishing_api.json) to something very nuanced (gds_api_adapters-bank_holidays_api.json). For these nuanced one an input seemed useful and I wanted to apply the same approach consistently. I've updated other aspects of this action to be more consistent with other pact-verify.yml files
This changes the approach for testing downstream apps against newly generated pact tests. We previously would upload the pact tests to the Pact Broker and then have the apps download these from the Pact broker to test against them. This changes that approach to instead use a GitHub Action Artifact [1] as a place to store these files for testing. The motivation for this change is because the Pact Broker method requires permission to view GitHub Action secrets, without this the task fail. We feel this pain most noticeably on pull requests opened by Dependabot. Applications that test against these pacts (consumers) will now operate in two ways depending on the circumstance. When changes are made to them or they are being locally tested they will pull the `branch-main` pacts from the pact-broker as per before. When they test against an iteration of GDS API Adpaters they will access the pacts from an artifact. --- This change separates the generate and publish pact steps into two, now only publishing the pacts when on the main branch. This will mean that eventually there is only branch-main on the pact-broker. All the downstream applications need changes to their pact-verify.yml action to accommodate this change, hence why they reference @pact-artifact branches. I didn't see their being value in keeping the artifact after testing so I set-up a means to delete it. This is a job that will only run if generate_pacts was a success and not until publish_pacts has been run or skipped. It will run even if publish_pacts was a failure. [1]: https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts
This application has a pact with GDS API Adapters and I missed it when migrating the pact tests to GitHub Actions [1]. [1]: #1175
brucebolt
force-pushed
the
pact-artifacts
branch
from
bdc2d95 to
88ceaaf
Compare
brucebolt
approved these changes
Feb 3, 2023
hannako
added a commit
that referenced
this pull request
May 7, 2024
In #1188 we set a restriction to only run rake:publish_pacts on builds of the main branch. This was not intentional.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've opened this PR as a draft as it needs the following branches to be merged first:
and then it needs to update the references to branches in .github/workflows/ci.yml.
This changes the approach for testing downstream apps against newly generated pact tests. We previously would upload the pact tests to the Pact Broker and then have the apps download these from the Pact broker to test against them. This changes that approach to instead use a GitHub Action Artifact 1 as a place to store these files for testing.
The motivation for this change is because the Pact Broker method requires permission to view GitHub Action secrets, without this the task fail. We feel this pain most noticeably on pull requests opened by Dependabot.
Applications that test against these pacts (consumers) will now operate in two ways depending on the circumstance. When changes are made to them or they are being locally tested they will pull the
branch-mainpacts from the pact-broker as per before. When they test against an iteration of GDS API Adapters they will access the pacts from an artifact.I've also caught an instance where we weren't previously performing pact tests against Frontend, I missed it in #1175.
Further info in the commits