Add TeX build GitHub Action

[user202729]

So that you can directly download the PDF for each pull request to check the difference instead of having to manually compile (and wait for a few minutes at that), I suppose.

(Would also be nice if something can be run to diff the PDF directly.)

Not sure how update-gh-pages.sh works.

(By the way, if it fails, you can use https://github.com/marketplace/actions/debug-via-ssh to debug it… I guess. Never tried it.)

You have 6 hours per job, which is a lot. (I figured Travis was previously used but it stopped working somehow at fd0907c .)

(There's also https://github.com/marketplace/actions/create-release if you want to use it.)

---

(Why exactly does it take 5 runs of pdflatex anyway? Further investigation needed, but it's possible to hack around it with https://tex.stackexchange.com/questions/363913/how-to-change-latexmks-number-of-maximum-runs --- there's also https://tex.stackexchange.com/questions/707465/latexmk-reruns-pdflatex-unnecessarily-when-run-xml-file-is-changed/707501#707501 but I guess I'll take a look if it seems important enough… note that the "Output written on Napkin.pdf (● pages, ● bytes)" value differs between the 3rd and 4th run though)

edit: one reason why it need 4 runs instead of 3 is like

another is for some reason (rewritten before read) is not reliably detected for .ptc files…

if I do something like

\documentclass{report}
\usepackage[tight,listfiles]{minitoc}
\usepackage{babel}
\begin{document}
\doparttoc
\tableofcontents
\part{P1}
\parttoc
\chapter{C1}
\chapter{C2}
\chapter{C3}
\chapter{C4}
\chapter{C5}
\chapter{C6}
\chapter{C7}
\chapter{C8}
\chapter{C9}
\chapter{C10}
\part{P2}
\parttoc
\chapter{C1}
\chapter{C2}
\chapter{C3}
\chapter{C4}
\chapter{C5}
\chapter{C6}
\chapter{C7}
\chapter{C8}
\chapter{C9}
\chapter{C10}
\end{document}

then it is reliably detected.

For now a workaround is

sub asy {
	move("Napkin.aux", "Napkin.bkp.aux");
	my $result = system("asy -o asy/ '$_[0]'");
	move("Napkin.bkp.aux", "Napkin.aux");
	return $result;
}

$hash_calc_ignore_pattern{'ptc' . $_}='^' foreach 1 .. 99;
$hash_calc_ignore_pattern{'xml'}='^';

which require only 3 runs from scratch. Maybe more can be cut down if asy output can be cached.

[vEnhance]

Yeah, Travis stopped working at some point, so I ended up deciding it was easier to compile on my own machine and upload to github pages manually. I thought about trying to rewrite it in GitHub actions, but I decided it's just easier to use my own system than try to offload it.

Why exactly does it take 5 runs of pdflatex anyway?

Normally documents take more than one run because the first time the ToC / crossrefs / etc. don't work, and then the next run stabilizes them, etc. But the Napkin is so large that the table of contents itself is like ~20 pages, etc. I'm not surprised therefore that it takes many more runs to stabilize than a shorter TeX document.

[user202729]

Great, why is it failing at the installing packages step???

---

I try to rerun the action in my repository and it fails, so reasonable hypothesis is the file just inconveniently disappear somehow…

I'll just assume it's transient error in Ubuntu package server and the next commit will pass the test.

[user202729]

Okay I know why (https://github.com/actions/runner-images/issues/2924), just add sudo apt update before.

Seriously why didn't I read the documentation??

---

(No, I mean… I know how latexmk and LaTeX processing works but 5 runs seem to be redundant, it's probably optimizable. But that's my problem.)

[vEnhance]

haha no worries.
i'm probably going to use awalsh128/cache-apt-pkgs-action@latest instead anyway so that I can cache the packages between runs.

[user202729]

Looks like the cache caused more headache than performance gain…

https://github.com/marketplace/actions/cache-apt-packages 182 stars though, that's a decent amount.

Although there are complaints about it breaking sometimes… awalsh128/cache-apt-pkgs-action#110

[vEnhance]

Yeah it seems like for TeX Live, it doesn't work well because there is some post-install stuff that can't be handled.

The issue awalsh128/cache-apt-pkgs-action#57 seems to describe with LaTeX in particular. My understanding from reading that is "just give up".

[user202729]

It's probably possible to hack together something with https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows and Docker ( https://github.com/marketplace/actions/github-action-for-latex already show how to use Docker image but first time I try it I realize Asymptote is not available inside https://github.com/user202729/napkin/actions/runs/9722647002 ) but it seems like more of a hassle, and it seems not worth it because the build itself take more time than installing the dependency anyway. (Evidently it seem that nobody has made one yet.)

The https://github.com/marketplace/actions/github-action-for-latex also pull a Docker image for each run and pulling it takes 1 minute. Seems comparable with installing directly from apt so I decide to just stick to apt to avoid external dependency.

[user202729]

By the way retention-days is 1 by default? https://github.com/actions/upload-pages-artifact/blob/main/action.yml#L13-L16 (I've no idea where it will deploy to though, is the readme still correct?)

---

There's https://github.com/marketplace/actions/cache-anything-new which might actually work and save one or two build steps. TODO test later perhaps (though GitHub action runtime is free anyway)…

[vEnhance]

By the way retention-days is 1 by default? https://github.com/actions/upload-pages-artifact/blob/main/action.yml#L13-L16 (I've no idea where it will deploy to though, is the readme still correct?)

Yeah, but I'm hoping the GitHub Page will still be up even after the artifact expires, if not I'll have to increase that threshold...