Static Publishing Triggers and Deployment Status in Admin

[alibosworth]

Problem

Could EmDash provide a supported, discoverable integration for publish-aware build triggers and deployment status in admin?

#63 suggests keeping output: 'server' for administration and APIs, opting public routes into prerendering, and connecting publish webhooks to a deploy hook. We tried it on EmDash 1.2.0 and it works for generating pages. The remaining request concerns the editorial workflow around it.

A deploy hook can start a build, but editors also need to know whether their changes actually went live. The workflow should avoid draft-only rebuilds, recover from failed dispatches, and distinguish published database content from the version currently served to visitors.

Please document how menu changes, media replacement, and media deletion trigger regeneration, and how changes made during a running build are handled. Unpublishing needs an explicit policy too: a failed removal build can leave withdrawn content public.

Hosting and CI can handle atomic deployment, assets, and build concurrency. The request is for a supported contract with EmDash's editorial workflow, including least-privilege build-time access to published content on D1.

Draft-preview routing is tracked separately in #4215, and image variant reuse in #4214.

Disclosure: this proposal was prepared with assistance from OpenAI Codex, based on our site's deployment experience, source inspection, and isolated prerender test.

Use case

Static generation is a major reason developers choose Astro. Portfolios, blogs, documentation, and business websites can generate shared published pages when content changes and reuse them across visits. A photography portfolio we are working on is one example, using EmDash 1.2.0, Astro, Cloudflare Workers, D1, and R2. Its editor needs a clear publishing workflow while visitors receive prebuilt pages. See Astro's rendering guide.

The desired editor experience:

1. Save a draft without rebuilding the public site.
2. Preview the draft immediately through a supported dynamic preview path (see #4215).
3. Click Publish, which starts a build of the updated public site.
4. See Pending, Building, Live, or Failed in EmDash, with the last successful deployment time and the content version or publishing generation it represents.
5. Retry a failed deployment without opening CI or hosting dashboards.

An older successful build should not mark newer pending changes as live.

Current workarounds

Astro prerendering

In an isolated copy of our project, using the Node adapter and a copied local SQLite database, we:

• Kept output: 'server'.
• Added export const prerender = true to the photography slug route.
• Enumerated published projects with getEmDashCollection() in getStaticPaths().
• Rendered the existing page through getEmDashEntry().

The build successfully generated HTML for all four photography projects. The admin route remained dynamic and redirected logged-out requests to login.

Untested: Cloudflare/D1 CI builds, Cloudflare routing, and live webhook delivery.

A maintained end-to-end recipe alongside the coming-from-Astro guide and Querying Content guide would help make the supported workflow discoverable.

Webhook notifier

We inspected the current upstream webhook-notifier source, separately from installed core 1.2.0:

• It subscribes to content:afterSave, content:afterDelete, and media:afterUpload, without publish/unpublish subscriptions or a draft-status filter.
• Installed core 1.2.0 hydrates saved draft revisions before firing afterSave. Directly connecting this notifier to an unconditional deploy hook would therefore also request builds for draft saves.
• It makes three delivery attempts with short exponential delays within the handler execution.
• Delivery records and a dashboard widget expose Delivered/Failed counts.
• That implementation has no durable retry queue, retry-failed-delivery action, or build-completion callback. Successful delivery establishes that the trigger was accepted, not that the site was deployed.

Plugin approach

Plugin routes and dashboard widgets look like suitable building blocks for authenticated deployment callbacks and a publishing-status view. We paused a plugin prototype until we know which direction you'd prefer. Would you prefer an official integration or a community plugin, and are there hook or plugin API changes we should account for before proceeding?

Your involvement

• I am requesting this capability.
• I am offering to champion the design in a feature plan or RFC.
• I am offering to implement it after the design is accepted.