Include previous lite builds in case of recoverable failure

[bollwyvl]

elevator pitch

If a full shave build passes, and then fails on the next build (but sphinx still runs), try to include the last-known-good build on all future failing builds.

motivation

On both GitHub Pages and ReadTheDocs, once a build is overwritten, it's gone. As we collect and re-report shave failures as a best-effort human-readable site, this means a previously-working, and still inspect-able product might be overwritten with boring error messages.

design ideas

At the end of a full shave, jupyter lite archive makes an npm-compatible tarball, currently always with the name work/dist/lite/lite-jupyterlite.tgz, which also gets uploaded to the host, e.g.

• https://deathbeds.github.io/jupyak/_static/work/lite/lite-jupyterlite.tgz
• https://jupyak--{:pr-number}.org.readthedocs.build/en/16/_static/work/lite/lite-jupyterlite.tgz

It may also be desirable to include the "version" (e.g. PR number), e.g.

• _static/work/lite/jupyak-{:pr-number}.tgz

Any further information (e.g. git hash, info about the repos) is likely not a good idea, though more information (such as build logs) could easily be brought over in a similar manner without changing the lite archive, a useful artifact in its own right.

Based on state of the work folder, and well-known environment variables, a failing sweep-up job can:

• derive the URL of a previous success (or previous pulled-along failure)
• check if it exists
• download it
• extract it into e.g. work/dist/last-known-good/
• copy itself into it
• point to it in e.g. the build info sidebar in the HTML site