I said "piece of cake", as I have already worked on jenkins pipeline, and knew about maven so that won't be a problem. But there was a hitch, "pipeline of Gitlab CI". I said "no problem, I'll learn about it" with a Ninja Spirit.
So for starters what is gitlab-ci pipeline. For those who have already work on Jenkins and maven, they know about the CI workflow of Building a code , testing the code, packaging, and deploy it using maven. You can add other goals too, depending upon the requirement.
The CI process in GitLab CI is defined within a file in the code repository itself using a YAML configuration syntax.
The work is then dispatched to machines called runners, which are easy to set up and can be provisioned on many different operating systems. When configuring runners, you can choose between different executors like Docker, shell, VirtualBox, or Kubernetes to determine how the tasks are carried out.
We will be establishing a CI/CD pipeline using gitlab-ci and deploying artifacts to NEXUS Repository.
- Gitlab server, I'm using gitlab to host my code.
- Runner server, It could be vagrant or an ec2 instance.
- Nexus Server, It could be vagrant or an ec2 instance.
- Artifacts: Objects created by a build process, Usually project jars, library jar. These can include use cases, class diagrams, requirements, and design documents.
- Maven Repository(NEXUS): A repository is a directory where all the project jars, library jar, plugins or any other project specific artifacts are stored and can be used by Maven easily, here we are going to use NEXUS as a central Repository.
- CI: A software development practice in which you build and test software every time a developer pushes code to the application, and it happens several times a day.
- Gitlab-runner: GitLab Runner is the open source project that is used to run your jobs and send the results back to GitLab. It is used in conjunction with GitLab CI, the open-source continuous integration service included with GitLab that coordinates the jobs.
- .gitlab-ci.yml: The YAML file defines a set of jobs with constraints stating when they should be run. You can specify an unlimited number of jobs which are defined as top-level elements with an arbitrary name and always have to contain at least the script clause. Whenever you push a commit, a pipeline will be triggered with respect to that commit.
Strategy to Setup Pipeline
Step-1: Setting up GitLab Repository.
I'm using a Spring based code Spring3Hibernate, with a directory structure like below.
# Now lets start pushing this code to gitlab
# Adding the code to the working directory
# Committing the code
# Pushing it to gitlab
Step-2: Install GitLab Runner manually on GNU/Linux
# Simply download one of the binaries for your system:
# Give it permissions to execute:
# Optionally, if you want to use Docker, install Docker with:
# Create a GitLab CI user:
# Install and run as service:
Step-3: Registering a Runner
To get the runner configuration you need to move to gitlab > spring3hibernateapp > CI/CD setting > Runners
And get the registration token for runners.
# Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com/):
# Please enter the gitlab-ci token for this runner:
# Please enter the gitlab-ci description for this runner:
# Please enter the gitlab-ci tags for this runner (comma separated):
# Please enter the executor: docker, docker-ssh, shell, ssh, virtualbox, docker+machine, parallels, docker-ssh+machine, kubernetes:
# Please enter the default Docker image (e.g. ruby:2.1):
# You can also create systemd service in /etc/systemd/system/gitlab-runner.service.
[Unit] Description=GitLab Runner After=syslog.target network.target ConditionFileIsExecutable=/usr/local/bin/gitlab-runner [Service] StartLimitInterval=5 StartLimitBurst=10 ExecStart=/usr/local/bin/gitlab-runner "run" "--working-directory" "/home/gitlab-runner" "--config" "/etc/gitlab-runner/config.toml" "--service" "gitlab-runner" "--syslog" "--user" "gitlab-runner" Restart=always RestartSec=120 [Install] WantedBy=multi-user.targetStep-4: Setting up Nexus Repository
You can setup a repository installing the open source version of Nexus you need to visit Nexus OSS and download the TGZ version or the ZIP version.
But to keep it simple, I used docker container for that.
# Install docker
# Launch a NEXUS container and bind the port
You can access your nexus now on http://<public-ip>:8081/nexus.
And login as admin with password admin123.
Step-5: Configure the NEXUS deploymentClone your code and enter the repository
# Create a folder called
.m2in the root of your repository
# Create a file called
# Copy the following content in settings.xml
Username and password will be replaced by the correct values using variables.
# Updating Repository path in pom.xml
Step-6: Configure GitLab CI/CD for simple maven deployment.
GitLab CI/CD uses a file in the root of the repo, named,
.gitlab-ci.yml, to read the definitions for jobs that will be executed by the configured GitLab Runners.
First of all, remember to set up variables for your deployment. Navigate to your project’s Settings > CI/CD > Variables page and add the following ones (replace them with your current values, of course):
- NEXUS_REPO_URL: http://<nexus_ip>:8081/nexus/content/repositories/
- NEXUS_REPO_USER: admin
- NEXUS_REPO_PASS: admin123
.gitlab-ci.ymland push it to the repo:
Now add the changes, commit them and push them to the remote repository on gitlab. A pipeline will be triggered with respect to your commit. And if everything goes well our mission will be accomplished.
Note: You might get some issues with maven plugins, which will need to managed in pom.xml, depending upon the environment.
In this blog, we covered the basic steps to use a Nexus Maven repository to automatically publish and consume artifacts.