GitHub Actions → Zesty.io WebEngine
Treat Content.One like code. Branch anything, get a live preview, review the exact impact on a pull request, then promote local → stage → production — where stage saves and production is a clean publish-only gate.
The webengine/ folder of this repo is the source of truth for the Content.One instance. A GitHub Action maps each file to its Zesty resource by ZUID (zesty.config.json) and syncs it over the Instance API.
No more pasting code into the Manager. Work in git, open a pull request, read a comment spelling out exactly what will change, and promote through branches. The CMS becomes a deploy target — versioned, reviewable, reversible.
local is just one example. Spin up a branch for any piece of work, push it, and WebEngine serves it at its own preview domain — pulled straight from GitHub. Share the link so a teammate can review the real rendered site before it touches the instance.
Redesign the homepage in isolation. Preview & share before it ever reaches stage.
A tiny fix on its own branch — reviewable on its own URL.
Build a whole campaign, demo the live preview to stakeholders, merge when approved.
These are working branches — make as many as you need, push them up, and the team reviews via the link. Nothing is written to the instance until a branch is merged into stage.
Two gates. Each is previewed and explained before it acts.
Where you build. No instance writes — but fully previewable and shareable.
Merge here saves changed files (and creates new ones) on the instance's dev version.
Merge here publishes — promotes the staged version live. No new files, no edits; just a publish trigger.
All authoring happens on stage. Production never introduces content — it just decides what goes live.
Two secrets, two workflows. That's the footprint.
commit new-resource ZUIDs back
post the impact comment
stage · production (+ any)
Open a PR into stage or production and a read-only bot comment lands automatically — it diffs the change against the instance, writing nothing.
Git says what was touched; the API says what actually differs. Only the intersection acts.
A git diff against the pre-push commit lists what the merge changed.
Each candidate is compared to the instance — dev for stage, live for production.
Identical resources are skipped — no needless saves, no blind republish; Manager drift is caught.
New files are created on stage and their ZUID is written back to zesty.config.json.
This very page was built by an AI agent and shipped through the exact flow it describes.
Because everything is git + PRs + URLs, an AI assistant can do the heavy lifting and a human stays in control through review. A typical loop:
The agent proposes; previews + comments make approval fast and safe.
Nothing publishes without a merge — production stays a deliberate, gated step.
Previews + an impact comment mean no one publishes blind.
Idempotent — re-running never republishes identical content.
Every content change is a commit — diffable and revertible.
Edits made directly in the Manager surface as a diff.
Real CI/CD for a website CMS with nothing but GitHub Actions:
Linters, HTML/CSS validation, link checks, Lighthouse — run on the PR and gate the merge on green.
Merge is the deploy. Stage saves; production publishes — automatically, scoped to real diffs. Roll back by reverting a commit.
Tests flow into the same pipeline: a check on the PR, a preview URL to eyeball, an impact comment to confirm scope — then a one-merge deploy. Production-grade delivery, built into the website with ease.