What Is a GitHub Actions Workflow? Jobs, Steps, and Triggers

By Daniel Zoghalchali·Latchkey

A workflow is just a YAML file in .github/workflows/ that says: when this event happens, run these jobs on these runners.

GitHub Actions automates CI/CD through workflows - declarative YAML files that bind events to the work they trigger. Understanding the four nouns (event, job, step, runner) makes the whole model click.

Events trigger workflows

A workflow declares the events it listens for in its on: block - a push, a pull request, a schedule, or a manual dispatch. When a matching event fires, GitHub queues the workflow.

on:
  push:
    branches: [main]
  pull_request:

Jobs run on runners

A workflow contains one or more jobs. Each job runs on a fresh runner and, by default, jobs run in parallel. Use needs: to make one job wait for another, forming a dependency graph.

Steps do the work

Each job is an ordered list of steps. A step either runs a shell command (run:) or invokes a reusable action (uses:). Steps in a job share the same runner and filesystem, so earlier steps set up state for later ones.

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

Putting it together

Event → workflow → jobs (on runners, possibly parallel) → steps (in order). Everything else - matrices, caching, artifacts, permissions - layers on top of this core shape.

Key takeaways

• A workflow is YAML in .github/workflows/ bound to events via on:.
• Jobs run on fresh runners and default to running in parallel.
• Steps run in order and share the job’s runner and filesystem.
• needs: turns parallel jobs into an ordered dependency graph.

Frequently asked questions

Related guides

References

• GitHub Actions documentation