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

Workspace got deleted for custom workspaces after updating to 1.485

    • Icon: Bug Bug
    • Resolution: Incomplete
    • Icon: Major Major
    • core
    • None
    • Windows 7. Jenkins runs via its own server, no master-slave setup, i.e. only running by itself

      After updating to 1.485 some of my builds broke. When checking the workspace they were all deleted.

      I found out that workspaces on slaves are deleted after 30 days of inactivity.
      But I don't have any slaves, and these workspaces are never updated, since they only contain some ANT scripts, or plain batch, that only copies files outside of Jenkins.

      My last version before this update was 1.481, I am running these scripts for over a year, and nothing like this ever happened.

          [JENKINS-15495] Workspace got deleted for custom workspaces after updating to 1.485

          Jesse Glick added a comment -

          Assuming reproducible, not a critical bug; workspaces are designed to be disposable, i.e. they can be freely recreated at the expense of a longer build.

          Jesse Glick added a comment - Assuming reproducible, not a critical bug; workspaces are designed to be disposable, i.e. they can be freely recreated at the expense of a longer build.

          Klaus Scharpf added a comment -

          The problem is that these workspaces were not in version control, since they only contain some scripts that never change. From time to time I back them up - and normally our company always does backups - but it still deleted some valuable items.
          I think this is still a serious issue since Jenkins allows workspaces without version control association, and therefore they will not be automatically re-created.
          Also, I have custom workspaces pointing into directories of my current development environment to run some scripts easily.
          Deleting them would delete ongoing development work. And yes, sometimes a specific branch might be dormant for a while...

          Klaus Scharpf added a comment - The problem is that these workspaces were not in version control, since they only contain some scripts that never change. From time to time I back them up - and normally our company always does backups - but it still deleted some valuable items. I think this is still a serious issue since Jenkins allows workspaces without version control association, and therefore they will not be automatically re-created. Also, I have custom workspaces pointing into directories of my current development environment to run some scripts easily. Deleting them would delete ongoing development work. And yes, sometimes a specific branch might be dormant for a while...

          Jesse Glick added a comment -

          Never put original scripts directly in the workspace. Rather, version the scripts somewhere, either as part of some VCS-controlled project or inlined in the job configuration (which you should back up), and copy them to the workspace as a build step.

          Jesse Glick added a comment - Never put original scripts directly in the workspace. Rather, version the scripts somewhere, either as part of some VCS-controlled project or inlined in the job configuration (which you should back up), and copy them to the workspace as a build step.

          Daniel Beck added a comment -

          More information is needed to investigate this issue further:

          • Does it still occur on Jenkins 1.551+ which changed how workspace cleanup works?
          • What is the full path of the workspace in question?
          • Where is the Jenkins home directory?
          • Do you have slaves, what are their remote FS root dirs?

          Jesse: The help on custom workspaces should probably be rephrased, currently it implies that Jenkins will not delete custom workspaces:

          Normally you should let Jenkins allocate and clean up workspace directories, but in several situations this is problematic, and in such case, this option lets you specify the workspace location manually.

          Daniel Beck added a comment - More information is needed to investigate this issue further: Does it still occur on Jenkins 1.551+ which changed how workspace cleanup works? What is the full path of the workspace in question? Where is the Jenkins home directory? Do you have slaves, what are their remote FS root dirs? Jesse: The help on custom workspaces should probably be rephrased, currently it implies that Jenkins will not delete custom workspaces: Normally you should let Jenkins allocate and clean up workspace directories, but in several situations this is problematic, and in such case, this option lets you specify the workspace location manually.

          Jesse Glick added a comment -

          Yes that description could be misleading.

          Jesse Glick added a comment - Yes that description could be misleading.

          Daniel Beck added a comment -

          No response to comment asking for further information in four weeks, resolving as incomplete.

          Daniel Beck added a comment - No response to comment asking for further information in four weeks, resolving as incomplete.

            Unassigned Unassigned
            klausscharpf Klaus Scharpf
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: