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

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

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Cannot Reproduce
    • 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.

    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

          Activity

            mat007 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 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.
            jglick 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.

            jglick 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 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 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).
            jglick 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.

            jglick 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 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 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.
            pedroreis 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.

            pedroreis 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.
            pedroreis 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?

            pedroreis 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?
            danielbeck 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.

            danielbeck 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.

            People

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

              Dates

                Created:
                Updated:
                Resolved: