| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
chore(start-sdk): promote next release to 3.0.0 (#3900) Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol | 3 天前 | |
ci: drop the runner's Microsoft apt sources before apt-get update (#3842) apt-get update fetches metadata for every configured source and exits 100 if any one of them fails, and the step shell runs with -e, so a single unreachable third-party source aborts the job before apt-get install ever runs. The GitHub runner image ships an azure-cli source on packages.microsoft.com that intermittently answers 403, which is enough to fail a build that installs nothing from Microsoft: E: Failed to fetch https://packages.microsoft.com/repos/azure-cli/dists/noble/InRelease 403 Forbidden E: The repository 'https://packages.microsoft.com/repos/azure-cli noble InRelease' is no longer signed. setup-build-env already removed microsoft-prod.list, but azure-cli is a separate file, so the hardcoded name missed it. Match on the host instead: that covers every Microsoft source whatever it is called and whether it is a .list or a deb822 .sources, and it cannot touch the Ubuntu mirror config, which lives in /etc/apt/apt-mirrors.txt rather than sources.list.d. Applied to the three places that run apt-get update on the runner itself. The call sites in start-registry.yaml and startos-iso.yaml run inside a container whose sources.list.d has no Microsoft repo, and are left alone. Verified under the step shell GitHub uses (bash --noprofile --norc -e -o pipefail) that the line deletes only the Microsoft source and that a no-match run still exits 0 rather than tripping pipefail. Co-authored-by: Matt Hill <9935159+MattDHill@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 12 天前 | |
advance live-docs on a release, and track it from a packaging workspace (#3877) * feat(ci): advance live-docs on a release, and track it from a workspace A packaging workspace cloned `master`, which carries the SDK that has not shipped: today its `projects/start-sdk` is 2.0.10 while every published package pins `@start9labs/start-sdk` 2.0.9. The guide, the package template and the SDK source a packager reads therefore ran ahead of what `npm install` resolves, and the local copy of the guide disagreed with docs.start9.com. `live-docs` is the branch that should answer this — it is what is published — but nothing has ever advanced its code. It was branched off master's tip on 2026-08-10 (#3652) and only `projects/<p>/docs` has moved since, so its `projects/start-sdk/lib` is still that day's in-progress 2.0.10, and `shared-libs/`, `.github/` and the repo root are all three weeks stale and drifting. docs-sync-on-tag now takes the tagged tree whole and puts every *other* `projects/*` back on the release it is on. A tag advances its own project, the shared libraries beneath it, and the repo root; it speaks for nothing another product owns. `projects/start-docs` rides along only with a product that ships a book, so a bookless release still refreshes the tree without triggering a site deploy. The stale-tag guard now covers the whole tree rather than the site alone: a backfilled tag still publishes its book and nothing else. `init-workspace` then clones `live-docs`, so `git pull --ff-only` stays the session-start sync and a workspace gets published-guide corrections the moment they go live, rather than at the next release. This does not repair the tree live-docs inherited on 2026-08-10; each project converges at its own next tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: fail a live-docs pull request that changes anything but a book live-docs now carries published code as well as published books, and nothing gated a pull request into it. A PR touching code would put a tree there that no release produced, and docs-backport pushes whatever merges into live-docs onto master unattended — so it would land on master unreviewed as a code change. The predicate is a rule rather than a mirror of docs-deploy's paths, so a new product's book is covered the moment it exists. The package template is the one thing under docs/ that it rejects: `s9pk init-package` scaffolds from it, and `manage-release.sh pre-check start-sdk` verifies its SDK pin against the release being cut, which an edit landing on live-docs would never face. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * say why the package template is not PR-able to live-docs Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(start-cli): say when start-cli is behind the published release start-cli installs outside the workspace, so nothing tied it to the guide the workspace carries. On Debian the installer adds an apt repo and `apt upgrade` carries it forward; on macOS and every other Linux it drops a binary in ~/.local/bin with no update path, and the guide never said to re-run the installer. Those packagers drift indefinitely against a guide that keeps advancing. The checkout tracks published releases and `projects/start-cli` only moves on a start-cli tag, so its manifest names exactly the version a packager should be running. Comparing it to the version baked in at build time is a file read with no network, printed once per process, and silent on anything unreadable. It rides on the workspace lookups s9pk work already does — signing (pack, publish, edit) and init-package — so it fires where a stale binary would bite and nowhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: judge a release against its own product's earlier syncs The rollback guard compared every tag against the newest sync of any product, but deb releases tag the commit alpha built, which is routinely behind a tag cut before it. Such a release was judged stale and never advanced its own tree; a bookless one crashed on the book-only path. The watermark was also read only from commits touching projects/start-docs, which a bookless sync no longer touches, so an older tag arriving after one rolled shared-libs and the root back. Two watermarks now. A product's own tree is behind only if an earlier release of the same product was synced from a descendant of the tagged commit. The shared trees are behind if any release was, and then stay where the newer release put them. Every earlier sync is consulted, not the newest, because syncs land out of ancestry order. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: let a retarget onto live-docs re-run the guard check-pr-retarget-workflows.py audits every workflow with a pull_request trigger, and the guard was not registered. It is a direct listener like conflict-markers rather than a retarget-called target: its verdict depends on the base, and the branch filter is evaluated against the new base, so taking `edited` is what checks a PR moved onto live-docs before its next push. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Matt Hill <9935159+MattDHill@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 4 天前 | |
advance live-docs on a release, and track it from a packaging workspace (#3877) * feat(ci): advance live-docs on a release, and track it from a workspace A packaging workspace cloned `master`, which carries the SDK that has not shipped: today its `projects/start-sdk` is 2.0.10 while every published package pins `@start9labs/start-sdk` 2.0.9. The guide, the package template and the SDK source a packager reads therefore ran ahead of what `npm install` resolves, and the local copy of the guide disagreed with docs.start9.com. `live-docs` is the branch that should answer this — it is what is published — but nothing has ever advanced its code. It was branched off master's tip on 2026-08-10 (#3652) and only `projects/<p>/docs` has moved since, so its `projects/start-sdk/lib` is still that day's in-progress 2.0.10, and `shared-libs/`, `.github/` and the repo root are all three weeks stale and drifting. docs-sync-on-tag now takes the tagged tree whole and puts every *other* `projects/*` back on the release it is on. A tag advances its own project, the shared libraries beneath it, and the repo root; it speaks for nothing another product owns. `projects/start-docs` rides along only with a product that ships a book, so a bookless release still refreshes the tree without triggering a site deploy. The stale-tag guard now covers the whole tree rather than the site alone: a backfilled tag still publishes its book and nothing else. `init-workspace` then clones `live-docs`, so `git pull --ff-only` stays the session-start sync and a workspace gets published-guide corrections the moment they go live, rather than at the next release. This does not repair the tree live-docs inherited on 2026-08-10; each project converges at its own next tag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: fail a live-docs pull request that changes anything but a book live-docs now carries published code as well as published books, and nothing gated a pull request into it. A PR touching code would put a tree there that no release produced, and docs-backport pushes whatever merges into live-docs onto master unattended — so it would land on master unreviewed as a code change. The predicate is a rule rather than a mirror of docs-deploy's paths, so a new product's book is covered the moment it exists. The package template is the one thing under docs/ that it rejects: `s9pk init-package` scaffolds from it, and `manage-release.sh pre-check start-sdk` verifies its SDK pin against the release being cut, which an edit landing on live-docs would never face. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * say why the package template is not PR-able to live-docs Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(start-cli): say when start-cli is behind the published release start-cli installs outside the workspace, so nothing tied it to the guide the workspace carries. On Debian the installer adds an apt repo and `apt upgrade` carries it forward; on macOS and every other Linux it drops a binary in ~/.local/bin with no update path, and the guide never said to re-run the installer. Those packagers drift indefinitely against a guide that keeps advancing. The checkout tracks published releases and `projects/start-cli` only moves on a start-cli tag, so its manifest names exactly the version a packager should be running. Comparing it to the version baked in at build time is a file read with no network, printed once per process, and silent on anything unreadable. It rides on the workspace lookups s9pk work already does — signing (pack, publish, edit) and init-package — so it fires where a stale binary would bite and nowhere else. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * ci: judge a release against its own product's earlier syncs The rollback guard compared every tag against the newest sync of any product, but deb releases tag the commit alpha built, which is routinely behind a tag cut before it. Such a release was judged stale and never advanced its own tree; a bookless one crashed on the book-only path. The watermark was also read only from commits touching projects/start-docs, which a bookless sync no longer touches, so an older tag arriving after one rolled shared-libs and the root back. Two watermarks now. A product's own tree is behind only if an earlier release of the same product was synced from a descendant of the tagged commit. The shared trees are behind if any release was, and then stay where the newer release put them. Every earlier sync is consulted, not the newest, because syncs land out of ancestry order. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * ci: let a retarget onto live-docs re-run the guard check-pr-retarget-workflows.py audits every workflow with a pull_request trigger, and the guard was not registered. It is a direct listener like conflict-markers rather than a retarget-called target: its verdict depends on the base, and the branch filter is evaluated against the new base, so taking `edited` is what checks a PR moved onto live-docs before its next push. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> --------- Co-authored-by: Matt Hill <9935159+MattDHill@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 4 天前 |