This idea popped up while chatting with Richard Lavoie. I was telling him about selenium tests for plug-ins, snakebite one thing leads to another, and then came the idea of measuring the coverage in plug-ins.

Basically, this tool would have to iterate over the 600+ plug-ins, and trigger a mvn test command. Then it would have to save the coverage information somewhere, and plot a graph, or generate some report about it.

Depending on the machine, probably this tool could spawn more than 1 thread for doing this. Even then, it would still take quite a while for processing all the plug-ins.

Na semana passada a CloudBees e a XebiaLabs disponibilizaram o webinar “Setting up Continuous Delivery with Jenkins Enterprise and Deployit” (Configurando Continuous Delivery com o Jenkins Enterprise e Deployit). Nesse webinar eles apresentaram alguns plug-ins interessantes que estão presentes no Jenkins Enterprise, mas também mostraram um ótimo exemplo de pipeline com continuous delivery.

Workshop Setting up Continuous Delivery with Jenkins Enterprise & Deployit 11-7-12 12.00 PM from XebiaLabs on Vimeo.

Last week CloudBees and XebiaLabs delivered the webinar Setting up Continuous Delivery with Jenkins Enterprise and Deployit. In this webinar they present some interesting plug-ins available in Jenkins Enterprise, but also demonstrate a great example of a continuous delivery pipeline.

Workshop Setting up Continuous Delivery with Jenkins Enterprise & Deployit 11-7-12 12.00 PM from XebiaLabs on Vimeo.

Last week we released a new API for PBS in Java - pbs-java-api. There is an existing API that works very well (pbs4java), and we even got in touch and worked with the author before releasing this new API. So what’s the difference between the two API’s and when should I use one or the other?

Here’s the main differences between the two API’s:

• pbs4java uses DDD, while pbs-java-api has a more classical approach. We needed this to avoid serialization problems in Jenkins.
• pbs-java-api is available from Maven Central
• pbs-java-api tries to map the commands (qnodes, qstat, qsub, …). So you would call PBS.qsub(…) instead of Job#submit().

That’s pretty much it, so you really don’t need to switch to pbs-java-api. We created this new API as we needed a non DDD API to be used with the Jenkins plug-in API and that was available from Maven Central.

pbs-java-api - https://github.com/tupilabs/pbs-java-api

The idea is basically to create a simple CRM for Open Source projects. As there’s a great diversity of Open Source tools, and depending on its nature (low level API, build server, office suite) the development team may need different features, the ideal is that it has some kind of plug-in API, or modules.

It could help organizing donors, events, meetings, file exchange, among other things. And it would be useful if it was a SaaS (and cheap/free!).

The idea came after a tweet by @agentdero.