Skip to content

build(docs): stop rebuilding the docs site on every push to main - #12746

Merged
hotlong merged 1 commit into
mainfrom
claude/issue-12743-docs-ignore-command
Aug 27, 2026
Merged

build(docs): stop rebuilding the docs site on every push to main#12746
hotlong merged 1 commit into
mainfrom
claude/issue-12743-docs-ignore-command

Conversation

@hotlong

@hotlong hotlong commented Aug 27, 2026

Copy link
Copy Markdown
Contributor

Every push to main rebuilds the documentation site, and almost none of them change what it renders.

Measured (7 days, whole team)

project production builds build-minutes avg
objectstack (docs) 228 2835 (98.6%) 12.4 min
objectui 123 36 0.3 min
hotcrm 42 5 0.1 min

The team runs concurrentBuilds: 1, so an 18-second objectui build queues behind a 12–46 minute docs build. The queue reached 92 deployments, the oldest 34 hours old. At 4 vCPU those docs builds cost roughly $171/month against a $20 included allowance — and 168 of the 228 were failures, so most of it bought nothing.

The change

apps/docs/vercel.json gains an ignoreCommand. Per Vercel's docs this overrides the dashboard's Ignored Build Step, which moves the rule into version control where it can be reviewed and reverted. scripts/vercel-ignore-docs.sh:

  1. non-production → skip (identical to the rule it replaces — its preview half was already right)
  2. content/** or apps/docs/** changed since the last successful deploy → build
  3. otherwise → ask turbo whether the docs dependency graph is affected (catches @objectstack/spec)
  4. anything indeterminate → build

⚠️ Why step 2 exists (the part that would silently break docs)

turbo --filter=<pkg>...[range] computes affected packages by package directory. This repo's MDX lives at the repo root in content/, outside the apps/docs boundary. turbo.json does list "$TURBO_ROOT$/content/**" under @objectstack/docs#build's inputs — but inputs only feeds the cache hash; it does not widen the affected-package calculation.

Verified against real commits on main:

commit changes dependency-graph verdict alone
72f91652 .claude/** only SKIP ✅
366f8957 packages/spec/** BUILD ✅
1265f12b content/docs/api/client-sdk.mdx only SKIP ❌ — doc update never ships

So the dependency-graph check cannot be used on its own here, which is the one thing #12698's suggested command would have done.

Failure direction is deliberate

A wrong "build" costs a few build-minutes. A wrong "skip" leaves the site quietly stale with no error anywhere — the exact shape of the two-day outage in #12333. So a missing VERCEL_GIT_PREVIOUS_SHA, a shallow clone that cannot reach it, an unparseable turbo verdict, and any non-0/1 exit from turbo all build.

Not npx turbo-ignore

#12698 suggested it. It is deprecated upstream ("turbo-ignore" is deprecated. Use "turbo query affected" instead) and it derives its own comparison range, falling back to [HEAD^] when it cannot read Vercel's git environment — silently answering a different question than the one asked. This names the range explicitly instead.

Tests

scripts/vercel-ignore-docs.selftest.sh pins all six cases against real commits from this repo's history:

  ok    preview deployments skip         -> skip
  ok    no baseline builds               -> build
  ok    unreachable baseline builds      -> build
  ok    content-only                     -> build
  ok    spec-dependency                  -> build
  ok    claude-only                      -> skip

Context

Independent of, and complementary to, the memory work: the build machine was moved to Enhanced (16 GB) after #12711 showed 403 pages need ~7.6 GB on an 8 GB machine. That took a docs build from 46–50 min failing to 3.7 min succeeding ($0.64 → $0.105 each). This PR reduces how often that runs at all — and every avoided build is one less chance to meet the ceiling as the docs keep growing (measured at ~9.7 MB of build memory per page).

Refs #12743, #12711, #12698

🤖 Generated with Claude Code

Every push to `main` rebuilt the documentation site, and almost none of them
changed what it renders. Measured over one week across the team: the docs
project ran 228 production builds consuming 2835 build-minutes -- 98.6% of the
whole team's build time -- while objectui (18s/build) and hotcrm (6s/build)
queued behind them on a `concurrentBuilds: 1` team. The queue reached 92
deployments, the oldest 34 hours old.

apps/docs/vercel.json now declares an `ignoreCommand`, which overrides the
dashboard's Ignored Build Step and moves the rule into version control.
scripts/vercel-ignore-docs.sh decides:

  1. non-production          -> skip (unchanged from the rule it replaces)
  2. content/ or apps/docs/  -> build
  3. otherwise               -> ask turbo about the dependency graph
  4. anything indeterminate  -> build

Step 2 is not redundant with step 3, and dropping it would silently stop
publishing docs: `turbo --filter=<pkg>...[range]` computes affected packages by
package directory, and this repo's MDX lives at the repo root in `content/`,
outside the apps/docs boundary. turbo.json does list `$TURBO_ROOT$/content/**`
under `@objectstack/docs#build`'s `inputs`, but `inputs` only feeds the cache
hash -- it does not widen the affected-package calculation. Verified: commit
1265f12 touches only content/docs/api/client-sdk.mdx and a dependency-graph
check alone answers SKIP for it.

Step 4's asymmetry is the point. A wrong "build" costs build-minutes; a wrong
"skip" leaves the site quietly stale with no error anywhere.

Not `npx turbo-ignore` as #12698 suggested: it is deprecated upstream ("Use
`turbo query affected` instead") and derives its own comparison range, falling
back to [HEAD^] when it cannot read Vercel's git environment. The range is
named explicitly here instead.

scripts/vercel-ignore-docs.selftest.sh pins all six cases against real commits.

Refs #12743, #12711, #12698

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation size/m tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants