What is the difference between pull_request and pull_request_target?

pull_request runs in the context of the merge commit with a restricted token and no secrets for fork PRs. pull_request_target runs in the base repository with full secrets and a write token, so you must never check out and execute untrusted PR code under it.

How do I trigger a workflow manually?

Use workflow_dispatch. You can declare inputs under the trigger, then run the workflow from the Actions tab or the REST API. Read the supplied values through the inputs context inside your jobs and steps.

How do I schedule a workflow to run periodically?

Use the schedule event with a cron expression in UTC, for example a daily 03:00 run. The minimum effective interval is roughly five minutes, and GitHub may delay scheduled runs during periods of high load, so do not rely on exact timing.

How do I run one workflow after another finishes?

Use the workflow_run event with the workflows filter naming the upstream workflow and the completed activity type. This is the standard pattern for deploy-after-CI chains where the second workflow needs the first to succeed.

What event makes a workflow reusable?

workflow_call marks a workflow as reusable so other workflows can invoke it with uses:. Declare its inputs, secrets and outputs under the trigger. This enables sharing one pipeline definition across many repositories or jobs.

What is the GitHub Actions Trigger Events?

Searchable reference for all GitHub Actions on: trigger events — push, pull_request, schedule, workflow_dispatch, workflow_call, release and more — with activity types, supported filters and usage notes. It runs free in your browser on Gera Tools, with nothing uploaded.

GitHub Actions Trigger Events

Name: GitHub Actions Trigger Events
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Pick the right workflow trigger

GitHub Actions workflows start in response to events declared under the on: key. This reference lists every trigger event with the activity types you can narrow on, the filters it supports (branches, tags, paths) and the gotchas worth knowing. Search by event name or keyword.

How events and filters work together

When something happens in or around a repository — a push, a pull request, a scheduled tick, a manual dispatch — GitHub emits an event. A workflow runs if its on: block names that event and any declared filters and activity types match. Activity types (types:) narrow broad events to specific actions, for example only opened and synchronize pull requests. Filters (branches, tags, paths and their -ignore variants) restrict pushes and PRs to certain refs or changed files.

Several events have important behaviour or security characteristics: pull_request_target runs with secrets and a write token even for fork PRs, schedule runs in UTC with best-effort timing, and workflow_call turns a workflow into a reusable building block.

Common events at a glance

Event	When it fires	Key notes
`push`	A branch or tag receives a commit	Filter on `branches`, `tags`, `paths`
`pull_request`	PR opened, updated, or other activity	Fork PRs run with a restricted token and no secrets
`pull_request_target`	PR activity, but runs in base repo context	Receives secrets — never checkout and run PR code
`schedule`	Cron expression fires in UTC	Minimum ~5-minute interval; timing is best-effort
`workflow_dispatch`	Manual trigger from UI, API, or CLI	Declare `inputs:` to accept parameters
`workflow_call`	Called from another workflow	Makes a workflow reusable across repos
`workflow_run`	Another named workflow completes	Use for deploy-after-CI chains
`release`	GitHub Release created, published, etc.	Filter by `types: [published]` for production deploys
`repository_dispatch`	External HTTP POST with a custom event type	Trigger from external systems via the GitHub API
`issue_comment`	Comment created on an issue or PR	Useful for ChatOps-style slash commands

Examples

Scope a CI run to relevant branches and changed files:

on:
  push:
    branches: [main]
    paths: ["src/**", "package.json"]

React to specific PR activity only — skip draft opens and re-title edits:

on:
  pull_request:
    types: [opened, synchronize, reopened, ready_for_review]

Manual trigger with a required input (for example to choose a deployment environment):

on:
  workflow_dispatch:
    inputs:
      environment:
        description: Target environment
        required: true
        type: choice
        options: [staging, production]

Schedule a nightly job:

on:
  schedule:
    - cron: "0 3 * * *"  # 03:00 UTC every day

Security notes

pull_request_target runs with write access and secrets even for pull requests from forks. Never use it with actions/checkout followed by arbitrary script execution — that is a code injection vector. Use it only for label management, commenter automation, or other steps that do not execute untrusted code.
workflow_call inputs and secrets must be explicitly declared and passed; they are not inherited automatically from the caller.
Chain a deploy after CI with workflow_run and the workflows: filter, and trigger automation from outside GitHub with repository_dispatch plus a custom event type.