Set PR to build the generator from a pull request's own head rather than master, so a change to omgendoc can be tried over the whole corpus before it is merged.
Such a run builds the documentation and applies the same checks to it, but publishes nothing: the upload to build.openmodelica.org and the deploy stage are both skipped, so a generator that is only being tried cannot replace what is served. gendoc.log is archived either way, which is what a question about memory is answered from.
`tar cJf` compresses on one thread and writes a single-block stream, which is also why the deploy node spent minutes unpacking it: a stream with one block cannot be decompressed on more than one thread whatever the reader asks for.
`xz -T16` at both ends. The blocks the compressor writes are what lets the deploy stage use its cores.
The ten-thread cap is gone. What it was working around was a leak in the generator rather than a limit of the machine: a scope and the identity cells under it owned each other, so nothing a thread built was ever freed and more threads only meant more of it kept.
`nproc` counts hardware threads. Rendering is bound by memory traffic, so a sibling thread on a core buys little speed while adding another library's live instantiation; count distinct core/socket pairs instead, as .CI/common.groovy counts the logical ones.
The comments around all this said more than the code needed.
