So the first step was to extend the jboss-eap-openshift image to support gradle as well. At the moment, the builder and runtime image are the same for EAP. So I extended the jboss-eap-openshift image and created a script to install gradle onto the image so that it can be called upon when needed.
I leveraged docker hub as the image repository and github as the source repository. In the github repo are also OSE stream and template configurations which can be applied for openshift to take advantage of the image in docker hub. Also instructions on how to run through an example. Of course you'll have to create your own or fork if you want to make updates to see what happens.
For this specific scenario I also used what I created in my previous blog post for my web application which uses gradle for building. The source to the repo for the kitchensink-gradle.
In this source, in addition to having a build.gradle rather than a pom.xml, is the .sti/bin/assemble script which is used to execute the actual build. I took the original assemble script used for the maven build located inside the jboss-eap-openshift image and added an additional condition checking for a build.gradle file.
This is just a test and experiment, your experiences may vary. Such as having a pom.xml and build.gradle in the same repo. It's going to try and execute both builds because all I do is check for the existing of the build.gradle file, but left the maven pom.xml check alone. I can probably take it out, since it's unique to the kitchensink-gradle project.
The sti run script remains the same, so no reason to extend/replace it.
In this example I also used it as an opportunity to leverage the sti tool to do my testing before I actually applied a build directly with openshift. A quick way to test things. I wasn't able to do a docker run because the jboss-eap-openshift has dependencies on other components such as the eap-ping tester.
As usual, all instructions and additional descriptions are available in the respective github repo readme.