Continuous integration

[emxsys]

Establish continuous builds and daily builds for the World Wind Java SDK.

Goal:

Configure Travis CI to perform the continuous integration.

Objectives:

• Run the ant build task on push events
• Run a daily build in a cron job
• Upload release artifacts from "tagged" builds to GitHub releases
• Upload JavaDoc from "tagged" builds to GitHub pages
  - [ ] Run unit tests on push events deferred

[emxsys]

Overview

For "push" events, the Travis CI service simply builds the SDK and asserts the success of the build. On "tagged" events, Travis CI builds the SDK and--if successful--uploads the release artifacts to GitHub.

Daily Builds

Travis CI runs a daily "cron" job which creates a "daily" tag on the current HEAD of the develop branch. This new daily tag will in turn initiate a subsequent "tagged" build on Travis that updates the "Daily Build" release on GitHub. The Daily Build is updated to reflect the new daily tag. During the update, old release artifacts are deleted, new release artifacts are uploaded, and old daily tags are deleted from the repository.

Semantic Versions

When the repository is tagged with a semantic version, the Travis CI service will create a GitHub draft release for the "version" tag and upload the release artifacts. The GitHub release is ready for editing and subsequent publication.

[emxsys]

Caveats

Travis CI creates a new "daily" tag every day and deletes the previous daily tags. Each time you update your local repository from GitHub, you will get a reference the current daily tag. These will accumulate in your local repository depending on how frequently you pull from the remote. Even though the old "daily" tags are deleted from GitHub, they are not automatically removed from your local repository. You'll have to remove them manually from your local repository if or when they become a bother.

Best Practices

You can create a "tagged" release in GitHub either through the GitHub Releases web interface, or via Git by a tag in your local repository followed by a "push" to the remote. The Travis CI implementation will upload the release artifacts for either approach.

Note that when you push to GitHub, be cognizant of pushing "tags" -- tags pushed to the remote trigger the generation of releases. When you are creating a "tagged" release via Git, you want to push just the individual tag for the release, NOT all tags. If you push all tags you run the risk of pushing old "daily" tags that may have accumulated in your local repository.

Creating a release in GitHub Releases is the safest approach for creating a "tagged" release. For routine push operations, you should disable or at least be conscious of the "push tags" options in your IDE.

[wcmatthysen]

Shouldn't the tests be run as well?

[wcmatthysen]

Sorry, didn't see the "Run unit tests on push events" task. Why is this task deferred? You can look at my pull request to get the unit tests up and running again from the command line.

[pdavidc]

wcmatthysen, The unit tests should indeed be run. This was deferred because the NASA World Wind team works iteratively, rather than in single monolithic tasks. Your pull request is a good start.