[tei-council] Jenkins errors: who gets notified

[Martin Holmes]

I've added some extra explanation about the Jenkins servers and how to 
use them to help you figure out problems to:

<http://www.tei-c.org/Activities/Council/Working/tcw20.xml#body.1_div.4>

Does this file belong in the repo somewhere as well, by the way?

I couldn't add a link directly to the "Parsed Console Output" because 
build pages are specific to the build itself, and will eventually 
disappear, since Jenkins only keeps a limited number of historical build 
artifacts.

Cheers,
Martin

On 11-12-05 02:03 PM, Kevin Hawkins wrote:
> Thanks.  Could we add the parsed console link to
> http://www.tei-c.org/Activities/Council/Working/tcw20.xml ?  All I was
> going on is the link in the email, which just gives me a list of SF
> revisions.
>
> On 12/5/2011 3:24 PM, Martin Holmes wrote:
>> Hi Kevin,
>>
>> First of all, there's no need to be paranoid at all; we all break the
>> build regularly, and Stormy does it several times a day. :-)
>>
>> If the change you made was purely textual -- say a fix for a typo in the
>> guidelines -- and you validated your file before committing it, then the
>> chance that it's your fault are very small. If you've done anything in
>> the Specs files, though, it's remarkable how many unforeseen
>> consequences there can be, and you should check whether you caused the
>> problem. The way to do that is to go to the page for the broken build,
>> and then click on Parsed Console Output -- for instance:
>>
>> <http://teijenkins.hcmc.uvic.ca:8080/job/TEIP5/123/parsed_console/>
>>
>> This will enable you to see the actual error messages relating to the
>> broken build (in this case, they're warnings), and you can determine
>> whether the issue looks like it might have been caused by your changes.
>> If you don't get enough clues there to help you track down the problem,
>> just ask on the list.
>>
>> One of the side-effects of more of us committing changes is that there
>> are more changes and more broken builds, but we're all learning all the
>> time, and it doesn't usually take long for one of us to figure out what
>> the problem might be and suggest a fix.
>>
>> Cheers,
>> Martin
>>
>> On 11-12-05 10:49 AM, Kevin Hawkins wrote:
>>> I understand that Jenkins won't know whose error it is, but as far as I
>>> can tell, Jenkins emails for failures only those who have committed
>>> changes since the last successful build, not everyone who has ever
>>> committed a change for which a build was not successful. So I suspected
>>> this could be done somehow.
>>>
>>> It's not so much that it's onerous but that it makes me paranoid. I
>>> keep expecting an irritated message from someone telling me that it's my
>>> error that caused the problem, not one of the others. I mean, how
>>> exactly do you know if it was yours that caused the problem?
>>>
>>> On 12/5/2011 1:37 PM, Martin Holmes wrote:
>>>> I don't think there's any way Jenkins can know whose changes caused an
>>>> error. The cycle of builds can take a couple of hours, and if three
>>>> changes are committed between one build and the next, Jenkins just knows
>>>> that one of those commits will have caused the problem; it can't know
>>>> which one.
>>>>
>>>> So if you're concerned that you're getting emails triggered by build
>>>> failures for which you're not responsible, then I don't think there's a
>>>> way around that. You won't really know whether you were responsible for
>>>> the build failure till you take a look at the log.
>>>>
>>>> Are you finding the volume of emails onerous?
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>> On 11-12-05 09:55 AM, Kevin Hawkins wrote:
>>>>> Folks,
>>>>>
>>>>> Is there a way to reconfigure Jenkins to only email those users who
>>>>> have
>>>>> committed new changes since Jenkins last ran rather than since Jenkins
>>>>> last ran successfully?
>>>>>
>>>>> Kevin
>>>>
>>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)