Roadmap to Leeroy 1.0
Leeroy CI is evolving just fine and in the timeframe I expected it to move forward. I have not seen any problems in production and it is already helping some developers and startups with automated builds and tests and harassing them to make sure all tests are passing before merging a pull request. Let me give you an update how far we are from the magical 1.0 release.
If you have not already seen it, I opened an issue on GitHub where I list and check off all features that will make it in 1.0.
Notifications
First of all I am happy that the major notification systems are completed. With Slack, HipChat, Campfire and Email the most important tools should be covered. There is one thing missing though and I am still thinking about the best way to implement it: IRC.
3rd Party Libraries
Currently Leeroy only uses Golangs standard library. This is pretty nice considering that dependency management in Golang is still suboptimal and that many libraries you find are not always that well maintained or stable. I would prefer keeping it that way.
Integrating with the services I mentioned was no big deal. They all provide a nice API and you only have to make one request and send your API key together with the message to display - or in the case of mail, well, the big advantage of Email is that it is supported by basically everything, including the standard library.
Writing an IRC client would be a bigger task than just making a request to an URL and drastically increase one part of the system for a feature with questionable value. To solve this I am considering adding some kind of webhook system. It does not matter which service is notified by the webhook and it can focus on doing one job well.
Integrate All The Things
GitLab, compared to GitHub, is a pain to integrate. You do not always get the SHA1 of a commit, the branch or other important information. This means the integration will likely have to do a lot requests compared to GitHub where you just have to parse the payload the webhook sends you.
BitBucket on the other hand should be a lot easier. But with the BitBucket integration I also want to make sure that the Mercurial is supported properly, eventually refactoring the existing code a bit and keeping the naming of the variables and structs either the same across all implementations or, more likely, creating an interface so it does not matter which VCS is triggering a build.
GitBucket, Gogs and Gitorious
I am not only considering supporting GitBucket, Gogs and Gitorious, I am actively looking into possible integrations. But as far as I am concerned GitLab and BitBucket are the most important services to support so I will start with them and move the other three to a later release. Of course, this depends on the level of webhook support those services will offer when I start working on the integration.
Currently it looks like Gogs will be the first one to be fully supported. I am considering to use it for personal projects I do not want on GitHub, so this would be a good reason.
Configuration and Authentication
Those two features are the biggest ones and will result in the most refactoring and it will, with nearly 100% certainty, end in the current configuration syntax changing. The end result will be a web interface so you do not always have to SSH to your CI box to configure something. But to allow web based configuration we first should have a concept of users.
So while being the two biggest features they also depend on each other to some degree. The most likely thing to happen is:
- new configuration syntax / style
- configuration validation
- user account support
- web based configuration
The new configuration style, which will break the current one, will bring keys and tokens for services on a per repository basis, named repositories getting rid of the hex representation in the URL and other nice things. Most of my thoughts are currently related to this feature. I would prefer to never change the configuration format again. Of course this is unlikely to happen if I do not abandon the project but I would prefer to keep the configuration the same as long as possible.
Overall
I am really satisfied with how Leeroy turned out. It is working great from what I can tell and it never got in the way - that is more than I can say for other software and tools I use daily.
There are some parts I will refactor to become more idiomatic Golang and easier to extend. I actually choose to move this back as long as possible to see what changes are required to support all services, makes the whole process and design a lot easier. So there is still some work to do before starting with the major features.
I cannot give you a fixed date when 1.0 will be released. I am still working on some features for drupan, including the webinterface to make posting a pure joy and letting you believe in Santa and unicorns again, but since I also do not like the "it is done when it is done" statements let me give you a vague idea: I am giving my best to release 1.0 with all promised features by the end of 2014.