What does "deferred wipeout" option really mean in Jenkins Workspace Cleanup plugin?

Question

Jenkins Workspace Cleanup plugin is a widely used plugin with over 200k installs per month in the past 12 months.

The thing that bothers me is that its "deferred wipeout" functionality is not documented properly. I can only suspect that "deferred" means asynchronous, so that it doesn't block the node/executor, but I'm guessing right now.

Also if it's actually asynchronous and another job is scheduled on the same node and the same workspace, do we have any guarantees that the workspace is properly cleaned up before the new job starts?

The documentation only says:

When deferred wipeout is disabled the old implementation of filesystem content deletion is used. (...)

For developers of (cloud, for instance) it might be useful to be sure deferred wipeout is never selected as a cleanup method.

What does this mean? What are the scenarios in which deferred wipeout should never be used?

Can anyone explain what is the real effect of having this option enabled/disabled, potentially with some use cases?

Answer 1

Deferred wipeout means that deletion takes place asynchronously to your build, that is:

1. rename workspace directory to a temporary directory name, then
2. start a background task for deleting that temporary directory.

(See source code for details).

For big workspaces, deletion can take very long, so this will reduce your build time.

When running multiple builds of the same job in parallel, Jenkins will automatically select build-specific workspace names (by adding a numeric extension to the workspace directory) -- so there's no interference with asynchronous deletion.

In a cloud environment where you have ephemeral build nodes created and deleted on-demand, you'd potentially destroy nodes which are still running the asynchronous delete operation, so you might prefer to disable the option in such cases.