The Personal Blog of Todd Sharp

Adventures in CI/CD [#5]: Deploying A Microservice To The Oracle Cloud With GitHub Actions [Gradle Plugin Edition]

Posted By: Todd Sharp on 5/4/2020 12:00 GMT
Tagged: Cloud, Containers, Microservices, APIs, Integration, Open Source

We’ve made it to post number five in this series, and I have to say that I’m having more fun than I should be allowed to have playing around with CI/CD and deploying microservices to the Oracle Cloud. I have learned a ton putting this series together and I truly hope you are enjoying it and finding it useful. To recap, here’s what we’ve done so far:

For brevity and to prevent repeating myself I will assume you have at least read the last post in this series so if you have not yet done so, please do that before continuing. In that last post we used the OCI CLI to create our instance but this time we’re going to switch our application to use the OCI Java SDK Gradle plugin by my esteemed colleague Andres Almiray. You’ll need many of the secrets from the previous post created in your repo, so if you haven’t created them yet then you might want to do that now.

Configure Gradle

First we will need to add the OCI Gradle plugin to our build.gradle file in the plugins block:

Since the plugin utilizes the OCI Java SDK which depends on javax.activation we’ll need to add a buildscript dependency:

Next, we’ll register a new task in our build that we can later invoke from our build pipeline. We’ll pass in the necessary variables from the pipeline, so register the task like so in your build.gradle:

This task will utilize the SetupInstanceTask method of the plugin and as I said above we will be able to pass additional variables in when we execute the task later on. Let’s move to our workflow YAML file and remove the references to the OCI CLI that we added in the last post in this series. Remove the following:

We’ll still need our OCI config file as it will be used for authentication by the Gradle plugin, so leave that step in and add another command at the end of it to create a blank cloud-init file. We won’t populate it for now, but if you wanted to further customize your newly launched instance you could certainly populate this shell script (or have a version checked in to your GitHub repo that you could copy over).

Now let’s add a step to use Gradle to invoke the task that we registered above. Note that the create instance task will also create all of the necessary VCN infrastructure to support the instance.

This step will complete successfully regardless of whether or not the instance exists beforehand so we don’t have to worry about checking that our instance already exists before we invoke it. It will also write out a properties file containing relevant data about the instance that we can use to get information like our instance’s public IP so we’ve eliminated yet another call to the CLI/SDK. That said, let’s add a step to our workflow to read the properties file and retrieve the instance IP as well as the security list ID so we can add an ingress rule for the app that our microservice runs on.

Now we can add the ingress rule using the addIngressSecurityRule task that the OCI Gradle plugin provides.

From here on out the build continues as it did in the previous post. We can stop the app, push the JAR and start the app with the following steps:

Once we commit and push our refactored build we can observe the workflow execution in GitHub Actions:

And we can confirm the application has been deployed on the new instance:


In this post, we refactored our microservice deployment to utilize the OCI Gradle Plugin to create our instance instead of using the OCI CLI. This presents an alternative option if you prefer to use Gradle but accomplishes the same end goal - deploying our microservice application on a VM in the Oracle Cloud.


I know it feels like we have covered a whole lot of content so far in this series, but trust me when I say we’re only about halfway done with what I plan on covering. Next up we’re going to spend a few posts going into some more “advanced” topics. The first thing we’ll look at is adding some database interactions to our microservice because a simple “hello, world” can only teach us so much. And since working with the database involves schema changes, we’ll also look at database migrations in a future post. There is lots more to come even after those topics, so stick around and thank you for reading!

Source Code

For this post can be found at

Photo by Dylan McLeod on Unsplash

Related Posts

Querying Autonomous Database from an Oracle Function (The Quick, Easy & Completely Secure Way)

Querying Autonomous Database from an Oracle Function (The Quick, Easy & Completely Secure Way)

I've written many blog posts about connecting to an Autonomous DB instance in the past. Best practices evolve as tools, services, and frameworks become...

Brain to the Cloud - Part III - Examining the Relationship Between Brain Activity and Video Game Performance

Brain to the Cloud - Part III - Examining the Relationship Between Brain Activity and Video Game Performance

In my last post, we looked at the technical aspects of my Brain to the Cloud project including much of the code that was used to collect and analyze the...

Brain to the Cloud - Part II - How I Uploaded My Brain to the Cloud

Brain to the Cloud - Part II - How I Uploaded My Brain to the Cloud

In my last post, we went over the inspiration, objectives, and architecture for my Brain to the Cloud project. In this post, we'll look in-depth at the...

Note: Comments are currently closed on this blog. Disqus is simply too bloated to justify its use with the low volume of comments on this blog. Please visit my contact page if you have something to say!