Hi. This might not be pact specific but I wanted to ask in case anyone has experienced this before. My team and I added consumer driven contract testing with Pact as a pilot in two repos our team used to own approx 2 years ago. One repository, provider, is open-source. Whenever a new PR is created on provider, we run pact provider verification to ensure everything works. We have the pact access token in Github secret and that secret is used to connect to Pactflow to get contract and push verification results. Recently, the verification started to fail on some PRs while it passed on others. Upon closer inspection, it was observed that the CI was always failing when creating PR from fork. It turns out Github does not pass secrets for such PRs due to security reason (https://docs.github.com/en/actions/security-for-github-actions/security-guides/using-secrets-in-github-actions#using-secrets-in-a-workflow). There is an option of pull_request_target (https://docs.github.com/en/actions/writing-workflows/choosing-when-your-workflow-runs/events-that-trigger-workflows#pull_request_target) but it is recommended to not use it if one plans to checkout the code from HEAD. To summarize: We store the pact access token in Github secret and pass that to Github action. This works fine for PRs created directly on repository but not when created from fork as access token is not accessible in that GA run. Has anyone faced this particular challenge before? What was the solution you opted for?

Unfortunately, that's a difficult problem to solve. For security reasons, as you pointed out, GitHub does not propagate secrets from a main repository to its forks. Doing otherwise could lead people to easily exfiltrate your secrets. You also correctly identified that

pull_request_target

would get around that, but you can't really adjust it to "just" have access to one secret. So a blanket

pull_request_target

trigger is usually not an option, unless you add additional review safeguards. I highly recommend you read this GitHub blog on the topic: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/

Thanks. Yes, that is a challenging problem indeed.