Automating Java Builds with GitHub Actions

Source: Dev.to

We’ve all been there. You write code, it runs perfectly on your laptop, you push it, and… the build breaks for everyone else. Or worse, a bug sneaks into production because someone forgot to run the tests.

This is where Continuous Integration (CI) comes in.

In this guide we’ll break down a very simple GitHub Actions workflow that automatically builds and tests a two‑microservice application (Order Service & Product Service) every time you push code.

What Problem Does This Solve?

Before we look at the code, let’s understand why we need it. This YAML file lives in your repository and solves three massive problems:

• Consistency – It builds your code in a clean, neutral environment (Ubuntu), not on your potentially messy laptop.
• Early Bug Detection – It runs your tests automatically on every Pull Request, so you can’t merge broken code.
• Monorepo Support – It handles multiple services (Order Service and Product Service) in a single repository, ensuring a change in one doesn’t break the other.

The Workflow File

Here is the complete ci.yml file we will be analyzing:

name: Java CI with Maven

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

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

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

      - name: Build and Test Order Service
        working-directory: ./OrderService
        run: |
          chmod +x mvnw
          ./mvnw clean verify

      - name: Build and Test Product Service
        working-directory: ./ProductService
        run: |
          chmod +x mvnw
          ./mvnw clean verify

The Code Breakdown

1. The Setup & Triggers

name: Java CI with Maven

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

• name – How the workflow appears in the Actions tab on GitHub.
• on – The events that trigger the workflow.
  • push – Runs whenever code is pushed to the main branch.
  • pull_request – Runs whenever a PR targets main (crucial for code review).
  • workflow_dispatch – Adds a “Run workflow” button so you can start it manually (great for debugging).

2. The Environment (The Job)

jobs:
  build:
    runs-on: ubuntu-latest

• jobs – A workflow consists of one or more jobs; here we have a single job called build.
• runs-on: ubuntu-latest – GitHub provisions a fresh virtual machine running the latest Ubuntu release. All subsequent steps run on this VM.

3. The Steps (The Actual Work)

Step A – Get the Code

steps:
  - name: Checkout code
    uses: actions/checkout@v4

• uses – Pulls a pre‑made action from the GitHub Marketplace. actions/checkout clones your repository onto the runner so the rest of the workflow can access your files.

Step B – Prepare Java

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

• actions/setup-java – Installs Java on the runner.
• distribution: 'temurin' – Uses the Eclipse Temurin build of OpenJDK.
• cache: maven – Caches Maven dependencies between runs, dramatically speeding up builds.

Step C – Build the Microservices

Order Service

  - name: Build and Test Order Service
    working-directory: ./OrderService
    run: |
      chmod +x mvnw
      ./mvnw clean verify

Product Service

  - name: Build and Test Product Service
    working-directory: ./ProductService
    run: |
      chmod +x mvnw
      ./mvnw clean verify

• working-directory – Changes to the specified folder before executing the commands (necessary in a monorepo).
• chmod +x mvnw – Makes the Maven Wrapper executable.
• ./mvnw clean verify – Runs the Maven Wrapper, which guarantees the exact Maven version defined by the project. verify executes the full lifecycle up to integration‑test validation, providing a more thorough check than install alone.

How to Set This Up in GitHub

1. Open your project (locally or on GitHub).

2. Create the directory structure:

   .github/
   └─ workflows/

3. Create the workflow file:

   • Path: .github/workflows/ci.yml
   • Add the YAML content shown above.

4. Commit and push:

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

Once pushed, GitHub will automatically detect the new workflow. You can view its execution under the Actions tab, or trigger it manually via the Run workflow button.

Running the Workflow

git push origin main

Go to the “Actions” tab in your GitHub repository. You will see your workflow spinning up. If the circles turn green, your code is safe. If they turn red, you broke the build—and thankfully, you found out before your users did.

Sample Setup: ci.yml