Your First Pipeline

Last module you watched a pipeline run and read this site’s deploy in GitHub’s UI. Today you build one yourself: a real GitHub Actions workflow that checks out splitease-api, installs Java 21, and runs mvn verify on every push. Then you’ll break a test on purpose and watch your own pipeline go red — the moment CI/CD stops being a diagram and becomes a tool you own.

The Goal

By the end of this module you can:

• Write a working GitHub Actions workflow file from scratch — by hand, understanding every line
• Explain what checkout, setup-java, and mvn verify each do and why they’re in that order
• Trigger a real pipeline by pushing a commit, and read the result in the Actions tab
• Read a green run step by step, and a red run straight to the failing line
• Break a test on purpose and confirm the pipeline catches it — fail-fast in your own repo

The Lesson

Where the file lives — and why that exact path

A workflow is a YAML file in one specific folder: .github/workflows/. GitHub scans that folder on every push; any .yml it finds there becomes a pipeline. The path is not a convention you can move — GitHub looks only there.

splitease-api/
├── .github/
│   └── workflows/
│       └── ci.yml          ← your pipeline lives here
├── src/
├── pom.xml
└── ...

The name ci.yml is yours to choose; the folder is not. Create the two nested folders if they don’t exist (the leading dot matters — .github, not github).

The whole file, then every line

Here is a complete, real CI workflow for splitease-api. Read it once top to bottom, then we’ll walk it line by line.

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Check out the code
        uses: actions/checkout@v4

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

      - name: Build and test
        run: mvn --batch-mode verify

Now decode it. Indentation is structural in YAML — two spaces per level, never tabs — so the nesting is the meaning.

Why these three steps, in this order

The steps aren’t arbitrary — each depends on the one before:

flowchart LR
    A[fresh empty runner] --> B[checkout pulls your code]
    B --> C[setup-java installs the JDK]
    C --> D[mvn verify compiles and tests]
    D --> E[green or red]

1. Checkout first — the runner boots empty. No code, nothing to build. actions/checkout clones your exact commit onto it.
2. setup-java second — now there’s code, but no compiler. The runner doesn’t ship a JDK by default; setup-java installs Java 21 and puts java and mvn on the PATH. Skip this and mvn fails with “command not found.”
3. mvn verify last — code is present, JDK is installed, now do the work.

Order is causal: you can’t compile code you haven’t downloaded with a compiler you haven’t installed.

What mvn verify actually does

mvn verify is the workhorse line. Maven has a lifecycle — an ordered chain of phases — and naming a phase runs it and every phase before it. verify sits near the end, so this one command runs the whole CI sequence:

flowchart LR
    A[compile] --> B[test]
    B --> C[package]
    C --> D[verify]

So mvn verify is build → test → package in a single command — exactly the CI half of the pipeline from module 01. The --batch-mode flag tells Maven it’s running unattended (no colour codes, no prompts), which is what you always want on a CI runner. If any phase fails, Maven exits non-zero, the step goes red, and — fail-fast — the pipeline stops. (Tests live in Spring Boot 08 — Testing; this is where they pay off, running automatically on every push instead of only when you remember.)

How GitHub knows it passed or failed

The runner reports the exit code of each step. A shell command (or mvn) that succeeds exits 0; any failure exits non-zero. GitHub reads that: 0 is a green check, anything else is a red X and the job stops. You never tell GitHub “this passed” — it infers it from the exit code, which is why a failing test (which makes mvn exit non-zero) automatically fails the pipeline with no extra config.

Check The Concept

How This Shows Up At Work

• Day one on a new team. You clone the repo and the first file you open is .github/workflows/. Reading it tells you how the project is built and tested faster than any README. Being fluent in this YAML is table stakes.
• The PR that can’t merge. A teammate’s pull request shows a red ✗ next to “CI / build.” They can’t merge until it’s green. You point them at the failing step’s log; the failing test name is right there. This loop happens dozens of times a week on any real team.
• The “add a check to CI” task. A bug slips through, so the team adds a step (a linter, a coverage gate) to the workflow. Knowing where steps go and how uses: vs run: differ is what lets you make that change in five minutes instead of asking around.
• The interview live-task. “Here’s a repo, add CI that runs the tests on every push.” If you can write the checkout → setup-java → mvn verify workflow from memory and explain the step order, you’ve demonstrated the practical half of CI/CD on the spot.

