Jenkins is an extensible framework, which can be applied to many areas including embedded software and even hardware development. With proper configuration, Jenkins can be operated with hardware peripherals attached to build agents to accelerate development of all kinds of embedded use-cases.
This page provides a brief overview of using Jenkins for automation with embedded and hardware projects.
Jenkins has plugins for integration with common tools such as GCC, Microsoft Visual Studio, etc. Currently there are not domain-specific embedded development or electronic design automation tool integrations. Jenkins can however integrate with practically any tool which can provide a command-line interface via its shell/batch scripting integration.
These command line tools can be invoked directly, assuming the build agent being used has the appropriate environment set up. To help configure the environments, a few of the following approaches can be considered:
Machine-specific variables (e.g. LM_LICENSE_FILE or port specifications for
peripherals) can be configured in Agent configuration in the Environment
Variables section. Once the variable is modified, the build agent should be
reconnected.
In order to integrate setup the tool environment, consider Custom Tools Plugin.
EnvInject Plugin allows to setup custom environments at the job level.
Interaction with FPGA boards can be done via CLI tools as well. Care must be taken in configuring Jenkins to prevent conflicts between parallel builds attempting to access the same shared external peripherals at the same time. There are a few plugins which can help manage concurrent peripherals access such as the:
Throttle Concurrent Builds Plugin allows preventing hardware and license usage conflicts.
Timeout Plugin helps prevent tools (e.g. cable drives) which might hang for whatever reason, blocking a Jenkins build indefinitely.
Naginator Plugin enables conditional restarting of builds in case of flakey hardware issues.
Jenkins has a limited support of computing grids, ideally for highly parallelized tests and builds it would be useful to provision Jenkins agents from computing grids
There is a LSF Cloud Plugin for LSF, but for other grids there is no open source plugins currently available.
As a workaround, Jenkins jobs can invoke CLI tools in order to utilize computing grid resources. Builds from such jobs should be able submit task on computing grids, wait until their completion and then collect the execution results.
Such jobs can be implemented, but due to double scheduling there are many potential issues with stability of the instances (e.g. runaway grid tasks if Jenkins server shuts down during the build). Currently these issues must be handled by the job itself.
Jenkins does not have specific plugins for parsing reports from many tools. In such case the general recommendation is to convert the reports to formats supported by exising Jenkins plugins.
For tools which generate some form of XML-based reports, formatting of those reports can be implemented with an XSLT converter. Consider the following plugins for incorporating generated reports into Jenkins:
Unit testing results: xUnit Plugin, which provides a "Custom report" handler to convert any XML to JUnit formatted reports for Jenkins
Timing analysis reports: Performance plugin (support JMeter-alike reports)
Code coverage: Cobertura Plugin or Emma Plugin
Presentation by Oleg Nenashev at Jenkins User Conference 2015 in London.
Presentation by Robert Martin at Jenkins User Conference 2014 in Berlin.
"kernelci.org: The by Milo Casagrande at FOSDEM 2016. KernelCI uses Jenkins as a backend automation engine.