• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • None

      For our maven jobs we deploy the artifacts to a Nexus Maven repository.
      This requires that I do not select the "Disable automatic artifact archiving" option.

      I have configured the LogRotator Discard old builds to keep the last 30 builds, but only keep 1 build with artifacts.

      In multimodule maven builds the following directory is deleted:
      ${jenkins_home}/jobs/${jobname}/archive

      The following directories are not deleted:
      ${jenkins_home}/jobs/${jobname}/modules/${moduleName}/builds/65/archive

      Is there another way to deploy the artifacts to nexus and retain a build history without having to keep all the module artifacts?

          [JENKINS-17355] LogRotator does not delete Maven Artifacts

          ndg added a comment - - edited

          Still occurs since 1.530 where the modules artefacts are not cleaned up... at least the old artefacts already in place are not cleaned up

          ndg added a comment - - edited Still occurs since 1.530 where the modules artefacts are not cleaned up... at least the old artefacts already in place are not cleaned up

          The old build artifacts for a job will not get cleaned up until after another build of that job has run.
          Have you checked the artifacts for a build after running a build?

          Geoff Cummings added a comment - The old build artifacts for a job will not get cleaned up until after another build of that job has run. Have you checked the artifacts for a build after running a build?

          ndg added a comment -

          I did already rerun the job after setting the values for build to keep and artefacts to keep to the value 2.
          I did not fill in the values for the days to keep.

          After rerunning the build 2 or 3 times i still see the artefacts under the modules sections for my multimodule project.
          Please note that we have a Maven Flat Layout setup.

          ndg added a comment - I did already rerun the job after setting the values for build to keep and artefacts to keep to the value 2. I did not fill in the values for the days to keep. After rerunning the build 2 or 3 times i still see the artefacts under the modules sections for my multimodule project. Please note that we have a Maven Flat Layout setup.

          ndg added a comment -

          Even with the days to keep filled in no folders with old artefacts are deleted from the modules folder on the linux server

          fi.
          /data/hudson/jobs/project/modules/be.company.domain$project-client/builds

          ndg added a comment - Even with the days to keep filled in no folders with old artefacts are deleted from the modules folder on the linux server fi. /data/hudson/jobs/project/modules/be.company.domain$project-client/builds

          ndg added a comment - - edited

          Alright..... configured the hudson.tasks.LogRotator logger and found the fix indeed do the cleanup now.
          nevertheless, I needed to manually delete the old modules builds which are not taken into account for purgin deleting after this issue was fixed.

          Another workaround is to rename the current project to project-to-delete, create a new one (copy of the one to delete), and remove the project-to-delete (you will lost all history data in this case)

          I'm on version 1.534 for now.

          ndg added a comment - - edited Alright..... configured the hudson.tasks.LogRotator logger and found the fix indeed do the cleanup now. nevertheless, I needed to manually delete the old modules builds which are not taken into account for purgin deleting after this issue was fixed. Another workaround is to rename the current project to project-to-delete, create a new one (copy of the one to delete), and remove the project-to-delete (you will lost all history data in this case) I'm on version 1.534 for now.

          ndg added a comment -

          Solved as the issue does indeed not occur anymore.
          The only problem still left is you need to manually remove the old modules builds.

          ndg added a comment - Solved as the issue does indeed not occur anymore. The only problem still left is you need to manually remove the old modules builds.

          If it's of use to anyone, here's a little bash script to remove the old build directories according to the numToKeep parameter configured in the job. You could probably put the script in a Jenkins job and run it from there, although I haven't tried this.

          Hope it helps.

          #!/bin/bash
          # Script to delete unwanted build directories left by the Log Rotator bug https://issues.jenkins-ci.org/browse/JENKINS-17355. 
          
          JENKINS_ROOT=$1
          DELETE_DIRS=$2
          
          if [[ -z "$JENKINS_ROOT" ]]; then
                  echo "Need to set the jenkins root Directory. The 'jobs' directory will be a sub-directory of this one."
                  echo "Usage: 
                          Identify directories with: ./oldLogRemoval /path/to/jenkins/root
                          Remove   directories with: ./oldLogRemoval /path/to/jenkins/root true"
                  exit 1
          fi
          
          for j in $(ls -d $JENKINS_ROOT/jobs/* ); do
                  #echo $j
                  numToKeep=$( cat $j/config.xml | grep numToKeep | sed 's/.*<numToKeep>//g' | sed 's/<\/numToKeep>.*//g' )
                  if [[ -n "$numToKeep" && "-1" != "$numToKeep" ]]; then
                          echo "Processing job$j. Number of builds to keep: $numToKeep"
                          for buildsDir in $( find $j -maxdepth 3 -name builds -type d); do
                                  echo "Processing builds directory: $buildsDir"
                                  for buildDir in $( ls -d $buildsDir/201* 2> /dev/null | head -n -$numToKeep ); do
                                          if [[ "true" == "$DELETE_DIRS" ]]; then
                                                  rm -rvf $buildDir
                                          else
                                                  echo "To remove: $buildDir"
                                          fi
                                  done
                          done
                  fi
          done
          

          Steve Boardwell added a comment - If it's of use to anyone, here's a little bash script to remove the old build directories according to the numToKeep parameter configured in the job. You could probably put the script in a Jenkins job and run it from there, although I haven't tried this. Hope it helps. #!/bin/bash # Script to delete unwanted build directories left by the Log Rotator bug https: //issues.jenkins-ci.org/browse/JENKINS-17355. JENKINS_ROOT=$1 DELETE_DIRS=$2 if [[ -z "$JENKINS_ROOT" ]]; then echo "Need to set the jenkins root Directory. The 'jobs' directory will be a sub-directory of this one." echo "Usage: Identify directories with: ./oldLogRemoval /path/to/jenkins/root Remove directories with: ./oldLogRemoval /path/to/jenkins/root true " exit 1 fi for j in $(ls -d $JENKINS_ROOT/jobs/* ); do #echo $j numToKeep=$( cat $j/config.xml | grep numToKeep | sed 's/.*<numToKeep> //g' | sed 's/<\/numToKeep>.*//g' ) if [[ -n "$numToKeep" && "-1" != "$numToKeep" ]]; then echo "Processing job$j. Number of builds to keep: $numToKeep" for buildsDir in $( find $j -maxdepth 3 -name builds -type d); do echo "Processing builds directory: $buildsDir" for buildDir in $( ls -d $buildsDir/201* 2> /dev/ null | head -n -$numToKeep ); do if [[ " true " == "$DELETE_DIRS" ]]; then rm -rvf $buildDir else echo "To remove: $buildDir" fi done done fi done

          DI2E SysAdmin added a comment -

          @lostinberlin: Sorry to dig up such an old thread, but I have a question about your bash script. Why is it combing through directories named $buildsDir/201*? What is the significance of the 201?

          DI2E SysAdmin added a comment - @lostinberlin: Sorry to dig up such an old thread, but I have a question about your bash script. Why is it combing through directories named $buildsDir/201* ? What is the significance of the 201?

          di2esysadmin sorry for the radio silence. didn't register the email notification. Phew, this was a long time ago. If I remember correctly the directories were named by date (YYYY-MM-DD..., so "2013-10-22...") with a symlink linking the build number to the directory. Since there were other directories in there (such as build number) I needed to narrow it down before deleting.

          I've checked (curiosity and all that). Here's an example of what I mean.

          [user@server ~]$ ll /jenkins/jobs/myJob/builds/ | grep 2015-03
          lrwxrwxrwx. 1 jenkins jenkins   19 Mar  2 11:23 1212 -> 2015-03-02_11-23-06
          lrwxrwxrwx. 1 jenkins jenkins   19 Mar  2 14:03 1213 -> 2015-03-02_14-03-08
          lrwxrwxrwx. 1 jenkins jenkins   19 Mar 12 11:58 1214 -> 2015-03-12_11-58-12
          drwxr-xr-x. 2 jenkins jenkins 4096 Mar  2 11:40 2015-03-02_11-23-06
          drwxr-xr-x. 2 jenkins jenkins 4096 Mar  2 14:18 2015-03-02_14-03-08
          drwxr-xr-x. 2 jenkins jenkins 4096 Mar 12 12:11 2015-03-12_11-58-12
          

          In hindsight, the script should also have checked for the existence of the symbolic link and deleted that as well.

          Hope it helps.

          Steve Boardwell added a comment - di2esysadmin sorry for the radio silence. didn't register the email notification. Phew, this was a long time ago. If I remember correctly the directories were named by date (YYYY-MM-DD..., so "2013-10-22...") with a symlink linking the build number to the directory. Since there were other directories in there (such as build number) I needed to narrow it down before deleting. I've checked (curiosity and all that). Here's an example of what I mean. [user@server ~]$ ll /jenkins/jobs/myJob/builds/ | grep 2015-03 lrwxrwxrwx. 1 jenkins jenkins 19 Mar 2 11:23 1212 -> 2015-03-02_11-23-06 lrwxrwxrwx. 1 jenkins jenkins 19 Mar 2 14:03 1213 -> 2015-03-02_14-03-08 lrwxrwxrwx. 1 jenkins jenkins 19 Mar 12 11:58 1214 -> 2015-03-12_11-58-12 drwxr-xr-x. 2 jenkins jenkins 4096 Mar 2 11:40 2015-03-02_11-23-06 drwxr-xr-x. 2 jenkins jenkins 4096 Mar 2 14:18 2015-03-02_14-03-08 drwxr-xr-x. 2 jenkins jenkins 4096 Mar 12 12:11 2015-03-12_11-58-12 In hindsight, the script should also have checked for the existence of the symbolic link and deleted that as well. Hope it helps.

          Daniel Beck added a comment -

          Note that from Jenkins 1.597 on, the structure of the build directories are different (no more symlinks, build numbers are used as directory names).

          Daniel Beck added a comment - Note that from Jenkins 1.597 on, the structure of the build directories are different (no more symlinks, build numbers are used as directory names).

            ndg ndg
            gcummings Geoff Cummings
            Votes:
            3 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: