Lesson 01 · Pipelines with GitHub Actions

Beyond the 1Z0-830 exam

Continuous Integration means every change is built and tested automatically — so breakage is caught in minutes, not at release. GitHub Actions is the most common CI for Java projects on GitHub: declarative YAML workflows that run your Maven/Gradle build on every push and pull request.

Objectives

After this lesson you will be able to:

• Explain CI and why it runs tests on every change.
• Read and write a basic GitHub Actions workflow for a Maven build.
• Use a build matrix to test multiple JDKs/OSes.
• Cache dependencies to speed builds.

What CI is (and isn't)

Continuous Integration: merge small changes frequently, and have an automated server build + test each one. The payoff is fast feedback — a broken test or compile error is flagged on the PR, before it reaches main. (Continuous Delivery/Deployment extends this to automatically releasing; that's out of scope here — see CURRICULUM.md.)

Anatomy of a workflow

A workflow is YAML in .github/workflows/. Events trigger jobs, each a sequence of steps:

name: build
on:                          # events that trigger the workflow
  push:
    branches: [ main ]
  pull_request:

jobs:
  test:                      # a job runs on a fresh VM ("runner")
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4              # check out the repo
      - uses: actions/setup-java@v4            # install a JDK
        with:
          distribution: temurin
          java-version: '21'
          cache: maven                         # cache ~/.m2 between runs
      - run: mvn -f labs/pom.xml test          # the build/test command

• on — when to run (push, pull_request, schedule/cron, manual).
• jobs — run in parallel by default; each on a clean runner.
• steps — uses: a prebuilt action or run: a shell command.

Nightly full runs

A schedule: trigger (cron) is how you run the full suite nightly while PRs run only the fast subset (Lesson 03). workflow_dispatch: adds a manual "Run" button.

Build matrix

A matrix fans one job out over combinations — verify the labs on multiple JDKs in parallel:

strategy:
  matrix:
    java: [ '17', '21' ]
    os: [ ubuntu-latest, windows-latest ]
runs-on: ${{ matrix.os }}
steps:
  - uses: actions/setup-java@v4
    with: { distribution: temurin, java-version: '${{ matrix.java }}' }

That's 2 × 2 = four parallel jobs. Matrices are also how you run UI tests across browsers (Module 18).

Gotcha — pin versions and don't leak secrets

Pin actions to a major version (@v4) for reproducibility, and never hard-code tokens. Use secrets (${{ secrets.MY_TOKEN }}) — they're masked in logs. A committed credential is a security incident (Module 19).

Caching for speed

Re-downloading every dependency on each run is slow. actions/setup-java's cache: maven (or a manual actions/cache keyed on pom.xml) restores ~/.m2, so a warm build skips the downloads. Fast CI is CI people actually wait for — slow pipelines get bypassed.

SDET note

Treat the pipeline as code you test and review. A green local build that's red in CI usually means a hidden dependency on local state — an env var, a file path, a running service, the system locale or clock (Module 14). CI's clean runner is the honest environment; make your tests pass there.

Key Takeaways

• CI builds and tests every change automatically for fast feedback before merge.
• A GitHub Actions workflow is YAML: events → jobs (parallel, clean runners) → steps (uses/run).
• A matrix runs a job across JDKs/OSes/browsers in parallel; a cron schedule drives nightly full runs.
• Cache ~/.m2 to speed builds; use secrets (never hard-coded tokens).
• The clean CI runner exposes hidden local-state dependencies — make tests pass there.

Lesson Quiz

Lesson Quiz · Pipelines with GitHub Actions0 / 5

1. The core goal of Continuous Integration is…

   • ADeploying to production automatically
   • BBuilding and testing every change automatically so breakage is caught fast
   • CWriting documentation
   • DReplacing code review

2. In a GitHub Actions workflow, jobs by default…

   • ARun sequentially on one machine
   • BRun in parallel, each on a fresh runner
   • CShare the same filesystem
   • DNever run on pull requests

3. A build matrix is used to…

   • AEncrypt secrets
   • BRun the same job across combinations (JDKs, OSes, browsers) in parallel
   • CCache dependencies
   • DSchedule nightly runs

4. Why cache ~/.m2 in CI?

   • ATo store test results
   • BTo avoid re-downloading dependencies every run, speeding up builds
   • CTo hide failures
   • DIt's required to compile

5. A test that passes locally but fails in CI most often indicates…

   • AA GitHub bug
   • BA hidden dependency on local state (env var, path, running service, locale/clock)
   • CThe runner is too fast
   • DCaching is disabled

---

Next: Docker & Testcontainers. This module's lab is in labs/src/main/java/com/jse21/m20_cicd/.