[dev] Continuous Integration for Horde (was: Re: [commits] Horde branch master updated. 1e394986ba8dd83a6f2854f51c361f72fce9e7b5)

[Chuck Hagenbuch]

Quoting Gunnar Wrobel <p at rdus.de>:

> Hi Jan,
>
> Quoting Jan Schneider <jan at horde.org>:
>
>> I'm not talking for Michael obviously, but I'm still gonna add my two cent.
>>
>> Zitat von Gunnar Wrobel <p at rdus.de>:
>>
>>> Hi Micheal,
>>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>
>>> [snip]
>>>
>>>>
>>>> commit e48b8a54fc54a179be749967a6a8b6b73cc1162e
>>>> Author: Michael M Slusarz <slusarz at curecanti.org>
>>>> Date:   Mon Feb 15 23:27:31 2010 -0700
>>>>
>>>>  Another Notification rewrite.
>>>>
>>>>  First, fix Bug #8870. Fixed by removing Nag specific event type
>>>>  (nag.alarm).  However, this was just a symptom of a larger problem.
>>>>
>>>>  The problem: using application specific Notification handlers to handle
>>>>  application specific event types.  The problem comes when switching
>>>>  between applications.  Since these application handlers don't have any
>>>>  knowledge of each other, events created by one handler may not be able
>>>>  to be displayed when notify() was eventually called, because another
>>>>  status handler had replaced the original handler.
>>>>
>>>>  The solution: all notifications need to be handled by a single,
>>>>  centralized source - namely, the horde-level handlers.  Application
>>>>  specific details are instead injected into the horde-level handler to
>>>>  extend behavior.
>>>>
>>>>  While reworking the code, also provided opportunity to remove all
>>>>  application-specific code from Notification.  Horde-specific
>>>>  instantiation (i.e. adding Horde logging and Alarm decorators) is now
>>>>  done in Horde_Core rather than in the base Notification object.
>>>
>>> Cool, great! Thanks.
>>>
>>>>
>>>>  Additionally, rework some of the complexity added to the package.  I
>>>>  believe the goal of the recent Notification changes was to make the
>>>>  Notification package testable and/or usable outside of a base Horde
>>>>  install.
>>>
>>> Doing such a rewrite for testing purposes would seem wrong to me.  
>>> The  only intention was to make the package usable outside of a  
>>> standard  Horde installation.
>>>
>>> I hope it is okay to transform Horde framework packages this way.  
>>> My  expectation has always been that the framework packages should  
>>> work  that way and be as independent of each other as reasonable.  
>>> Probably  originates from the fact that the Kolab server always  
>>> relied to a  larger degree on the framework than on the  
>>> applications. This has been  somewhat difficult in the past  
>>> because of the tendency to use global  scope in the current code.  
>>> But things are improving of course.
>>
>> This expectation is absolutely correct.
>>
>>> One question concerning the unit tests: I added them because they  
>>> are  required to a certain degree by the project where I'm using  
>>> the  Horde_Notification package. I am however not 100% certain if  
>>> these  tests are useful to the Horde project. I see a tendency  
>>> towards  PHPUnit testing within Horde. But we are also ignoring  
>>> them to a  certain degree as we don't seem to care much if they  
>>> break. And I feel  that at that point unit tests may become more  
>>> of a nuisance rather  than being helpful.
>>
>> We rather need more tests than less. The fact that they break from  
>> time to time is probably due to us not having used tests that much  
>> in the past. We still have to get used to run them after each  
>> change. Some continuous integration would probably help too, but I  
>> don't see anyone having the resources at the moment to set this up.
>
> I have a high interest in doing so but of course it is always hard  
> to find the time. Nevertheless it is important to me as I consider  
> running the tests manually before each commit to be a little bit of  
> an additional burden and hard to enforce. For many commits one can  
> assumes that no test was affected. So one commits right away. Of  
> course sometimes this assumption does not hold. I consider it  
> sufficient to get an email from your friendly build bot in these  
> cases.
>
> I've seen the system in action for the past half year and it is  
> indeed very helpful to have it.
>
> A while ago I have briefly looked at some of the available  
> solutions. I admit I don't like the Java approaches like  
> phpUnderControl very much. The project that uses Horde_Notification  
> and that I'm involved in runs bitten (http://bitten.edgewall.org/).  
> It is trac based and coded in Python. It is not bad but I still  
> consider it too much of an overhead for Horde. We don't need another  
> source code viewer that links potential build failures with commits.
>
> So I lean towards something really lightweight that basically runs  
> framework/bin/test_framework for each commit and sends a mail to  
> dev at horde.org on failure. A build report and a link to git.horde.org  
> should be possible.
>
> Would that match your expectations?

Not speaking for Jan, but that sounds like a great first step to me...

-chuck