ClinkerHQ approached us with an interest of hosting the Arquillian build infrastructure.
They provide SaaS for the usual suspects; Jenkins, Sonar, Nexus etc…
While the details are not discussed yet some of the immediate advantages are:
- Groovy execution support
- Opens for easier scriptable builds, e.g. Job DSL, Build Flow, WorkFlow etc.
- Docker support
- Different Browsers
In our current build infrastructure we have many self maintained small jobs to build single modules. I’ve always wanted to expand this but the lack of scripting abilities has always held me back from moving forward.
With the idea of a new infrastructure I’ve started planning/playing with the idea again. The first draft is here;
This ‘Global Job DSL’ generates up ~95 jobs. In short it does:
- Read in all repositories from some external source (Ohloh now, could be GitHub org)
- Create 2 types of jobs, Flow and Build
- The Build job is just a simple Maven build with some additional parameters
- The Flow job is intended as the entry point for e.g. Pull Requests
Core Flow: When a pull request come in to Core it will build Core then spawn Drone and Warp downstream Build jobs using the previously built Core v. Simple enough.
(Missing currently here is triggering a few Arquillian Container TCK runs to verify that part)
Drone Flow: When a pull request come in to Drone it will build Drone, then spawn N(3) Drone test jobs based on the last N Core releases, then spawn a Graphene Build based on the build Drone.
This will allow us to test Arquillian Cube and Arquillian Persistence Extension.
Arquillian Droidium should have some benefits here
This might be useful for Arquillian Graphene, Arquillian Drone, Arquillian Recorder.
Next to just building and testing stuff I want to use more of this information like Include test results from Drone build in e.g. release notes: verified with Core 1.1.5.Final 1.1.6.Final etc. Similar with a Container and the Arquillian Container TCK results.
Automating the release process is another natural step.
Adding weekly Sonar builds.
Any objections on moving forward on this? Any additional requirements you would like to see?
- Maven / Java
- Groovy Scripts (BuildFlow, Job DSL)
- Linux/ (Windows?)