Wrangling the package repo!

Once you're using a builder from day-to-day frequently adding new packages to the ControlTier (WebDAV) repository, it's alarming how quickly their numbers and the amount of disk space they consume can rise!

A couple of new Builder base type commands were introduced with ControlTier 3.1 to facilitate managing the package repository: "repoFind" & "repoPurge".

The "repoFind" command's "-purge" option comes to the rescue by providing the antidote to "repoImport":

repoFind [Builder] [-buildstamp <.*>] [-packagetype <>] [-session ] [-version <.*>] [-purge]
Find package objects in the repository.

Essentially, the command queries the object model matching package objects by "buildstamp" and "packagetype" regex patterns to create a list of candidate packages, the (optionally) calling the "repoPurge" command which invokes each package's "purge" command:

purge -url <>
removes the file from the repository

... which in turn deletes the package file using the Ant "davdelete" task. Finally, the "repoPurge" command executes a batched deletion of all the selected package objects. Note that only package that do not have referrer relationships are deleted (i.e. packages that are not in use).

Here are a couple of examples:

• Purge all packages regardless of their type associated with a given buildstamp:
  

  $ ad -p rhbc -t AtgDasModuleBuilder -o babyandchild -c repoFind --
     -buildstamp 8734 -purge
  

• Purge all packages of a given type regardless of their buildstamp (the "packagetype" option value can be a regex too):
  

  $ ad -p rhbc -t AtgDasModuleBuilder -o babyandchild -c repoFind -- -buildstamp '.*'
     -packagetype AtgModuleJar  -purge
  

By the way, having just run through using "repoFind" with one of our client's projects, I can report a subtle bug that I've just fixed in the "repoPurge" command. It turns out that the command assumes that the required Package module is installed in order to be able to run the "purge" commands. This is always the case if you invoke the "repoPurge" command from a node which has previously been used for a "repoImport" (e.g. your build system), but if you choose another system (e.g. the ControlTier server), the module is not available and the command fails.

Here's the fix using the same logic used in "repoImport":

$ svn diff repoPurge.xml
Index: repoPurge.xml
===================================================================
--- repoPurge.xml       (revision 8087)
+++ repoPurge.xml       (working copy)
@@ -88,6 +88,13 @@
    <session-get session="${session.command}" resultproperty="pkg.mapref-uri" key="purge.package.@{pkgType}.@{pkgName}.mapref-uri"/>
    <session-get session="${session.command}" resultproperty="pkg.repo-url" key="purge.package.@{pkgType}.@{pkgName}.repo-url"/>
    <propertyregex property="filetype" override="true" input="@{pkgName}" regexp="[^\.]*.([^\.]*)$" select="\1"/>
+         <controller>
+           <execute>
+             <context/>
+             <command name="Install-Module" module="Managed-Entity" depot="${context.depot}"/>
+             <arg line="-depot ${context.depot} -module @{pkgType} -version head"/>
+           </execute>
+         </controller>
    <controller>
      <execute>
        <context/>

The fix will make the next 3.1 point release and will be merged into the 3.2 development brach and posted to Sourceforge soon.

Thanks,

Anthony.