It's all about the answers!

Ask a question

Build email: Notify users who delivered changes does not work


Martina Riedel (20322939) | asked May 29 '13, 7:28 p.m.
edited Jun 20 '13, 8:58 p.m. by Millard Ellingsworth (2.5k12431)
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.

Comments
Martina Riedel commented May 30 '13, 12:14 p.m.

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


Heather Fraser-Dube commented May 30 '13, 3:52 p.m.
JAZZ DEVELOPER

"who delivered" are the authors of the change sets that were included in the build.


Martina Riedel commented May 31 '13, 10:42 p.m.

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


Millard Ellingsworth commented Jun 20 '13, 8:00 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER

@martinar It has been a few weeks. Do you consider this resolved? Or is there more data you can share about what's happening?


Martina Riedel commented Jun 20 '13, 8:46 p.m.

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:

- developer delivers
- build accepts change into build workspace, creates a snapshot and baseline
- build fails and build workspace gets reset to last baseline that had a good build via replace component.
- developer who delivered gets notified
- build runs again, build accepts the change again in the workspace
- build fails again
- developer is NOT notified
I think the developer should get notified the 2nd time around as well.


Millard Ellingsworth commented Jun 20 '13, 8:58 p.m.
FORUM ADMINISTRATOR / JAZZ DEVELOPER

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.


There are also several build related enhancements associated with this Plan Item: https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=233478

showing 5 of 6 show 1 more comments

Accepted answer


permanent link
Spencer Murata (2.3k115870) | answered Jul 16 '13, 5:37 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
 I think the baseline replace isn't what you want.  The build snapshot will still be associated to the stream and the changeset, if it is the exact same changeset, will already be part of the previous snapshot, so the snapshot compare will not find that changeset as a diff between them.  Is it the exact same changeset?  This is a bit of an edge case if so.  Generally we don't allow removing changesets as its somewhat counter to the stream strategy.  Maybe the process should be tweaked to not allow the rollback of the bad delivery.  Rather it could be replaced with a personal build to ensure that there is no build failure, then a 'real' delivery to the stream after the personal build is successful.

~Spencer
Martina Riedel selected this answer as the correct answer

Comments
Martina Riedel commented Jul 16 '13, 7:08 p.m.

fair enough. So internally it compares snapshots. Guess I am waiting for that snapshot delete command from the command line then.
I see where a personal build could come in handy. We just have to make sure that other builds don't pick up libraries generated by personal builds.
I have an idea ...... thanks again.

Your answer


Register or to post your answer.