Intro
This week we, the class, continue with the development of the Devcathlon Events. Just like the previous week’s assignment, we were all given an event to implement; but this time we would be working in groups of two.
The Task
I was teamed up with Philip to build the event named “Keep the Repository Clean”. Here is our event description:
Summary: Penalize (or award) developers for committing code that fails (or passes) a continuous integration build.
This event requires that Build sensor data is generated from the continuous integration server, and that CI build sensor data has a special property associated with it (such as Type=continuous.integration). This is to distinguish continuous integration Build sensor data from local builds (for which frequent failure is to be expected.) Note that the specific tag to be checked for could be a configurable property for each match.
PAR-1: Wakeup every 60 minutes. If there is any CI Build sensor data that does not have a successful Result type, then assign -5 points. Note that you get a deduction of a maximum of -5 points no matter how many times you fail the build during the interval.
Rationale: If you commit code that fails the build, you shouldn't be penalized further for any additional commits you make trying to fix the failing build as long as you do them right away (within an hour of the original failing commit). However, if you wait more than an hour to try to fix it, then you should incur additional penalties.
PAR-2: Wake up every 1 day. If there are successful CI Build events during that day, then assign +5 points.
Rationale: Reward developers for passing continuous integration builds. Note that this is relatively easy to "fake", as there is no verification in the design of this PAR that any actual work was done before kicking off the build. We could look for threshold churn values to ensure that there was nontrivial editing, at least.
For this event we were able to split it up into two sections; one being for Par-1 and the other being for Par-2, I was in charge of implementing Par-2. Making Par-2 at first was not so difficult, being that it was just like the previous event I developed. The similarity of this event, with my previous one, was that I was obtaining data from the daily project build; the difference was I also had to get data from the daily project commit.
Problems and Fixes
Getting the data from the daily project build was easily obtained. I simply copied lines of code from my previous file to get the data. Then when implementing the code to get the commit data, which is similar to obtaining code for build data, I hit a brick wall. For some reason I was not able to get any sort of data.
After hours of trying to get hold of the data and reviewing the hackystat component documentations; with no avail, I was not able to find a solution. I decided to get external help, from other members of the Devcathlon development team by posting a topic in the devcathlon-discuss group; there you can see all development issues that have arisen in our journey to completion.
With posting a topic on the discussion board and uploading a file for the members to see what was happening, the solution came within hours. The problem was solved by John Ly; he saw the method of making commit data was missing a property.
The makeCommitData issue I had:
protected void makeCommitData(User owner, Project project, XMLGregorianCalendar timestamp)
throws Exception {
String host = getSensorBaseHost();
String email = owner.getEmail();
SensorBaseClient client = new SensorBaseClient(host, email, email);
SensorData data = new SensorData();
data.setOwner(email);
data.setTool("Ant");
data.setSensorDataType("Commit");
data.setResource(users + project.getName() + foo);
data.setTimestamp(timestamp);
data.addProperty("linesDeleted", "10");
client.putSensorData(data);
}
The chunk of code, above, was missing the line “data.addProperty(“linesAdded”, “10”). Once John had pointed that out to me and uploaded a new file to resolve my issue, I had another minor setback in my development. From the commit data I was also trying to get the sum amount of lines added and deleted, in other words the amount of churn made.
The issue of getting the amount of churn from commit data was easily resolved by creating a new makeCommitData method which takes in lines added and deleted as inputs (parameters) as well.
The new makeCommitData method:
protected void makeCommitData(User owner, Project project, XMLGregorianCalendar timestamp,
String linesAdded, String linesDeleted) throws Exception {
String host = getSensorBaseHost();
String email = owner.getEmail();
SensorBaseClient client = new SensorBaseClient(host, email, email);
SensorData data = new SensorData();
data.setOwner(email);
data.setTool(ant);
data.setSensorDataType("Commit");
data.setResource(users + project.getName() + foo);
data.setTimestamp(timestamp);
data.addProperty("linesAdded", linesAdded);
data.addProperty("linesDeleted", linesDeleted);
client.putSensorData(data);
}
Along with creating a new method, I also had to make a small minor change to avoid a PMD error. Apparently PMD does not like it when you use the same thing more three times in a row, in my case was the string Ant. So I resolved this by making a variable and having each method that used string Ant, refer to the variable I made. With all the issues resolved I was able to finish my part of this event implementation a head of schedule.
Conclusion
Unlike my previous works, I started this one as soon as possible. Also my team, Philip and I, were fortunate that our event had a big resemblance to our previous events for the Devcathlon; which made things easier on us. The only major setback I had, was not being able to get commit data. Before getting the resolution; I had added the line of code which would fix the problem, but commented it out. I guess I was afraid of tampering with that section of the code, but good thing I got a second opinion from John. After viewing more parts of the system, I now have a better understanding of things.