Build This / Try This

You’ll add a real pipeline to splitease-api, push it, watch it go green, then break it on purpose and watch it go red. All in PowerShell from the project root.

1. Create the folder and file. From the splitease-api repo root:

New-Item -ItemType Directory -Force .github\workflows

Then create .github\workflows\ci.yml with the exact YAML from the Lesson (the full file). Type it — your fingers learning the indentation is the point.

2. Commit and push — the push is the trigger:

git add .github/workflows/ci.yml
git commit -m "ci: run mvn verify on every push"
git push

3. Watch it run. Open your repo on GitHub → the Actions tab. A run named CI appears within seconds, with a spinning amber dot. Click it → click the build job → expand the steps. You’ll see them execute in order:

✓ Set up job
✓ Check out the code
✓ Set up Java 21
✓ Build and test          ← mvn verify runs here, the slowest step
✓ Complete job

When the dot turns green, you just ran your first pipeline. Read the “Build and test” log — you’ll see Maven’s BUILD SUCCESS and the test count, the same output you’d get locally, now produced by a robot on a clean machine.

4. Confirm the trigger works again. Make any trivial change (a comment), commit, push. A second run appears. Every push is a run — that’s CI.

5. Break it on purpose — watch it go red. Open any test in src/test/java and sabotage one assertion so it must fail. For example, change a settle-up test’s expected value:

// was: assertThat(balance).isEqualTo(0);
assertThat(balance).isEqualTo(999);   // deliberately wrong

Commit and push:

git add .
git commit -m "test: break a test on purpose to see CI go red"
git push

6. Read the red run. Back in the Actions tab, the new run gets a red ✗. Click it → the build job → the Build and test step is red, and no steps after it ran — fail-fast, in your own repo. Expand the log and scroll to the failure: Maven prints the failing test’s class, method, and the expected-vs-actual mismatch (expected: 0 but was: 999). That is the pipeline doing its entire job — a bad change caught in two minutes, never reaching anyone.

7. Fix it back. Restore the assertion, commit, push. The next run goes green. You’ve now seen both halves: green proves safe, red holds the gate. Leave the workflow in place — it’ll protect every future push to splitease-api.

Interview Practice

These come up in backend and SDE rounds at Indian product companies — narrate the answer, don’t just name a tool.

Where to Practice

Check Yourself

1. What’s the exact folder a workflow file must live in?
2. Name the three steps of the splitease-api workflow, in order, and what each does.
3. Why must checkout run before setup-java?
4. What does mvn verify run, and why is it more thorough than mvn test?
5. How does GitHub know a step passed or failed?
6. What does runs-on: ubuntu-latest give you, and why does “fresh every time” matter?
7. Why also trigger on pull_request and not only push?
8. You broke a test; describe exactly what you’d see in the Actions tab.

Explain it out loud: Without looking, recite the workflow file — name, on, jobs, runs-on, the three steps — and say what each line does and why the steps are in that order. Then explain what happens, step by step, from git push to a green check in the Actions tab. If you can’t say why checkout comes first, re-read the step-order section.

Why AI Can’t Do This For You

AI will generate this YAML instantly, and for a standard Maven project it’ll even be correct. But the skill isn’t the file — it’s reading your red run at 11pm: why did mvn verify pass on your laptop and fail on the runner? Was it a missing service container, a Java version mismatch, a test that depended on your local timezone? AI can’t see your runner’s log, your test’s hidden assumptions, or what you changed last commit.

You built and broke this pipeline yourself today, so when a real one goes red you know exactly where to click and what the failing line means. The YAML is cheap and copyable; the debugging instinct — formed by watching your own pipeline go green and red — is the thing that makes you useful on a team, and no prompt hands it to you.

Module done? Add it to today’s tracker