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

Workspace deleted when subversion checkout happens

    XMLWordPrintable

Details

    • Bug
    • Status: Reopened (View Workflow)
    • Major
    • Resolution: Unresolved
    • subversion-plugin
    • None
    • Platform: All, OS: All

    Description

      When a subversion checkout is done, the entire workspace is deleted - not just
      the previous checkout folder. There may be other files held in the workspace
      outside the checkout folder - especially when the same workspace is share by
      multiple jobs. Code should be changed so that only the previous checkout
      folder, if there is one, is deleted before a checkout is done.

      Attachments

        Issue Links

          Activity

            We're seeing random deletions of our workspace even without any interaction with SVN. We have a few jobs where we turned off SCM polling and we've seen the workspace mysteriously go bye-bye for those.

            Can anyone explain what might be the cause?

            dankirkd Daniel Kirkdorffer added a comment - We're seeing random deletions of our workspace even without any interaction with SVN. We have a few jobs where we turned off SCM polling and we've seen the workspace mysteriously go bye-bye for those. Can anyone explain what might be the cause?
            melder michael elder added a comment -

            I'm constantly snapping our build machine because of this problem. Since the project we are working on has multiple versions, it is more convenient to keep them in a single, custom workspace dir. If for some reason SVN locks one of the project dirs, the next time it updates the entire workspace is rm -rf'ed

            Is there a plugin or a way to sidestep this issue until it is resolved?

            melder michael elder added a comment - I'm constantly snapping our build machine because of this problem. Since the project we are working on has multiple versions, it is more convenient to keep them in a single, custom workspace dir. If for some reason SVN locks one of the project dirs, the next time it updates the entire workspace is rm -rf'ed Is there a plugin or a way to sidestep this issue until it is resolved?
            alghe Alexandru Gheorghe added a comment - - edited

            Still there with subversion-plugin 2.5, our configuration is pulling many folders under one directory (as it would resemble when the library is built) and it should look like this (assuming we're in $WORKSPACE of the job):

            .
            ├── COPYING
            ├── COPYING.LESSER
            ├── coverage.xml
            ├── src
            │   ├── commands
            │   ├── core
            │   ├── __init__.py
            │   ├── ...
            │   └── webshell
            ├── core_tests
            │   ├── ...
            │   ├── __init__.py
            │   └── test_version.py
            │
            ├──flake8.log
            └── ...
            

            We fetch different folders and put them all in src/ which then we export to PYTHONPATH when we run the unittests from core_tests (with nosetests).

            The problem is that at each fetch from SVN even if we don't want and we specify this to SVN to only update we get the workspace src/ folder erased!

            Is it possible to avoid this? A snippet of the fetch:

            Switching to https://.../core at revision '2015-03-06T12:05:11.289 +0100'
            D         __init__.py
            A         tests
            ...
            

            now comes the next checkout

            Switching to https://.../lib at revision '2015-03-06T12:05:11.289 +0100'
            D         core
            D         data
            D         datatypes
            A         commands
            

            as you can see the "D" will erase previous fetches afterwards adding the new ones. Is this the intended behavior?





            Later addition: after a few more builds it seems it "fixes by itself" and concludes the build successful without any importation failures of any libraries (caused by the then deleted folders), not sure how correct this is how and needs an analysis from our part, but is this normal?

            alghe Alexandru Gheorghe added a comment - - edited Still there with subversion-plugin 2.5, our configuration is pulling many folders under one directory (as it would resemble when the library is built) and it should look like this (assuming we're in $WORKSPACE of the job): . ├── COPYING ├── COPYING.LESSER ├── coverage.xml ├── src │   ├── commands │ ├── core │   ├── __init__.py │ ├── ... │   └── webshell ├── core_tests │ ├── ... │   ├── __init__.py │   └── test_version.py │ ├──flake8.log └── ... We fetch different folders and put them all in src/ which then we export to PYTHONPATH when we run the unittests from core_tests (with nosetests). The problem is that at each fetch from SVN even if we don't want and we specify this to SVN to only update we get the workspace src/ folder erased! Is it possible to avoid this? A snippet of the fetch: Switching to https://.../core at revision '2015-03-06T12:05:11.289 +0100' D __init__.py A tests ... now comes the next checkout Switching to https://.../lib at revision '2015-03-06T12:05:11.289 +0100' D core D data D datatypes A commands as you can see the "D" will erase previous fetches afterwards adding the new ones. Is this the intended behavior? Later addition: after a few more builds it seems it "fixes by itself" and concludes the build successful without any importation failures of any libraries (caused by the then deleted folders), not sure how correct this is how and needs an analysis from our part, but is this normal?
            danielbeck Daniel Beck added a comment -

            alghe:
            In my experience the modules need to be ordered by increasing root folder depth, e.g. my first module checks out to `.`, and subsequent ones to `foo`, `bar`, etc. – maybe something similar helps in your situation.

            Note that this issue is ancient and probably should not be revived. File new bugs, or (better if you're not sure it's a bug) ask the jenkinsci-users mailing list.

            danielbeck Daniel Beck added a comment - alghe : In my experience the modules need to be ordered by increasing root folder depth, e.g. my first module checks out to `.`, and subsequent ones to `foo`, `bar`, etc. – maybe something similar helps in your situation. Note that this issue is ancient and probably should not be revived. File new bugs, or (better if you're not sure it's a bug) ask the jenkinsci-users mailing list.
            vvv444 Vasili Galka added a comment -

            alghe: I agree with danielbeck, what you described does not seem to be related to the initial point of this issue. Also, I don't fully understand what behaviour you expected. Can you please provide a manual list of svn commands that produce your desired behaviour? Then we can analyze how it differs from what Jenkins does.

            Beside alghe comment from 2015, can anyone please explain what is this issue about and why is it still opened? Does the initial problem still exist? I tried digging all the above history, but I fail to find a clear scenario description defining the problem.

            vvv444 Vasili Galka added a comment - alghe : I agree with danielbeck , what you described does not seem to be related to the initial point of this issue. Also, I don't fully understand what behaviour you expected. Can you please provide a manual list of svn commands that produce your desired behaviour? Then we can analyze how it differs from what Jenkins does. Beside alghe comment from 2015, can anyone please explain what is this issue about and why is it still opened? Does the initial problem still exist? I tried digging all the above history, but I fail to find a clear scenario description defining the problem.

            People

              kaxelson kaxelson
              kaxelson kaxelson
              Votes:
              5 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: