Your First Pipeline

In one line

A minimal, real pipeline — checkout, build, test — running on every push, is the entire foundation everything in this course builds on top of.

0/4 · 0%

Key ideas

01
Every CI/CD platform's pipeline, however it's specifically configured, needs to do at minimum three things: CHECK OUT the repository's code (the runner starts with nothing; it needs your actual source), BUILD it (Topic 0.3's Maven/Gradle commands, or the equivalent for another language), and TEST it — genuinely the minimum viable pipeline, before any deployment logic is added at all.
02
This course uses GitHub Actions for this first, platform-agnostic example specifically because it requires zero separate installation or account setup beyond a GitHub repository you likely already have from Git's own course — Phase 2 covers GitHub Actions in full depth; this topic's goal is just seeing the complete shape once, concretely.
03
A GitHub Actions WORKFLOW file lives at .github/workflows/*.yml, committed directly into the repository — Git's own course already established that CI/CD configuration lives in the repo itself and goes through the same review process as any other code (Phase 4.4), and this is exactly that principle made concrete.
04
on: push (or on: pull_request) defines the TRIGGER — Phase 1.1 covers this in depth, but for now, simply knowing that a pipeline runs in response to a specific Git event is enough to understand why pushing a commit is what actually starts everything else in this topic's example.
05
Each STEP in a job runs either a plain shell command (run: mvn test) or a reusable ACTION (uses: actions/checkout@v4) — actions/checkout is genuinely the single most common first step in almost every real workflow, since without it, the runner's fresh workspace has no source code to build or test at all.
06
Once this workflow file is committed and pushed, GitHub Actions runs it AUTOMATICALLY on every matching push — no separate registration, no external tool to configure — genuinely the fastest possible path from zero to a real, working CI pipeline, which is exactly why this topic uses it as the first concrete, hands-on example before Phase 2 goes deeper.

Code & diagrams

.github/workflows/ci.ymlmarkdown

A genuinely complete, minimal pipeline — checkout, build, test, on every push.

name: CI

on:
  push:
    branches: [main]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out the repository
        uses: actions/checkout@v4

      - name: Set up Java
        uses: actions/setup-java@v4
        with:
          java-version: "21"
          distribution: "temurin"

      - name: Build and test
        run: mvn clean package

first-pipeline.shmarkdown

Commit, push, and watch it run — the entire loop, once, concretely.

mkdir -p .github/workflows
# (save the workflow YAML above as .github/workflows/ci.yml)

git add .github/workflows/ci.yml
git commit -m "Add a minimal CI pipeline"
git push

# On GitHub: open the repository's "Actions" tab
# — the workflow should already be running, triggered automatically by the push
# — click into it to watch each step's live output, exactly like a terminal

Explain it without notes

Why does almost every real workflow's very first step use actions/checkout, and what would happen if it were left out?

Why does committing a workflow file to .github/workflows/ automatically make GitHub start running it, with no separate setup step?

Practice

Create the example workflow file (adjusted for your own project's build tool) in a real GitHub repository, push it, and watch it run in the Actions tab.

Deliberately break the build (introduce a compile error or a failing test), push it, and observe the workflow report a failure — then fix it and confirm a subsequent push succeeds.

Trade-offs

↔
This minimal pipeline (checkout, build, test) is deliberately small — genuinely useful as a real starting point, but it doesn't yet handle caching (Phase 1.3), matrix testing across multiple versions (Phase 1.4), secrets, environments, or deployment at all — every one of those is a deliberate, incremental addition on top of this exact same foundational shape, not a replacement for it.

Done when you can

I can identify the minimum three things any real pipeline needs to do: checkout, build, test.
I have created and pushed a real, working GitHub Actions workflow and watched it run.
I understand why CI/CD configuration lives in the repository itself, reviewed like any other code change.