fix(ci): remove Cargo-backed docs export smoke

This commit is contained in:
t8y2 committed 2026-09-11 11:28:50 +08:00
1 parent ea44730c8a
commit 1c9846dc57
3 files changed
+2 -231

No files matched your search

@@ -1,53 +0,0 @@
import { execFileSync } from "node:child_process";
import { readFileSync } from "node:fs";
import os from "node:os";
import path from "node:path";
import { beforeAll, describe, expect, it } from "vitest";
// @vitest-environment happy-dom
// Not under the workspace's `target/`: this repo's global `~/.cargo/config.toml`
// can redirect cargo's target-dir elsewhere (to dedupe build artefacts across
// worktrees), so a path assuming `<repo>/target/` is not portable. `os.tmpdir()`
// has no such dependency on cargo configuration.
const htmlPath = path.join(os.tmpdir(), "docs-export-smoke.html");
describe("the exported file", () => {
beforeAll(() => {
// Generated by a small Rust example so the test exercises the REAL
// to_standalone_html output rather than a hand-built approximation.
//
// `--no-default-features`: the docs module doesn't touch duckdb-sidecar,
// mq-admin, sqlite-sqlcipher or system-fonts, and matching that flag here
// to the CI workflow's prebuild step (same cargo invocation, same
// fingerprint) is what makes this a cache hit instead of a fresh compile
// of dbx-core inside the hook. If this flag ever drifts from the
// workflow's build step, the hook goes back to compiling from scratch
// and risks the 120s timeout below.
execFileSync("cargo", ["run", "-p", "dbx-core", "--no-default-features", "--example", "docs_export_smoke", "--", htmlPath], { stdio: "inherit" });
// The CI workflow prebuilds this example in its own step so this hook
// only pays for a freshness check and a run (well under a second warm,
// measured locally). 120s covers a slow/cold worst case without making
// an unrelated hook's timeout wait this long by raising it globally.
}, 120_000);
it("mounts and renders a table name", async () => {
// The route is read from `location.hash` at mount time (ExportApp.vue),
// so landing directly on the table page is what makes the assertion
// below check rendered CONTENT rather than merely an element's presence:
// the index page lists "orders" and "public" as separate text nodes
// (a schema header, then a bare table name), never the joined string
// "public.orders" that only the table page's heading produces.
location.hash = "#/table/public.orders";
document.documentElement.innerHTML = readFileSync(htmlPath, "utf8");
for (const script of Array.from(document.querySelectorAll("script"))) {
if (script.getAttribute("type") === null) new Function(script.textContent ?? "")();
}
await new Promise((resolve) => setTimeout(resolve, 100));
const rendered = document.querySelector("#app")?.textContent ?? "";
expect(rendered).toContain("public.orders");
// Column data, not just the heading — proves the fixture's real
// structure (built by the Rust example, not this test) reached the DOM.
expect(rendered).toContain("customer_id");
});
});