How to Use Gitlab-CI with Nexus

Recently I was asked to set up a CI-Pipeline for a Spring based application.

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 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.

What We Are Going to Do?

We will be establishing a CI/CD pipeline using gitlab-ci and deploying artifacts to Nexus Repository.

null

Resources Used:

  1. Gitlab server, I’m using gitlab to host my code.
  2. Runner server, It could be vagrant or an ec2 instance.
  3. Nexus Server, It could be vagrant or an ec2 instance.

Before going further, here are a few terminologies. 

  • 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 (Read more...)

*** This is a Security Bloggers Network syndicated blog from Sonatype Blog authored by Sudipt Sharma. Read the original post at: https://blog.sonatype.com/how-to-use-gitlab-ci-with-nexus