Developing Jenkins plugin

This blog post is to help you with resources to get you started with Jenkins plugin development. This is NOT a plugin development tutorial. I do not wish to repeat any of the contents which are already available online. This blog post should be seen as a pointer towards those various contents which could help you develop your first Jenkins plugin. 

General idea

As part of my integrations development duties, I needed to work on Jenkins plugin development. The idea was simple: the plugin should work as post-build step, and pull some report from a cloud based system. This plugin is supposed to be used in CD/CI pipeline.

What you need to know to develop Jenkins plugin?

1. Maven.
2. Setting up your development environment.
3. Plugin project structure.
4. Java.
5. Groovy script.
6. Extension points to use in your plugin.

Since I had no prior experience with developing any plugin with Jenkins, I had to start right from the scratch. First obvious step was to start reading and trying out some code. This Jekins wiki page is really helpful getting started. It shows how to setup your development environment, how to test run your code, how to debug, and how to package your plugin.

Its better if you already know how to use Maven, but that is not any hard and fast requirement. Even if you haven't used it earlier, you can still work with that. With help of Maven archetype, you would be generating your starter code. Instructions for that are also given in that Jenkins wiki page. It generates a simple Builder step. 

Point # 6 above is Extension points. There are several classes exposed by Jenkins - called as extension points - which you will be extending or implementing to provide your plugin functionality. For example, to do something after build is completed, you need to extend Notifier class. Whichever class you annotate with @Extension annotation, Jenkins will load at appropriate time - depending on which class you are extending or implementing. 

If you are going to support only freestyle project, you would mostly need to implement SimpleBuildStep class.

Supporting pipelines

As mentioned on Jenkins pipeline page, its a suite you use for continuous integration/delivery. If you need to support pipeline project, SimpleBuildStep may not be the correct choice for you. AFAIK, you need to implement AbstractStepImpl to provide same functionality as a pipeline step. However, this class is marked deprecated and anytime down the line it could be discontinued.

Having said that, I did not find any other alternative to use for pipeline which is as simple as SimpleBuildStep. But, this blog post was very helpful in refactoring the SimpleBuildStep-based code to support pipeline.

Further reading

1. Plugin development basics
2. How to write Jenkins plugin
3. Custom Jenkins plugin development webcast
4. post-completed-build-result-plugin
5. How to set build result in pipeline

Somebody found webmon useful!

It gives me great pleasure to let you all know that, somebody have found my Webmon useful! Yes, and they have forked it on github and are using it in their project - of course, with due attribution.

I used it to monitor job portals and career pages of companies of my interest. I maintained it until Feb 2014. After that, it became a dormant project. 

One fine day, I was revisiting my github profile - which I do every week, as such - and found that somebody had forked out my webmon. I quickly opened their repository in other tab and started going through it. As a developer, it was so joyful for me, that my pet work is actually of help to somebody. It just made my entire day! 

So, what is Webmon?

Webmon is a free software, written in PHP. I created it way back in 2013, with following objectives: 

1. Detect whether listed webpage have any change in contents.
2. If change is detected, calculate the difference, and output what have changed.
3. Detect both - positive and negative changes.

I distributed it in the hope that it will be useful, but without any warrenty; without even the implied warranty of merchantability or fitness for a particular purpose. Its still available to everyone. You can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

I do not have any plan as of now to actively contribute to it and take it further, but I would really like if some other developer starts contributing to it, and make it a truly open source project.

How to setup Splunk Search Head Cluster?

If you already know what is Splunk, and are interested in setting up your own Search Head Cluster, continue reading.

For this, the environment will be:

• 1 Deployer – sends apps/configurations to the search heads
• 3 Search Heads – for the SHC
• 1 Indexer – the “search peer” that the SHC will dispatch jobs to
• 1 Forwarder – for testing data input from the TA/App into the indexer

Sizing wise you could make them all VMs. Something reasonably small could be as follows for each system – with the Deployer and Forwarder being much smaller.

• 4 cores
• 8GB RAM
• 60GB disk

Once you have all your machines ready, follow steps given below. My steps consider linux-based setups, but you can do it on any other Splunk-supported OS. Make sure to change paths accordingly.

0) If you haven't done already, change the default admin password 'changeme' to something else. Any of the SHC setup commands will not work properly if your admin password is the default one.

1) on Deployer:
in /opt/splunk/etc/system/local/server.conf add following line under [general] stanza, write following line.
pass4SymmKey = yourKey

Replace yourKey with your plaintext key. Do not worry, Splunk will definitely encrypt it later.

2) Initialize all search head clusters:
On each SH, run these commands -
/opt/splunk/bin/splunk init shcluster-config -auth admin:splunk -mgmt_uri <mgmt uri of this setup> -replication_port <any unusual port like 20000> -conf_deploy_fetch_url <mgmt uri of deployer> -secret yourKey
/opt/splunk/bin/splunk restart

Now, at this point, each SH where you ran above commands knows who is deployer for them and the key to authenticate with.

3) Bring up cluster captain:
This step is required only for SH cluster. You can omit this step if you are not setting up SHC.
/opt/splunk/bin/splunk bootstrap shcluster-captain -servers_list "<comma-separated list of mgmt uri of all search heads, including designated captain>" -auth <this setup's username:password>

4) Check search head cluster status:
To check the overall status of your search head cluster, run this command from any of the members:
/opt/splunk/bin/splunk show shcluster-status -auth <this setup's username:password>

5) Deploy the bundle (app):
/opt/splunk/bin/splunk apply shcluster-bundle -target <mgmt uri of SH where you want to deploy app> -auth <SH's username:password>

Your Search Head Cluster setup should be ready and operational now.