CI/CD pipeline and package registry (domain project) for MuleSoft hybrid deployment using GitLab
- March 31, 2022
Continuous integration/continuous delivery (CI/CD) is the practice of building and releasing software in an automated and safe manner. This tech article is about the CI/CD pipeline and how to deploy a domain project JAR for the Maven reference in the Package Registry of GitLab.
Prerequisites
- GitLab account
- Anypoint Platform account
- Standalone Mule Server
- Container Registry — for example, Nexus or jFrog (if using Maven dependencies, which aren’t found in .m2/repository)
NOTE: If the client account doesn’t have a Nexus Repository, then contact MuleSoft support to get a Nexus Repository for free.
Objectives
- To deploy a domain project to the Package Registry of the GitLab
- To deploy a MuleSoft application having a domain project to Anypoint Platform using Mule Standalone Server with GitLab Pipeline
Deploy a domain project in Package Registry
- Create an empty project and name it Package Registry
- In the Settings, go to the Repository and expand the Deploy Token sections. Fill in the name and expiration (otherwise the token will remain active until it’s exclusively deleted) properties and create a token
- Save the token externally, as it will not be shown again
You can also create the deployment token from a personal account. Go to the dropdown menu in the top right corner, select Preferences and Access Token.
Authenticate to the Package Registry with Maven
Add the credentials — as follows — in the settings.xml of the Maven.
Authenticate with a personal access token in Maven
To use a personal access token, add the following section to your settings.xml file. The name must be Private-Token.
Authenticate with a deploy token in Maven
To use a deploy token, add the following section to your settings.xml file. The name must be Deploy-Token.
Use the GitLab endpoint for Maven packages
To use the GitLab endpoint for Maven packages, choose one of the following options:
- Project-level. Use a project-level endpoint to publish Maven packages to a project. To install Maven packages, use a project-level endpoint when you have only a few Maven packages and they’re not in the same GitLab group.
- Group-level. Use a group-level endpoint when you want to install packages from many different projects in the same GitLab group.
- Instance-level. Use an instance-level endpoint when you want to install many packages from different GitLab groups or in their own namespace.
The option you choose determines the settings you add to your pom.xml file.
In all cases, to publish a package you need:
- A project-specific URL in the distributionManagement section
- A repository and the distributionManagement section
Project-level Maven endpoint
The relevant repository section of your pom.xml in Maven should look like this:
The ID is what you defined in settings.xml.
The PROJECT_ID is your project ID, which you can view on your project’s home page.
Replace gitlab.example.com with your domain name.
To retrieve artifacts, use either the URL-encoded path of the project (for example, group%2Fproject) or the project’s ID (for example, 42). However, only the project’s ID can be used for publishing.
Group-level Maven endpoint
If you rely on many packages, it might be inefficient to include the repository section with a unique URL for each package. Instead, you can use a group-level endpoint for all the Maven packages stored within one GitLab group. Only packages you have access to are available for download.
The group-level endpoint works with any package name, so you have more flexibility in naming. However, GitLab doesn’t guarantee the uniqueness of package names within the group. You can have two projects with the same package name and package version. In such cases, GitLab serves whichever one is more recent.
This example shows the relevant repository section of your pom.xml file. You still need a project-specific URL to publish a package in the distributionManagement section.
For the ID, use what you defined in settings.xml.
For the GROUP_ID, use your group ID from your group’s home page.
For the PROJECT_ID, use your project ID from your project’s home page.
Replace gitlab.example.com with your domain name.
To retrieve artifacts, use either the URL-encoded path of the group (for example, group%2Fsubgroup) or the group’s ID (for example, 12).
Publish a package
After you set up the remote and authentication and configure your project, publish a Maven package to your project.
Publish by using Maven
To publish a package by using Maven:
If deployment is successful, the build success message should display. The message should also show that the package was published to the correct location.
Once the package is deployed, you can take the dependency to install the JAR from the project/group package registry.
Deploy a MuleSoft application to Anypoint Platform using Mule Standalone Server with GitLab Pipeline
- Before starting the server, download the domain project .jar file from the Package Registry and add it to the domain folder of your runtime (if any).
- Create a develop branch in the project and check-in the folders and file in the project repository.
- Once the branch is created, go to settings -> repository -> protected branches and add the branch/branches to the protected branches so that whenever you create a pipeline variable, it allows you to mask the variable.
- Open the pom.xml of the project and add the armDeployment properties in the configuration for the Standalone/Hybrid Deployment Model.
- Create a .gitlab-ci.yml file, as the GitLab CI/CD automatically detects the pipeline file.
- Within the .gitlab-ci.yml file, write the following pipeline code:
- The values of username, password, environment, businessGroup, mule_env_build and mule_key_build are taken from the group variable (go to group -> settings -> CICD -> Variable) and make sure that the variable values are masked and protected. (If the branches are protected, then only it will take the values of the variable from the defined pipeline variable.)
- The values of mule.env and key for the API-level encryption and decryption must be defined in the wrapper.conf of the Mule Runtime (as well as the values for anypoint clientId/ClientSecret and anypoint URL).
- The build stage will execute for each environment and rules for each environment if different.
Develop environment
If the commit is made in the develop branch, then only it will automatically start the pipeline deployment for the development environment.
Staging environment
If the commit is made in the staging environment or the trigger source is from the staging environment, then only it will run the staging deployment — but it will need approval to start the deployment because the method to deploy in staging is “Manual,” as show in the image below:
Production environment
Once the code is merged from the staging branch to the main branch, the build of the project will run automatically. Once the build stage is successful, it will need approval to deploy the code from the production pipeline to the Mule Runtime because the method of deployment over here is also “Manual.”
— By Ashutosh Kumar