mirror of
https://github.com/hanzoai/hanzo.el.git
synced 2026-10-30 18:34:28 +00:00
.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]>
30 lines
1.2 KiB
YAML
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
|