[work in progress] Continuous integration with Travis CI

[vielmetti]

This was previously considered in #175 which is now closed. I'm bringing it back up again. There's a corresponding PR that I'm working on.

In order to properly test the proposed changes in #65 that affect lexer.c it's going to be necessary to test a whole lot of test cases. In addition, the proposed patch to #65 is based on an old codebase and thus might no even build without a bunch of tweaking.

I'll patch what I can in a fork, which does have Travis turned on. At some point that's going to be too awkward to maintain, and I really don't want to fork my own version of this.

[geoffmcl]

@vielmetti since Travis CI has been discussed and rejected in #175...

And have added lots more comments on the same topic recently...

As stated elsewhere, #65 is not a case for CI...

Do not see a reason why tidy needs this at this time...

So again this is CLOSED.

[vielmetti]

A snapshot of my work to date is here:

https://gist.github.com/283310f5d9ae5b8335b2

and here

https://gist.github.com/f46d7f6db4afead6c170

for the next person who comes along.

[geoffmcl]

@vielmetti it seems to me you are more interested in the process of automation, the CI itself, setting it up, than in any results or benefits this could bring to the project... but that's ok... no problem...

Some things I note from your various CI links -

• I saw some compile warnings travis-ci. It would be good if these were looked at and fixed... pprint.c:1030:52, localize.c:370:27, streamio.c:955:19, ...
• If I understand your skip notation, several compares with testbase fail. I think 427672(msg), 431895(2), 675205(2), 1415137(msg)... is this all of them? What is the problem? Can we fix? Test 427664 is already in Test 427664 has different output on ARM, Intel platforms, maybe others... #266, so others could be added to there...
• testcases.txt contains 228 tests, but you seem to only compare a small sub-set, but maybe I do not understand. Why are you not doing ALL 228? You do seem to run testall.sh, which does 228... Due note of the WIP title, but is this something that will be fixed?
• you build the docs, and we see some warnings. Have these been looked at? Can they be fixed? And I think there is a wrong path in CMakeLists.txt but lack the time to track it down... There are two tidy1.xsl files? Which is correct?

As can be seen in #266 to be able to analyse the problems, and look at fixing this diff, need access to the ouput generated by testall.sh, not specifically that generated by a diff tool, or perhaps changed in the cut-paste operation... Prefer the files themsleves... maybe in a zip...

And as expressed elsewhere, it would be great if the testall.sh tool chain could be enhanced to have just one log output, and include the version of tidy being used in the test... date, time, ... and need access to that log also...

And after the API docs build, there seems a deploy: token. Can I get access to the tidy-docs.zip, assuming it contains the entire contents -r temp/tidylib_api/*. As you can read in #248, this is part of what I seek...

So I would say, these are some very positive results from your CI work. Thank you for the effort! I might even be tempted to try the same with my own tidy-fork ;=)) Looks like fun...

But I do not see any follow-up on fixing the actual problems in tidy source...

As always, any help on fixing tidy is much appreciated...