Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-14699

hg clone adding "@2" to end of clone destination path

    • Icon: Bug Bug
    • Resolution: Cannot Reproduce
    • Icon: Major Major
    • core
    • 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

          [JENKINS-14699] hg clone adding "@2" to end of clone destination path

          mat007 added a comment -

          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.

          mat007 added a comment - 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.

          Jesse Glick added a comment -

          You have asked that your job be capable of multiple concurrent builds, so Jenkins is obliging by creating multiple workspaces for it.

          Jesse Glick added a comment - 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).

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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?

          Daniel Beck added a comment -

          Needs to be reproduced in 1.561 or newer, as it contains a fix for JENKINS-21622 that could well be at fault here.

          Daniel Beck added a comment - Needs to be reproduced in 1.561 or newer, as it contains a fix for JENKINS-21622 that could well be at fault here.

            kohsuke Kohsuke Kawaguchi
            kmleinen Kyle Leinen
            Votes:
            1 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: