[PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable

[PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable

[Ian Campbell]

If a downstream osstest instance has nothing to test it its local
pretest then it will attempt to merge from the upstream instance. If
this fails then it will try again and again generating a new merge
commit each time, even if upstream has not moved.

It is desirable that these merges instead be stable i.e. the same if
the inputs have not changed. This is good for potential bisection
attempts, history reporting/mining as well as just being sensible.

Here we arrange for this by recording the last merge "epoch" (being
the first merge of the current input branches) in a new branch
"merge-epoch" in the local testing.git and comparing our fresh merge
against it.

If the tree and parents are the same then the merge is effectively
identical (it may/will differ in the date) and we reuse the epoch
merge.

If they new merge does not match then something has changed (i.e.
upstream has moved on) and so we take the new merge and establish a
new epoch.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
---

I think this change might be best off applied initially to the
Cambridge instance pretest and once it passes testing there to be
folded into upstream via a PR.
---
 ap-fetch-version | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

diff --git a/ap-fetch-version b/ap-fetch-version
index ec52889..d8d4f97 100755
--- a/ap-fetch-version
+++ b/ap-fetch-version
@@ -134,6 +134,36 @@ osstest)
 		    git merge \
 			-m "Automerge of $TREEBRANCH_OSSTEST_UPSTREAM into production" \
 			ap-merge >&2
+		    merge=$(git log -n1 --pretty='%T %P' HEAD)
+
+		    if git fetch $HOME/testing.git +merge-epoch:merge-epoch ; then
+			# If the new merge matches the current epoch's
+			# tree (%T) and parents (%P) then it is the
+			# same in all the ways which matter. (It
+			# likely only differs in the date). In which
+			# case reuse the epoch merge so that repeated
+			# flights and potential bisections over
+			# osstest see something stable.
+			#
+			# If e.g the parents have changed
+			# (e.g. upstream has progressed) or the trees
+			# differ then use the new merge and establish
+			# a new merge-epoch.
+			epoch=$(git log -n1 --pretty='%T %P' merge-epoch)
+		    else
+			echo >&2 "Failed to fetch merge-epoch"
+			epoch="NONE"
+		    fi
+		    
+		    echo >&2 "Merge Epoch: $epoch"
+		    echo >&2 "This Merge:  $merge"
+		    if [ x"$epoch" = x"$merge" ] ; then
+			echo >&2 "Reusing existing merge-epoch"
+			git reset --hard merge-epoch
+		    else
+			echo >&2 "New merge-epoch"
+			git push $HOME/testing.git +production:merge-epoch
+		    fi
 		)
 
 		# Fetch the result of the above merge into local tree
-- 
2.1.4

Re: [PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable

[Ian Jackson]

Ian Campbell writes ("[PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable"):
> If a downstream osstest instance has nothing to test it its local
> pretest then it will attempt to merge from the upstream instance. If
> this fails then it will try again and again generating a new merge
> commit each time, even if upstream has not moved.
> 
> It is desirable that these merges instead be stable i.e. the same if
> the inputs have not changed. This is good for potential bisection
> attempts, history reporting/mining as well as just being sensible.
> 
> Here we arrange for this by recording the last merge "epoch" (being
> the first merge of the current input branches) in a new branch
> "merge-epoch" in the local testing.git and comparing our fresh merge
> against it.
> 
> If the tree and parents are the same then the merge is effectively
> identical (it may/will differ in the date) and we reuse the epoch
> merge.
> 
> If they new merge does not match then something has changed (i.e.
> upstream has moved on) and so we take the new merge and establish a
> new epoch.
> 
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>

Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Re: [PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable

[Ian Campbell]

On Wed, 2015-07-08 at 16:23 +0100, Ian Jackson wrote:
> Ian Campbell writes ("[PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable"):
> > If a downstream osstest instance has nothing to test it its local
> > pretest then it will attempt to merge from the upstream instance. If
> > this fails then it will try again and again generating a new merge
> > commit each time, even if upstream has not moved.
> > 
> > It is desirable that these merges instead be stable i.e. the same if
> > the inputs have not changed. This is good for potential bisection
> > attempts, history reporting/mining as well as just being sensible.
> > 
> > Here we arrange for this by recording the last merge "epoch" (being
> > the first merge of the current input branches) in a new branch
> > "merge-epoch" in the local testing.git and comparing our fresh merge
> > against it.
> > 
> > If the tree and parents are the same then the merge is effectively
> > identical (it may/will differ in the date) and we reuse the epoch
> > merge.
> > 
> > If they new merge does not match then something has changed (i.e.
> > upstream has moved on) and so we take the new merge and establish a
> > new epoch.
> > 
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> 
> Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>

Thanks. I've put this into the Cambridge instance's pretest, and will
send a pull request to merge back the result when it has baked there.

Ian.

Re: [PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable

[Ian Campbell]

On Wed, 2015-07-08 at 16:26 +0100, Ian Campbell wrote:
> On Wed, 2015-07-08 at 16:23 +0100, Ian Jackson wrote:
> > Ian Campbell writes ("[PATCH OSSTEST v1] ap-fetch-version: Arrange for osstest merges from upstream to be stable"):
> > > If a downstream osstest instance has nothing to test it its local
> > > pretest then it will attempt to merge from the upstream instance. If
> > > this fails then it will try again and again generating a new merge
> > > commit each time, even if upstream has not moved.
> > > 
> > > It is desirable that these merges instead be stable i.e. the same if
> > > the inputs have not changed. This is good for potential bisection
> > > attempts, history reporting/mining as well as just being sensible.
> > > 
> > > Here we arrange for this by recording the last merge "epoch" (being
> > > the first merge of the current input branches) in a new branch
> > > "merge-epoch" in the local testing.git and comparing our fresh merge
> > > against it.
> > > 
> > > If the tree and parents are the same then the merge is effectively
> > > identical (it may/will differ in the date) and we reuse the epoch
> > > merge.
> > > 
> > > If they new merge does not match then something has changed (i.e.
> > > upstream has moved on) and so we take the new merge and establish a
> > > new epoch.
> > > 
> > > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > 
> > Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
> 
> Thanks. I've put this into the Cambridge instance's pretest, and will
> send a pull request to merge back the result when it has baked there.

This passed the Cambridge push gate but then turned out to be missing at
least one ">&2" on the git reset, which resulted in things leaking onto
stdout which should have been there and:

OSSTEST_REVISION='HEAD is now at 8f88bfa ap-fetch-version: Arrange for osstest merges from upstream to be stable
8f88bfa7ac682d4d0df7da206b239a062870c84c'

Needless to say things did not improve from there...

I've placed a stop file and am about to unwind the various things which
need unwinding and push a new version with >&2 added in the appropriate
places, including a couple of "git fetch" which seem to not need them in
practice (at least while things are operating normally), but for
robustness I added them.

Ian.