[Buildbot-devel] How to have blamelist include all blamed checkins since last successful build?

tom fogal tfogal at sci.utah.edu
Sun Oct 14 15:59:26 UTC 2012


For the use this was envisioned of in that project, for me it would be 
fine to simply have a "build-failed" table:

    Repository | UserID

which simply saw an INSERT with the committer whenever a build failed, 
and got cleared (per-repo, of course) when a build succeeded.  We don't 
really need to do a reverse lookup to figure out when it started failing 
or anything, we just want it to be annoying to every *active* developer 
until it gets fixed.

But I realize our use case is probably pretty simple compared to others. 
  TBH, I no longer work on the project that needed this... though I 
might use functionality as described above on other projects, if it was 
part of standard buildbot.  Did you get approval / submit a pull request 
on GH?

-tom

On 10/14/2012 05:33 PM, Dustin J. Mitchell wrote:
> The troubles here are:
>
>   * figuring out what the "previous" build means in the face of build
> re-ordering and buildrequest merging
>
>      * this is even harder with codebases - if you have a failure for a
> build of (revision A1 in codebase A and revision B1 in codebase B),
> and B is the "busier" codebase, do commits B2, B3, B4, and B5 count as
> still failing, even if it ultimately turns out that the bug was in
> codebase A?
>
>   * maintaining this state somewhere other than in memory, to reduce
> memory footprint and allow the feature to work in a multi-master
> environment
>
> Dustin
>
> On Wed, Oct 10, 2012 at 12:39 PM, Mike Winter <miwinter at cisco.com> wrote:
>> Wow, I found this buried in old mailbox.
>>
>> I implemented a solution to http://buildbot.net/trac/ticket/394 that turned out to be more than a bread-bin and less than a truck, perhaps because of my neophyte python experience.
>>
>> Happy to share if my company lawyers are willing. This way if accepted as reasonable approach it might be rewritten by experts. Here's the principle api:
>>
>> class Problem:
>>      '''some state, first failed build and blamelist for same'''
>>      def owner():  return self.owner
>>      def firstFailedBuild(): return self.build
>>
>>
>> class ProblemNotifier(MailNotifier):
>>      '''event reception, problem pickle maintenance etc'''
>>      def onBuildFinished(build):
>>          '''check for extant entries for all failures, add new failures, move fixes to archive
>>          '''
>>
>> On Sep 1, 2010, at 3:16:57PM, tom fogal wrote:
>>
>>> Bill Deegan <bill at baddogconsulting.com> writes:
>>>> Greetings,
>>>>
>>>> If we have say 2 or more failed builds in a row, it would be nice if
>>>> (at least) the initial blame list was cc'd on all failures until the
>>>> build succeeds again.
>>>>
>>>> Is there a way to configure buildbot to do this?
>>>
>>>   http://buildbot.net/trac/ticket/394
>>>
>>> -tom
>>>
>>> ------------------------------------------------------------------------------
>>> This SF.net Dev2Dev email is sponsored by:
>>>
>>> Show off your parallel programming skills.
>>> Enter the Intel(R) Threading Challenge 2010.
>>> http://p.sf.net/sfu/intel-thread-sfd
>>> _______________________________________________
>>> Buildbot-devel mailing list
>>> Buildbot-devel at lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/buildbot-devel
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> Buildbot-devel mailing list
>> Buildbot-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/buildbot-devel





More information about the devel mailing list