Summary: The entire code is written in Groovy with HTML and CSS inter webbed inside. I had never written in Groovy before but wanted to tackle a project that involved a Jenkins integration. I realized that so many companies used Jenkins for running a bulk of their builds using VM’s. The problem was that there is only so much core power to run more and more builds because then at a certain point more VM’s would be created. As more VM’s went online this would cause a major issue with the speed of the Jenkins total environment capabilities. The goal of this project was to present a dashboard to every user which displayed each build in a 24 hour table. Instead of adding a whole new VM or dealing with slow build times this would utilize each builds availability. The user would be able to see if there are certain times where a lot of builds are clustered to space them out. Also if a new build needed to be run, then they could see a multitude of good times to run. The only builds that would appear would be the ones that run on a timer. I didn’t include any manual builds because if the user were to run a manual build they could just look at the schedule and space out when they need to run their build. Execution: The biggest problem I had initially was understanding the mixture of Groovy along with the Jenkins library. I was able to catch onto Groovy because of my Java background, but using the Jenkins documentation didn’t come as fast since a lot of the documentation was out dated. My first objective was to find out how to go through every node, which in this case was each machine used to run the builds. After being able to find each node in the Jenkins environment, each node has builds underneath them which can range from 1 to any possible number. Of course there could be faster ways to optimize this process like going through each and every build, but at the moment optimizing for the quickest possible code wasn’t the objective. The code takes each VM node and then begins to run through each of the builds on that machine. It begins by going through each build using a customized loop to extract particular build information. Before it even goes through the process of getting information from each build, the build trigger is analyzed to see if it runs by manual command or through a scheduled activation.

Then if the build is ran through a schedule, it continues and if not it gets discarded. The current build, running through the loop is then brought on by a method to receive its last build duration which is formatted in hours, minutes, and seconds. This is then converted into only hours. The last build is also called upon by another method to find the exact start time of the build. Combining both the original start time of the last build along with the duration this allowed to map each hour out for each build.

For the dashboard to universally be used I wanted to make sure that the build names wouldn’t randomly be cut out of the HTML. If the build name exceeded a certain length then the second half would be put onto the line below it. Then using an array called "hours", I was able to mark each index as a 24 hour time manager. This would allow me to store the information until a later point. The next part was to obtain the machine name in which the current build was apart of. This name was then added to a variable to be stored for later use. Towards the end of the loop the last part was to add each build to a data structure. A list utilizing placement variables was exactly what I used. The list stored the information along with checking if the build passed, failed, or aborted. The variables were then reset for the next loop.

The next step was to present the data not only to the user but also in the form of an integrated dashboard for Jenkins. By creating a character upstream, I was able to then create a markupBuilder variable to begin constructing the HTML layout. I then created a table in HTML with rows to show machine names, build names, build date, and then the 24 hour layout. After the rows were created the columns had to be constructed. This was done by integrating loops to form the machine name with all of the builds underneath. The CSS was used at first to style the rows and columns to be particular fonts. Then I went back in to organize the data into a colored coordinated system. The list created in the beginning starts to extract data from each section in the list to a particular row and columns in the table. After all the deconstruction and reassembly is made, the HTML is then exported into a file to be exported onto a custom dashboard in the Jenkins environment.

Utilizes: Jenkins Virtual Machines, Groovy, HTML, CSS, Linear Data Structures Visit Project