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.

GitHub Actions Trigger Events

Email me this result

Get this tool's output sent to your inbox, plus one useful tool a week. No spam, unsubscribe any time.

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 it works

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. The reference surfaces these in the per-event note.

Tips and examples

Scope a CI run to relevant branches and files:

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

React to specific PR activity only:

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

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.
Treat pull_request_target as privileged: never actions/checkout the PR head and run its scripts under it.