This page was generated based on Github’s Documentation. See our welcome page for context and details.

Github Event pull_request_target #

Github Action Trigger #

source

Note: More than one activity type triggers this event. For information about each activity type, see “Webhook events and payloads.” By default, a workflow only runs when a pull_request_target event’s activity type is opened, synchronize, or reopened. To trigger workflows by different activity types, use the types keyword. For more information, see “Workflow syntax for GitHub Actions.”

Runs your workflow when activity on a pull request in the workflow’s repository occurs. For example, if no activity types are specified, the workflow runs when a pull request is opened or reopened or when the head branch of the pull request is updated.

This event runs in the context of the base of the pull request, rather than in the context of the merge commit, as the pull_request event does. This prevents execution of unsafe code from the head of the pull request that could alter your repository or steal any secrets you use in your workflow. This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.

To ensure repository security, branches with names that match certain patterns (such as those which look similar to SHAs) may not trigger workflows with the pull_request_target event.

Warning: For workflows that are triggered by the pull_request_target event, the GITHUB_TOKEN is granted read/write repository permission unless the permissions key is specified and the workflow can access secrets, even when it is triggered from a fork. Although the workflow runs in the context of the base of the pull request, you should make sure that you do not check out, build, or run untrusted code from the pull request with this event. Additionally, any caches share the same scope as the base branch. To help prevent cache poisoning, you should not save the cache if there is a possibility that the cache contents were altered. For more information, see “Keeping your GitHub Actions and workflows secure: Preventing pwn requests” on the GitHub Security Lab website.

For example, you can run a workflow when a pull request has been assigned, opened, synchronize, or reopened.

on:
  pull_request_target:
    types: [assigned, opened, synchronize, reopened]

Running your pull_request_target workflow based on the head or base branch of a pull request #

You can use the branches or branches-ignore filter to configure your workflow to only run on pull requests that target specific branches. For more information, see “Workflow syntax for GitHub Actions.”

For example, this workflow will run when someone opens a pull request that targets a branch whose name starts with releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'

Note: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a pull request that includes a change to a JavaScript (.js) file is opened on a branch whose name starts with releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

To run a job based on the pull request’s head branch name (as opposed to the pull request’s base branch name), use the github.head_ref context in a conditional. For example, this workflow will run whenever a pull request is opened, but the run_if job will only execute if the head of the pull request is a branch whose name starts with releases/:

on:
  pull_request_target:
    types:
      - opened
jobs:
  run_if:
    if:  startsWith(github.head_ref, 'releases/')
    runs-on: ubuntu-latest
    steps:
      - run: echo "The head of this PR starts with 'releases/'"

Running your pull_request_target workflow based on files changed in a pull request #

You can use the paths or paths-ignore filter to configure your workflow to run when a pull request changes specific files. For more information, see “Workflow syntax for GitHub Actions.”

For example, this workflow will run when a pull request includes a change to a JavaScript file (.js):

on:
  pull_request_target:
    paths:
      - '**.js'

Note: If you use both the branches filter and the paths filter, the workflow will only run when both filters are satisfied. For example, the following workflow will only run when a pull request that includes a change to a JavaScript (.js) file is opened on a branch whose name starts with releases/:

on:
  pull_request_target:
    types:
      - opened
    branches:
      - 'releases/**'
    paths:
      - '**.js'

Running your pull_request_target workflow when a pull request merges #

When a pull request merges, the pull request is automatically closed. To run a workflow when a pull request merges, use the pull_request_target closed event type along with a conditional that checks the merged value of the event. For example, the following workflow will run whenever a pull request closes. The if_merged job will only run if the pull request was also merged.

on:
  pull_request_target:
    types:
      - closed

jobs:
  if_merged:
    if: github.event.pull_request.merged == true
    runs-on: ubuntu-latest
    steps:
    - run: |
        echo The PR was merged        

Event Payload #

This event populates the pull_request payload.