[Users] [Test] EinsteinToolkit - Build #409 - Failure

[Ian Hinder]

On 19 Jan 2015, at 18:23, ian.hinder at aei.mpg.de wrote:

> BUILD FAILURE
> 
> Build URL:	https://build.barrywardell.net/job/EinsteinToolkit/409/
> Project:	EinsteinToolkit
> Date of build:	Mon, 19 Jan 2015 17:13:41 +0000
> Build duration:	9 min 29 sec
> 
> Changes
> 
> Revision:	68cdcc5ecc34e0fac714e13a5a53016651a64903
> Author:	Einstein Toolkit Git Server
> Log:	
> Updated submodules:
> 
> * arrangements/CactusBase 11f4180...9b1bab2 (1):
>   > CactusBase: Support CCTK_INT16
> 
> * arrangements/CactusNumerical 93a286d...49912fb (1):
>   > CactusNumerical: Support CCTK_INT16
> 
> * arrangements/CactusPUGH 0ac5c78...cb3c70f (1):
>   > PUGH: Support CCTK_INT16
> 
> * arrangements/CactusTest 8c3b35b...48004a2 (1):
>   > TestAllTypes: Test CCTK_INT16
> 
> * repos/carpet 7ddf438...2efdefc (2):
>   > CarpetLib: Disable new bboxset class if the compiler does not support C++11
>   > Merge branch 'eschnett/int16'

Hi,

This test failure was caused by the git super-repository update system not successfully updating the flesh in its working copy.  I believe this was caused by somebody pushing a commit which rewrote the flesh history.  From the repository history I can see, I think this was the push by Erik at 15-Jan-2015 19:12 which added commit 

	104612e - Cactus: Output schedule routine when outputting warnings (2014-12-31) <Erik Schnetter>

with parent

	c7fd13a - Merged in redirect_root (pull request #2) (2014-12-30) <Frank Löffler> 

The master branch then evolved from this commit.  However, there were already more commits on master, including

	065b00c - Merged in simple_make_for_single_config (pull request #6) (2015-01-12) <Frank Löffler>
	f47e1d0 - (origin/simple_make_for_single_config) Don't require configuration name when only one is present anyway. (2014-12-25) <Frank Loeffler>
	9c7a72a - Merged in Makefile_invalid_configuration_names (pull request #5) (2015-01-12) <Frank Löffler>

which were then lost.  These commits were then added onto the end of master (I think again by Erik?), so that the code was correct, but the history was different.

I'm basing this on the history I can see in the update server's copy of the repository, and the commit email notifications which give the timeline of pushes.

This could have been caused by Erik rebasing his master branch off a feature branch, instead of the other way around, and then overriding the warning when pushing to bitbucket by adding the --force option to "git push".  Erik, is it possible that this is what happened?

The super-repo update system should have detected the failure to update and sent me an email, but there is a bug there which means it ignored the error.  I have corrected the repository problem on the update server.

I believe the current master branch contains all the code that it should, and that it will now update correctly, unless another forced push is performed.  

Possible actions:

	– We could disable forced pushes in bitbucket for the master branch to stop this happening again (this should presumably be done for all the repositories, so it should be done by a script).  

	– The super-repo update system should be fixed so that errors like this are detected and reported

-- 
Ian Hinder
http://members.aei.mpg.de/ianhin