0

I have the following code to do a repository dispatch to another repository:

jobs:
  trigger-repository-dispatch:
  runs-on: ubuntu-latest
  env:
    ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
    REPOSITORY: ${{ inputs.repository }}
  steps:
    - name: Checkout project
      uses: actions/checkout@v3
    - name: Trigger dependant common project repository dispatch
      run: |
        curl -X POST https://api.github.com/repos/${REPOSITORY}/dispatches \
        -H 'Accept: application/vnd.github.everest-preview+json' \
        -H "Authorization: Bearer ${ACCESS_TOKEN}" \
        --data '{"event_type": "success"}'

In the secrets.ACCESS_TOKEN its my PAT to authenticate with the otre repo.

This code works if I set the env.ACCESS_TOKEN variable with plain text but if I try to read it from secrets it returns this and of course doesn't trigger the destination workflow:

{
  "message": "Bad credentials",
  "documentation_url": "https://docs.github.com/rest"
}

Any ideas?

MrBlackV
  • 43
  • 7
  • 1
    See [Storing Base64 binary blobs as secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets#storing-base64-binary-blobs-as-secrets). – Azeem Mar 22 '23 at 15:51
  • 1
    Encode your secret as Base64 e.g. `base64 <<< "YOUR_KEY_HERE"` and then set it as a GHA secret and before using it decode it first e.g. `"Authorization: Bearer $(base64 -d <<< "$ACCESS_TOKEN" | tr -d '\n')"`. – Azeem Mar 22 '23 at 15:59
  • Thanks for your response @Azeem but I still receive the same Bad credentials message, I tried setting the env.ACCESS_TOKEN variable manually to the base64 encoded token and it worked, so my guess remains the same, that somehow I'm not receiving the correct value on secrets.ACCESS_TOKEN – MrBlackV Mar 23 '23 at 14:01
  • 1
    How did you set your secret? Steps? Did you try verifying it with `echo` before making the `curl` call? Did you try using [GitHub CLI](https://cli.github.com/) for this? – Azeem Mar 23 '23 at 15:30
  • 1
    See [`gh workflow run`](https://cli.github.com/manual/gh_workflow_run). – Azeem Mar 23 '23 at 15:31
  • 1
    Thank you for all @Azeem, I was about to tell you how I set my secret and how I couldn't use the CLI to run this because it has a workflow_call trigger and I had secrets: inherit in the caller, but then I realized that the caller workflow was triggered also as workflow_call but in that one I forgot to pass the secrets. My bad. – MrBlackV Mar 24 '23 at 07:39

1 Answers1

1

If the GHA workflow is triggered as workflow_call you must pass the secrets from the caller (or in my case, the caller hierarchy) as stated in Reusing Workflows: Using inputs and secrets in a reusable workflow.

MrBlackV
  • 43
  • 7