Hi pactflow team, i'm currently having trouble imp...
# pactflow
n
Hi pactflow team, i'm currently having trouble implementing the webhookless approach to pactflow. In this query i'll try and provide as much information and files as possible. I've attached both the github workflow files as well as the consumer and provider tests. Right now I am facing a few problems. The first is the one I mentioned right in the above post ^. The second is that if the test fails on the consumer PR then it blocks the provider, now I know that this is covered in the docs via pending pacts. I tried using the pending as well as WIP features to solve this but clearly I think something is wrong with my flow. I feel that i'm close but might just be missing a few small pieces here and there. Please let me know if you would like me to provide any more information.
m
What error is the provider build seeing?
n
Well it is seeing the same error that the consumer build gets. So for example if the consumer asks for a first name and in their PR the provider runs and fails because the master version of the provider does not have a first name field for that particular api then on the provider side if I run the test on the PR they also fail. So I think im doing something wrong here in the sense that the new or updated consumer expectation in their own PR is stopping the provider.
y
https://docs.pact.io/pact_broker/advanced_topics/pending_pacts you don't have enablePending set to true, so you are seeing expected behaviour
Copy code
PactProviderModule.register({
            ...
          publishVerificationResult: true,
          enablePending: true,
        }) as any as Type<unknown>,
in
providerTest-guest-users.pact.test.ts
you also have no consumer version selectors in this build (which would be triggered when the provider codebase changes?), so I assume it is just grabbing the latest pact on your branch to verify, you should have some https://docs.pact.io/pact_broker/advanced_topics/consumer_version_selectors You would have another build that would be triggered by the URL of a changed pact, normally done by webhooks, but I believe you want to checkout your providers codebase and use a webhookless flow? If you could draw out a picture of what you are trying to attempt, I'll run through the workflows tomorrow
had a look at the files, and pretty sure I've sussed out your issues Running the provider verification task in your consumer build
Copy code
Verify:
    needs: Test
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    strategy:
      fail-fast: true
    env:
      pact_broker: example
      pact_broker_token: exmaple
      PACT_BROKER_PUBLISH_VERIFICATION_RESULTS: true
      version: ${{ github.sha }}
      GITHUB_REF: ${{ github.ref }}
      GIT_COMMIT: ${{ github.sha }}
      application_name: 'platform_payment_service'

    steps:
    # checking out the provider so that we can run their pact tests on the consumer side
      - uses: actions/checkout@v3
        with:
          repository: 'applyboard/platform_payment_service'

    #  some steps in the middle that i removed as they are confidential but essentially just setting up the provider test database and authentication etc.
      - name: run pact Test and publish results
        run: npm run pact:test
the following values are from your consumer build and shouldn't be used by your provider, and in-fact aren't picked up by your provider build which uses these two
Copy code
const commitHash = execSync('git rev-parse HEAD')
.toString().trim()

const branch_name = execSync('git rev-parse --abbrev-ref HEAD')
    .toString().trim()
the type of provider build you are running, should normally be run in the providers pipeline when the provider build changes, it should have 1. consumer version selectors 2. enablePending true 3. includeWIPPacts it would then pick up your pacts, and not fail the build There is an additional type of provider verification that can be run, based on a changed pact URL, this URL, is output when your consumer contract is uploaded, and dependant on the event (pact content changed or contract requiring verification published), you could then verify just that Pact. this provider verification build would only need the the pact url, over the above options.