Software documentation

Development tools

Code Structure

Techniques and Standards

How To

Functional Info

Background Info

JMRI: 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.

We also use two additioanl CI engines to test every change entered into our GitHub code repository.

Travis CI

We 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 CI

We 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.

Jenkins

JMRI 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://jmri.tagadab.com/jenkins/, with the original engine at http://builds.jmri.org/jenkins/ and a secondary engine at https://jmri.ci.cloudbees.com.

Specific Jenkins results of interest:

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.

Within the NetBeans environment, reference is made to the Hudson CI engine - Jenkins is a "fork" of the Hudson code and supports the same API.

Integration

Integration into NetBeans is achieved by executing the following steps:

  1. Open NetBeans
  2. Switch to the 'Services' window (shortcut key 'Ctrl+5')
  3. Right-click (Ctrl-click on Mac) the entry 'Hudson Builders' and choose 'Add Hudson Instance...'

    Add Hudson Instance...

  4. In the resulting pop-up, complete the following:
    Name
    JMRI
    URL
    http://builds.jmri.org/jenkins/
    Auto refresh every X minutes
    60 (change from the default of 5 to avoid overloading the CI server)
    Add Hudson Instance dialog

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'.

Jenkins Overview