Building a CI Pipeline with GitHub Actions

1. What is GitHub Actions?

GitHub Actions is a powerful automation tool built directly into GitHub. It allows you to create custom workflows that respond to events in your repository, such as a code push or a pull request. We'll use it to define and run our CI pipeline.

A workflow is defined in a YAML file and is composed of several key components:

• Workflow: The overall automated process.
• Event: The trigger that starts the workflow (e.g., push).
• Job: A set of steps that execute on a virtual server, called a runner.
• Step: An individual task within a job, which can run shell commands or use a reusable Action.
• Action: A pre-packaged, reusable command that simplifies complex tasks (e.g., checking out code or setting up Java).

To get a feel for how these concepts translate into a workflow file, let's explore a guide that breaks down the YAML syntax.

2. Building Your CI Workflow Step-by-Step

We are now ready to create our first workflow. This workflow will perform the "Build" and "Test" stages of our pipeline. For a Java Maven project, this means compiling the code, running the unit tests, and packaging the application.

We will create a single job named build-and-test that performs the following steps:

1. Checks out the source code from our repository.
2. Sets up the correct JDK version.
3. Caches Maven dependencies to speed up future runs.
4. Runs the mvn package command to build the application and run tests.

The following video provides an excellent walkthrough of this process. We will follow its structure to build our workflow.

Step 1: Create the Workflow File

First, you need to create the directory structure and the YAML file for your workflow inside your Spring Boot project. GitHub Actions automatically discovers workflows placed in a specific folder.

After this step, your main.yml file should look something like this:

name: Java CI with Maven

on:
  push:
    branches: [ "main" ]

Step 2: Define the Job and Steps

Next, we'll define our job. This involves specifying the runner environment and outlining the sequence of steps.

Your file will now have a jobs section:

# ... (name and on sections) ...

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest
    steps:
      # We will add steps here

Step 3: Implement the Workflow Steps

Now, let's fill in the steps with the actions needed to build and test our application.

1. Check out the code: The first step in any CI job is to get a copy of your repository's code onto the runner.

2. Set up JDK and Cache Dependencies: The runner needs the correct Java version. We can also use this step to cache our Maven dependencies, which will make subsequent pipeline runs much faster.

To enable caching, we simply add a cache property to this step. This is a powerful feature of the setup-java action.

3. Build and Test with Maven: Finally, with the environment set up, we can run the Maven command to compile, test, and package our application.

3. The Complete Workflow and Execution

After following all the steps, your complete main.yml file should look like this:

name: Java CI with Maven

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

jobs:
  build:
    name: Build and Test
    runs-on: ubuntu-latest

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

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

    - name: Build with Maven
      run: mvn -B package --file pom.xml

Note: I've also added a pull_request trigger, which is a common practice to ensure code is tested before it's even merged.

Now, commit this file to your local repository and push it to the main branch on GitHub.

git add .github/workflows/main.yml
git commit -m "feat: Add CI workflow for build and test"
git push origin main

Once you've pushed the change, navigate to your repository on GitHub and click the "Actions" tab. You should see your workflow running!

Click on your workflow run to see the Build and Test job. You can expand each step to see its detailed log output. A green checkmark means everything succeeded!

on:
  push:
    branches: [ "main", "develop" ]
  pull_request:
    branches: [ "main", "develop" ]

Conclusion

Congratulations! You have successfully created your first automated Continuous Integration pipeline. You've taken a crucial step from manual, local commands to a repeatable, automated process that safeguards your project's quality.

Key Takeaways:

• GitHub Actions workflows are defined in YAML files located in the .github/workflows directory.
• Workflows are triggered by events (like push) and consist of one or more jobs.
• Jobs run on runners and are made up of a sequence of steps.
• We use pre-built Actions like actions/checkout and actions/setup-java to handle common tasks.
• The run command executes shell scripts, allowing us to run our mvn -B package command.
• The "Actions" tab in GitHub provides real-time monitoring and detailed logs for your workflow runs.

What's Next?

Our CI pipeline now builds and tests the code, but the resulting .jar file simply disappears when the runner shuts down. In our next lesson, Extend the CI pipeline to automatically build and publish a Docker image to a registry, we will add more steps to our workflow. We will use the Dockerfile you created in a previous lesson to build a Docker image and push it to a container registry like Docker Hub, making it ready for deployment.