Fix issues with uom CI process

[iliekturtles]

I recently discovered a number of issues with the current Travis CI process. These issues have let a number of regressions slip through. I have fixed some in a57f4b5 and 4d820e5. I have additional changes I'm working on to resolve failures seen here: https://travis-ci.org/github/iliekturtles/uom/jobs/742299009

• Builds not executing for PRs
• Builds executing after a significant delay.
• Builds not responding cancel requests.
• Travis CI made changes that caused the exclude keyword to start causing explicitly specified jobs to be skipped. This caused the most import test job to be skipped.
• Code coverage is not being reported.

How should the issues be fixed?

• Fix Travis CI issues?
• Switch to GitHub actions (https://github.com/actions-rs)?
• Switch to another CI provider? Azure?

[iliekturtles]

CI should be switched off of Travis CI. Travis has been slowly lowering the number of active open source builds. As of this writing the cap is 395. This is leading to a backlog which peaks around 9000 pending jobs daily. When uom builds are submitted during busy times this is leading to 5 hour delays before results are available.

When switching to a new CI system I would like to meet the following goals:

• Run at least one stable cargo test on Linux, OSX, and Windows.
• Run at least one MSRV (1.37.0 right now), beta, and nightly cargo test.
• Run full test suite with more features. Running with --all-features takes too long. See the current .travis.yml for the current solution.
• Run clippy and rustfmt.
• Run Tarpaulin (or another tool?) for code coverage.

[CreepySkeleton]

I'm trying to move it to Github Actions.

Could you comment on why most of your tests are only compiled but not run? At first I thought it was about keeping CI run time within the limits of sanity, but when I try to actually run them, they panic. Are they just broken or what?

[iliekturtles]

Thanks for taking a look at this! It is expected that many of the integer tests fail which is why they're --no-run. Non-f32/f64 storage types aren't fully supported. There are issues like what to do about rounding that I haven't taken the time to find an answer for yet. The other reason is compile time. The rational types may work, but I haven't checked the test suite to see how close they are. Until I can figure out how to handle the issues I just want to make sure that all of the tests compile and will use f32/f64 for correctness.