GitLab + MuleSoft + CICD
Introduction
This is yet another blog regarding CI/CD of MuleSoft applications using GitLab. The target audience of this article is MuleSoft beginners only. If you are experienced, you can happily skip this article and you will not miss anything.
The Goal
My goal is straightforward. Every time I make some changes in my Mule application and push my codes to GitLab, a CI/CD pipeline will run which will eventually build my code and on success will deploy the artifacts to CloudHub.
That's it!
MuleSoft Application
I have a simple Hello World application for which I want to streamline the build & deployment process. Application source code is not the focus here.
So, before doing anything let's init the git repository for the application.
git init -b master
git remote add origin https://gitlab.com/USERNAME/ag-gitlab-cicd
git add .
git commit -m "Initial import"
git push origin master
After the last command execution, we should have our brand new repository created in GitLab.
Article Navigation
I have divided the article into two sections.
GitLab Configuration
CI/CD configuration for MuleSoft application
If you are going to use GitLab's shared Runner you can skip the first part.
GitLab Configuration
If you like to use the Shared Runner of GitLab you can skip this phase. But, for a personal touch, I would like to configure my own runner.
To do that click the CI/CD menu as shown below.
Next, expand the Runners section.
Now, here we go.
Click the link and you will land on the perfect page to configure your own Runner. In my case, I would go for the Docker runner. Installation steps are quite straightforward, so I will note down the exact steps I executed on my MacBook.
Note that you need to have a Docker engine running on your machine. Execute the below command to create the runner container.
That's it. It will start a container named gitlab-runner-docker
Next, we will need to register this runner with our GitLab which is running in the cloud. It's easy.
Execute the below command:
Once executed it will ask for some data as shown below.
Note that for the executor, I have selected docker, and for tags I put docker. (Can be anything you want). Tags will help you choose the particular runner at the time of defining the pipeline. We will use this tag in the later sections of this article.
Cool. Once done now you can have your own runner registered in GitLab.
You can click the blue link to check more information about the Runner. Check this.
You can also verify that in your Docker runtime there is a container running called gitlab-runner-docker.
At this point, our on-prem Runner configuration is done.
CI/CD configuration for MuleSoft application
For the CI/CD configuration of my demo application, I will use MuleSoft's maven plugin. I will not delve too much into it because it's quite simple and the documentation is self-explanatory.
Maven Plugin Configuration
For the authentication part with Anypoint Platform, I have chosen the Connected App option which is much more secure than providing your login and password in the configuration.
Above is my simple configuration. Upon successful build, the application named ag-gitlab-cicd will be deployed to CloudHub. No more secret. Below is the maven command for this, directly copied from the document.
mvn clean package deploy -DmuleDeploy
You can try this out locally before configuring the pipeline.
Pipeline configuration
Open the ag-gitlab-cicd project and navigate to the below section.
Let's create a mock template. Click this button and GitLab will create a test pipeline template for us.
Commit the change. You will find the file called .gitlab-ci.yml in your root folder of the repository. That's our pipeline template.
Click the CI/CD → Editor section and it will take you to the section where you can edit the pipeline configuration.
Now, let's create our simple pipeline.
Important things to note here:
The pipeline is going to run in a container whose base image is maven:3.8.2-jdk-8
There is only one stage for this pipeline i.e deploy
I have specified my local runner for the pipeline to run. It's done through the tags element. Note that in the previous section when we configured the runner, I provided a tag called docker.
In the scripts section, I just provided the necessary maven command to execute in the container.
That's the simplest possible pipeline. Definitely, you should go for parametrizing the values e.g clinet_id & client_secret, etc provided in the maven plugin of the pom file. I will keep this part for a later part of the article.
Executing the pipeline
Let's first disable the Shared Runner of the project. Go to
project →Settings → CI/CD → Runners
Expand the Runners and simply click the enable/disable button to disable it.
Now, the pipeline can be executed in either of the following two ways:
Make any changes in the code of the application and commit the changes. It will trigger the pipeline.
Or
Click the Run Pipeline button and it will execute.
Check the logs
Run the pipeline in either way. Now, if you list the docker containers in your system you can see that a new container is spawning up.
This new container is a temporary container that will actually execute the pipeline. It will download the maven dependencies, build the application and finally publish it to CloudHub. You can even do docker logs -f CONTAINER_ID to check the logs or if you prefer you can check logs in the web console itself.
After successful execution of the pipeline, you can have your application deployed in CloudHub. Check this,
Conclusion
This is the simplest possible pipeline that can be written for automating the build & deployment process of a Mule application using GitLab. Apart from the pipeline, I also covered how to configure your own runner for GitLab. In the next articles, let's try to improve this pipeline with more steps and parameters to store the secrets, etc.
Happy learning!!!
