In the process of writing my posts (#1 and #2) on .NET Core and RHEL, it was made clear to me by several friends that I had neglected to use the de facto standard for continuous integration on Linux, Jenkins. Always happy to try out new (to me) tools, I settled in for what I was assured would be a simple configuration to test out my previous work in this bastion of automation.
What is Jenkins?
The first order of business was to understand the difference between Jenkins and TeamCity, another popular CI platform. After 20 minutes of reading, I discovered the following crucial differences:
- Jenkins has been around longer (though not always under the Jenkins moniker).
- Jenkins is open source.
- There are many plugins for Jenkins.
Other than these three things, any noteworthy differences I found seemed to ultimately boil down to personal preference. Even so, with my research out of the way, it was off to the races!
The Calm Before the Storm
The installation instructions for RHEL are very straightforward, and are outlined here. I went through the process without issue, and in minutes had a working instance of Jenkins. Though I encountered no problems, I did make some notes:
- Since I’d already installed Java for TeamCity, I skipped all listed steps related to Java.
- Once started, the service ran for me at http://localhost:8080/
- I have no intention of serving my Jenkins instance publicly, so I also didn’t bother opening ports in my firewall.
The installation process left me feeling confident. It was barely more complicated than the TeamCity process of “download and run”, and also, it was more complete in how it interfaced with the system (creating its own service information was a bonus).
All was going well, but in my years of being a developer there has been a constant theme of learning and forgetting lessons regarding hubris and/or ego. In this case, it often seems that the time I feel confident comes directly before I learn I should not have been confident.
Jenkins Limitations
Jumping directly from installation/configuration into setting up my first project, I created a simple C# application that outputs a randomly generated number between 0 and 100. This allowed me to replicate the TeamCity process somewhat, and gave me another reason to play around in an admittedly simplistic .NET Core project.
Once I did, I discovered some drawbacks. They included:
- First, I found that Jenkins does not have an option for Git integration as a build trigger out of the gate, but instead has a plugin hidden (in a truly massive list of plugins) that does the job for you.
- Even after finding the plugin, I had trouble getting it to appear as an option, and eventually (out of frustration) opted to simply manage the git interaction through the command line build step.
- Finally, the .NET Core command, dotnet, was inaccessible to my Jenkins installation.
None of these issues made Jenkins unusable. But they felt foreign to me, coming as I did from a TeamCity perspective. I note them not because I think people should avoid Jenkins, but because they’re good to keep in mind if you’re using it for the first time—especially if you come to Jenkins with preconceived notions about how CI platforms operate.
Conclusion
At this point, I had exhausted a much larger amount of time than I’d bargained for. I decided that maybe, for the moment, I would put things on hold. Technically speaking, I had achieved my goal of installing and learning the use of Jenkins on a very basic level.
As is usually the case on my journeys into Linux these days, I am quite certain my problems revolve around ignorance on the finer points of managing things like security and general administration. I’ll keep poking around with this until I solve it, but for now I admit that Jenkins has temporarily bested me in combat.
For additional information and articles on .NET Core visit our .NET Core web page for more on this topic.
Andrew Male
Andrew Male (@AndyM84) is a senior engineer at an enterprise development company in Boston, MA. Andrew has been programming from a young age and is entirely self-taught; he has spent time in many corners of the programming world including game/VR work, agency work, and teaching development to students and adults alike. He spends most of his time working on architecture design and pursuing his favorite hobby—physics.
