| My optimism was misplaced - when the code runs, it has a fairly myopic view of the world and only sees the project/job that it's running within. To fix this issue properly, it would be necessary for the code, once it has an idea of what workspaces (on what slaves) it might want to remove, to then iterate across the entire Jenkins configuration, asking each project in turn where their "current" workspace is, and then removing this from the list of workspaces to be cleaned. That's unlikely to be quick.
...and I guess it should also iterate across all currently-running builds and ensure that their workspaces aren't cleaned either (as, in the case of concurrent builds, it's possible to have the same build folder being used on multiple slave nodes). So, while my recent changes will have made this issue easier to fix, they've not fixed it; right now, the only workaround is for users to refrain from enabling the workspace cleanup on jobs that share both workspaces and slaves.
One could argue that, in such a case, there's little point in enabling the plugin for those builds as they're re-using the same workspaces anyway, so the end-user impact of not be able to enable the plugin safely in such situations is of limited significance and hence of "minor" significance rather than "major". |
