timescale.info
Sign inSign up

How OpenChronology was built

Every merged pull request of openchronology/timeline-app, its first week of commits and its releases; and before them the 2020 PureScript editor, from snapshots of its deleted repositories in the Wayback Machine. Written to this server through the HTTP API.

327 moments · 2020-03-09T00:15:08Z CE – 2026-11-02T20:11:21Z CE · by @athan · @athan

#370 · Cache the Node.js tarball for the package builds

  • timeline-app
  • pull request
  • packages

Fixes #369 The .deb and .rpm builds' hangs came from downloading Node.js from nodejs.org inside Docker on GitHub's runners (#367, #368). Each package job now downloads the tarball once, outside Docker, caches it, and gives it to the build. ## How the tarball reaches the build - **Version, one source:** the Debian Dockerfile's `ARG NODE_VERSION` / `ARG NODE_SHA256`. `nodeRuntime()` in `scripts/server-targets.mjs` reads them; a test checks the RPM Dockerfile's pair matches, and that the Windows installer's zip is the same release. - **CI** (`server-packages.yml`, the `package` matrix: debian13, ubuntu24.04, rocky10, fedora44): `node scripts/node-tarball.mjs --print` gives the version, architecture and file name; `actions/cache` (pinned SHA, v6.1.0) restores `$RUNNER_TEMP/node-tarball` under `node-tarball-v -linux-x64`; on a miss, `scripts/node-tarball.mjs` downloads it with #368's curl retries and limits (step `timeout-minutes: 5`); the build gets `OCH_NODE_TARBALL`. - **`scripts/server-package.mjs`:** with `OCH_NODE_TARBALL` set (it must be the pinned file name), passes its folder as `--build-context node-tarball= `. - **Dockerfiles:** a new empty `FROM scratch AS node-tarball` stage, which the build context replaces. The package stage bind-mounts it, copies the tarball when it is there, and otherwise downloads it from nodejs.org as before. Local builds without the variable don't change. ## Checksums - In Docker, either way: `sha256sum -c` against the pinned `NODE_SHA256` before unpacking, as before. A corrupted tarball fails the build (checked locally). - In CI, before caching: `node-tarball.mjs` checks that `SHASUMS256.txt` (cached alongside) lists the tarball with the pinned SHA-256, and that the file has that hash. ## Not covered - The Windows installer (`deploy/windows-server/build.ps1`) downloads its zip outside Docker with its own pinned hash, and hasn't stalled. FreeBSD and macOS use their package managers' Node.js. The platform and Compose images use `node:24` images. ## Tests - `test/ci-workflows.test.mjs`: the version step, cache, download and build steps come in that order; the cache key uses the shared version and architecture; the workflow has no Node.js version or URL of its own; the Dockerfiles agree; and both branches (given or downloaded) are followed by the SHA-256 check before unpacking. - Local: `npm test` passes (361 tests). debian13 built with a given tarball (`Using the given node-v24.21.0-linux-x64.tar.xz`, `node.tar.xz: OK`) and without one (downloaded, `OK`). `test/server-deb.mjs` passes on the given-tarball build. fedora44 was also built with a given tarball and tested with `test/server-rpm.mjs`.

Sources

Open #370 · Cache the Node.js tarball for the package builds in the timeline