Deploying to GitHub Pages

Cherry generates its own deploy pipeline. You never write YAML unless you want to.

Generate the workflow

cherry gen.action --json

{
  "ok": true,
  "command": "gen.action",
  "data": {
    "path": ".github/workflows/pages.yml",
    "cname": "example.com",
    "branch": "main"
  }
}

The workflow builds your site with the published Cherry build action (toolchain setup, dependency caching, cherry.build, and cherry.check --strict in one uses: step), then uploads and deploys via GitHub's official Pages actions. It adds .nojekyll, and a CNAME when your site's url is a custom domain.

One-time repo setup

Settings → Pages → Build and deployment → Source → GitHub Actions. That's the entire manual step. Every push to main now checks, builds, and ships.

Custom domains

With url: "https://example.com" in cherry.exs, the workflow emits the CNAME file automatically. On the DNS side: a CNAME record from your domain to <user>.github.io (grey-cloud/DNS-only if you're on Cloudflare, so GitHub can issue the certificate), claim the domain in the repo's Pages settings, and enforce HTTPS once the cert lands.

Project pages and base_path

Deploying to https://user.github.io/myrepo/ means every URL needs the /myrepo/ prefix. Set it once:

# cherry.exs
url: "https://user.github.io",
base_path: "/myrepo"

Every emitted URL (pages, assets, feeds, canonical links, icons, nav) respects it. No template ever concatenates URL strings, so there's no class of half-prefixed bugs to chase. This is gate-tested on every commit at root and under a base path.