Correlate workflow triggered externally with the exact workflow run


I trigger a git action workflow using repository dispatch event and then use the workflow runs api to get the states of the run, job and individual steps. Due to the nature of the gitactions api, I am unable to correlate the workflow run for a particular repository dispatch event. Currently, I retrieve all the ongoing workflow runs (status=in_progress) and pick the latest one based on the Created timestamp. However this can fail in certain scenarios. Is there a better way of correlating the trigger event and the workflow run?

Thank you.

Hi @isurulucky,

Image you create a repository dispatch event from Repo A to trigger RepoB workflow.
You can get the runid…etc info from repoA, put them in the rest api client payload, it will transfer to repoB, and in repo B workflow, get them via context, eg: ${{ github.event.client_payload.checkrunid }}.
Code sample as below:
Repo A workflow:

    runs-on: [ubuntu-latest]
      - name: send info to repoB     # send out the info about the workflow
        uses: peter-evans/repository-dispatch@v1
          token: ${{ secrets.PAT2 }}
          repository: org/repo
          event-type: eventA
          client-payload: '{"checkrunid": "${{ github.run_id }}"}'       # the run_id

And in repoB workflow:

name: repoB workflow
    types: [eventA]
    runs-on: [ubuntu-latest]
      - name: echo checkrun id
        run: |
          echo ${{ github.event.client_payload.checkrunid }}      #get the checkrunid transfered from repoA.

Based on the payload content, eg: checkrunid, repository name, pull_request number, you can use rest api to get the content from repoA then. Please check my answer in similar ticket: Making links to artifacts available from pull requests


edited- fixed typo.

Hi @weide-zhou,

This appears to be similar to my Question a while back under GitHub API Development and Support.

From what I can tell there is no way link an event (e.g. repository_dispatch, deployment) to the GitHub Actions workflow run that it triggers without collecting the run id from an action inside the workflow itself. This is a fundamental limitation of the API and something I hope to see addressed.

In my case I tried creating a repository dispatch from a deployment workflow. It didn’t need to trigger another workflow as I only needed the event to communicate with my GitHub App. The problem was that if the workflow configuration file was invalid or GitHub Actions errored for another reason (has happened a few times recently) then the action inside the workflow would not run and I would have no guaranteed way of figuring that out if I were to trigger multiple workflows at the same time.

In the end I figured out that I could lock deployments to an environment and figure out the correct workflow by triggering it on a custom branch per environment. However that doesn’t look to be an option in this case as repository dispatch events only run on the head of the master branch.

Thanks @weide-zhou and @dbalcomb for the replies. Seems there is no straightforward solution to this. Would love to see this properly supported!

Hi @isurulucky,

Sorry I’m a little confused, could you please add more details? For example, repo A and repo B.
In workflow of repo A, create a repository dispatch event to trigger workflow in repo B. What do you want to get?
Follow my first post, you can transfer any info via client payload to repoB, use ‘event-type’ you can trigger the specific workflow in repoB.


Hi @weide-zhou,

Apologies about the confusion.

In your solution, as I understand, you can access repo A’s workflow run status from repo B, to which you pass the run id. Please correct me if I’m wrong.

Explaining a bit more about my usecase, I have a golang client which is coordinating github workflows and it needs to get information about the status of the specific workflow run triggered by a repository_dispatch event - what are the jobs/steps in progress/complete, final status etc. For this usecase, the approach you have described is not a perfect match.

The ideal solution would be:

  • The workflow api[1] has the capability to invoke a particular workflow in a repository, which returns an id (run id?)
  • Use the id returned to retrieve the status of the workflow run, manage it etc.

I believe this would be a common requirement for workflow automation, which other CICD systems support already.

Do let me know what you think.

Thank you.


Hi @isurulucky,

Thanks for your reply! Looks you’re trying to return jobs/steps status from repo B to repoA. It’s a little hard to interact between two workflows, since the workflow needs to wait for the reply from another one, you may need an external server to store the value as a toggle, and check in repoA until get the wanted value continue the next steps.
But based on your requirements, you only want to get the jobs/steps status, in my opinion, you can use two workflows in repoA:

  1. 1st one to trigger repoB workflow.
  2. In repoB, send a repository dispatch event back to repoA( suggest to specify event-type), with the status…info in client payload.
  3. 2nd workflow in repoA will be triggered by repoB, you can use the payload to manage it now.

You can use the action ‘peter-evans/repository-dispatch@v1’ to send the repository dispatch event. And instead of rest api, use steps/jobs context as the payload value, please check the doc for more details.
My recently answer: Count the total number of successful steps in a job using github actions


Hi @weide-zhou,

Sorry for the late reply and than you so much for all the possible alternatives provided.

However to re-clarify, I do not have two repos in my usecase. Just a single repo which has the workflow, and a client program written in go which is triggering and managing workflows runs via the repository_dispatch event and the workflow rest API. Therefore the ideal solution would be a way to get an id when a workflow is triggered from the client code, and then use the id to obtain the statuses, etc.
Comparing to other CICD solutions I think this is an important feature which is currently missing in gitactions. Would be great if this can be properly supported, as this is a common usecase.

Thank you.

Hi @isurulucky,

Thanks for your reply!

‘repository dispatch’ is an ‘external’ event when you want to trigger a workflow for activity that happens outside of GitHub. As you know, the rest api has no return.
According to the policy, you can raise a feeback ticket to confirm whether it’s possible to have any improvement of it, github developing team will check and help to answer:[category]=actions


Thank you so much @weide-zhou!