Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
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.
Description
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
Attachments
Issue Links
- duplicates
-
-
- Resolved
-
Activity
You have asked that your job be capable of multiple concurrent builds, so Jenkins is obliging by creating multiple workspaces for it.
mat007
added a comment - The "Execute concurrent builds if necessary" check box is unchecked and we don't see multiple concurrent builds (not counting axis of the build matrix of course).
mat007
added a comment - The "Execute concurrent builds if necessary" check box is unchecked and we don't see multiple concurrent builds (not counting axis of the build matrix of course). Then it is probably specific to matrix jobs, and probably not a bug in that case either: you just need multiple workspaces to handle the concurrent (matrix) builds.
mat007
added a comment - I really don't think matrix builds need multiple workspaces as all our projects are matrix based and they don't all create @2 workspaces all the time.
Most builds re-use the same workspace, our flagship project builds 30+ times a day and triggers the issue only once a week.
Plus it hasn't always been like that : the server has been running for a few years and we have only been experiencing this issue for a few months.
Also once a project has switched to @2 it doesn't come back to the regular workspace unless we shutdown jenkins, remove the workspaces manually and re-start jenkins.
mat007
added a comment - I really don't think matrix builds need multiple workspaces as all our projects are matrix based and they don't all create @2 workspaces all the time.
Most builds re-use the same workspace, our flagship project builds 30+ times a day and triggers the issue only once a week.
Plus it hasn't always been like that : the server has been running for a few years and we have only been experiencing this issue for a few months.
Also once a project has switched to @2 it doesn't come back to the regular workspace unless we shutdown jenkins, remove the workspaces manually and re-start jenkins. 
pedro reis
added a comment - Hi,
We're having today this "@2" problem for the first time at a Linux slave.
Jenkins ver. 1.502 creates job workspace as "<job>@2" even when there is no "<job>" dir.
pedro reis
added a comment - Hi,
We're having today this "@2" problem for the first time at a Linux slave.
Jenkins ver. 1.502 creates job workspace as "<job>@2" even when there is no "<job>" dir. pedro reis
added a comment - Thanks mat007!
I confirm that Jenkins needs to be restarted in order to <job>@2 become <job>.
Is there any easier way?
pedro reis
added a comment - Thanks mat007!
I confirm that Jenkins needs to be restarted in order to <job>@2 become <job>.
Is there any easier way? Needs to be reproduced in 1.561 or newer, as it contains a fix for JENKINS-21622 that could well be at fault here.
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.