cleanup of orphaned jobs

[Martin Mrazik]

Some jobs get orphaned e.g. when you change configuration (quantal-amd64 vs raring-amd64). We should figure out how to cleanup/delete such jobs so they are not in jenkins forever even when they are not used.

[Francis Ginther (fginther)]

I discussed some thoughts on this with Chris, here's what I remember:

Any solution has to be careful not to remove jobs that have been moved to the 'to_transition' section of the stack file. In this case we still want to run continuous integration on these even though the daily-release process is not building them.

I see these most common use cases:
 - target_branch changes
 - builder jobs are transitioned to a new release (i.e. quantal to raring)
 - builder jobs are dropped from a project (i.e. we discover the project only builds for armhf, but i386 was also defined)

target_branch changes are the trickiest as the entire set of jobs as been orphaned and we have no way to identify them from an existing stack file. It might help to stuff meta-data inside the jenkins job description so that we can cross reference a job to a stack file and vice versa.

builder job changes can be solved in two ways:
 1) use the current and orphaned string trick (good for when changing to a new release)
 2) use a regex to find all jenkins jobs that match <project>-*-<job_type>, then match that list to the downstream jobs triggered by <project>-<job_type>.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:cupstream2distro-config at revision 157, scheduled for release in cupstream2distro-config, milestone Unknown