GitHub Actions CI/CD Pipeline for MuleSoft Cloudhub Deployment

Author: Satyam Singh

In this article, we will set up a CI/CD pipeline using GitHub Actions.



  1. GitHub account. You can create an account from this link:
  1. Anypoint Platform Account.
  2. Anypoint Studio.


CI/CD stands for Continuous Integration and Continuous Deployment/Continuous Delivery.

Continuous Integration is that concept as different members of the teamwork on code on different git branches. The code is merged to one working branch, which is then built and tested with automated workflows. This helps to constantly confirm everyone’s code is functioning properly together and is well-tested.

Continuous Deployment takes this a step further and takes this automation to the deployment level. In the CI process, you automate the testing, and therefore the building Continuous Deployment will automate deploying the project to an environment.


Github Actions

Actions are a comparatively new feature to GitHub, allowing you to line up CI/CD workflows employing a configuration file right in your Github repo. Previously, if you wanted to line up any automation with tests, builds, or deployments, you’d need to look to services like Circle CI and Travis or write your script.


Setting up  a workflow in  GitHub

  • Create a new Github repository.
  •  Now to we have to setup the workflow  Actions tab-> set up a workflow yourself and Commit the new file.

Copy the below code at place 1:

name: Java CI with Maven
on:  push:    branches: [ master ]  pull_request:    branches: [ master ]
jobs:  build:    runs-on: ubuntu-latest    steps:    – uses: actions/checkout@v2    – uses: actions/cache@v1      with:        path: ~/.m2/repository        key: ${{ runner.os }}-maven-${{ hashFiles(‘**/pom.xml’) }}        restore-keys: |          ${{ runner.os }}-maven-    – name: Set up JDK 1.8      uses: actions/setup-java@v1      with:        java-version: 1.8    – name: Build      run: mvn -B package –file pom.xml    – name: Stamp artifact file name with commit hash      run: |        artifactName1=$(ls target/*.jar | head -1)        commitHash=$(git rev-parse –short “$GITHUB_SHA”)        artifactName2=$(ls target/*.jar | head -1 | sed “s/.jar/.$commitHash.jar/g”)        mv $artifactName1 $artifactName2    – uses: actions/upload-artifact@master      with:          name: artifacts          path: target/*.jar
deploy:    needs: build    runs-on: ubuntu-latest    steps:        – uses: actions/checkout@v2    – uses: actions/cache@v1      with:        path: ~/.m2/repository        key: ${{ runner.os }}-maven-${{ hashFiles(‘**/pom.xml’) }}        restore-keys: |          ${{ runner.os }}-maven-    – uses: actions/download-artifact@master      with:        name: artifacts    – name: Deploy to CloudHub      env:        USERNAME: ${{ secrets.username }}        PASSWORD: ${{ secrets.password }}      run: |        artifactName=$(ls *.jar | head -1)        mvn mule:deploy -Dmule.artifact=$artifactName -Danypoint.userName=”$USERNAME” -Danypoint.password=”$PASSWORD”

This workflow will build a MuleSoft project and deploy it to CloudHub

  •  The workflow contains two jobs one to build the application and the other to deploy it to CloudHub. The Workflow is triggered by a push or pulls request on the master branch.


Build Job

  • MuleSoft is based on Java, so the next is to set up the Java environment for building the application.
  • Next is packaging, which will create an output jar file that will be used for deployment.
  • The last step of the build job is to upload the build artifact, which allows build and deploy jobs to share data between them.
  • Also, the Artifact output jar file will be available after the workflow is completed in your repository.


Deploy Job

  • First, the deployment will check the repository and retrieve all the dependencies.
  • Secondly, it will download the output jar file created and uploaded by the build job.
  • In the last step, it takes the Anypoint platform userName and Password from the environment secret and deploys the application in cloudhub.
  • Deploy job will only run when the build job is completed. If the build job fails then the deploy job will not run.


Setting up  Anypoint platform userName and Password in  GitHub

  • All the Credentials are stored in one place called secret in GitHub.
  • Give your Anypoint username and Password as a secret.


Setting up the mule Application

Add the CloudHub deployment configuration settings from the project POM file like the below screenshot. Few things to be note

  • The Mule version should be the same as the currently supported by CloudHub in Runtime Manager.
  • The application name should be unique across cloudhub.
  • ObjectStoreV2 setting should be set to true if not then by default it will be set for V1 which is not supported for using an Anypoint Platform Trial account.
  • All others should be set according to requirements.

Copy from below:

<cloudHubDeployment>    <uri></uri>     <muleVersion>4.3.0</muleVersion>    <username>${anypoint.userName}</username>     <password>${anypoint.password}</password>     <applicationName>githubactionscicd</applicationName>     <environment>Sandbox</environment>     <workerType>MICRO</workerType>    <region>us-east-2</region>     <workers>1</workers>     <objectStoreV2>true</objectStoreV2>  </cloudHubDeployment>

Commit the Mule Application to Github

  • Right-click on the project and follow the below screenshot from1 to 6.
1 2 3
4 5 6

Check the Github Under Actions tab

  • The build job and deployment are successful as shown in the green.
  • Artifacts are also available after the workflow is completed (output jar file).

This is how we set up the CICD Pipeline in Github Actions.

Hope this was helpful.

For more than one branch in GitHub just add the branch name in the workflow.

We use cookies on this site to enhance your user experience. For a complete overview of how we use cookies, please see our privacy policy.