A year later and nothing still!?

Over three years and counting

I am trying to run and monitor a workflow from outside Github, so using an existing GH Action workaround is not viable for my use case - but thanks to the community for building these.

@owattley-rotageek The "finished code" linked to in my update to the original post can be used from anywhere. It's just bash code. Although it's part of an existing action, it doesn't use any features of the actions environment. It works reliably without any ugly workarounds.

@lkfortuna we really need this. Workarounds aren't fun to work with. Please prioritize this.

Same here, I am in a dire need of this functionality. Thanks

Please provide an example.
Thank you

Does the workflow runs API return the input values?

I happen to be encountering the same issue now, and I'm not seeing where the raw inputs are returned in the workflow runs API. ☝️
Thanks

I just ran into this and opened an issue on octokit/octokit.rb#1790. At first, I thought it was just a status change, but I too have verified that the body is now returning the ID. I assumed this was coming in 2026, because it literally says so here: https://github.blog/news-insights/product-news/lets-talk-about-github-actions

This is madness. It's basic API design. You can still be asynchronous with the webhook - return a UUID for this request and call that the dispatch_uuid. The UUID is attached to the payload that is part of the slower tasks. This UUID is attached to the workflow run information as dispatch_uuid...

2+ years since this has been reported and no progress, this is really necessary for any kind of 3rd party integration launching and monitoring workflow in Github. Is there any news on this?

Or at least if there was a way to send an identifier as part of the payload and have the way to search by that identifier would help as well, in that way it won't matter if it's async or not because the info will be part of the inputs.

I unmarked this as "answered" because it's been 2y and there still isn't a real solution, only clunky workarounds.

This is API design 101 for any asynchronous task or API, amazing this made it to production in this state

Perfect! Thank you!

And only took almost 4 years. Better later than never, I guess 😅

That's a great blog post, and it's very pleasing to see this issue mentioned in the list of things to be done in early 2026. I understand now why this feature hasn't had any attention recently. The backend rearchitecture must have taken a lot of work, and as a fellow-developer I fully understand the need to put features on hold and work on core tech for a while.

However, it's very frustrating that the development team weren't able to let us know the reason for the delay. I understand the need for secrecy around internal product development sometimes, but in this case case it's hard to see why the rearchitecture work couldn't have been made public. A little more information would have helped a lot in reducing people's frustrations, and I hope this can be communicated up the chain to management.

Did this go live by accident already? Currently the create-workflow-dispatch API returns a 200 (instead of 204), with this response:

This also breaks PyGithub - because it only accepts a 204 response.
https://github.com/PyGithub/PyGithub/blob/61dcf49d30d6854849ab745c501cab8856267bdb/github/Workflow.py#L169

I was also struck by the status code change. Created a separate discussion for this issue: https://github.com/orgs/community/discussions/182272

I can confirm that this now works. The workflow run id is returned in the response's data:

    steps:
      - name: 'Workflow dispatch'
        id: workflow-dispatch-e2e
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GH_ACTIONS_PAT_SCOPE_REPO }}
          result-encoding: 'string'
          script: |
            const createWorkflowResponse = await github.rest.actions.createWorkflowDispatch({
              owner: '<owner>',
              repo: '<repo>',
              workflow_id: 'e2e-test-staging.yml',
              ref: 'development',
            });
            console.log(createWorkflowResponse);
            return createWorkflowResponse.data.workflow_run_id;
      - name: 'Watch e2e tests run'
        id: watch-e2e
        run: |
          run_id="${{ steps.workflow-dispatch-e2e.outputs.result }}"
          # Watch until completion
          gh run watch -R <owner>/<repo> --interval 45 $run_id

          # Check if any steps failed in any job
          if failed_logs=$(gh run view -R <owner>/<repo> $run_id \
              --log-failed 2>/dev/null) && [ -n "$failed_logs" ]; then
            echo "❌ e2e tests failed:"
            echo "$failed_logs"
            exit 1
          fi
          echo "✅ No failures found"
        env:
          GH_TOKEN: ${{ secrets.GH_ACTIONS_PAT_SCOPE_REPO }}

I recommend you use the convictional/trigger-workflow-and-wait action:

- name: Example
  uses: convictional/[email protected]
  with:
    owner: my-org
    repo: other-repo
    workflow_file_name: other-workflow.yaml
    github_token: ${{ secrets.GH_TOKEN }}
    client_payload: '{"key1": "value1", "key2": "value2"}'

This takes care of waiting for the other job and returning a success or failure according to whether the other workflow succeeded or failed.

It's a workaround that probably a lot of people are now using (me too), but I would not call it a robust solution.

That's a fair comment. However, it's more robust than any of the previous non-intrusive solutions, and it seems to work well in practice. Have you experienced any problems with it?

We have been using this approach for a couple years now https://github.com/orgs/community/discussions/9752#discussioncomment-5247573. GitHub's APIs for creating branches are somewhat flakey at scale. I wish I didn't have to do this.

I also wish we didn’t have to jump through these hoops