METRON-885 Build RPMs in Travis

[nickwallen]

We should focus on improving our CI builds to catch as many problems as possible and rely less on manual testing and due diligence.

One gap we have now is that if a change is submitted that breaks the RPMs, the CI build will not detect the problem. This kind of problem can only be detected by relying on our contributors and committers to dutifully run-up the development environment.

This change allows for the RPMs to be built as part of the Travis CI build. If the RPMs fail to build, the Travis CI build should fail.

Point to Consider for Reviewers

Building the RPMs requires a complete build of Metron. This will likely push our backs up against the 50 minute time window allowed by Travis. #1522 gave us some breathing room by shuffling what we build and when, but did not fundamentally solve that problem.

If this change risks causing numerous intermittent test failures due to timeouts, I'd prefer to hold this change until that problem can be addressed. I will confirm whether this is a problem and comment later on this PR.

Changes

This adds an additional step "Build RPMs" that builds the Metron RPMs in parallel with the other build and validation steps.

Testing

1. Break the RPM build by modifying the metron.spec.
2. Ensure the Travis CI build fail.
3. Fix the metron.spec.
4. Ensure the Travis CI build runs succecssfully.

See the following Travis builds.

• https://travis-ci.org/apache/metron/builds/619846316

Pull Request Checklist

• Is there a JIRA ticket associated with this PR? If not one needs to be created at Metron Jira.
• Does your PR title start with METRON-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
• Has your PR been rebased against the latest commit within the target branch (typically master)?
• Have you included steps to reproduce the behavior or problem that is being changed or addressed?
• Have you included steps or a guide to how the change may be verified and tested manually?
• Have you ensured that the full suite of tests and checks have been executed in the root metron folder via:
• Have you written or updated unit tests and or integration tests to verify your changes?
• If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under ASF 2.0?
• Have you verified the basic functionality of the build by building and running locally with Vagrant full-dev environment or the equivalent?