Java, Web and Mobile

Blog

Getting started with GitLab-CI: Build and test your app

This guide walks you through the process of creating an initial GitLab-CI configuration with Docker. As first article in a series about the GitLab-CI, we create a basic CI configuration. In the following we will extend this one, with auto deployment, display of test coverage, caching and publishing documentation.

What you will achieve

On each push on GitLab, the project is automaticly build and tested.

What you will need

  • An account on a GitLab-Server (for example gitlab.com)
  • A sample program
  • Git in Version 2.0.0 or later
  • Jdk 1.8
  • Maven 3.0+

Set up

You start to create a new project in GitLab by cloning a new (empty) repository. In order to test your configuration a sample project is needed. You can use the provided sample programm or your own project. Notice that Maven is used for this guide. With minor configuration adaptions, you can also use other build tools as well.

Define a simple CI

By pushing a file with the name ‘.gitlab-ci.yml’ with the following content to the repository, the GitLab-CI is enabled. As starting point the following configuration is used:

The first line of this initial example configuration defines the used docker image, which will be discussed later. The other lines provide a job definition by stating a unique name: ‘compile’. Each job is a task which is independently run from other task in its own docker container. The job itself can be understood as shell script. After the ‘script’ key word, a series of shell commands can be used. In this case only one is needed: ‘mvn compile –batch-mode’.

Stages and Jobs

Like already mentioned, jobs may be run in parallel. So, if tasks have to be scheduled sequentially, another concept is needed: the so called stages. The stages are defined by the keyword ‘stages’. For example we could define two phases: build and test.

There are the default stages “build”, “test” and “deploy” defined without any explicite definition. The jobs are assigned to a stage with the keyword ‘stage’. By omitting the stage statement the job is assigned by Gitlab to the stage “test”. In the example below, the job ‘verify’ is assigned to the stage ‘test’ and run the tests.

Choose of image

Like already mentioned, the keyword ‘image’ defines the name of the Docker image. The Docker executor is performing the CI tasks. By default images can be choosen from the Docker Hub collection. But again this can be configured by setting the Docker pull policy to allow using local images. We will dedicate a special article to this topic. For the initial configuration the maven-jdk-8 image will be fine.

Conclusion

We have seen how to define jobs and how to run them in sequence. In our example, the first job compile the project and in the second job run the tests.

Your comment

Your email address will not be published. Required fields are marked *