The website consumes the wiki through the _coursebook submodule and
updates it with --remote, so the SHA recorded in the site's tree never
affects what deploys. It had drifted months behind as a result, which is
a trap for anyone who runs a plain 'git submodule update' and then builds
a stale book.
The trigger commit this script already pushes is the natural place to fix
that: point the gitlink at the wiki commit push_to_wiki.sh just published,
so the recorded pointer matches reality at no extra cost. ls-remote plus
update-index writes the gitlink directly, so the shallow clone never has
to fetch the submodule.
Both steps are non-fatal. The push is what rebuilds the site, and under
'set -e' a transient ls-remote failure would otherwise skip it. The commit
keeps --allow-empty so an already-current pointer still triggers a build.
The PDF job takes ~9 minutes and is the whole workflow's wall clock,
because install.sh pulls texlive-full: 455 packages and 4.0 GB of every
language pack, ConTeXt and Metapost. The book needs 68 packages,
768 MB.
Measured by building the book both ways in ubuntu:24.04 and comparing:
packages download apt install make pdf
texlive-full 455 3995 MB 270s 188s
reduced set 68 768 MB 92s 141s
Output is equivalent, not merely similar: all 19 PDFs (main plus 18
chapters) have identical page counts (main.pdf is 390 pages either
way), identical page sizes, and byte-identical pdftotext output, with
no unresolved references in either.
Also:
- fail-fast: false, so a WIKI failure 90 seconds in stops cancelling
the 9 minute PDF job. That happened repeatedly while fixing CI: the
run then says nothing about whether the PDF is healthy.
- concurrency groups, asymmetric on purpose. PR builds have no side
effects so a superseded run is cancelled. Deploy is NOT cancelled
mid-run: it pushes the wiki, force-pushes epub_deploy and pdf_deploy
and nudges the website, and interrupting that can leave the three
targets on different commits.
- timeout-minutes: 30, so a hung link check cannot burn six hours.
- pip cache. Marginal - five small pure-python wheels - but free.
Note make -j4 was tried and rejected: it cuts the build to 80s but
produces a wrong book, numbering the appendix 13 instead of 17 and
degrading a cross-reference to ??.
The coursebook now publishes its wiki again, but nothing tells the
website to rebuild, so a change reaches the site only when someone
else pushes to it.
Restore that trigger with a deploy key (SITE_DEPLOY_KEY) rather than
the built-in token: GITHUB_TOKEN is scoped to this repo, and pushes
made with it deliberately do not trigger workflows. A deploy key also
has no expiry and is exempt from the org's SAML SSO, so it will not
silently lapse the way the old credentials did.
- point site_deploy.sh at cs341-illinois/cs341-illinois.github.io; it
still named illinois-cs241, two renames stale
- add IdentitiesOnly so ssh cannot offer some other key
- seed known_hosts with ssh-keyscan instead of relying on the runner
- skip the site deploy when the secret is absent, so forks still pass
Every deploy has been failing at the push with "git@github.com:
Permission denied (publickey)". The repo has no deploy keys registered
at all, so the keys inside site-deploy.enc and wiki-deploy.enc cannot
authenticate - most likely lost in the illinois-cs241 ->
cs341-illinois org rename. GPG decryption itself still works, so
GPG_PASSPHRASE is not the problem.
Comment out the gpg/ssh-agent machinery and push over https with the
built-in GITHUB_TOKEN, granting the job contents: write. Nothing to
rotate, and it survives future renames.
site_deploy.sh stays disabled: it pushes to a different repo to nudge
the website into rebuilding, which GITHUB_TOKEN cannot do, and it still
names the twice-stale illinois-cs241/illinois-cs241.github.io.
The WIKI build died on www.gnu.org with "[Errno 101] Network is
unreachable". gnu.org is not down: it has an AAAA record and GitHub
runners have no IPv6 route, so the connection fails before IPv4 is
tried. Reachability of the build machine is not a property of the book,
so warn and carry on instead of aborting.
Also add a 15s timeout - the failing host stalled the job for over two
minutes of retries - and report non-2xx as a warning. The previous
status test was `code < 200 and code > 299`, which no integer can
satisfy, so no status has ever been checked. It stays non-fatal
deliberately: www.gnu.org answers a bare requests HEAD with 403 (it
blocks the default user agent), so failing on non-2xx would break the
build on links that are perfectly fine in a browser.
* Fix error in script
* Temp update CI to test out build
* Change back CI
* Add new workflow to test if builds work in a PR
* Fix formatting
* Update job name
* Initial Github Actions workflow + script modifications
* Remove old keys
* Add deploy key
* Rename deploy key
* Oops add back
* Some changes after testing with website repo
* Remove env section
* Temporary changes for testing CI
* Enable github-actions on this branch for testing
* Fix?
* Only test out EPUB
* Fix?
* Fix?
* Update
* Typo and enable PDF
* Enable WIKI
* Add site deploy key
* Revert testing changes + Disable Github Actions on this branch
* Update README
* Typo
* Lowercase
Markdown does not process style tags from my observations, and the websites CSS rules make it so that the width and height attributes have lower precedence than one of the global CSS rules ( img:not(.emoji) { width: 100%} ).
Therefore, we need both (style) and (height and width) attributes.
Lawrence Angrave