Using Fossil SCM with Jenkins CI

Currently, there is no SCM plugin for Fossil in Jenkins. I've been coding one but it's not yet ready.

Update: I have permission from my employer to open source the plugin. Now if only I had the time...

Update 2:  I've created a github repo for my code: 
https://github.com/rjperrella/jenkins-fossil-adapter

It turns out, you should be able do a pretty good job of integrating Fossil into Jenkins without using such a plugin.

Here's my idea:

For now, you should just need the Xtrigger plugin. This plugin is capable of triggering a build based on a number of things changing. Among them, a web-addressable piece of content in XML.

Fossil is able to generate RSS feeds trivially.

On the Fossil machine, you'll want to start the fossil server as usual:

$ fossil server --port=1234

On the Jenkins machine, you'll simply install the Xtrigger plugin and set it to trigger a build, by polling the following URL for changes:

   http://<FOSSILMACHINE>:1234/timeline.rss?y=ci&n=0

This provides the top "checkin" in the repo.  The "y" parameter says I want "check-ins" and the "n" parameter means only 1 record of output (the last checkin.)

If the last checkin changes, there's been a change to the repo. Voila!  Just extract all the code by doing this in the workarea:

$ fossil clone http://<FOSSILMACHINE>:1234 reponame
$ fossil open reponame
$ fossil close reponame --force

Now,  you should be able to run make, ANT, Maven, or whatever else suits your fancy.

Does anyone see something wrong with this approach?






Comments

  1. How's the plug-in coming? Post to the fossil list when you get somewhere with it. Or are you saying by this post that you are scrapping the idea in favor of the generic approach?

    ReplyDelete
    Replies
    1. Will do - hopefully I'll have something soon.

      Delete
  2. That was a year ago. How are you doing?

    ReplyDelete
    Replies
    1. No closer. At this point, I'm just going to upload the code as is to github. I'll put a notice on this site pointing to the repo.

      Delete
  3. it would be better if each checkin launched it's own build cycle. This way you can be assured that each commit was independently reliable. There is also a challenge with branching. I had been looking at the leaves syntax and it is interesting because it gives all of the leaves at once. Unfortunately it would eventually suffer from the same problem... out of sync.

    ReplyDelete
    Replies
    1. Branching definitely causes problems. Your point is well taken - each commit should be built in isolation, in a clean repo. The Jenkins plugin I wrote allows for both clean (full) builds and dirty(delta) builds.

      Delete
    2. Richard, I uploaded my code to github at https://github.com/rjperrella/jenkins-fossil-adapter

      I will put a compiled version of the plugin out there at some point.

      Delete
  4. Just an update for anyone else wanting to poll Fossil from Jenkins. Using Fossil version 62dcb00e68 (2015-11-02 17:35:44) and Jenkins 1.647

    It seems that some aspects of "timeline.rss" page has changed. I used fossil URL "timeline.rss?y=ci&n=1&tag=testing" to fetch single last commit. Relevant Jenkins plugin is now called XTrigger. As Fossil RSS feed content changes upon each refresh (it includes request date and time) I had to set up URLTrigger to monitor for changes in XML content and use XML XPath query "/rss/channel/item[1]/guid/text()"

    ReplyDelete

Post a Comment

I reserve the right to remove any objectionable comments at my sole discretion. The definition of objectionable is arbitrary.

Popular Posts