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
