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-event
In 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-event
The 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 }}", } }