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

removing a job (including multibranch/org folder branches/repos) does not remove the workspace

    • 2.0.21

      Removal of a job leaves the workspace intact.

          [JENKINS-2111] removing a job (including multibranch/org folder branches/repos) does not remove the workspace

          bll created issue -

          Olaf Lenz added a comment -

          This is still true. But is this really a bug?

          Olaf Lenz added a comment - This is still true. But is this really a bug?

          pjdarton added a comment -

          It's certainly messy.
          It means that if you've got various slaves, and folks create/rename/delete jobs, you end up with all sorts of junk data left on your slaves.
          I would have expected that any data that isn't reachable from the Jenkins UI to be removed.

          At present, we've got a resource leak that will ultimately kill the slave.
          (it's a bug, but I wouldn't call it a "Major" bug)

          pjdarton added a comment - It's certainly messy. It means that if you've got various slaves, and folks create/rename/delete jobs, you end up with all sorts of junk data left on your slaves. I would have expected that any data that isn't reachable from the Jenkins UI to be removed. At present, we've got a resource leak that will ultimately kill the slave. (it's a bug, but I wouldn't call it a "Major" bug)

          I agree that this is a bug. When a build gets deleted, so should all the data be deleted.
          When a build gets renamed, the files or directories on the file system (with the previous name) should be renamed as well.
          At present Jenkins will use space on the file system unnecessarily. Over a longer period of time, this will cause an issue, particularly for jobs that used a fair bit of space prior to being deleted or renamed.

          Jason Spotswood added a comment - I agree that this is a bug. When a build gets deleted, so should all the data be deleted. When a build gets renamed, the files or directories on the file system (with the previous name) should be renamed as well. At present Jenkins will use space on the file system unnecessarily. Over a longer period of time, this will cause an issue, particularly for jobs that used a fair bit of space prior to being deleted or renamed.

          I have used Hudson for a long time and now Jenkins, and as far as I remember, the default behaviour always was delete the workspace when deleting jobs. IMHO, it is a big regression.

          Michel Graciano added a comment - I have used Hudson for a long time and now Jenkins, and as far as I remember, the default behaviour always was delete the workspace when deleting jobs. IMHO, it is a big regression.

          William Zhang added a comment -

          William Zhang added a comment - you can use script and https://wiki.jenkins-ci.org/display/JENKINS/NodeLabel+Parameter+Plugin to do the same thing,such as my script https://gist.github.com/jollychang/5260975
          Oleg Nenashev made changes -
          Component/s New: core [ 15593 ]
          Component/s Original: other [ 15490 ]

          Daniel Beck added a comment -

          I agree that this is a bug. When a build gets deleted, so should all the data be deleted.

          This may not be possible in the case of distributed builds (nodes may be offline). It may not be desirable in the case of custom workspaces shared with other projects or not meant to be deleted at all (it happens).

          I have used Hudson for a long time and now Jenkins, and as far as I remember, the default behaviour always was delete the workspace when deleting jobs.

          Possibly since new installs use a different top level directory for workspaces than for jobs. It used to be jobs/foo/workspace, now it is workspace/foo, like slave FS layout always was. However, for the master node, this is configurable in global config.

          Daniel Beck added a comment - I agree that this is a bug. When a build gets deleted, so should all the data be deleted. This may not be possible in the case of distributed builds (nodes may be offline). It may not be desirable in the case of custom workspaces shared with other projects or not meant to be deleted at all (it happens). I have used Hudson for a long time and now Jenkins, and as far as I remember, the default behaviour always was delete the workspace when deleting jobs. Possibly since new installs use a different top level directory for workspaces than for jobs. It used to be jobs/foo/workspace, now it is workspace/foo, like slave FS layout always was. However, for the master node, this is configurable in global config.

          Hi
          this issue is very annoying when dealing with hundred jobs you manage dynamically. In long term, this causes a lot of space disk issues.
          I agree this not desirable when having a workspace shared with others jobs. In this case it should be the responsibility of the job author to know if the job deletion (along with its workspace) should impact others jobs.
          To avoid such case I suggest to add a check box "Don't delete the workspace if this job is deleted" in job configuration and find a way to mark a directory not eraseable.

          Concerning the slaves I suggest to check once a the node is reconnected, the list of orphan job workspaces and remove them automaticaly.
          Is it conceivable?

          Laurent TOURREAU added a comment - Hi this issue is very annoying when dealing with hundred jobs you manage dynamically. In long term, this causes a lot of space disk issues. I agree this not desirable when having a workspace shared with others jobs. In this case it should be the responsibility of the job author to know if the job deletion (along with its workspace) should impact others jobs. To avoid such case I suggest to add a check box "Don't delete the workspace if this job is deleted" in job configuration and find a way to mark a directory not eraseable. Concerning the slaves I suggest to check once a the node is reconnected, the list of orphan job workspaces and remove them automaticaly. Is it conceivable?

          Nick Volynkin added a comment -

          This happens when you rename a job - its workspace is not renamed and not deleted either. The job page shows the size of the old workspace, but after next build the new workspace will be created and the used space will equal to the sum of two workspaces. When the job is deleted or when you wipe out the workspace, only the new workspace gets deleted.

          Just found that my Jenkins (v 1.635) "stashed" 35GB this way.

          Nick Volynkin added a comment - This happens when you rename a job - its workspace is not renamed and not deleted either. The job page shows the size of the old workspace, but after next build the new workspace will be created and the used space will equal to the sum of two workspaces. When the job is deleted or when you wipe out the workspace, only the new workspace gets deleted. Just found that my Jenkins (v 1.635) "stashed" 35GB this way.

            jglick Jesse Glick
            bll6969 bll
            Votes:
            90 Vote for this issue
            Watchers:
            101 Start watching this issue

              Created:
              Updated:
              Resolved: