Files
zeekayandHanzo Dev b0fd65e403 ci: publish the docs through our own Sites plane, not GitHub Pages
.github/workflows/docs.yml built docs/ with actions/jekyll-build-pages and
handed it to actions/deploy-pages. That is a deploy plane outside our CI/CD,
outside the Sites plane and outside our analytics, and it never worked:
hanzoai.github.io/hanzo.el answers 404 and every "Deploy Docs" run on this repo
has failed. This repo has had no live docs site at all.

.hanzo/workflows/deploy.yml replaces it with the shape hanzoai/hips already
proves: build the export, POST /v1/projects/hanzo-el/deploy, sync the bytes
straight to the S3 prefix cloud names in the 202, then flip the deployment live
— and mark it error if the run dies after enqueueing, so cloud never records a
deployment as "queued" forever. It runs on hanzo-build-linux-amd64, which is a
label the forge runners actually advertise; a label nothing answers does not
fail, it queues silently until the 24h timeout.

The Jekyll source loses its Pages-only machinery. `remote_theme:
pages-themes/midnight` + jekyll-remote-theme resolve through the GitHub API and
supplied nothing that rendered — _layouts/default.html is a complete page with
its own <html>, <style>, header and footer. baseurl `/hanzo.el` under a
hanzoai.github.io url was a project-page artifact; the site serves from the root
of its own host now. `permalink: pretty` because hanzoai/static answers /page
from page/index.html and 404s on page.html.

Analytics is the ONE hosted tag (cloud apps/analytics/tag.go) posting to
POST /v1/event — no GA, no second tracker. The tag is stamped into the export
rather than into the layout because the other doc sites in this fleet export
rustdoc and storybook HTML no layout of ours can reach; one mechanism for all of
them. Its key is read from the project this run deploys, so pk- rotation is one
server-side change rather than five repo edits, and no key means no tag: a
keyless beacon is accepted 200 into $public, a tenant this org cannot read.

The footer linked five hanzoai.github.io URLs. All five answer 404 — the org has
no Pages site. They now point at the native host, the repo, or the brand's own
domain.

release.yml is untouched: it publishes an Emacs package tarball, not a site.

Co-authored-by: Hanzo Dev <[email protected]>
2026-08-04 18:24:40 -07:00

30 lines
1.2 KiB
YAML

title: hanzo.el
description: AI-powered Emacs package
# The site serves from the root of its own host on the Hanzo Sites plane, so
# there is no path prefix. It used to carry `baseurl: /hanzo.el` and a
# `hanzoai.github.io` url, which are GitHub Pages project-page artifacts: every
# root-relative link they produced would 404 here.
url: https://hanzo-el.hanzo.app
baseurl: ""
# _layouts/default.html is a COMPLETE page — its own <html>, its own <style>,
# its own header and footer. It never reads a theme's stylesheet or includes, so
# `remote_theme: pages-themes/midnight` + the jekyll-remote-theme plugin were
# fetching a theme whose output nothing rendered. They are also Pages-only
# machinery (remote_theme resolves through the GitHub API), which is exactly what
# keeps a site buildable in one place and one place only.
markdown: kramdown
highlighter: rouge
# Directory permalinks, because that is what the site server actually resolves:
# hanzoai/static answers `/page` from `page/index.html` and 404s on `page.html`.
# One page today, but the rule has to be the config's, not the page count's.
permalink: pretty
defaults:
- scope:
path: ""
values:
layout: default