On July 20th 2016 Eficode released their second official Jenkins plugin. But how does software get from your computer into global distribution?
Hi everybody! My name is Aleksi Simell and I started as a DevOps consultant here at Eficode last April. This blog post will handle my work with Eficode’s second official Jenkins-plugin release and what are the steps required to get your code from your computer to the official Jenkins distribution. The plugin was initially developed by a former Eficodean Jouni Rajala, so a huge thanks goes to him for giving me a good base to develop the plugin further and finally getting it to the official distribution.
The easiest way to create a Jenkins-plugin is to use Maven. Maven is used to build Java-based software creating the required .jar (and .hpi in case of Jenkins-plugins) files. The generated .hpi is then uploaded to Jenkins as a plugin and it can be tested in practice. Well, here’s where it gets interesting. Once the plugin is finished you probably want others to be able to use your plugin also. After all, if you got an idea for the plugin, it is more than likely that someone else will eventually need the exact same plugin you have just created.
The first step into making your plugin available for everybody is to upload it to a public repository in GitHub. This way other people can actually find the plugin even if you didn’t release it to Jenkins. Also, all Jenkins plugins are forks from some GitHub repository, so it needs to be there in order to advance further. It is possible to fork the base of your plugin from some existing plugin, but the forked dependency will need to be removed before hosting the plugin in Jenkins. The forked repository will need to be deleted and the code needs to be copied to an empty repository to cut the fork chain. The second step is to post a plugin hosting issue to Jenkins’ Jira. If everything seems fine, the code will get forked to the official Jenkins repository and the people marked as developers will get an invitation to work in the forked repository. At this point, you’re already winning so no point quitting. The first thing remember is that from now on, all code needs to be committed to the Jenkins repository, not your own. It might be a good idea to remove your own repository at least from your local machine, so you will not accidentally develop in the wrong repo.
After the plugin has been successfully forked to Jenkins, your plugin needs a wiki-page. Basically it just needs a short guide as to what your plugin does and how to configure it. Once the wiki-page has been created, it needs to be added to your pom.xml and the changes need to be pushed for you plugin information to be automatically updated to your new wiki-page.
And that’s basically everything there is to it… in theory. However, even with simple steps like these I have faced countless issues starting from simple missing imports and dependencies to more difficult error log throw-ups. It took me a week to get my working plugin to get through the release. Of course, one can argue that if it doesn’t go through the release it isn’t working, but the errors I got were not entirely related to the functionality of the plugin (e.g. the release introduced new dependencies which I had to include).
When I was introduced to Jenkins about a year ago, I could’ve sworn I will never develop any plugins for it let alone publish my work as an official plugin. However, things never go as you plan, so here I am writing this blog post about how I released a Jenkins plugin. The development wasn’t as difficult as I anticipated, even though my colleagues laughed at my frustrated cries a few times. However, the satisfaction I got after the plugin got released was totally worth it and who knows, maybe I’ll get to create another plugin for Jenkins in the future.
If publishing your own Jenkins-plugin didn’t make your coding fingers to itch, we have several other projects in our Github. We at Eficode are passionate about open source development, so check out our projects and unleash your inner software developer!