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

Pipeline Job-- deletedir() delete only current directory but @script and @tmp dir still there in workspace.

    Details

    • Similar Issues:

      Description

      Directories with an ampersand (like @tmp and @script) are not removed when using 'deletedir()' in pipeline stage.

        Attachments

          Issue Links

            Activity

            Hide
            nitram Martin Karing added a comment -

            Steven Christenson: I don't think the directory is required for the replay operation. If I delete the @libs workspace on the master by hand, replay still work fine. There is a copy of the required files of the library in the directory of all builds. I am guessing this one is utilized for what ever the replay requires it for, or the required commit is just checked out from the repository again.

            No matter, there is still a @libs directory in the directory for the master workspaces, that just sits there forever. It contains the in my case implicitly loaded shared libraries for each job. And there are a lot of them due to heavy use of feature branches and pull requests. It can't be deleted by the pipeline and it's not automatically deleted if the associated job in Jenkins is deleted. Also I do not have any build processors enabled on the master node, so that workaround with switching to the problematic directory directly does not fly as well, because I can't get into the master workspaces with the pipelines as far as I know.

            The one way to get rid of those directories I was able to come up with is to have the server run a nightly cron job that clears our the workspace directory of the master, so the issue does not get out of hand. That solution works, but I'd rather solve that issue inside of Jenkins.

            Show
            nitram Martin Karing added a comment - Steven Christenson : I don't think the directory is required for the replay operation. If I delete the @libs workspace on the master by hand, replay still work fine. There is a copy of the required files of the library in the directory of all builds. I am guessing this one is utilized for what ever the replay requires it for, or the required commit is just checked out from the repository again. No matter, there is still a @libs directory in the directory for the master workspaces, that just sits there forever. It contains the in my case implicitly loaded shared libraries for each job. And there are a lot of them due to heavy use of feature branches and pull requests. It can't be deleted by the pipeline and it's not automatically deleted if the associated job in Jenkins is deleted. Also I do not have any build processors enabled on the master node, so that workaround with switching to the problematic directory directly does not fly as well, because I can't get into the master workspaces with the pipelines as far as I know. The one way to get rid of those directories I was able to come up with is to have the server run a nightly cron job that clears our the workspace directory of the master, so the issue does not get out of hand. That solution works, but I'd rather solve that issue inside of Jenkins.
            Hide
            stevenatcisco Steven Christenson added a comment -

            Szczepan Zaskalski: That directory is on the MASTER to allow you to do Replay operations.  It contains the content of any library that was loaded at run time. Without a copy, Replay can't work reliably.

            Oliver Gondža: Indeed, deleting scripts that may well be executing is unsafe.

            However in general deleteDir(), IMHO should remove any copy on a slave (provided the slave isn't actually the master)

            Show
            stevenatcisco Steven Christenson added a comment - Szczepan Zaskalski : That directory is on the MASTER to allow you to do Replay operations.  It contains the content of any library that was loaded at run time. Without a copy, Replay can't work reliably. Oliver Gondža : Indeed, deleting scripts that may well be executing is unsafe. However in general deleteDir(), IMHO should remove any copy on a slave (provided the slave isn't actually the master)
            Hide
            szczepix Szczepan Zaskalski added a comment -

            Why my jenkins create tmp directories in the master workspace for Jenkins Shared library instead of using agent workspace?

            Show
            szczepix Szczepan Zaskalski added a comment - Why my jenkins create tmp directories in the master workspace for Jenkins Shared library instead of using agent workspace ?
            Hide
            olivergondza Oliver Gondža added a comment -

            Seeing the workarounds, I am wondering how wise it is to delete the pipeline helper folder(s) while the pipeline is still running.

            Show
            olivergondza Oliver Gondža added a comment - Seeing the workarounds, I am wondering how wise it is to delete the pipeline helper folder(s) while the pipeline is still running.
            Hide
            alexander_samoylov Alexander Samoylov added a comment - - edited

            Baptiste Mathus wrote: "Not a bug by the way, more an improvement."
            I strongly disagree. Jenkins creates the @tmp automatically and stores there temporary files. Therefore it should be removed also automatically by Jenkins.
            Each tool that produces temporary data should be responsible for its removal. It is easy as ABC.
            Following your logic, memory leaks are also "not a bugs"...

            +1 for the fix (which must be trivial)

            Update: I confirm that the workaround dir(<dir> + '@tmp')

            { deleteDir() }

            is working. Luckily it does not create the nested @tmp@tmp. Thank you, Niels van Aken.

            Show
            alexander_samoylov Alexander Samoylov added a comment - - edited Baptiste Mathus wrote: "Not a bug by the way, more an improvement." I strongly disagree. Jenkins creates the @tmp automatically and stores there temporary files. Therefore it should be removed also automatically by Jenkins. Each tool that produces temporary data should be responsible for its removal. It is easy as ABC. Following your logic, memory leaks are also "not a bugs"... +1 for the fix (which must be trivial) Update: I confirm that the workaround dir(<dir> + '@tmp') { deleteDir() } is working. Luckily it does not create the nested @tmp@tmp. Thank you, Niels van Aken .

              People

              • Assignee:
                Unassigned
                Reporter:
                hiten_prajapati Hiten Prajapati
              • Votes:
                65 Vote for this issue
                Watchers:
                83 Start watching this issue

                Dates

                • Created:
                  Updated: