Build email: Notify users who delivered changes does not work
![]()
Martina Riedel (203●2●32●41)
| asked May 29 '13, 7:28 p.m.
edited Jun 20 '13, 8:58 p.m. by Millard Ellingsworth (2.5k●1●24●31)
RTC 3.0.1.2, BF 7.1.2.2
I am running a build using the JBE and have the email notification in the build def configured. I am selecting send notification when a build has completed, only if there are errors and then Notify users who delivered changes and Notify user who requested the build. The requestor gets the email, and only the requestor. If I add other recipients, either via role, user or email, it also works and in the email I get I see who gets notified. So pared down to the 2 checkmarks, only I as the requestor get the email. The build result has the work item that was delivered for this build linked, so JBE definitely identified the wi and I assume the changeset. I am using a somewhat customized BF adaptor that uses the passwordFile parameter for the JBE. If there is an option that will make the JBE spit out debug info, I would love to know about it. I am already calling it with -verbose and all I see in the build-xxx.log in RTC is Accepting changes and Fetching Files The "send email" piece might be in RTC though, so ....... I don't have access to the server itself, so any digging in server logs, please be as specific as you can. Also this is production and we can't change log settings. Our test server doesn't have email configured, so I am a bit limited with options to debug this.
showing 5 of 6
show 1 more comments
|
Comments
hmm, it worked fine when we did another deliver and run today.
the changeset that It didn't do the notify on yesterday was a bit older.
so maybe once we really get going with builds, it will work.
any insights in how it determines the "who delivered" are still appreciated
"who delivered" are the authors of the change sets that were included in the build.
yep, that is what I expected. If the build fails we rollback to the last good snapshot/baseline and when we deliver (the build workspace accepts) the 2nd time, it won't send the email when the build fails again. I have too few samples to be sure of he pattern, but that is what is looks like right now
@martinar It has been a few weeks. Do you consider this resolved? Or is there more data you can share about what's happening?
We started running scheduled builds last week and I am staring to see a bunch of data. It definitely doesn't always send the email. The pattern seems to be:
hmm, I'm not positive what the intended/documented behavior is for that one. Up until the "fails again" part it seems all is well. Let me add tags for the build folks and see if we can get someone to tell us if this is the designed behavior (don't send a second email about the same change set) or a defect.