[FEATURE REQUEST] Get run id upon dispatch

[jjICP]

trafficstars

When you execute a dispatch, the action that is dispatched (the receiver) has a run id. You can use this run id to track the status of that action. i.e. -

      - name: Wait for Dispatch Completion
        uses: actions/github-script@v7
        env:
          REPO: github-dispatch-receiver
          RUN_ID: ${{ steps.get-run-id.outputs.run_id }}
        with:
          github-token: ${{ steps.app-token.outputs.token }}
          script: |
            const repo = process.env.REPO;
            const run_id = process.env.RUN_ID;

            const run = await github.rest.actions.getWorkflowRun({
              owner: context.repo.owner,
              repo,
              run_id,
            });

            ....

Is there any way to update the repo dispatch command to get back that run id? Right now, you have to do some pretty complicated/impossible logic to try and figure out what action run was started if you want to track the status of the action. If we could get the run id back that would be ideal.

The only way I know to get the run id now is to record the current time before the dispatch and then try and get workflow runs with type repository dispatch that came after that time, but it's certainly not a perfect solution:

      - name: Save current UTC time
        id: save-time
        uses: actions/github-script@v7
        with:
          result-encoding: string
          script: |
              return new Date().toISOString();

      - name: Send Dispatch
        uses: peter-evans/repository-dispatch@v3
        with:
          token: ${{ steps.app-token.outputs.token }}
          repository: jjICP/github-dispatch-receiver
          event-type: dispatch-testing-trigger
          client-payload: |
            {
              "job_id": "${{ env.JOB_ID }}"
            }

      - name: Wait for 10 seconds to ensure dispatch is processed
        run: sleep 10

      - name: Get the Run ID for the dispatch
        id: get-run-id
        uses: actions/github-script@v7
        env:
          REPO: github-dispatch-receiver
          SINCE: ${{ steps.save-time.outputs.result }}
        with:
          github-token: ${{ steps.app-token.outputs.token }}
          script: |
            const repo = process.env.REPO;
            const since = new Date(process.env.SINCE);

            const delay = ms => new Promise(resolve => setTimeout(resolve, ms));
            for (let i = 0; i < 36; i++) { // 36 * 5s = 3 min timeout
              const res = await github.rest.actions.listWorkflowRunsForRepo({
                owner: context.repo.owner,
                repo: repo,
                event: 'repository_dispatch',
                per_page: 10,
              });

              if (res.data.workflow_runs.length > 0) {
                const runs = res.data.workflow_runs;
                const matching = runs.find(run => new Date(run.created_at) >= since);

                if (!matching) {
                  core.setFailed('No matching workflow run found');
                } else {
                  console.log("Run ID:", matching.id);
                  core.setOutput('run_id', matching.id);
                  return;
                }
              }

              await delay(5000);
            }
            core.setFailed('Timed out waiting for testing to finish.');

[jjICP]

UPDATE: I realized this is not really the fault of this code but more the GitHub API call that does not return the run id either so I put in a feature request to github to update the api call to do this as well.

[peter-evans]

Hi @jjICP

This request has come up multiple times in the past. There's some discussion and a possible solution that might help you in this one: https://github.com/peter-evans/repository-dispatch/issues/260#issuecomment-1719861720

[WillyJL]

was using this action, but also ran into this limitation. what solved it for my use case was using this instead https://github.com/Codex-/return-dispatch. hopefully github will address this eventually so we dont need these hacky workarounds, but i doubt they ever will

[liviutomo]

I’ve set up a post-report flow from the child repo back to the parent. The sequence works like this:

• The main repo triggers a dispatch call. Once the main build passes, a check mark is set for it.
• A secondary status line (“Check Job Status”) is created for the child repo, marked as pending, with a link pointing to the child repo’s Actions page.
• The child repo is triggered by the dispatch event. After execution, it updates the pending status with the final result (Pass or Fail), overwriting the body with the new status and the exact job link (including run ID).