OS release pipeline
How a Desktop/UI source change becomes a compiled, immutable, installable School-GIT OS release.
System flow
Build
Validate
Publish
Store URL binaries
Install
Verify again
Stage pending
Restart
Source map
- scripts/build-schoolgit-os.mjs
- app/cdn/os-publish/page.tsx
- app/api/cdn/os/releases/route.ts
- lib/cdn/os/os-release-store.ts
Architecture diagram
mermaidflowchart TD
A[Source tree] --> B[esbuild browser runtime]
B --> C[os-runtime.js + os.css + manifests]
C --> D[OS publisher]
D --> E[Server validates release]
E --> F[URL-backed immutable binary records]
F --> G[System Update downloads]
G --> H[SHA-256 verify + OPFS write]
H --> I[Re-read OPFS + verify]
I --> J[pending-version]
J --> K[Restart + bootstrap]Build output
The release builder snapshots the browser OS entry graph into compiled JavaScript and snapshots the current CDN stylesheet into the release. Installed OS releases do not execute raw TSX from OPFS.
- os-runtime.js
- os.css
- os-manifest.json
- build-meta.json
- release.json
Server-side publication validation
The OS release API validates semantic versioning, normalized paths, duplicate paths, file sizes, runtime entry presence, manifest consistency and release metadata before committing immutable binary records.
A partial publication failure cleans up staged binary records rather than leaving an intentionally half-created release.
Install and activation are separate
Downloading a release does not immediately switch the running desktop. A verified release first becomes pending. The bootstrap changes active-version only after the new runtime successfully starts.