Continuous Integration with Mule and Gradle



We use automated systems not only because they make our lives easier by taking care of building our apps, but because they can run our automated tests and deploy what we to the target platform. One of our options for building applications (especially Mule applications) is Gradle. The Gradle plugin for Mule apps provides a variety of ways to deploy Mule apps and that’s what we’ll be covering in this post!

Note:This is the fifth part of our Gradle plugin series; be sure to check out the previous posts!

First, I want to mention what our current version of Gradle can do today. Then, I’ll introduce features that are under development for release 2.0 of the plugin.

Deployment to the local File System

This option consists on copying the resulting app (or domain) to a local runtime. There are a couple of options for configuring the target runtime:

  • Through the ‘MULE_HOME’ system Variable.
  • Through the Mule DSL.

This type of deployment is also available out-of-the-box by applying the basic ‘mule‘ or ‘mulestudio‘ plugin. Let’s take a look at how this is done:

In linux / unix or:

In windows. As well the DSL would look like the following:

Now we can build, run our tests and if everything is successful deploy locally with the following command line:

Deployment to MMC

One of our favorite ways of deploying apps is through the Mule Management Console. Although this way does not deploy directly (it instead loads the deployable to the Management Console Repository), it allows us to do the heavy lifting. If we want a fully automated deployment, further calls to the API can be done directly through a Gradle task.

We do have a DSL for configuring multiple MMC environments and it looks like this:

Then, we can call the ‘uploadToRepository’ task to invoke the MMC API and upload to its repository. In the previous example I also externalized the selection of the environment, this is very suitable for . Now, the command line for performing the build is:

Deployment to Cloudhub

For us, CloudHub is the platform of choice for SaaS integration (not restricted to only SaaS). We can very easily deploy our apps thanks to the ‘cloudhub’ plugin. This plugin performs the deployment itself and it is configured through a DSL. The following is an example of that DSL:

We can call the ‘deploy’ task to invoke the CloudHub API and deploy this application. In the previous example I also externalized the selection of the domain, this is very suitable for continuous integration (similar to the MMC settings), and allows the user to select the domain through the command line:

Features coming on Version 2.0

Currently we’re focusing con the version 2.0 of , this release will join the current evolution of the product and apart for building by default 3.6.x applications, it will introduce:

  • A DSL for deploying to single instances or clustered instances running the all new mule agent.
  • Accept environment variables or system properties for selecting environments out of the box.

The following is a sneak peak of the DSL that we’ll be implementing for deployment to the new Mule agent:

Final Words

So this is what the Gradle plugin offers to tackle continuous integration. I would like to take the time and thank the great community effort, especially through pull requests and issue reporting. If you like what you’re seeing and would be interested in participating, please feel free to fill in this anonymous survey to help us improve this plugin:

Gradle feedback form.

We'd love to hear your opinion on this post

2 Responses to “Continuous Integration with Mule and Gradle”

  1. Hello Juan,

    Thanks for sharing these valuable tutorials.
    However, I would like to know how to execute MUnits in the Mule projects using Gradle on a CI tool like Jenkins?

    • Hi Raj, munit is not fully supported with gradle only java-style munits.