hudson CI: how to delete all jobs?

Question

I have about 100 jobs on my hudson CI, possible to mass delete them ?

Answer 1

You can programmatically use the XML api (or use the JSON flavor if you prefer that):

http://your.hudson.url/api/xml?xpath=//job/name&wrapper=jobs

Returns:

<jobs>
    <name>firstJob</name>
    <name>secondJob</name>
    <!-- etc -->
</jobs>

Now iterate over the job names and do a post request to

 http://your.hudson.url/job/your.job.name/doDelete

(You can do this with any programming language you like that supports XML and HTTP)

Answer 2

Just delete the job directories:

cd $HUDSON_HOME/jobs
rm -rf <JOB_NAME>

See: Administering Hudson

Answer 3

The easiest way, IMHO, would be to use script. Go to http://your.hudson.url/script/

Delete jobs by running:

for(j in hudson.model.Hudson.theInstance.getProjects()) {
    j.delete();
}

And this way gives you an option to easily use condition to filter out jobs to delete.

---

FOR JENKINS

Current versions (2.x):

for(j in jenkins.model.Jenkins.theInstance.getAllItems()) {
    j.delete()
}

Older versions:

for(j in jenkins.model.Jenkins.getInstance().getProjects()) {
    j.delete();
}

Answer 4

I had similar manageability problems with a Hudson instance that was running 500+ build jobs - it was impractical to manually maintain that many jobs using the gui. However, you can provision jobs in Hudson remotely and programatically by using the CLI - which is supplied as a jar file [http://wiki.hudson-ci.org/display/HUDSON/Hudson+CLI].

The command to delete a job would be something like:
**java -jar hudson-cli.jar -s http://host:port/ delete-job jobname**

And the rest of the commands you will need are here:
**java -jar hudson-cli.jar -s http://host:port/** help

I wrapped the cli in python and created an XML file from which to hold the build configuration - then I could use this to manipulate my running instances of Hudson. This also provided the ability to 'reset' the CI instance back to a known configuration - handy if you suspect build failures were caused by manual changes in the UI or if you are using a different CI server for each environment you deploy to (ie dev, test, prod) and need to provision a new one.

This has also got me out of a few binds when badly written plugins have mangled Hudson's own XML and I've needed to rebuild my instances. Hudson is also I/O bound and for really loaded instances it is often faster to boot Hudson from scratch and populate it's configuration this way.