Status: Resolved (View Workflow)
There are a couple aspects to this:
- If you actually expect persistence in your workspace for some reason (I know, I know) and run the job expecting said persistence monthly, some months you'll discover that your workspace got nuked if you're in a Pipeline job. WorkspaceCleanupThread just looks for AbstractProject when checking if the workspace is the one used by the last build - that should probably be Job instead, at least for the last-built-on check. But then there's the matter of figuring out which workspaces were actually involved in the last build of a Pipeline job, which brings me to...
- WorkflowJob.getLastBuiltOn() always returns the master. So if we want to have WorkspaceCleanupThread not nuke the workspace(s) used in the last build of a Pipeline job, we actually need to get all workspaces that an ExecutorStep in the last build used. And that brings up a related matter...
- If you've got multiple workspaces for a single Pipeline job on a single agent (i.e., a @2 etc one as well as the default), say due to parallelization, only the default one gets deleted in the first place. I think this may be the case for other job types as well, but don't quote me on that quite yet. Anyway, that's a problem too.
JENKINS-2111 removing a job (including multibranch/org folder branches/repos) does not remove the workspace
WorkspaceCleanupThread as currently conceived is close to useless.