Error in docs or misunderstanding for workflow_dispatch event

On the document for “create a workflow dispatch event”, it says the ref parameter “can be a branch, tag or a commit SHA”. However, when I try the following curl command, it errors out.

curl \                                                                                                                                              Ruby 2.4.1
  -u mrcoder:9b6a0cdf00b17809957ebcb8061a74c565f036fa \
  -X POST \
  -H "Accept: application/vnd.github.v3+json" \ \
  -d '{"ref":"60ef7d59930c49be20ef342783abb84d55817673"}'
# !Error output
  "message": "No ref found for: 60ef7d59930c49be20ef342783abb84d55817673",
  "documentation_url": ""

Am I reading the doc correctly?

1 Like


I can reproduce the same issue.
When I tried to use a commit SHA as the ref to execute this API, the workflow was never triggered, and I also get the following message:

Status: 422 Unprocessable Entity

    "message": "No ref found for: <commit_SHA>",
    "documentation_url": ""

On the specified commit SHA, the “workflow_dispatch” trigger had been defined in the workflow file.
I also tried to create a tag on this commit SHA, and then used this tag as the ref to execute this API, it can work fine. Using the branch as the ref also can work fine.

I have created an internal ticket to report this issue to the appropriate engineering team for further investigation and evaluation. If they have any progress, I will notify you in time, and sometimes the appropriate engineers may directly reply you here.


Ran into this one and went round it for a good 30 minutes or so trying to figure out if I read the docs incorrectly. Thanks for making this forum post :slight_smile: . Helped me verify that this behaviour is in fact a bug. @brightran, is this in the pipeline for being fixed yet?

Bumping this as I’ve spent the last two days trying to get it to work and failing. This would be really great to get this to work, as instead I’ve had to create a worklow workaround:

name: blah
    types: [foo]

    name: Whatever job you want
    runs-on: ubuntu-latest
      - name: Clone Repository at ref
        uses: actions/checkout@v2
          ref: ${{ github.event.client_payload.ref }} # This info is POSTed to the API
      - name: Update commit status (success)
        if: ${{ success() }} # If previous steps succeed
        uses: Sibz/github-status-action@v1
          authToken: ${{secrets.GITHUB_TOKEN}} # Set this on the repo
          context: 'Remote trigger'
          description: ${{ }}
          state: 'success'
          target_url: "<OWNER>/<REPO>/actions/runs/${{ github.run_id }}"
          sha: ${{ github.event.client_payload.ref }}
      - name: Update commit status (failure)
        if: ${{ failure() }} # If previous steps fail
        uses: Sibz/github-status-action@v1
          authToken: ${{secrets.GITHUB_TOKEN}}
          context: 'Remote trigger'
          description: ${{ }}
          state: 'failure'
          target_url: "<OWNER>/<REPO>/actions/runs/${{ github.run_id }}"
          sha: ${{ github.event.client_payload.ref }}

This works, but has these drawbacks:

  • Have to add a GitHub token as a secret (don’t have to for workflow_dispatch)
  • Have to manually update a commit status
  • Commit status of whatever the workflow actually runs against (normally HEAD of master) gets updated

If this could get fixed so we could simply use workflow_dispatch as the docs suggest that would be great!

After many tries to use sha commit I found that it’s not working and found this thread.

While there are workarounds to checkout using the commit in the payload but it’s unnecessarily complicated compared to API working as documented.
The other drawback with the workaround is the commit status, for example if the workflow performs some tests it is nice to have the status on the commit the workflow is running on without having to hack the status as well.

@brightran are there any updates on this?

Also see Workflow dispatch - can't set ref to commit SHA

:rofl: the solution: Remove it from the docs

The source file is in a private repository. A hubber had to fix the docs:

Note that this is consistent with other APIs, which also accept a branch or tag name, but no commit hashes.