Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 326060

Summary:	Workspace incorrectly built after delete virgo.test.snapshot build
Product:	Community	Reporter:	Steve Powell <zteve.powell>
Component:	CI-Jenkins	Assignee:	Eclipse Webmaster <webmaster>
Status:	CLOSED WORKSFORME	QA Contact:
Severity:	normal
Priority:	P3
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Mac OS X - Carbon (unsup.)
Whiteboard:	stalebug

Description Steve Powell

2010-09-23 10:10:58 EDT

Delete workspace of virgo.test.snapshot and re-run build (build #228).

Build fails due to build.xml file not being found:

[virgo.test.snapshot] $ git clean -fdx
FATAL: Unable to find build script at /opt/users/hudsonbuild/workspace/virgo.test.snapshot/build-test-framework/build.xml

Look at workspace (and disable build) and we see that the top-level workspace consists of the virgo-build directories, which is the submodule, and should be under 'virgo-build'.  The main git directores do not appear to be there.

Structure and content of workspace is incorrect.

Look at the console log in greater detail:

--8<----
Started by user spowell
Building remotely on hudson-slave2
Checkout:virgo.test.snapshot / /opt/users/hudsonbuild/workspace/virgo.test.snapshot - hudson.remoting.Channel@52db59df:hudson-slave2
Using strategy: Default
Last Built Revision: Revision ae1a993da2a0bf1511e905bea6534edbf063aadc (origin/master)
Checkout:virgo.test.snapshot / /opt/users/hudsonbuild/workspace/virgo.test.snapshot - hudson.remoting.LocalChannel@20e9df17
GitAPI created
Cloning the remote Git repository
Cloning repository origin
$ git clone -o origin git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.test.git /opt/users/hudsonbuild/workspace/virgo.test.snapshot
Fetching upstream changes from git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.test.git
[virgo.test.snapshot] $ git fetch -t git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.test.git +refs/heads/*:refs/remotes/origin/*
[virgo.test.snapshot] $ git ls-tree HEAD
GitAPI created
Fetching upstream changes from git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.virgo-build.git
[virgo-build] $ git fetch -t git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.virgo-build.git +refs/heads/*:refs/remotes/origin/*
warning: no common commits
From git://git.eclipse.org/gitroot/virgo/org.eclipse.virgo.virgo-build
 + ae1a993...fe59664 master     -> origin/master  (forced update)
 * [new tag]         1.0        -> 1.0
.
.
 * [new tag]         1.29       -> 1.29
.
.
[virgo.test.snapshot] $ git submodule init
[virgo.test.snapshot] $ git submodule update
[virgo.test.snapshot] $ git tag -l master
[virgo.test.snapshot] $ git rev-parse origin/master
Commencing build of Revision fe596640fb1c24f55a0d3f85691d0dfccc078605 (origin/master)
GitAPI created
Checking out Revision fe596640fb1c24f55a0d3f85691d0dfccc078605 (origin/master)
[virgo.test.snapshot] $ git checkout -f fe596640fb1c24f55a0d3f85691d0dfccc078605
[virgo.test.snapshot] $ git tag -a -f -m "Hudson Build #228" hudson-virgo.test.snapshot-228
Recording changes in branch origin/master
[virgo.test.snapshot] $ git whatchanged --no-abbrev -M --pretty=raw ae1a993da2a0bf1511e905bea6534edbf063aadc..fe596640fb1c24f55a0d3f85691d0dfccc078605
Cleaning workspace
[virgo.test.snapshot] $ git clean -fdx
FATAL: Unable to find build script at /opt/users/hudsonbuild/workspace/virgo.test.snapshot/build-test-framework/build.xml
Archiving artifacts
.
.
Finished: FAILURE
--------

and cannot see the problem -- it looks as though the submodule is being correctly built.

Comment 1 Denis Roy

2010-09-23 10:16:14 EDT

droy@hudson-slave2:~> ls -l /opt/users/hudsonbuild/workspace/virgo.test.snapshot/build-test-framework/build.xml
-rw-r--r-- 1 hudsonbuild callisto-dev 678 2010-09-23 10:12 /opt/users/hudsonbuild/workspace/virgo.test.snapshot/build-test-framework/build.xml

*shrug*  it looks there to me.

Comment 2 Steve Powell

2010-09-23 10:43:42 EDT

I don't know when you were looking Denis.  After this failure I re-ran the test build and the workspace was correctly generated.  Workspaces are moving targets.

When I looked after the run the web interface showed me an incorrectly structured workspace and the build file isn't there because the build-test-framework directory wasn't at the top level.  

This could be a web i/f problem were it not for the fact that the job itself complains it can't find the file.

Comment 3 Steve Powell

2010-10-14 06:16:15 EDT

This problem still occurs.  When trying builds for Bug 325824, it occurred every time.

Wipe out the workspace for any successful build (e.g. virgo.test.snapshot) and then 'build now'.

The very next build will fail (can't find the build.xml file) but simply repeat the job and it works.

Looking at the workspace after the failing job, it appears to be constructed incorrectly -- the submodule (virgo-build) appears to be fetched twice instead of the top level (test) with the submodule within it.

Comment 4 Steve Powell

2011-01-19 10:11:01 EST

This problem has been hanging around for some considerable time.  It would be nice to have some constructive movement on it.

I suggest looking at the git reconstruction of a source tree when it has to do a full clone -- does it correctly deal with submodules then?  (Does it, for example, clone the submodules instead of issuing submodule update --init after cloning the top level?)

Comment 5 Eclipse Genie

2014-10-01 17:56:51 EDT

This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.

Comment 6 Eclipse Webmaster

2014-10-07 16:09:46 EDT

Virgo is now using HIPP, and a quick peek at this job indicates it's been running fine.  So I suspect this bug is now moot.


-M.