Lecture 145: Integrating with GitLab CI — automatic build and testing

Today we'll take a closer look at GitLab CI, the built-in tool of the GitLab version control system for managing CI/CD processes. Its main benefit is seamless integration with your code repository. Right inside GitLab you can describe the whole build, test and even deploy process using a plain YAML file.

Core concepts of GitLab CI

Before jumping into practice, let's cover a bit of theory:

• Pipeline — a set of stages that automate the whole process (for example: build → test → deploy).
• Stage — an individual pipeline step (for example, "test" or "build").
• Job — a task inside a stage (for example, running tests).
• Runner — the executor that runs your jobs. Can be local or hosted by GitLab.

Think of it like a factory conveyor: code goes in at the input, and your CI/CD pipeline, like a well-trained robot, builds, tests, checks and, voilà, everything's ready!

Goals of this lecture

In today's session we'll:

1. Create a basic .gitlab-ci.yml for a Spring Boot project.
2. Set up build and test stages.
3. Make sure automatic build and testing run successfully on every commit.

Practice: Setting up GitLab CI for a Spring Boot project

1. Preparing the Spring Boot project

First, make sure your Spring Boot project already exists and is set up to work with Maven. For example, we have a small app that uses controllers, services and repositories.

Project structure:

my-spring-boot-app/
├── src/
│   ├── main/
│   │   ├── java/
│   │   └── resources/
│   │        └── application.yml
│   ├── test/
│   │   ├── java/
│   │   └── resources/
├── pom.xml

If you don't have a project yet — create one using Spring Initializr (https://start.spring.io).

Now that your project is ready, let's add a little "automation magic".

2. Creating the .gitlab-ci.yml file

This is the key file for CI/CD pipeline configuration; it's what controls the automation. The file should live in the root of your repository.

Example .gitlab-ci.yml for a Spring Boot project:

stages: # Define pipeline stages
  - build
  - test

variables:
  MAVEN_OPTS: "-Dmaven.repo.local=/cache/.m2/repository" # Cache local Maven dependencies

build:
  stage: build
  image: maven:3.8.5-openjdk-11 # Use a Docker image with Maven and JDK
  script:
    - mvn clean compile # Command to compile the project
  artifacts:
    paths:
      - target/ # Pass artifacts (e.g., jar files) to next stages

test:
  stage: test
  image: maven:3.8.5-openjdk-11
  script:
    - mvn test # Run the tests
  artifacts:
    reports:
      junit: target/surefire-reports/TEST-*.xml # Log test results

That's it! Now let's break down what we wrote here.

• stages: we list pipeline stages that run sequentially: first build, then test.
• image: we use a Docker image with Maven and Java 11. This helps reproduce the build environment.
• variables: here we set Maven options to speed up the build by caching dependencies.
• script: the set of commands to run at each stage.
• artifacts: files passed between stages or included in the pipeline results.

P.S.: YAML might look like a bunch of spells at first. But really you just need to learn indentation and remember that the "colon" (:) separates key and value!

3. Testing the pipeline

1. Commit the .gitlab-ci.yml file to the repository:

   
   git add .gitlab-ci.yml
   git commit -m "Added GitLab CI"
   git push origin main
   

2. Open GitLab and go to CI/CD → Pipelines. There you'll see the pipeline running. If everything is set up correctly, the build and test stages should complete successfully (green 🎉).

Common errors and how to fix them

1. Error: "No such file or directory"
   • This means the GitLab Runner can't find some file or directory (for example, pom.xml). Make sure your project is correctly pushed to the repository.
2. Error: "Permission denied"
   • The Runner might not have permissions to run commands. Check the access rights of your Runner.
3. Build error: "Dependency not found"
   • Make sure your Maven project is configured and all dependencies are listed in pom.xml.

How does this help in real life?

Now every time you make changes to the repository (for example, add new features), your code is automatically compiled, tested and checked. You'll know right away if something breaks.

Now go ahead — add automation, you're on the verge of building a truly professional pipeline!