An emergency replacement for the CIA service is coming.

A few hours ago I learned that, due to a virtual-server mishap, the cia.vc notification service is dead. And not coming back.

This was not entirely unexpected. The CIA codebase was a shambles, the service has been flaky and subject to outages, and the server-site operator who inherited it has for some time been muttering darkly that the end was probably nigh.

I’ve been sitting on a lightweight replacement for CIA since late August, holding off shipping until it was clear whether or not a salvage effort on the codebase was going to succeed. That option is off the table now, so I’m going into emergency overdrive to get a release out.

The main thing that still needs to be done is for me to finish and test a hook script for git repos, so that when I ship the admins at places like SourceForge and GitHub will be able to drop in both a server instance and the correct hook code. This script will also be a model for hooks serving other VCSes such as Mercurial, Subversion, and (ugh) CVS.

I’m working on that now and expect to ship within 48 hours. Watch this space.

19 thoughts on “An emergency replacement for the CIA service is coming.

  1. I came in late:

    The intended functionality is that if someone checks in something, it automatically gets built and unit tested on a variety of different machines, he gets notified of failure, and the checkin gets annotated with the results?

  2. >automatically gets built and unit tested on a variety of different machines

    Nothing that fancy. It’s just a way to automatically publish notifications to project IRC channels on each commit to the repo – quite useful when your dev group hangs out on the project channel to discuss development in real time.

    The CIA service wrapped a bunch of (mostly useless) data mining around that – activity statistics and fancy Django displays. I’ve written a long critique of the design as a case study in overengineering; it will be published here soon.

  3. One of the things that a project that I work on did is to use CIA to also pass on activity on our bugtracker (trac), will something like that be possible with what you are planning to release?

  4. Am I the only sysadmin around here?

    A well-known and relied-upon service is permanently dead because of some hosting provider shenanigans? (From what little I’ve been able to read).. One VM gets deleted and it’s gone forever? I shudder to think what else is run on such an amateur-hour basis.

  5. >One of the things that a project that I work on did is to use CIA to also pass on activity on our bugtracker (trac), will something like that be possible with what you are planning to release?

    I don’t know. How was it done? That is, was the bugtracker somehow watching an IRC channel, or was something more complex going on?

  6. >Please tell me that you’ll call your service GRU.

    No, it’s already called “irker” :-). I did consider calling it MI5.

  7. >One VM gets deleted and it’s gone forever?

    Not the entire problem. In theory it might be possible to reconstruct a running CIA if the codebase for it were in good shape, but – it isn’t. Long essay on this mess will be published here shortly.

  8. > I’ve written a long critique of the design as a case study in overengineering; it will be published here soon.

    Looking forward to it. It’s a hard thing to learn, but the trick to design is not what to put in, but what to leave out.

  9. Antoine de St-Exupéry had it exactly right: Perfection (in design) is achieved not when there is nothing more to add, but rather when there is nothing more to take away.

  10. I don’t know. How was it done? That is, was the bugtracker somehow watching an IRC channel, or was something more complex going on?

    It used http://trac-hacks.org/wiki/TracCiaPlugin to accomplish this; it just posts updates to the cia service which in turn would put them into our channel.

  11. No, that is not going to work. You’ll have to write a bot that monitors your project channel and massages the notifications into Trac actions.

    I think you have it backwards; it does not take notifications from cia and do something with them in trac; whenever someone does something in trac it sends a notification to cia (new ticket, updated ticket, changes in the wiki).

  12. The replacement is purely an IRC bot that the commit hook posts information to. If you were using CIA for multiplexing your commit notifications, you should probably look into writing a new commit hook instead.

  13. And now I notice that I got it backwards too. Your trac updates can simply be sent to the same service that the commit hooks use.

  14. >whenever someone does something in trac it sends a notification to cia

    Ah, OK. You’ll probably want to use nenolod’s XML-RPC proxy as a stopgap until you can rewrite the trac plugin. Release announcenent will be the next post.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>