The other day someone watching the platform at github asked me “Who is Joomla-jenkins?” That certainly seems to be someone doing a lot. Except it’s not exactly someone.

Jenkins is continuous integration software (a fork of the Hudson project) which is used to ensure the stability of the platform by running unit tests, style checks and various analytics.

Ian MacLennan recently announced a process change where all pull requests (requests from someone to have code committed) should go to the staging branch. That’s to allow the commit to be made and tested. If the tests fail then the “pull requester” needs to fix the code before  it is committed. That way test breaking code never makes it into the “point of truth” master branch.

If you look on github you’ll see a drop down that says “Switch Branches” which is where you can see how the staging branch and the master branch differ. Most of the time they will be the same, but if you go at the right moment you will see differences.

Eventually some of the Jenkins data will be fed continuously to the developer site. But besides that fact that no tests are failing in the master repository (and it will stay that way thanks to Jenkins), it gives other interesting analyses.

For example, recently there has been a lot of work done on code style which is to say making the way the framework is coded consistent across the work of many people. While we have had various style guides in the past (the one consistent rule over the years: tabs not spaces for indenting in code otherwise more or less the PEAR standards) . Now with Jenkins the code styles can actually be enforced. We’ve been getting a lot better on internal consistency, mainly thanks to automated checking that Andrew Eddie has been running and work that Louis Landry has been doing.

This is a recent snap shot, with the biggest group of issues being underscores at the start of the names of public variables and various spacing issues. As you can see, however, when you introduce rules all of a sudden the number of violations goes up, so in the future don’t be surprised to see this pop up and down.

Duplicate code is also headed in the right direction. Not surprisingly, since it is new code and because of the way the code is structured, the most is in the new database classes.

The unit tests are the most important aspect of continuous integration. Currently we have 1216 tests and they are all passing. But we still need a lot more. This is a great place to help improve Joomla!. The more unit tests we have, the less likely it is that changes will break things and the fewer backward compatibly issues.  Writing a test is not just helpful to everyone using Joomla, it is a great learning experience for if you want to understand code better. If you look through the examples in the test folder you will see that really, in a lot of cases, the php itself is not that complex. It’s thinking about all the possible things that could happen and should happen that matters. So if you are looking for a way to contribute, doing a weekend or evening project writing a test for one method or even finishing a test that needs more is a great help.