Salesforce / Mulesoft

MuleSoft Build and Deploy: GitHub Actions for CI/CD Setup

Computer Analytics

In this blog, I will take you through a step-by-step process to set up CI/CD workflows using GitHub actions for MuleSoft Anypoint Platform integration projects with GitHub as the project repository.

First, you need to create a sample MuleSoft 4 application in Anypoint Studio. Run and test the application in Anypoint Studio. Check the project into GitHub for automatic build and deploy to Anypoint Platform for any new code check-ins or updates to existing code.

GitHub Action Prerequisites

  • Repo access
  • Anypoint Platform Access
    • To deploy an application to the CloudHub Anypoint Environment Org/Business Group: Environment, Client ID, and Client Secret credentials are required

MuleSoft Application Configurations

All MuleSoft 4 applications are Maven compliant. In order to effectively use Maven for build and development, the following configurations should be available for every project that needs to be enabled for CI/CD in DevOps.

Maven Project Pom.xml Configuration: Every pom.xml file in a MuleSoft project should have this configuration to enable CI/CD.

MUnit Maven Plugin Configuration: This configuration helps run MUnit tests and validate for minimum test coverage before allowing successful build and deployment.






























Make sure you have a license to access the MuleSoft Enterprise Repository to execute an MUnit test in GitHub Action. For further documentation and instruction, click here.

Mule Maven Plugin Configuration: This plugin is used for CLI-based application deployment using Maven deploy goal.

The below configuration is an example for deployment to a CloudHub environment:





















Salesforce - Make Salesforce Stick
Make Salesforce Stick

To ensure your Salesforce implementation or migration goes as planned, our team of change management professionals discuss how to manage the transition process to ensure your team is ready, willing, and able to perform effectively in the new environment.

Get the Guide

The variables that appear between ${} are externalized and supplied during GitHub Action execution using secrets.

GitHub Action Configurations

The below configuration assumes that the MuleSoft project is maintained in its own GitHub Repository.

Build and deploy to any environment. Any push to the branch will trigger GitHub Actions tasks. As part of these Actions, it would trigger build, test, and package, then deploy the application. If any test fails or the test coverage is below the set threshold, the workflow execution will fail and the deployment will be aborted.

Workflow setup: Under Action, set up GitHub Action workflow. Create a workflow file in .github/workflows and name it as <<app-name>-build-deploy.yaml. This workflow will trigger the build and deploy process every time a user pushes the change to the dev branch or raises a pull request on the dev branch.

Github 1

Replace the action yaml details with the following sample Action workflow. This will check out MuleSoft code that is available in the current GitHub repository and deploy the application to Anypoint Platform based on the username and password provided in the repository secrets section.

# This workflow will build and deploy a MuleSoft project


name: MuleSoft deployment with GitHub Actions CI


# Controls when the action will run.


# Triggers the workflow on push or pull request events on dev branch


branches: [dev ]


branches: [ dev ]


# Allows you to run this workflow manually from the Actions tab workflow_dispatch:


# A workflow run is made up of one or more jobs


# “build”


# The type of runner that the job will run on

runs-on: ubuntu-latest


# Steps represent a sequence of tasks that will be executed as part of the job



# Checks-out your repository

– uses: actions/checkout@v2

– uses: actions/cache@v1


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


java-version: 1.8


– name : build

run: mvn -B package –file pom.xml


– name: 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


name: artifacts

path: target/*.jar



needs: build

runs-on: ubuntu-latest


– uses: actions/checkout@v2

– uses: actions/cache@v1


path: ~/.m2/repository

key: ${{ runner.os }}-maven-${{ hashFiles(‘**/pom.xml’) }}

restore-keys: |

${{ runner.os }}-maven-

– uses: actions/download-artifact@master


name: artifacts


– name: Deploy to Anypoint Platform




run: |

artifactName=$(ls *.jar | head -1)



mvn mule:deploy -Dmule.artifact=$artifactName -Dusername=$USERNAME -Dpassword=$PASSWORD

Define secrets such as the Anypoint Platform username and password to be used in the workflow to deploy an application.

Github 2

Build and deploy the application. The GitHub Action build and deploy flow will be triggered either by updating a file or by checking in a new file to the repository:

Github 3

Github 4

Github 5

Github 6By following these simple steps, you can set up streamlined and effective CI/CD workflows using MuleSoft’s Anypoint Platform.

Contact us to learn more about what you can do with MuleSoft.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Axaya Jena

Axaya Jena is a Technical Architect at Perficient with cross-functional roles in Development, Technical lead, Solution Architecture, and Functional/Business Analysis involving TIBCO, MuleSoft, and Java applications spanning finance, telecom, and retail industries.

More from this Author

Subscribe to the Weekly Blog Digest:

Sign Up
Follow Us