A GitHub action to create a repository dispatch event.
In the caller workflow file:
jobs:
Dispatch:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- name: Repository Dispatch
uses: peter-evans/repository-dispatch@v4
with:
event-type: my-eventIn the callee workflow file:
name: MyWorkflow
on:
repository_dispatch:
types: [my-event]Use a repo scoped Personal Access Token (PAT).
- name: Repository Dispatch
uses: peter-evans/repository-dispatch@v4
with:
token: ${{ secrets.PAT }}
repository: username/my-repo
event-type: my-event| Name | Description | Default |
|---|---|---|
token |
GITHUB_TOKEN or a repo scoped Personal Access Token (PAT). See token for further details. |
GITHUB_TOKEN |
repository |
The full name of the repository to send the dispatch. | github.repository (current repository) |
event-type |
(required) A custom webhook event name. | |
client-payload |
JSON payload with extra information about the webhook event that your action or workflow may use. | {} |
This action creates repository_dispatch events.
The default GITHUB_TOKEN token can only be used if you are dispatching the same repository that the workflow is executing in.
To dispatch to a remote repository you must create a Personal Access Token (PAT) with the repo scope and store it as a secret.
If you will be dispatching to a public repository then you can use the more limited public_repo scope.
You can also use a fine-grained personal access token (beta). It needs the following permissions on the target repositories:
contents: read & writemetadata: read only(automatically selected when selecting the contents permission)
Here is an example setting all of the input parameters.
- name: Repository Dispatch
uses: peter-evans/repository-dispatch@v4
with:
token: ${{ secrets.PAT }}
repository: username/my-repo
event-type: my-event
client-payload: '{"ref": "${{ github.ref }}", "sha": "${{ github.sha }}"}'Here is an example on: repository_dispatch workflow to receive the event.
Note that repository dispatch events will only trigger a workflow run if the workflow is committed to the default branch.
name: Repository Dispatch
on:
repository_dispatch:
types: [my-event]
jobs:
myEvent:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.client_payload.ref }}
- run: echo ${{ github.event.client_payload.sha }}You can dispatch to multiple repositories by using a matrix strategy. In the following example, after the build job succeeds, an event is dispatched to three different repositories.
jobs:
build:
# Main workflow job that builds, tests, etc.
dispatch:
needs: build
strategy:
matrix:
repo: ['my-org/repo1', 'my-org/repo2', 'my-org/repo3']
runs-on: ubuntu-latest
steps:
- name: Repository Dispatch
uses: peter-evans/repository-dispatch@v4
with:
token: ${{ secrets.PAT }}
repository: ${{ matrix.repo }}
event-type: my-eventThe GitHub API allows a maximum of 10 top-level properties in the client-payload JSON.
If you use more than that you will see an error message like the following.
No more than 10 properties are allowed; 14 were supplied.
For example, this payload will fail because it has more than 10 top-level properties.
client-payload: ${{ toJson(github) }}To solve this you can simply wrap the payload in a single top-level property. The following payload will succeed.
client-payload: '{"github": ${{ toJson(github) }}}'Additionally, there is a limitation on the total data size of the client-payload. A very large payload may result in a client_payload is too large error.
A multiline client-payload can be set directly in YAML, as in the following example.
- name: Repository Dispatch
uses: peter-evans/repository-dispatch@v4
with:
token: ${{ secrets.PAT }}
repository: username/my-repo
event-type: my-event
client-payload: |-
{
"repo": {
"name": "${{ github.repository }}",
"branch": "${{ needs.build_cfg.outputs.REPO_BRANCH }}",
"tag": "${{ needs.build_cfg.outputs.REPO_TAG }}"
},
"deployment": {
"project": "${{ env.MY_PROJECT }}",
"container": "${{ env.MY_CONTAINER }}",
"deploy_msg": "${{ env.SLACK_DEPLOY_MSG }}",
}
}