3 years ago, once I was assigned to introduce continuous integration to my previous company, CI/CD was famous buzzword which I had limited information. Although I was aware of Cruise Control, and the idea of automation of tests, I had no idea about the importance of continuous integration.
Okay, I guess nowadays everyone (hopefully) is somehow recognize the crucial benefits of quick testing, immediate feedback while developing software. If you obey SOLID principles, design modular software, and create a set of independent and portable tests, believe me this is so simple. All you need to do is just to install a test automation tool (Jenkins, Hudson or Cruise Control, or whatever) and integrate it with your code versioning system (CVS).
What To Do If You Cannot Install Jenkins On Your OS?
Here the problem begins: Your target OS, which was QNX in my case, does not allow you to install Jenkins, due to the lack of Java support. If you cannot install Jenkins you cannot let that machine to be a slave Jenkins node.
Good thing is that Jenkins allows you to use its built-in SSH client implementation to connect your unix-like real time operating system QNX. So you might think of sending build commands to QNX via SSH. But how would your target QNX PC receive the source code? At this point you face two options: You can check out source code from master node and transfer all the necessary files to QNX via SSH, or you can directly check out source code into QNX via commands from SSH. While former increases load on your network, the latter adds one more CVS authorization node and brings responsibility to your scripts to clean the environment after your tests are done.
Once your QNX target obtains the files, simply prepare your build scripts and send it via SSH from master node.
Code Coverage and Test Results
The final stage of continuous integration is to collect feedback for your small contribution to product; test results and coverage analysis. There are many ways to obtain code coverage statistics and gcov tool is only one of them. There is also a very nice tool gcovr, which is written in python, and creates human readable outputs from gcov command. It is also very practical to generate Cobertura style xml reports and let Jenkins Cobertura Plug-In to parse these reports and show nice coverage statistics under your Jenkins job.
But here you will again face two options: After running your tests either you can transfer back gcno & gcda files to master node and run gcovr command. This will create xml files in directly in master. Or you can run gcovr command under QNX and transfer only the xml files to master node. Bad news for the ones who prefer the first way: you will get an error message from gcovr script complaining about the object file paths in gcno & gcda files. You will then find yourself messing with GCOV_PREFIX and GCOV_PREFIX_STRIP environment variables.
The same way, you can also transfer your test results into your master node. In my case I was using googletest and it is capable of creating junit style xml outputs. These xml files can be parsed by Jenkins JUnit Plug-In and yields a nice graphical representation of your tests’ pass/failed results.
