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

Please add ability to use the git 'clean' options AFTER job execution

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Minor Minor
    • git-plugin
    • None

      I would love to be able to have my jobs automatically return the workspace to a clean state after execution - but otherwise leave the cloned repo present at the end of a job automatically. I could do this myself in a post step, but seems like it would be nice to be able to just define this in the SCM section and have it done automatically.

      Even better would be ability to say "Clean after job, if:

      {stable|unstable|failed}

      " - to allow leaving the workspace around for examination if the job fails, but otherwise clean when done.

          [JENKINS-27211] Please add ability to use the git 'clean' options AFTER job execution

          Mark Waite added a comment -

          Can you explain why you want to clean after build? It seems like you would be intentionally sacrificing diagnostic information which is in the workspace in order to save the disc space used by the files which the build generated.

          I'm accustomed to thinking of disc space as very low cost, while diagnostic time is very expensive.

          Mark Waite added a comment - Can you explain why you want to clean after build? It seems like you would be intentionally sacrificing diagnostic information which is in the workspace in order to save the disc space used by the files which the build generated. I'm accustomed to thinking of disc space as very low cost, while diagnostic time is very expensive.

          In my case it's from developers that don't clean up after themselves and leave numerous very large/bloated builds sitting around. Particularly when they create new jobs, and then delete them - since jenkins doesn't seem to clean any of that up out on the agents.

          Nathan Neulinger added a comment - In my case it's from developers that don't clean up after themselves and leave numerous very large/bloated builds sitting around. Particularly when they create new jobs, and then delete them - since jenkins doesn't seem to clean any of that up out on the agents.

          I can clean the whole workspace, but that just means the inefficiency of updating the clone from repo server again.

          Nathan Neulinger added a comment - I can clean the whole workspace, but that just means the inefficiency of updating the clone from repo server again.

          Mark Waite added a comment -

          Aren't you better served by requesting that deleted jobs be removed from slaves, rather than using a "git clean" in the workspace on the slave?

          A "git clean" in the workspace on the slave won't remove the working directory, or the .git directory within that working directory, so it will still leave plenty of "debris" around if the Jenkins server is not deleting the slave workspaces.

          Mark Waite added a comment - Aren't you better served by requesting that deleted jobs be removed from slaves, rather than using a "git clean" in the workspace on the slave? A "git clean" in the workspace on the slave won't remove the working directory, or the .git directory within that working directory, so it will still leave plenty of "debris" around if the Jenkins server is not deleting the slave workspaces.

          That's true, for the 'delete' case. However, it's a lot easier to universally say "Hey, if you have a job, mark it to 'git clean' at the end of the job if the job is successful". That takes care of most of the build scenarios where the content of the job is much larger than the repo.

          It looks like I could rig up something with: https://wiki.jenkins-ci.org/display/JENKINS/Global+Post+Script+Plugin

          Just seems like this would be much easier to have here since it's already controlling that cleanup process during init, and it's already aware of each of the clone paths in the job.

          Nathan Neulinger added a comment - That's true, for the 'delete' case. However, it's a lot easier to universally say "Hey, if you have a job, mark it to 'git clean' at the end of the job if the job is successful". That takes care of most of the build scenarios where the content of the job is much larger than the repo. It looks like I could rig up something with: https://wiki.jenkins-ci.org/display/JENKINS/Global+Post+Script+Plugin Just seems like this would be much easier to have here since it's already controlling that cleanup process during init, and it's already aware of each of the clone paths in the job.

            Unassigned Unassigned
            nneul Nathan Neulinger
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: