Re: Integrating Anthill with a Problem Report systyem?

Eric,

	Thanks for the reply!

	I guess that the "only send out emails on the first failure" would be 
useful, yes. (I do have a small concern about it, at the end of this 
message.)

	But having a pluggable failure handling mechanism would be useful too. 
Email would be one option. Talking to a PR system, another, etc. 
Basically I think you need, for the error handling, the notion of 
pluggable adapters, much like you have for Version Control. You could 
ship with the email adapter, and people could come up with different 
sort of adapters: Bugzilla, JIRA, FTP, whatever. Basically a way to 
define which 1 or more of these adapters should run on a failure. If you 
passed enough parameters to these adapters, they could do the logic 
"only do this for the 1st failure" and others. Or have this filter logic 
be a separate thing, a trigger for teh adapter to run.

	I will look into ALF, thanks.

	Yes, I agree that the "if I'm inside Anthill" check shouldn't be too hard.

	Going back to the PR notification, I basically want a way to enter just 
1 PR for a problem. If the build fails 10 times on the same spot, I want 
to enter a PR just once. If a build fails, and then the next build fails 
in a different spot, I do want to enter 2 separate PRs. I don't want the 
system preventing me from entering the 2nd PR by not notifying me. 
That's why I worry a bit about the flag you mention at the beginning. 
Would it prevent me from seeing this scenario?

	Thanks,

marcio



Eric Minick wrote:
> Marcio,
> 
> Another approach to limiting the constant email problem would be to have 
> an option to only send out emails on the first failure. Anthill can 
> continue spinning it's wheels on the 30 minutes schedule trying to get a 
> build out, but not harass people about it. Would that make sense for you?
> 
> Interestingly enough, you did describe on of the use cases laid out in 
> the planning of ALF (http://www.eclipse.org/alf/) which would address 
> problem #3 - how do we get all these tools to talk to one another. You 
> might want to take a look at what's going on there, it's a really 
> exciting concept and we plan to leverage it in Anthill somewhere down 
> the line.
> 
> The "if I'm inside Anthill" check shouldn't be too hard. You can have 
> Anthill pass an additional flag into the build script or just check for 
> the presence of one of the other Anthill specific build properties.
> 
> Regards,
> Eric
> 
> Marcio Marchini wrote:
> 
>> Hi,
>>
>>
>>     Has anybody given any thought to integration between Anthill and a 
>> Problem Report system like Bugzilla or similar?
>>
>>     I have seen cases where a build was being done every 30mins. 
>> Sometimes it failed and remained failed for hours. Having it email 
>> again and again was a pain. Emails became noise. If we had Anthill add 
>> a Problem Report automatically to Bugzilla (or similar), that would 
>> have become noise too. What can be done, then?
>>
>>     I was thinking that what you want is to be able to disable timed 
>> builds when a build fails. Basically, if a timed build fails you would:
>>
>> 1) enter a PR against Bugzilla or similar, attaching whatever report 
>> you wanted (junit output, whatever)
>> 2) switch to non-timed builds
>> 3) if the PR system was closed, have a way to switch the timed builds 
>> ON again
>>
>>
>>     Has anybody given this any thought? It would require a mechanism 
>> of plugins to talk to different PR systems (JIRA, Bugzilla, etc) and a 
>> mechanism to be notified back. Web Services is something that comes to 
>> mind here, but anything goes as long as it can be done in a 
>> straightforward manner?
>>
>>     I think that #1 can be done with a custom Ant task. So, it could 
>> be invoked from the build.xml. The problem with that is that if the 
>> developer tests locally, he'd be sending a bug and you don't want 
>> that. You'd have to do a "If I am running inside ANthill then submit 
>> the PR". For #2 you'd need an Anthill option to "switch to another 
>> schedule if teh build fails", and make it switch to a apaused 
>> schedule. The real problem is #3, as it would require instrumenting 
>> the PR system and Anthill, so they talk to each other.
>>
>>
>>     Ideas? Suggestions? URLs?
>>
>>     Thanks,
>>
>> marcio
>>
>> _______________________________________________
>> Anthill mailing list
>> Anthill-IWHQxnLZ/[email protected]
>> http://lists.urbancode.com/mailman/listinfo/anthill
> 
> 
> 
> _______________________________________________
> Anthill mailing list
> Anthill-IWHQxnLZ/[email protected]
> http://lists.urbancode.com/mailman/listinfo/anthill