Am So., 22. Juli 2018 um 00:42 Uhr schrieb Joan Touzet <woh...@apache.org>:
> Yes - you can do this in your own Jenkinsfile or job description. > > In a Pipeline build (declarative or procedural), use deleteDir() : > > https://jenkins.io/doc/pipeline/steps/workflow-basic-steps/#-deletedir-%20recursively%20delete%20the%20current%20directory%20from%20the%20workspace > > In a old-school build, use the Workspace Cleanup Plugin: > > https://plugins.jenkins.io/ws-cleanup My intent is that jenkins hopefully can be configured to enforce workspaces to be wiped after a build, regardless of its outcome. The rationale behind this is, that a build pipeline shall start a build from scratch. Otherwise a lot of funny side effects arise that may escalate in collateral damage in regard to stability and quality of built binaries - even only after a signifcant amount of time has passed by (months or even years). For instance, I had the chance only to find a "bug" in a build pipeline where builds did no longer pass but worked fine until some day earlier. It coincided with an event where the workspace was wiped. After a lot of brain and time passing by, we found that essential files were purged from the repository several months ago but were kept alive in the ci workspace. Interestingly, none of the devs had issues building the project either. *sigh* On another event a software did no longer work after that an assembly was renamed. Once more, after a lot of brain and time passing by, we found that the build system shipped both the old and the new assembly because the workspace of the ci pipeline was not cleaned. There were another few occasions and funny stories to tell. Lesson learned: a ci pipeline that has no genuine workspace to start from can be a risky game.
