[dev] CI suggestion

[Gunnar Wrobel]

Hi Micheal,

Zitat von Michael M Slusarz <slusarz at horde.org>:

> CI/Jenkins is a really cool tool (Thanks Gunnar!)  But one  
> suggestion: ditch the code complexity tests.  They are worthless.   
> They clutter the output for the more useful results, and don't  
> provide any meaningful input.  They would have you reduce a  
> method/class to the point of extreme abstraction, and unmaintainable  
> code, just for the sake of making sure an artificial number stays  
> below a certain vague threshold.
>
> Either that or dramatically increase the limits before it starts  
> throwing warnings.  E.g., it complains that Horde_Variables "has too  
> many methods".  Really?  It has 22: 1 is the constructor, 4 are  
> magic methods for property manipulation, 5 are methods requiring to  
> implement Iterator, and 1 is a method required to implement  
> Countable.  I hardly think the 11 remaining methods in this class  
> are "too many".  (I don't think 100 methods in a class is too many  
> either, FWIW, as long as they coherently tie in with each other).

To be honest I didn't care very much about these numbers yet. When I  
originally considered continuous integration for Horde I really  
pondered on having just a script that would run  
framework/bin/test_framework and mail to the list if there were  
problems. Jenkins comes with more bells and whistles and I won't  
disagree that it is a tad too much.

The reason why I still favored the fluffy, colored approach is because  
it is close to what others try to establish as a standard for  
continuous integrations setups in the PHP world  
(http://jenkins-php.org/). In my experience people in the business  
world do actively look for things like that when they consider using  
external open source libraries for their own development. So if  
possible I'd like to stick close to that "standard" in order to  
indicate that we are interested in what others consider to be good  
coding practices. Completely ditching PMD might be a bit much.

At the same time I agree that we probably don't want to look bad on  
http://ci.horde.org. And if there are PMD rules we know don't care for  
I don't see any reason why we shouldn't remove them from the ruleset.  
We did define our own Horde-specific code style definition for the  
CodeSniffer as well. So we can certainly also define our own ruleset  
for PMD to suit our needs.

It is quite some time ago since I looked at the PMD ruleset definition  
- I think it was just an XML configuration. But it is probably nothing  
I will get into before we had our Horde 4 release. If others have an  
alternative definition I'm fine with replacing the default.

I admit it would also be nicer if the "Job" overview page in Jenkins  
would be easier to configure. The PMD plots I added with my Hudson ->  
Jenkins switch yesterday are a bad compromise. They are placed very  
prominently now. The problem is that they wouldn't be accessible at  
all otherwise. Hm, though that gets me thinking... if it is possible  
to embedd HTML in the job description it might be possible to just  
place these images in another HTML report. That way they wouldn't be  
lost completely but still accessible. Have to try that.

Cheers,

Gunnar


-- 
Core Developer
The Horde Project

e: wrobel at horde.org
t: +49 700 6245 0000
w: http://www.horde.org

pgp: 9703 43BE
tweets: http://twitter.com/pardus_de
blog: http://log.pardus.de