Unfortunately, clients need to be preserved in order for subsequent syncs to be more efficient. Deleting them at the end of the job would cause every run to sync everything from scratch, which is a massive waste of time and bandwidth. It's far more efficient to just keep them around.

True, unless you're using the force sync option and wiping your workspace at the end of each build anyway. Maybe it could be a checkbox under the force sync option?

I have no idea how typical this workflow is, but ours relies on us wiping the workspace and force syncing each time. This is done because for a number of branches across a large pool of nodes, there isn't near enough storage space on each build slave to keep a sync'ed workspace on each (Dealing with a few hundred branches of 5-10GB workspace size in each, and a pool of a couple dozen nodes = 100s * (5-10)GB * ~ 24 = many terabytes of expensive SAN). Typical space/bandwidth tradeoff, with a local perforce proxy keeping the traffic across the WAN to a minimum. Additionally, it keeps builds from being contaminated by old artifacts.

Also this proposed enhancement would probably be useful for jobs that are run only rarely.

A few things:

• You can very easily just run 'p4 client -df $P4CLIENT' as the first step in your job.
• The plugin is already overloaded with options. We should only add new ones if they are absolutely necessary.
• Someone else (possibly you) will need to implement it if we decide to go ahead with adding it.

1) True, there is an very easy workaround adding the command as the last step or post build task. It'd just be cleaner inside the plugin (arguably the opposite if you're not using it and concerned about bloat).
2) Yes, it has become an incredibly flexible plugin.
3) Took a look at the code (guess I should've done that part first). I was originally thinking it'd be a checkbox under force sync, which would be pretty attractive. Looking at the SCM class though, the only obvious way I can see to do it would be to add it as a separate post-build step - similar to the way the labeling works (I'm assuming that's why the labeling portion isn't grouped with the rest of the plugin). A post-build step just for that option would be almost as annoying as having to add a generic step with the command line command, so I'm somewhat inclined to side with your reluctance on this feature.

Well, thanks for the time and input! Perhaps we can leave this ticket open for a month or so and see if anyone else wants to weigh in, then close it out?

I have ran into the same issue. We also have many jobs and jenkins slave nodes with limited space, and so deleting codebases at the end of jobs is necessary. Also for release jobs (of which we have many), I prefer to run a brand new force sync to retrieve the code to be built.

I am using the workspace-cleanup-plugin to delete job workspaces, however this is part of the solution, as it deletes the jenkins workspace, but does not safely cleanup the perforce workspace. It would be nice, if there was a post build action that could be activated to delete or at the least safely cleanup (i.e. revert any checked out files, delete any pending changelists, remove all workspace files) as a post build action that could be run before the workspace-cleanup-plugin deletes the jenkins workspace.

Omar, deleting the workspace through Jenkins automatically flushes the client back to #0. It is not necessary to also delete the client itself, and in many cases it is not desirable to do so.

I am not adding this option, partly because this plugin is no longer maintained, but mostly because it's not a useful option given the plethora of alternatives that have been listed. If someone else wants to write a post-build task, or extend the workspace clean functionality to optionally delete the client spec, they are more than welcome to.