Not sending emails to individuals who broke the build

[Thomas Sondergaard]

I have a jenkins job that is not sending emails to the individuals that
broke the build. I've attached the config.xml for the job.

Looking at a particular build (build #65) where jenkins failed to send
emails, I get some conflicting and surprising information. Jenkins tells
me the job was triggered by an SCM change (see attached pollinglog.txt).
At the same time the changelog section for build #65 tells me "no changes."

The job is a multi-config job and the failing job reports: "An attempt
to send an e-mail to empty list of recipients, ignored"

So in a way the "no changes" is consistent with not sending any emails,
but there were changes as correctly noted by the SCM polling that caused
the job to be triggered.

I'd like to get to the bottom of this. Help, suggestions, insights are
greatly appreciated.

Thanks,

Thomas

[Thomas Sondergaard]

Just replying to my own post here :-)

I got to thinking about how the git-plugin detects changes. In my case
the branches that are built are typically new, so if the git-plugin is
checking against what it has built on that branch earlier, that wont
work. I am using the git-plugin in "merge to target branch" mode and the
stuff that should be considered changes are the commits that are merged
to the target branch.

Perhaps someone can tell me how the git-plugin detects changes (for new
branches)?

Thanks,

Thomas

[Thomas Sondergaard]

On 2012-07-05 09:19, Thomas Sondergaard wrote:
> Just replying to my own post here :-)
>
> I got to thinking about how the git-plugin detects changes. In my case
> the branches that are built are typically new, so if the git-plugin is
> checking against what it has built on that branch earlier, that wont
> work. I am using the git-plugin in "merge to target branch" mode and the
> stuff that should be considered changes are the commits that are merged
> to the target branch.
>
> Perhaps someone can tell me how the git-plugin detects changes (for new
> branches)?

Looking at the git-plugin source and some more of my build logs I notice
that the following is output by the git-plugin:

No change to record in branch origin/for-5.0.0/bug-14458-use-git-submodule

This is written by git-plugin if it cannot find a previous build for the
branch. But my job is configured to merge changes to release/5.0.0 and
build that branch, so it seems to me that it should use
origin/release/5.0.0 as the reference instead of a previous build.

As an alternative it could record the results as release/5.0.0, ie the
mergeTarget and compare against the last build on the merge target, but
that would not be accurate either, since the previous builds could be
build with changes from completely different branches.

I think the right solution for the case where there is a mergeTarget
configured in the job to either

1. always use <mergeRemote>/<mergeTarget> as the previous ref or
2. Look for a previous build for the branch first and then fall back to
<mergeRemote>/<mergeTarget>

The names <mergeRemote> and <mergeTarget> are from the config.xml file,
where I have:

<userMergeOptions>
<mergeRemote>origin</mergeRemote>
<mergeTarget>release/5.0.0</mergeTarget>
</userMergeOptions>

Comments?

Thomas