Re: testing out Docker CI scripts?

[David Kastrup]

Han-Wen Nienhuys <address@hidden> writes:

> On Sat, Feb 22, 2020 at 11:43 PM David Kastrup <address@hidden> wrote:
>> >> Assuming that all translations are kept at exactly the same level and
>> >> the example code is not at all adapted to the language in question in
>> >> lyrics and code comments.
>> >>
>> >> And assuming that our regtests make up 40% of the LilyPond material in
>> >> the documentation and are not getting recompiled as part of including
>> >> them into the various forms of the documentation.
>> >>
>> >> Since the documentation graphics are produced in PNG format for HTML
>> >> inclusion and in PDF format for PDF inclusion, that seems audacious.
>> >
>> > I don't understand you; what seems audacious?
>> >
>> > I think the runtime of make doc is off by a factor of about 5, which
>> > could be explained if somehow each language recompiles the snippets
>> > afresh.
>> >
>> > You seem dismissive of my analysis, so I guess you don't want to look
>> > into this further?
>>
>> Clicking on the images in the HTML documentation leads you to the source
>> code of the respective snippet as generated by lilypond-book.  Doing
>> this on corresponding images in different translations leads you to the
>> same source file.
>>
>> That does appear like the basic database mechanism is working.
>>
>> Most of the non-English documentation is outdated to some smaller or
>> larger degree, meaning that there is considerable variance in the
>> contained snippets compared to the upstream English version.
>>
>> The generation of snippets as PNG (not needed for running the regtests)
>> creates them as larger size bitmaps in Ghostscript, scaling them down
>> for quality.  There is also extensive Ghostscript carnage happening for
> (etc)
>
> You are telling me that "make doc" is slow for good reasons.  I am
> telling you that we don't need to spend so much processing time to get
> test results for pending patches, because the doc itself is not what
> we're interested in when pushing a change.
>
> For example, I agree that the antialiased images are nice for the docs
> that serve as downloads, but the AA is irrelevant for qualifying a
> staging => master push.  So there is certainly some gains to be had
> here.

At the cost of dissociating what we do on the tests with what we do
when, for example, building the web pages.  Which are regularly built
from master if I remember correctly.

Of course our cost/benefit analysis of what we are doing now was
dependent on what we knew our available resources regarding test
infrastructure and manpower and expertise to be.  Having more
fine-grained choices available would certainly do no harm, but the
decision of how to use them will depend on the situation at the time we
have to reevaluate our use of resources in light of the available
options.

-- 
David Kastrup
My replies have a tendency to cause friction.  To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".