On 11 August 2017 at 13:03, Pavel Sanda <sa...@lyx.org> wrote: > Christian Ridderström wrote: > > I agree HTML pages online would be nice. > > Not sure if our manuals can (in a nice way) just be exported as HTML > though. > > Last time I tried (around 2009 and "merged manuals" idea) it did not came > out nicely. > IIRC I reported the issues, Richard might have fixed them since then... > > > [*] It might make sense to have a CI job that builds PDFs etc from the > > manuals as a separate test. > > The problem is you need to check them visually as well. >
I agree that checking the generated PDFs is the difficult part. However, in my mind the test's purpose is simply to ensure that LyX doesn't fail when reading and exporting the manuals as PDFs. This could catch introduced errors in HEAD, or if you let the TeX installation update itself, breakage due to that. > I guess once fixed we could just add one makefile rule to > 1. create all major manuals into pdf & html from tarball > 2. copy it to svn web tree, svn add new html figs > 3. commit it > > It just needs someone to sit and spend couple hours on it... I don't think the server autodeploys from SVN these days, but I could be wrong. Anyway, I didn't intend for such a CI job to also automatically publish the manuals/PDFs. IMHO, before publishing a new set of manuals some kind of manual review is necessary. /Christian [*] I have previously done some stuff that might be relevant/useful. E.g. in one project we got a large log file from a build that might somewhere contain a new error or warning message. Or perhaps one of thousands of values in the log output had changed although it shouldn't. Filtering for 'errror' and 'warning' is of course one way to go. Instead I introduced this approach: 1. Before one release, let two developers manually review the log file 2. Commit the reviewed log file as reference baseline (after fixing some things) 3. After each new build, automatically diff the generated log to the baseline. The diff, if any, had to be manually reviewed and if the changes were intentional and as expected we converted the newly generated log into a new reference for future builds. This worked well IMHO and it did help us catch some subtle bugs. However, the build situation was very different compared to that of LyX. I also introduced this approach for other "outputs", like big automatically generated data tables that were based on the source. Before 'diff:ing' we sometimes had to convert to another format, but it worked pretty well. In theory the procedure above could work on PDFs (or perhaps PS?), or possible PDFs converted to RTF or something else that's text based.... duh, perhaps HTML :-) It's a totally different question if the effort needed to setup the above is worth it though, which is why I thought of a simpler test that fails if LyX fails to export a PDF.
