search JMRI:

Development tools

• Getting the code via Git
• Developing with JMRI Code
• Git FAQs
• Building with:
  • Ant
  • NetBeans
  • Eclipse
  • IntelliJ IDEA

Code Structure

• Introduction
• Names and Naming
• Application Structure
• Code Structure Patterns
• Swing Structure
• External Connection Structure
• Application Preferences
• Threading
• Use of XML
  • XML Schema
  • XSLT Formatting
• Web Site
• Javadocs
  • Name Index
  • Packages
  • Classes

Techniques and Standards

• Recommended Practices
• Continuous Integration
• Internationalization
• Logging & Error Handling
• Unit testing with JUnit
• Documentation with Javadoc and UML
• Run the SpotBugs static analysis tool
• Providing help with JavaHelp
• Portable Filename Method
• XML Persistance

How To

• Extend JMRI
• Add a New System
• Add a New Type

Functional Info

• Turnout Feedback
• Network Connections
• How the startup scripts work
• LogixNG

Background Info

• Technology Roadmap
• Survey of JVM Capabilities
• Usage Poll, Spring 2007

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

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

   

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)

   

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

---