Git + Maven + Jenkins + Gitlab + Nexus


When you are building software for multiple clients, multiple configurations and architectures you need a common way to deal with software building. The usual way of doing is not useful anymore.

We found project were you have to build a system for JBOSS 7 AS with EJB and J2EE compliance while maintaining a version for Tomcat 6, built on WARs and Spring. The system can have two flavors, JPA one and pure Hibernate and must run over Mysql, Oracle or Postgresql. Maybe others.

When a customer requires a release of a new version, you must provide a clean environment no matter what happened on development side.

This is why we built our CI environment based on this tools:

  • Git: We need to track every version of the files over time. And ensure that nothing breaks between changes.
  • Maven 3: Our build system must track dependencies, be able to build different types of packages and allow customization on each build.
  • Sonatype Nexus: We must track every version that’s deployed to the client. And also make available to all team every new version of each library. Additionally it also stores a clean version of each product, ready to be deployed.
  • Jenkins: Is the loyal majordomo that joins all together.
  • GitLab: It eases software management, let us to write tutorials about how to configure the software, and the most important. The “Hook” feature let’s Jenkins know when a repository has changed.

With all this in place our day to day is as follows:

  • Every project is built as needed. When code changes or developer requires a build.
  • Every dependent on the built project is built to see if nothing breaks.
  • A version of the “ready to use” packages are made available for the rest on Nexus.

And developer even doesn’t knows that this happened.





We suppose that you have every product installed and running. We are going to join every piece together.

So we are going to:

  1. Jenkins needs access to GitLab repository so it can download (clone) the latest repo when it’s changed.
  2. GitLab must inform Jenkins over repo changes.
  3. Jenkins also need access to Sonatype Nexus to upload new versions when everything is compiled and ready to use.
  4. Jenkins maven need to be access to company repos.



An user must be created in GitLab, this can be done as administrator in the GitLab Panel:



Now we must create a public and private key so it can access to the repos.



$> ssh-keygen -t rsa -C ""
$> cat ~/.ssh/

And what it shows is what you have to put in the key.

And now you have to copy the keys to the jenkins server under the jenkins home. In my case from /etc/passwd:


So I created a directory there called .ssh where I put both keys, public and private. Is this a security risk? Maybe I have to check and surely change the home of jenkins in the OS.



Now we must give access to Jenkins to Sonatype Nexus. This is done in the interface.


Remember the password you set to Jenkins user because you will need it for configuring access to the repos. This is done by editing ~/.m2/settings.xml of the jenkins user.


 <?xml version="1.0" encoding="UTF-8"?>
<settings xmlns=""


If you need to give it access to another repos, please add it here. I only added support for nexus-snapshots repo. And you will ask. What’s the nexus-snapshot repo? Well this depends on the project jenkins it’s building. More on this later.



Well, now our Jenkins majordomo is ready to build. Let’s build a task. But first we must tell Jenkins to use the SSH credentials created on the server under his user.



We are telling Jenkins to use the private key to access any resource it needs. Remember we configured and copied the keys on the GitLab step.



We tell Jenkins to access GitLab to clone the repo on building. And also we tell it must compile the master branch. In our case we will not use master, we prefer to use develop because we use another methodology called gitflow. You can read more about this here.


You can make Jenkins to compile only the branch where you did commit by setting the “Branches to build” to origin/${gitlabTargetBranch}. But it will only work when GitLab launches the compilation so make sure to launch always from GitLab by using “Test Hook”.




We tell Jenkins to build it whenever a dependency changes or when GitLab informs it that the code changed. To see the GitLab stuff you must have the GitLab plugins installed on Jenkins.



And also we want to build the project and if it compiles upload it to Nexus. It’s great that Jenkins now about Nexus because the only think you have to do it is configure credentials as done before, and let the system perform as expected.



I tell Jenkins execute after build steps only when inestable of good. This means that we will have a version if it compiles. The action after is “Deploy to maven repository”. And it knows what to do.





When we upload a new change to Gitlab, it will tell Jenkins that something changed. It will use maven to compile the code and if everything went okay, automagically it will upload the version to Nexus. It’s magic!!!

I will post some pictures of the result when I do a change… 😀



4 thoughts on “Git + Maven + Jenkins + Gitlab + Nexus

  1. Hello
    Thanks for your explanations.
    About gitLabJenkins exchanges, I can set up a jenkins project to get the gitlab stuff and compile it, but it only works manually.
    I set up an hook in gitLab that points to my project’s url and the hook test is OK,but pushing a new version in the repo does not launch the jenkins project.
    Any advice or info on how you set up the gitlab hook ?

    • Hi Arnaud,
      It seems there’s a problem in the latest versions of the jenkins gitlab plugin. I downgraded it and got it working. But I was unable to check what’s the exact version that left the system not working. So if you guess it, please post it.

      Hope it helps

    • Hi Derek,
      Of course! Do it. I appreciate your software… 😀

Leave a Reply

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