Java, Web and Mobile

Blog

Using Cache with GitLab-CI and speed up the Maven build

|
Continuous Integration

In the first three parts of our series about GitLab-CI we have seen how to set up some basic configuration and how to enable auto deployment. But until now our Maven build process always starts with downloading the world. So the log is filled with download information.

This guide walks you through the process to enable a cache for a maven build and how to hide download information during the building process by setting maven variables.

What you will achieve

A clean GitLab-CI log without download information.

What you will need

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

Set up

You can use any maven project in combination with the following GitLab-CI configuration or a similar one. If you have none on hand you can create one with spring initializer, just use the result of the previous guides of this series or use this sample programm.

Hide download information

Since a clean docker image has been used, the maven process starts with downloading a bunch of packages.

 

Click to enlarge

 

The first step should be to hide the downloading information as long everything works fine.

This can be achieved by setting the maven log level for file transfer to the level ‘warning’. The keyword ‘variables’ can be used in order to avoid setting the options for each job. Using ‘variables’ allows to specify general enviroment variables like “MAVEN_OPTS”.

Using the cache

The settings above clean up the logs but the same packages are still downloaded for each build execution. Caching this packages would speed up the build process all the time.

 

Click to enlarge

 

With GitLab-CI there are two possibilities to interchange data: Artifacts and Caches. As rule of thumb, we use the first to interchange data in one job between several stages and the second to interchange data between several jobs.

Firstly a local maven repository was set up. Secondly interchange of data between jobs like a local maven repository was enabled by the keyword ‘cache’. By specifying the cache with a keyword, we can configure if the cache is used for all jobs and all stages, or just for special branches and stages. This can be done by using the predefined variables.

But notice the cache is not necessary reliable! If your admin restricts the size of storage like Gitlab.com to 10 GB; old cache data may be deleted already. So cache is not usable for interchanging deployment artifacts. For this we use the ‘artifacts’, which is described in the second article of this series.

Conclusion

We have seen how to hide the not needed download information and how to use a cache to avoid unnecessary downloads.