www builds currently bypass Turbo. This caches Next.js compilation and
sitemap generation while keeping content refreshes and asset uploads on
every build, including cache hits.
**Changed:**
- Refresh content before Turbo hashes its inputs, and upload assets
after Turbo saves or restores the build output.
- Include generated content, shared code, environment settings,
sitemaps, and the customer RSS feed in the cache configuration.
- Remove the redundant `vercel.json` build override and consolidate
public environment settings into `NEXT_PUBLIC_*`.
Cache reuse requires the same commit and build inputs because production
CDN URLs include the commit SHA.
**Added:**
- Build lifecycle tests covering cache restoration, input invalidation,
root/app commands, and upload ordering and failure handling.
## To test
- From `apps/www`, run `pnpm exec vitest run turbo-build.test.ts
generate-sitemap.test.ts scripts/lib/githubStars.test.ts`.
- Check the Vercel preview build runs content preparation before
`build:next`, and verify the homepage, `/sitemap.xml`, and
`/customers-rss.xml` load.
- Rebuild with identical prepared content and environment settings to
check compilation is cached. Asset uploads should still run when
enabled.
Validation: 63 tests passed, along with typecheck, ESLint for the new
test, formatting, and a full local build. The local build used public
example settings and placeholder survey configuration, with asset
uploads disabled; Vercel deployment validation is still pending.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **Build & Deployment**
- Production builds now reuse cached outputs and restore generated
assets when a cache is available.
- Static assets upload after a successful build, and changes to content,
documentation, configuration, or shared components trigger a fresh
build.
- **Documentation**
- Added production build guidance covering caching, CDN uploads,
overrides, and direct-build limitations.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Alaister Young <10985857+alaister@users.noreply.github.com>
I added content dates to `sitemap_www.xml` and `dateModified` to blog
JSON-LD so crawlers can compare freshness with page metadata. Both use
`updated` when present, otherwise the publication date.
**Changed:**
- **Consistent dates:** I use the same frontmatter parser for the blog
page and sitemap. It preserves authored dates across quoting and
timezones and rejects JavaScript frontmatter.
- **Invalid dates stop the build:** I reject impossible calendar days,
out-of-range times and offsets, malformed dates, and `updated` before
publication. Content changes run the generator in CI.
- **Authoring:** I documented optional `updated` for substantive
revisions. Events, static pages, and `/evals` omit `<lastmod>`.
**Note:** Changelog dates come from RSS. Existing sitemap omissions for
nonnumeric changelog slugs (GROWTH-1212) and app-router pages
(GROWTH-1214) remain separate.
## To test
On the preview:
- [x] Open `/sitemap_www.xml`: blog, alternatives, customer stories, and
included changelog entries should carry `YYYY-MM-DD` lastmod values.
Verified on the 2092513 preview: all 425 blog, 3 alternatives, 43
customer story, and 207 changelog entries carry a `YYYY-MM-DD` lastmod,
zero malformed values. Production currently emits no lastmod at all.
- [x] Inspect `/blog/supabase-is-now-available-in-gemini-enterprise`:
BlogPosting `dateModified` should be `2026-09-09`, matching its sitemap
entry. Verified: one BlogPosting block, `datePublished` and
`dateModified` both `2026-09-09`, sitemap lastmod `2026-09-09`.
- [x] Find the `/company` and event entries in the sitemap: neither
should carry lastmod. Verified: `/company` and all 13 `/events/` entries
have no lastmod.
- [x] Added: `/evals` and the `/changelog` index carry no lastmod
either.
- [x] Added: the blog page renders with no new console errors. The only
console error is a `/docs?_rsc=` prefetch 404: the preview host serves
404 for `/docs` itself, unrelated to this change.
## Linear
- fixes GROWTH-1206
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
- **New Features**
- Blog posts now support optional updated dates for substantive
revisions.
- Sitemap entries include accurate modification dates for blog,
alternatives, customers, and changelog content.
- Blog structured data now includes the post’s modification date.
- **Bug Fixes**
- Improved validation prevents invalid or inconsistent content dates
from generating incorrect sitemap data.
- Changelog sitemap links are deduplicated and assigned their published
dates.
- **Documentation**
- Added guidance for specifying publication and update dates in blog
post metadata.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
Closes DOCS-1278
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES
## What kind of change does this PR introduce?
Feature. Adds E2E test scaffolding and a CI check for the marketing
site.
## What is the current behavior?
Closes [FE-4047](https://linear.app/supabase/issue/FE-4047).
The marketing site has no E2E coverage. Docs has a suite in `e2e/docs`,
but its
runner, git helpers and axe reporting are private to that package, so a
second
site cannot reuse them.
## What is the new behavior?
* **A www suite scoped to changed content.** Changed `.mdx` files in
`_blog`,
`_events`, `_customers` and `_alternatives` map to the URLs they render.
Pages
with `disable_page_build: true` are skipped because they 404 by design.
Capped
at 20 pages. Enforces `heading-order` and `page-has-heading-one`,
matching docs.
* **`e2e/shared` The docs site is also static with similar needs. This
folder shares the docs logic with www.
* **A CI check that is safe to mark required.** Path scoping lives in a
`Detect changed paths` step rather than a `paths:` trigger, so the check
reports on every pull request instead of being skipped.
`waitForVercelDocsPreview.js` becomes `waitForVercelPreview.js`, shared
by both
workflows.
## How the check behaves
The job always reports a check run, so it is safe to mark required. Path
scoping
happens in a step rather than a `paths:` trigger, which would leave
non-www pull
requests waiting on a check that never reports.
| Case | Behavior |
| --- | --- |
| Fork pull request adds new pages | Passes without testing. The Vercel
wait is gated on `head.repo.full_name == github.repository`, so forks
resolve no preview URL. The job emits a `::warning` and a job summary
containing a ready-to-run `gh workflow run www-e2e.yml` command with the
resolved page paths, so a maintainer can run it against the preview. |
| Vercel preview times out or fails | Passes without testing. The wait
step is `continue-on-error: true`, so a 900s timeout or a failed
deployment leaves the URL unset and the suite skips. Vercel's own
`Vercel – zone-www-dot-com` check already reports the failure. |
| Draft pull request | Job does not run at all, gated at the job level
on `pull_request.draft == false`. `ready_for_review` is in the trigger's
`types`, so marking it ready runs the check. |
| Another app changed, www untouched | Job runs and every step skips.
The `www` filter matches only the four content directories, `e2e/www`,
`e2e/shared`, the lockfile, and this workflow. |
| Only the harness changed | Passes without testing. Scope resolves to
zero pages, and the Vercel wait is additionally gated on `www_app`, so
it does not wait for a preview Vercel skipped. |
| No preview resolves, any reason | Skips rather than falling back to
production. Production does not serve pages the pull request adds, so
testing it would fail a valid change. |
### Not covered
Changes to `apps/www` components and routes do not trigger this check —
only the
four content directories do. A follow-up can check global components
such as the navigation and the footer.
## Manual testing
1. Start the site: `pnpm dev:www`
2. Run `pnpm e2e:www` with no www content changed. It should resolve
zero pages
and skip Playwright, not fail.
3. Touch a post, then run `pnpm e2e:www` again:
`echo "" >> apps/www/_blog/2024-01-01-some-post.mdx`. The resolved
`/blog/...`
path should be listed before Playwright starts.
4. Run against production with no local server:
`PLAYWRIGHT_BASE_URL=https://supabase.com
WWW_E2E_PAGE_PATHS=/blog/postgres-language-server pnpm e2e:www`
5. Point step 4 at a page with a known heading problem. The failure
should name
the rule, the CSS selector and the markup.
6. Confirm docs still passes on the shared runner: `pnpm dev:docs`, then
`pnpm e2e:docs`
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **New Features**
* Added WWW end-to-end testing for affected content pages, including
accessibility checks.
* Added standard and full-site test commands, configurable preview
testing, and failure reports.
* Added shared utilities for page discovery, accessibility scanning, and
test execution.
* **Documentation**
* Documented WWW test setup, coverage, debugging, CI behavior, and
running checks against production or preview environments.
* **Improvements**
* Updated documentation test workflows to better identify affected
changes and handle preview environments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
## I have read the
[CONTRIBUTING.md](https://github.com/supabase/supabase/blob/master/CONTRIBUTING.md)
file.
YES/NO
## What kind of change does this PR introduce?
Bug fix, feature, docs update, ...
## What is the current behavior?
Please link any relevant issues here.
## What is the new behavior?
Feel free to include screenshots if it includes visual changes.
## Additional context
Add any other context or screenshots.
This PR removes all CMS code from the `www` app. This includes fetching
of blog posts, API routes for proxying blog posts and types.
All functionality should remain the same (and the number of blog posts
should be the same).
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Chores**
* Removed CMS integration, APIs, preview/draft/revalidate endpoints,
related env vars and dependency; switched to static markdown-only blog
pipeline.
* **Refactor**
* Simplified image and author resolution, tightened component props to
static post shapes, and migrated imports to path aliases.
* **Documentation**
* Deleted CMS integration docs and rich-text conversion helpers.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
## What kind of change does this PR introduce?
Frontmatter name change.
## What is the current behavior?
We repeatedly mistake `thumb` for `image` and visa versa, meaning the
wrong images are used for Open Graph and in-site thumbnails on blog
posts. Events and case studies use the same naming convention too.
## What is the new behavior?
These two bits of frontmatter are renamed for clarity:
- Blog posts: `imgThumb` + `imgSocial`
That mapping for blog posts:
- `thumb` is now `imgThumb`
- `image` is now `imgSocial`
These related bits remain as-is:
- Events
- Case studies
The
[www/README.md](https://github.com/supabase/supabase/blob/dnywh/chore/blog-image-frontmatter/apps/www/README.md#best-practices)
file has been expanded to clarify all of the above. It now also provides
instructions on image optimisation.
## To test
A lot of files were touched here. Please help make sure:
- [ ] The CMS works as intended. This is the **biggest unknown**.
- [x] All blog posts render the correct image as their on-site thumbnail
and Open Graph image. You can test the latter by firing up a draft
iMessage. Online Open Graph services like Facebook cache images, so
aren’t reliable.
- [x] All events render their correct images
- [x] All case studies render their correct images
- [x] All customer stories render their correct images ([known
issue](https://supabase.slack.com/archives/C072FL5KKKP/p1768888063209359?thread_ts=1768885681.502169&cid=C072FL5KKKP),
predates this work)
