GitHub Actions Cheat Sheet

Updated 2026-07-29

🎯Take a practice test on this topic6 practice tests · 169 questions→

🧠Study flashcards on this topic106 cards · spaced repetition→

GitHub Actions is GitHub's CI/CD and automation platform built directly into repositories, enabling workflows to run on code events, schedules, or manual triggers. It eliminates external CI/CD dependencies by providing hosted runners, a marketplace of pre-built actions, and flexible YAML-based workflow definitions. The platform scales from simple automated testing to complex deployment pipelines with matrix builds, reusable workflows, and fine-grained security controls—making it the de facto automation solution for projects hosted on GitHub. In 2026, hosted runner prices dropped up to 39% and major new features include timezone-aware schedules, artifact attestations, OIDC custom properties, and a new case expression function.

What This Cheat Sheet Covers

This topic spans 18 focused tables and 156 indexed concepts, 106 flashcards, 6 practice tests with 169 questions. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.

Table 1: Workflow TriggersTable 2: Workflow Syntax ElementsTable 3: Job ConfigurationTable 4: Step ConfigurationTable 5: Matrix StrategyTable 6: Workflow Event FiltersTable 7: Expressions and ContextsTable 8: Expression FunctionsTable 9: Common Marketplace ActionsTable 10: Secrets and VariablesTable 11: Runner TypesTable 12: Caching and ArtifactsTable 13: Reusable Workflows and ActionsTable 14: Security and PermissionsTable 15: Deployment and EnvironmentsTable 16: Advanced Workflow ControlTable 17: Debugging and TroubleshootingTable 18: Cost Optimization

Quick IndexSubscribe to unlock

A jump-to index of every table row in this cheat sheet.

Mind MapSubscribe to unlock

An interactive map of every table and concept in this topic.

Table 1: Workflow Triggers

Every workflow starts with one question: what should make it run? These are the events you list under on: a push, a pull request, a manual click, a schedule, or a call from another workflow. Watch the security-sensitive pair: pull_request runs with restricted permissions for fork safety, while pull_request_target runs with full write access and secrets, which is exactly where careless handling of untrusted fork code turns into a supply-chain incident.

Event	Example	Description
push	`on:` `push:` `branches: [main]`	• Triggers on commits pushed to specified branches or tags • most common trigger for CI pipelines.
pull_request	`on:` `pull_request:` `types: [opened, synchronize]`	• Runs on PR events like open, sync, or close • checks out the merge commit by default, and gets restricted, secret free permissions when the PR comes from a fork.
workflow_dispatch	`on:` `workflow_dispatch:` `inputs:` `environment:` `required: true`	Allows manual triggering via UI or API with optional custom input parameters (up to 25 inputs).
schedule	`on:` `schedule:` `- cron: '30 5 * * 1'` `timezone: 'America/New_York'`	• Runs workflow at specific times using POSIX cron syntax • supports IANA timezone field (defaults to UTC) • useful for nightly builds or regular maintenance • auto-disabled after 60 days of inactivity in public repos.
workflow_call	`on:` `workflow_call:` `inputs:` `config:` `required: true`	• Makes workflow reusable so other workflows can call it • supports inputs, secrets, and outputs for modular pipeline design.
repository_dispatch	`on:` `repository_dispatch:` `types: [deploy-prod]`	• Triggers workflows from external events via GitHub API • only runs on default branch • ideal for cross-system integrations.
workflow_run	`on:` `workflow_run:` `workflows: [CI]` `types: [completed]`	• Triggers after another workflow completes, succeeds, or fails • runs with base repo permissions • useful for chaining workflows.
release	`on:` `release:` `types: [published]`	• Triggers on release events like published or created • commonly used for deployment or asset uploads • subscribe to published rather than released or prereleased to also catch pre-releases promoted from a draft.
pull_request_target	`on:` `pull_request_target:` `types: [opened]`	• Runs with base repo write access and secrets • dangerous if executing untrusted fork code without sanitization • the token stays live in memory even if no step explicitly references a secret.
issue_comment	`on:` `issue_comment:` `types: [created]`	• Runs when an issue or PR comment is created, edited, or deleted • fires for both issues and pull requests, use `github.event.issue.pull_request` to tell them apart • useful for chatops-style automation.

Table 2: Workflow Syntax Elements

The top-level keys that shape an entire workflow file. Most of these nest, meaning env, permissions, and defaults can be set at the workflow, job, or step level, with the most specific level winning. Getting permissions right matters most: scoping the GITHUB_TOKEN to least-privilege read-only by default is the single cheapest security hardening you can apply.

Element	Example	Description
name	`name: CI Pipeline`	• Workflow display name shown in the Actions tab • if omitted, defaults to workflow file path.

The rest of this section is part of the full cheat sheet

Table 3: Job Configuration

A job is a unit of work that runs on its own fresh runner, and these properties control how it relates to the others around it. needs builds the dependency graph, if decides whether the job runs at all, and strategy fans a single job into a parallel matrix. Reach for environment, services, and container when a job needs deployment gates, a sidecar database for tests, or a fully isolated execution image.

Property	Example	Description
needs	`needs: [build, test]`	• Declares job dependencies • current job waits for listed jobs to succeed before starting.

The rest of this section is part of the full cheat sheet

Table 4: Step Configuration

Steps are the individual commands inside a job, and every step is either a uses (a packaged action) or a run (raw shell), never both. Giving a step an id is what unlocks passing data forward: later steps read its outputs through the steps context. The with block feeds inputs to actions, while if, shell, and working-directory tune exactly how and whether each step executes.

Property	Example	Description
uses	`uses: actions/setup-node@v6` `with:` `node-version: 20`	• Executes a marketplace or custom action • format `owner/repo@ref` or local `./.github/actions/name`.

The rest of this section is part of the full cheat sheet

Table 1: Workflow Triggers

Event	Example	Description
push	`on:` `push:` `branches: [main]`	• Triggers on commits pushed to specified branches or tags • most common trigger for CI pipelines.
pull_request	`on:` `pull_request:` `types: [opened, synchronize]`	• Runs on PR events like open, sync, or close • checks out the merge commit by default, and gets restricted, secret free permissions when the PR comes from a fork.
workflow_dispatch	`on:` `workflow_dispatch:` `inputs:` `environment:` `required: true`	Allows manual triggering via UI or API with optional custom input parameters (up to 25 inputs).
schedule	`on:` `schedule:` `- cron: '30 5 * * 1'` `timezone: 'America/New_York'`	• Runs workflow at specific times using POSIX cron syntax • supports IANA timezone field (defaults to UTC) • useful for nightly builds or regular maintenance • auto-disabled after 60 days of inactivity in public repos.
workflow_call	`on:` `workflow_call:` `inputs:` `config:` `required: true`	• Makes workflow reusable so other workflows can call it • supports inputs, secrets, and outputs for modular pipeline design.
repository_dispatch	`on:` `repository_dispatch:` `types: [deploy-prod]`	• Triggers workflows from external events via GitHub API • only runs on default branch • ideal for cross-system integrations.
workflow_run	`on:` `workflow_run:` `workflows: [CI]` `types: [completed]`	• Triggers after another workflow completes, succeeds, or fails • runs with base repo permissions • useful for chaining workflows.
release	`on:` `release:` `types: [published]`	• Triggers on release events like published or created • commonly used for deployment or asset uploads • subscribe to published rather than released or prereleased to also catch pre-releases promoted from a draft.
pull_request_target	`on:` `pull_request_target:` `types: [opened]`	• Runs with base repo write access and secrets • dangerous if executing untrusted fork code without sanitization • the token stays live in memory even if no step explicitly references a secret.
issue_comment	`on:` `issue_comment:` `types: [created]`	• Runs when an issue or PR comment is created, edited, or deleted • fires for both issues and pull requests, use `github.event.issue.pull_request` to tell them apart • useful for chatops-style automation.

Table 2: Workflow Syntax Elements

Element	Example	Description
name	`name: CI Pipeline`	• Workflow display name shown in the Actions tab • if omitted, defaults to workflow file path.

Table 3: Job Configuration

Property	Example	Description
needs	`needs: [build, test]`	• Declares job dependencies • current job waits for listed jobs to succeed before starting.

Table 4: Step Configuration

Property	Example	Description
uses	`uses: actions/setup-node@v6` `with:` `node-version: 20`	• Executes a marketplace or custom action • format `owner/repo@ref` or local `./.github/actions/name`.