Files
zeekay a5d59ebc9d one document, one generator, one lock
Regenerated from hanzoai/cloud's openapi.yaml at the commit .spec-lock now
names, by hanzoai/openapi's generate.py under a `swift:` row — the same driver,
the same pinned generator and the same document as every other client.

What was here projected hanzo.yaml at info.version 8.0.0 through a generator
version nothing else in the fleet uses, and recorded neither: 1937 of the 2308
addresses it published appear in neither cloud's emission nor any projection of
it. This client publishes 2479, as 192 API types over 2460 models, with no
dependency.

Four things Swift needs said, all of them in the row: swift6 for typed throws,
four model names its own modules own, the legacy snake/camel property pairs it
would otherwise declare twice, and the two schemas that store themselves, which
a struct cannot. One generator template is overridden so the transport compiles
where corelibs Foundation keeps URLSession — which is what makes `swift build`
a gate this fleet's runners can run.

Package.swift comes from the generator now, so the language mode and the code
it compiles have one home. The Carthage, CocoaPods and XcodeGen manifests are
gone with the old generator's docs: SwiftPM resolves this package.
2026-08-14 20:19:17 -07:00

48 lines
2.4 KiB
YAML

# Hanzo CI — the ONE way this repo is gated, read by hanzoai/ci.
#
# No `images:` and no `deploy:`: this is a client library. SwiftPM resolves it
# from a git TAG, so what CI owes is a gate, not an artifact — and no `version:`
# either: a tag is a human's decision.
test:
- name: build
# The compiler is the gate, as it is for every sibling client: 2667 files,
# 192 API types over 2460 models, and a document defect lands here as a file
# and a line rather than as a consumer's surprise. Measured cold on linux:
# `Build complete! (34.06s)`.
#
# It compiles OFF Apple platforms at all because the row that generates this
# client overrides one generator template — the transport imports
# MobileCoreServices behind `#if !os(macOS)` and names URLSession without
# FoundationNetworking, neither of which holds on Linux. See
# hanzoai/openapi's `sdks.yaml`.
#
# The runner needs a Swift toolchain, and hanzoai/ci's build.yml provisions
# Go, Node, Rust, Java and C but not yet Swift — one guarded step in that
# file, `if: hashFiles('Package.swift') != ''`, in the shape the other four
# already have. That is where a toolchain comes from; a client repo
# inventing its own container invocation would be the second way.
run: swift build
- name: examples
# The flows compile against the client they demonstrate, so a document that
# moves a method breaks HERE — one place — rather than in a reader's editor.
# `models` is then RUN for real: it is the one flow that needs no credential,
# and it proves the whole path a consumer takes — URLSession over corelibs
# Foundation, the request the client builds, a 200 back — which no amount of
# compiling can. Measured: `HTTP 200 from https://api.hanzo.ai`, 520 models.
run: |
set -e
swift build --package-path examples
swift run --package-path examples models
# THE CLIENT LANE — this repo is a PROJECTION of one API document at one version.
#
# hanzoai/cloud's release sends `repository_dispatch: spec-update` carrying
# (version, sha, spec_sha256); hanzoai/ci fetches openapi.yaml AT THAT SHA,
# REFUSES if the bytes hash to anything else, runs `generate:`, writes
# `.spec-lock` beside the code, and — only after `test:` above has passed over
# exactly those bytes — commits.
client:
generate: ./scripts/generate.sh