Promote zola-export-smoke.sh to a gated CI job (follow-up to #378)

[avrabe]

Follow-up to #378, which is now resolved on the script side: scripts/zola-export-smoke.sh exists (merged in #391, REQ-138) and runs the full export → zola build → absolute-link check under a sub-directory base_url.

What remains is wiring it as an automatic CI gate so the REQ-115/116/118 link-regression class is caught without anyone remembering to run the script.

Why it wasn't done in #391

The existing Docs Check / Test jobs run on [self-hosted, linux, x64, rust-cpu] and have no zola-install step anywhere in .github/workflows/ to reuse. I declined to commit a fresh zola-install workflow step I couldn't execute/verify on the runners (a blind workflow change can silently break or no-op — worse than not having it).

Suggested approach

Add a job (mirroring docs-check) that:

1. installs a pinned zola release (e.g. download the getzola/zola tarball to a temp dir and add to PATH), then
2. RIVET_BIN=… scripts/zola-export-smoke.sh (or let the script build release itself).

Start it as continue-on-error: true (advisory, like the Kani/Verus jobs) until the install step is proven stable on the runners, then promote to a hard gate. The script already exit 0-skips when zola is absent, so a missing-install never turns into a false failure.

Whoever has access to confirm the self-hosted runner can fetch/run zola should land this; it's a ~15-line workflow addition on top of the merged script.

[avrabe]

Triage pass — verified the premise on main:

• scripts/zola-export-smoke.sh exists (REQ-138, feat(scripts): Zola export build smoke check (REQ-138, #378) #391, merged 2026-06-02), with the documented exit 0-skip when zola is not on PATH — confirmed in the script header. So a workflow job that installs zola conditionally and then runs the script can never turn a missing install into a false failure.
• No workflow in .github/workflows/ currently references zola or invokes the smoke script. The seven existing workflows (ci.yml, release.yml, compliance.yml, benchmarks.yml, fuzz.yml, rivet-delta.yml, release-npm.yml) have no zola-install step to reuse, as the body states.

So the gap is exactly as described: the smoke check exists and is sound, but is not wired as an automatic gate.

The body's "Suggested approach" is a clear plan but is not bulleted, testable statements-of-done. For autonomous pickup under the one-PR-per-issue rule, could you lift it into an explicit ## Acceptance Criteria block? Shape:

## Acceptance Criteria
- [ ] A new `zola-export-smoke` job in `.github/workflows/ci.yml` (or a sibling docs workflow) runs on PRs touching `rivet-core/src/`, `rivet-cli/src/`, `scripts/zola-export-smoke.sh`, or `templates/zola/**`
- [ ] Job installs a pinned `getzola/zola` release (version + sha256 pinned in the workflow) and puts it on PATH before invoking the script
- [ ] Job runs `RIVET_BIN=target/release/rivet scripts/zola-export-smoke.sh` (or lets the script cargo-build) and asserts exit 0
- [ ] Job starts as `continue-on-error: true` (advisory, per the body) so a runner-side install issue cannot block merges; promotion to a hard gate is tracked as a follow-up issue once the install step is proven stable on `[self-hosted, linux, x64, rust-cpu]`
- [ ] A REQ-NNN artifact tracks this CI gate (e.g. `Implements: REQ-NNN` paired with `Refs: REQ-138`); commit trailers follow the AGENTS.md rules
- [ ] `rivet validate` on the rivet repo still PASS after the workflow addition

Implementation-side blocker for this agent: the body itself flags it — the runner is [self-hosted, linux, x64, rust-cpu] and I cannot verify a zola-install step against it from this sandbox. A blind workflow change that no-ops or silently breaks on the actual runner is worse than not adding the gate (your own argument in the body). So even with AC, this needs either (a) a maintainer who can drive one trial run and confirm zola-install succeeds, or (b) a verified install recipe (download URL + sha256) committed to the issue. The continue-on-error: true start is the right safety rail but doesn't substitute for confirming the install actually fetches a binary on the runner.

If you confirm a specific zola version + download URL (the getzola/zola GitHub release tarball for linux-x64), this collapses to the ~15-line workflow patch the body describes and the AC above becomes mechanical.

Not implemented this run.

---

Generated by Claude Code — issue-triage agent run 2026-06-02.

---

Generated by Claude Code

[avrabe]

Valid and high-value — implemented in #450, and gating it immediately paid off. Running scripts/zola-export-smoke.sh locally (which #450 wires as the CI job you asked for) caught a real export bug: a zola build failure on the corpus because an artifact description containing \.rs$ (REQ-174) was emitted into a TOML multi-line basic string unescaped — a bare backslash is an invalid TOML escape and broke the whole site build. #450 fixes the escaping (\\ like the title already does) and adds the zola-export-smoke job (ubuntu-latest, pinned zola, advisory continue-on-error to start, exactly as suggested). So this issue would have caught the regression class on the very next backslash-containing description.