JMRI Code: Continuous Integration
"Continuous Integration" is the process of rebuilding a system every time it changes, so that you rapidly learn of new problems and are motivated to remove existing ones.
The core of our system is a series of Jenkins jobs that routinely build the code, run checks, and creates downloadable installers. That means that we can and do put changes into our users hands very quickly. There's a CI status page that shows the combined status of that.
We also use two additional CI engines to test every change entered into our GitHub code repository.
Travis CIWe use Travis CI to do integration/test builds on Linux for every pull into our main GitHub repositories.
Travis will build any branch that contains a .travis.yml file. The build history for the main JMRI repository is at https://travis-ci.org/JMRI/JMRI.
Travis normally runs the checks for valid line-ends, the check for proper ASCII characters, followed by building the code and running the "AllTest" test routine. A screen buffer (not a real screen) is used for all the GUI tests.
You can enable Travis CI for your fork (personal GitHub repository) as well. After merging JMRI/master into your own fork, allow Travis CI to monitor your fork, and it will begin testing after your next push to GitHub. Follow the instructions at Travis CI to set up your forks.
You can prevent a Travis CI from running against a specific commit by including "[ci skip]" (including the brackets, but not the quotes) anywhere in the commit message if so desired.
AppVeyor CIWe use AppVeyor CI to do integration/test builds on Windows for every pull into our main GitHub repositories.
AppVeyor will build any branch that contains a appveyor.yml file. The build history for the main JMRI repository is at https://ci.appveyor.com/project/JMRI/jmri.
AppVeyor normally runs the property-files checks (for duplicate targets and other errors), followed by building the code and running the "AllTest" test routine. A screen buffer (not a real screen) is used for all the GUI tests.
Although it is possible to enable AppVeyor to build commits to your own fork of the JMRI repositories, it's a bit complicated to do it within the AppVeyor security model.
JenkinsJMRI uses the Jenkins continuous integration engine for integration and test builds. This includes keeping our web site up to date as changes are committed, building installer packages from development builds, and building final releases.
Our primary Jenkins engine is at http://builds.jmri.org/jenkins/,
also known as http://jmri.tagadab.com/jenkins/.
Because it's hosted outside the US, we force its
Java locale to US English by setting the
LC_ALL environment variable to
en_US in the master Jenkins configuration settings.
Specific Jenkins results of interest:
- Builds page, showing status of the builds done after every series of commits. Successful builds are followed by builds installers via the Packages job.
SpotBugs page, showing status of the more-extensive
SpotBugs tests done
periodically. There are also pages of the
most recent changes and the
most recent results.
For more information on JMRI's use of SpotBugs, see the separate SpotBugs page.
Jenkins Integration with NetBeans
If you are developing in the NetBeans 7.0 environment, it is possible to integrate feedback from the Jenkins Continuous Integration (CI) engine.
Integration into NetBeans is achieved by executing the following steps:
- Open NetBeans
- Switch to the 'Services' window (shortcut key 'Ctrl+5')
- Right-click (Ctrl-click on Mac) the entry 'Hudson
Builders' and choose 'Add Hudson Instance...'
- In the resulting pop-up, complete the following:
- Auto refresh every X minutes
- 60 (change from the default of 5 to avoid overloading the CI server)
From now on, the current status of the Jenkins builds can be reviewed in the 'Services' window by expanding the 'JMRI' entry under 'Hudson Builders'.