Triggering actions by other repository webhooks

[wojtekmach]

Hi, I’d like to ask if there’s a way of triggering actions from other repository webhooks without leaving GitHub platform.

For example, when there’s a new release on elixir-lang/elixir, I’d like to trigger a workflow in my docker-elixir repository, ideally with the event (ReleaseEvent) payload. Ideally this would be totally decoupled and I could subscribe to any repository webhooks, even those I don’t have write access to.

There’s the repository_dispatch trigger for actions, but I believe it only has event_type field, not the whole payload. Also, I believe it’s not possible to trigger that event from a webhook, I was getting authorization failures.

I noticed there’s a preview support for WebSub, it looks like by subscribing to a topic we (understandably so) set up a webhook, but this means I can only subscribe to repos I am allowed to create webhooks on.

This can be solved today by having a workflow in my docker-elixir that runs on schedule and checks whether there’s a new release in elixir-lang/elixir, and if so it buils the image. If I get elixir-lang/elixir maintainers to set up a webhook, that webhook could hit a web app I maintain that in turn would trigger repository_event which again would check whether there are any new releases. While the 2nd option avoids doing unnecessary checks it brings a ton of complexity.

Are there any other ways of solving this?

[chrispat]

You can put a client_payload in a repository_dispatch and use that information during your run.  However, you still need a way to send that event which is going to require your own webhook for now.  This sort of automatic dependency building is something we are looking at for the future but the potential scale concerns are significant.

[bendavies]

@chrispat i cannot see client\_payload documented anywhere:

https://developer.github.com/v3/repos/#create-a-repository-dispatch-event

can you clarify?

Thanks!

[chrispat]

Unfortuately the docs are lagging a bit.  If you simply add something like

client_payload: { greeting: "hello" }

to the post body for your request it should be available in the github.event context

[ciiqr]

For anyone landing here and needing a more specific example:

send event with body

curl -H "Authorization: token :token" \
-H 'Accept: application/vnd.github.everest-preview+json' \
"https://api.github.com/repos/:owner/:repo/dispatches" \
-d '{"event_type": "awesomeness", "client_payload": {"foo": "bar"}}'

access fields of the payload directly, or simply the entire payload as json

- run: 'echo "field: ${{ github.event.client_payload.foo }}"'
- run: 'echo "payload: ${{ toJson(github.event.client_payload) }}"'

[idemianspro]

Hello,
The following line works for me:
curl -XPOST -u "${{ secrets.PAT_USERNAME}}:${{secrets.PAT_TOKEN}}" -H "Accept: application/vnd.github.everest-preview+json" -H "Content-Type: application/json" https://api.github.com/repos/xxx/yyyy/dispatches --data '{"event_type": "build_application"}'
work only default baranch https://api.github.com/repos/xxx/yyyy/
How to use non-default brunch ?

[woter1832]

@github, has there been any movement on this?

As you refuse to provide a way for us to stop automatic updates of your runner, it would go some way to alleviating the pain if you would providing a webhook that we could use to trigger automatic builds of our containers every time you update your runner.

Thanks