Jobs, dependencies, and triggers

With the basics of workflow structure in place, the next step is coordinating work across multiple jobs and understanding when a workflow should run in the first place.

Coordinating multiple jobs

Workflows may contain multiple jobs. By default they run in parallel as soon as their triggering event occurs. Use needs: to create explicit dependencies and form a directed acyclic graph (DAG). The 03-core-features--03-workflows-jobs-steps.yaml workflow prints out how this coordination behaves:

jobs:
  job-1:
    runs-on: ubuntu-24.04
    steps:
      - run: echo "A job consists of"
      - run: echo "one or more steps"
      - run: echo "which run sequentially"
      - run: echo "within the same compute environment"
  job-2:
    runs-on: ubuntu-24.04
    steps:
      - run: echo "Multiple jobs can run in parallel"
  job-3:
    runs-on: ubuntu-24.04
    needs:
      - job-1
      - job-2
    steps:
      - run: echo "They can also depend on one another..."
  job-4:
    runs-on: ubuntu-24.04
    needs:
      - job-2
      - job-3
    steps:
      - run: echo "...to form a directed acyclic graph (DAG)"

Use this pattern to gate deployments on successful builds, collect artifacts from test jobs, or otherwise coordinate work across multiple environments.

Controlling when workflows run

Events determine when a workflow runs. GitHub Actions supports dozens of events, but the most common are push, pull_request, workflow_dispatch, and schedule. You can filter each event so that it only fires for the branches, tags, or file paths that matter.

The 03-core-features--04-triggers-and-filters.yaml example demonstrates practical filters:

on:
  push:
    branches:
      - "example-branch/*"

  pull_request:
    paths:
      - "03-core-features/filters/*.md"
      - "!03-core-features/filters/*.txt"

  schedule:
    - cron: "0 0 * * *" # Midnight UTC

  workflow_dispatch:

• Branch and tag filters let you restrict execution to feature branches, release branches, or semantic tags.
• Path filters are incredibly useful for monorepos because they allow you to skip expensive jobs when unrelated files change.
• Scheduled workflows use cron schedule expressions and run even if no commits land that day.
• Manual dispatch gives you a “Run workflow” button in the UI for ad-hoc builds, emergency fixes, or demos.

To debug why a workflow fired, inspect the event payload saved at $GITHUB_EVENT_PATH. The sample workflow finishes by cat-ing this file so you can see the exact JSON GitHub sent to the runner.