-
Bug
-
Resolution: Cannot Reproduce
-
Major
-
None
-
Master is Jenkins 1.471 running on Windows XP 64-bit using Mercurial 2.0.2 via TortoiseHG 2.2.2.
Slave Node is running (via SSH) on Ubuntu 10.04 64-bit using Mercurial 2.3 via TortoiseHG 2.1.
Intermittently, the Mercurial plug-in will attempt to clone to a workspace that doesn't exist because it is adding "@2" to the end of the workspace path. This results in a clone that is unexpected and unnecessary.
CONSOLE OUTPUT
--------------------------------------------------
13:55:22 Started by an SCM change
13:55:22 [EnvInject] - Loading node environment variables.
13:55:22 Building remotely on <NODE_NAME_REMOVED> in workspace /var/lib/jenkins/workspace/<JOBNAME_REMOVED>@2
13:55:22 Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd'T'HH:mm:ssZ.
13:55:22 $ /usr/bin/hg clone --rev default --noupdate http://<REPO_ADDRESS_REMOVED> /var/lib/jenkins/workspace/<JOBNAME_REMOVED>@2
14:24:19 Build was aborted
14:24:19 Aborted by <USERNAME_REMOVED>
14:24:19 Archiving artifacts
14:24:19 Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd'T'HH:mm:ssZ.
14:24:19 adding changesets
14:24:19 adding manifests
14:24:19 adding file changes
14:24:19 transaction abort!
14:24:19 Recording test results
14:24:19 Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd'T'HH:mm:ssZ.
14:24:19 No test report files were found. Configuration error?
14:24:19 Recording fingerprints
14:24:19 Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd'T'HH:mm:ssZ.
14:24:19 Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd'T'HH:mm:ssZ.
14:24:19 Description set: MERCURIAL_REVISION: ${MERCURIAL_REVISION}
14:24:19 Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd'T'HH:mm:ssZ.
14:24:19 Finished: ABORTED
- duplicates
-
JENKINS-21622 Build creates new workspace@2 (and so on) when option concurrent builds NOT checked
-
- Resolved
-
We're using SVN and very regularly (e.g. once a week) we experience this issue.
Sometimes it even goes to @3 or @4 before we notice.
The thing is the workspace does exist, it just seems for some reason something decides to switch to the @2 workspace.
For instance one build starts with :
Started by an SCM change Building remotely on Slave-2 in workspace E:\workspace\<PROJECT> Updating http://svn.<DOMAIN>/<PATH>/<PROJECT>/trunk at revision '2013-02-19T15:26:09.965 +0100'
and the next one :
Started by an SCM change Building remotely on Slave-2 in workspace E:\workspace\<PROJECT>@2 Checking out a fresh workspace because E:\workspace\<PROJECT>@2\trunk doesn't exist Cleaning local Directory trunk Checking out http://svn.<DOMAIN>/<PATH>/<PROJECT>/trunk at revision '2013-02-19T17:11:09.863 +0100'
We are using matrix builds with a few slaves started via jnlp, all on windows.
Any clue how we could help debug this ?
It is quite inconvenient as some of our projects take up to 70GB disk space and duplicating them fills up the disk pretty quickly.