add travis ci testing #85
Conversation
|
when you get travis set up, drop me a comment here and I'll push another commit to kick off a test. |
|
@msimerson Alrighty. I have signed up for Travis. If I had known it was a simple sign up form, I'd have done it right away. ;-) ---Alex |
* and lint tests with shellcheck
|
Okay @aqw , this PR is complete and you can see the results of running the lint tests against all your files. I've disabled a handful of shellcheck tests but you ought to review them and make sure my guesses about how you'd choose were accurate. There remains a handful of shellcheck lint errors that I think should be changed in the scripts, but I'll leave that to you to decide if you prefer to fix or suppress the warning. Once those are addressed, then the Travis CI tests will pass and you'll get automated tests run on every PR. |
|
I have updated this PR further:
Now the test suite (including new lint tests) is automatically run and the build passes. This PR is now safe to merge. However, I'd still recommend going through the list of disabled tests. In a couple cases, I think it would be better to change the code than disable the test, but for now, I'm erring on the side of "make fewer changes." |
|
ping |
|
Hey @msimerson, Thanks for the ping. Quick mind-dump, as I'm in the middle of an all-consuming project at work that should be done in 4 weeks. After that, next on my list is zfsnap; cleaning things up, merging PRs, and finally, oh so finally, getting 2.0.0 released. I've left a few comments on your commits, but my overall question is: can travis do what we need it to do? I have neither setup nor used travis before, so it's a question from ignorance rather than a counterargument. More than anything, zfsnap needs to be tested across as many available shells on linux, FreeBSD, OS X, smartos, and Solaris. Different shells behave differently on different systems. The joys of portability... The current vagrant system we're using is insecure and not easily used as CI. At work, we are hoping to get a new server in 2 months; with that, I should be able to peel off off a few CPUs and use them for CI. Then we can have whatever OS targets we want. So, the question for me is: how flexible is travis when it comes to integrating with private CI boxes? ---Alex |
|
Your unknown preference is why that particular change was in it's own commit. So you could, if desired, use cherry-pick and only merge the others. I don't know how portable it is, but IIRC, it's part of the POSIX shell spec and bash for a very long time. Since you asked, here's some references for that change: |
|
@msimerson Ok. I'll be sure to drop that commit if/when merging. I understand well why $() is superior to ``; I use it all the time. I can't remember which shell was problematic; it's in my notes somewhere; it was 3 years ago. ---Alex |
note if cherry picking: just add SC2004 to the list of disabled checks in tests/lint.sh if you do not like this commit
|
I have removed the |
and lint tests with shellcheck
fixes #84