| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix(ci): alpha apt publish collects artifact directories as debs (#3744) fix(ci): publish only regular files to the apt suite `gh run download` extracts each artifact into a directory named after the artifact, and start-cli/start-tunnel/start-registry name theirs `<product>_<arch>.deb`. The collection find matched those directories, so dpkg-deb was handed one and aborted every alpha publish. | 30 天前 | |
fix(ci): unbreak package builds on fork PRs (#3568) `build.yml` writes the identity key one of two ways: from the `DEV_KEY` secret, or — when there is no secret — by generating one with `start-cli init-key`. Fork PRs get no secrets, so they take the second path. Since start-cli 1.1.0 renamed `developer.key.pem` to `id.key.pem`, `init-key` now writes the new name while the next step still copied the old one: cp: cannot stat '/home/runner/.startos/developer.key.pem': No such file Error: Process completed with exit code 1 The job dies before it builds anything, so every fork PR against every `*-startos` package repo fails its build check. The secret path kept working only because start-cli renames a legacy key file when it loads one, which papered over the mismatch wherever both files existed. Use the current names in this step: write the secret to `id.key.pem`, and provision the workspace key as `.startos/build.key.pem` — the name `s9pk init-workspace` creates and `s9pk pack` looks for. Other call sites (`release.yml`, `start-wrt.yaml`, `startos-iso.yaml`, `s9pk.mk`) still use the pre-1.1.0 names. They work today via that same legacy-rename shim and are deliberately left alone; they belong with whoever removes the shim. Co-authored-by: Matt Hill <9935159+MattDHill@users.noreply.github.com> | 1 个月前 | |
fix(ci): re-check a pull request when its base branch moves (#3836) * fix(ci): re-check a pull request when its base branch moves Changing a pull request's base fires the `edited` activity type, which none of these workflows listened for, and it does not move the head SHA — so no run was created and the checks computed against the old base stood as the verdict. Every conclusion here is base-derived: `actions/checkout` defaults to the merge ref on a pull request, and `conflict-markers.yml` diffs `"$BASE"...HEAD` outright. `edited` also fires on every title and body edit, which nothing here needs to recompute, so the root job of each heavy workflow takes an `edited` event only when `github.event.changes.base` is present. Guarding the root job is enough: the jobs downstream reach it through `needs` and skip with it. Conflict Markers is left ungated, being one checkout and one grep. Measured on a scratch repo carrying these job shapes. Opening the pull request ran all four checks. Retitling it skipped `Prettier`, `Detect non-docs changes` and — through the needs chain — `Run Automated Tests`, while Conflict Markers re-ran and stayed green. Retargeting the base ran all four again, with `github.event.changes.base.ref.from` holding the old branch and the payload's `base.ref` already the new one. * fix(ci): keep a no-op edited run out of the real run's concurrency group An `edited` event that leaves the base alone skips every job, but the run is still created and takes the workflow's concurrency slot, so it cancelled the build that was already running and left the pull request with no result that any push would restore. Give that run its own group. Test the base change by presence rather than comparing `changes.base.ref.from` against the empty string, which only worked through Actions' numeric coercion of null, and which the comment above it already described as a presence test. Register the types/guard/concurrency trio in AGENTS.md "Coupled changes": a workflow carrying one without the others is broken rather than noisy. * fix(ci): route pull request retarget checks Route base-edit events through an unfiltered caller so every base-sensitive workflow reruns even when the new base or changed paths miss its direct trigger filters. Use the PR-numbered pull_request_target job itself for mergeability, polling only trusted API data and cancelling stale runs without checking out pull request code. Keep textual marker scanning independent, and structurally lock the explicit workflow sets, permissions, concurrency, and event routing. | 16 天前 | |
ci: retire the docs VPS (#3993) docs.start9.com and marketplace.start9.com now resolve to evelyn, so the rsync-and-reload-nginx halves of docs-deploy.yml and deploy-brochure.yml go, along with the deploy key they used. docs-deploy.yml publishes to Start9 Pages itself instead. That copy reaches live-docs only with the next product tag, and until then the copy there still rsyncs to a box that is going away. So the publisher on master keeps running in the meantime: it now follows every docs-deploy run rather than only the successful ones — its own build is the gate — and stands down the moment the live-docs copy of docs-deploy.yml publishes for itself. After that it can be deleted. versions.conf and the start-docs docs stop describing nginx maps; the routing they drove is what build.sh writes into the tree now. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 天前 | |
ci: retire the docs VPS (#3993) docs.start9.com and marketplace.start9.com now resolve to evelyn, so the rsync-and-reload-nginx halves of docs-deploy.yml and deploy-brochure.yml go, along with the deploy key they used. docs-deploy.yml publishes to Start9 Pages itself instead. That copy reaches live-docs only with the next product tag, and until then the copy there still rsyncs to a box that is going away. So the publisher on master keeps running in the meantime: it now follows every docs-deploy run rather than only the successful ones — its own build is the gate — and stands down the moment the live-docs copy of docs-deploy.yml publishes for itself. After that it can be deleted. versions.conf and the start-docs docs stop describing nginx maps; the routing they drove is what build.sh writes into the tree now. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 天前 | |
feat(ci): publish the brochure and the docs to Start9 Pages (#3985) Two more of the VPS's sites now also land in the NextExplorer folders Start9 Pages serves on evelyn, ahead of moving their DNS: the brochure from its own deploy, and the docs from a new workflow that follows every successful "Build and deploy docs" run, checks live-docs out and rebuilds it, because a pull request to live-docs may not carry workflow files and the next tag is not a schedule to wait on. The VPS steps stay until DNS moves. Each site's bundle is made by one command that a workflow only calls: `npm run build:brochure` and `npm run build:wrt:demo` (config from the sample, mocks on, stamped) both double index.html as 404.html, which is how a static host boots the SPA on a deep link. A bundle built on a laptop and dropped into NextExplorer is therefore the same site. The publish action learns two things the docs need. A folder path may be nested (docs.start9.com/0.3.5.x), so the retired Sphinx site — 293 MB that no repo builds — can be seeded by hand where the old nginx served it. And `keep` names entries of the folder's previous contents to carry across the swap: they are server-side copied into the staging folder before the renames, a copy rather than a move so the live folder holds them until the swap lands, and a run that died between its two renames is repaired at the start of the next one by putting .old back. Verified against nxzai/explorer:v2.2.7 locally: a first publish with nothing to keep, a nested seed, a replacing publish that keeps it, the mid-swap recovery, and a kept entry colliding with published content. Both build commands run locally and yield the 404.html. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 天前 | |
docs: backport live-docs a0a5ca0e9 to master Backports the following from live-docs: - a0a5ca0e9 fix(ci): build the backport payload off disk, not off argv (#3751) | 1 个月前 | |
ci: retire the docs VPS (#3993) docs.start9.com and marketplace.start9.com now resolve to evelyn, so the rsync-and-reload-nginx halves of docs-deploy.yml and deploy-brochure.yml go, along with the deploy key they used. docs-deploy.yml publishes to Start9 Pages itself instead. That copy reaches live-docs only with the next product tag, and until then the copy there still rsyncs to a box that is going away. So the publisher on master keeps running in the meantime: it now follows every docs-deploy run rather than only the successful ones — its own build is the gate — and stands down the moment the live-docs copy of docs-deploy.yml publishes for itself. After that it can be deleted. versions.conf and the start-docs docs stop describing nginx maps; the routing they drove is what build.sh writes into the tree now. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 天前 | |
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> | 16 天前 | |
chore(github): park gated issues on the triage owner (#3957) A gated issue needs someone to supply its type and label, which is triage, not ownership. MattDHill does that; the product owner gets the issue once it can be routed. 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> | 16 天前 | |
fix(ci): re-check a pull request when its base branch moves (#3836) * fix(ci): re-check a pull request when its base branch moves Changing a pull request's base fires the `edited` activity type, which none of these workflows listened for, and it does not move the head SHA — so no run was created and the checks computed against the old base stood as the verdict. Every conclusion here is base-derived: `actions/checkout` defaults to the merge ref on a pull request, and `conflict-markers.yml` diffs `"$BASE"...HEAD` outright. `edited` also fires on every title and body edit, which nothing here needs to recompute, so the root job of each heavy workflow takes an `edited` event only when `github.event.changes.base` is present. Guarding the root job is enough: the jobs downstream reach it through `needs` and skip with it. Conflict Markers is left ungated, being one checkout and one grep. Measured on a scratch repo carrying these job shapes. Opening the pull request ran all four checks. Retitling it skipped `Prettier`, `Detect non-docs changes` and — through the needs chain — `Run Automated Tests`, while Conflict Markers re-ran and stayed green. Retargeting the base ran all four again, with `github.event.changes.base.ref.from` holding the old branch and the payload's `base.ref` already the new one. * fix(ci): keep a no-op edited run out of the real run's concurrency group An `edited` event that leaves the base alone skips every job, but the run is still created and takes the workflow's concurrency slot, so it cancelled the build that was already running and left the pull request with no result that any push would restore. Give that run its own group. Test the base change by presence rather than comparing `changes.base.ref.from` against the empty string, which only worked through Actions' numeric coercion of null, and which the comment above it already described as a presence test. Register the types/guard/concurrency trio in AGENTS.md "Coupled changes": a workflow carrying one without the others is broken rather than noisy. * fix(ci): route pull request retarget checks Route base-edit events through an unfiltered caller so every base-sensitive workflow reruns even when the new base or changed paths miss its direct trigger filters. Use the PR-numbered pull_request_target job itself for mergeability, polling only trusted API data and cancelling stale runs without checking out pull request code. Keep textual marker scanning independent, and structurally lock the explicit workflow sets, permissions, concurrency, and event routing. | 16 天前 | |
fix(ci): re-check a pull request when its base branch moves (#3836) * fix(ci): re-check a pull request when its base branch moves Changing a pull request's base fires the `edited` activity type, which none of these workflows listened for, and it does not move the head SHA — so no run was created and the checks computed against the old base stood as the verdict. Every conclusion here is base-derived: `actions/checkout` defaults to the merge ref on a pull request, and `conflict-markers.yml` diffs `"$BASE"...HEAD` outright. `edited` also fires on every title and body edit, which nothing here needs to recompute, so the root job of each heavy workflow takes an `edited` event only when `github.event.changes.base` is present. Guarding the root job is enough: the jobs downstream reach it through `needs` and skip with it. Conflict Markers is left ungated, being one checkout and one grep. Measured on a scratch repo carrying these job shapes. Opening the pull request ran all four checks. Retitling it skipped `Prettier`, `Detect non-docs changes` and — through the needs chain — `Run Automated Tests`, while Conflict Markers re-ran and stayed green. Retargeting the base ran all four again, with `github.event.changes.base.ref.from` holding the old branch and the payload's `base.ref` already the new one. * fix(ci): keep a no-op edited run out of the real run's concurrency group An `edited` event that leaves the base alone skips every job, but the run is still created and takes the workflow's concurrency slot, so it cancelled the build that was already running and left the pull request with no result that any push would restore. Give that run its own group. Test the base change by presence rather than comparing `changes.base.ref.from` against the empty string, which only worked through Actions' numeric coercion of null, and which the comment above it already described as a presence test. Register the types/guard/concurrency trio in AGENTS.md "Coupled changes": a workflow carrying one without the others is broken rather than noisy. * fix(ci): route pull request retarget checks Route base-edit events through an unfiltered caller so every base-sensitive workflow reruns even when the new base or changed paths miss its direct trigger filters. Use the PR-numbered pull_request_target job itself for mergeability, polling only trusted API data and cancelling stale runs without checking out pull request code. Keep textual marker scanning independent, and structurally lock the explicit workflow sets, permissions, concurrency, and event routing. | 16 天前 | |
fix(ci): read release notes from en_US, not the never-matching en-US The reusable package release workflow builds the GitHub-release body from `.releaseNotes | .["en-US"] // first(.[])`. StartOS locale keys are underscore-separated — `LocaleString::localize_for` splits on `_`, and every package, the SDK's i18n scaffold, and the package template all key on `en_US` — so the `en-US` lookup never matches and the expression always falls through to `first(.[])`: whichever locale the packager happened to write first in `releaseNotes`. That is the first key in serialization order, not a language choice. The manifest's map is insertion-ordered, so it works by convention today (packages write `en_US` first, following the template) and silently ships the wrong language the moment one doesn't: $ echo '{"releaseNotes":{"de_DE":"GERMAN","en_US":"ENGLISH"}}' \ | jq -r '.releaseNotes | (.["en-US"] // first(.[]))' GERMAN `first(.[])` stays as the fallback for a package with no `en_US` at all, and the `type == "object"` guard still passes a legacy plain-string `releaseNotes` through untouched. | 1 个月前 | |
fix(repo): publish release-note commits to alpha (#3929) Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol | 8 天前 | |
fix(repo): publish release-note commits to alpha (#3929) Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol | 8 天前 | |
fix(repo): publish release-note commits to alpha (#3929) Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol | 8 天前 | |
fix(repo): publish release-note commits to alpha (#3929) Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol | 8 天前 | |
feat(startos): welcome a server with the release notes it updated to (#3927) * feat(startos): welcome a server with the release notes it updated to post_init raises one notification for the version just landed on, carrying the release-notes file the GitHub release and the update screen are composed from, with the changelog link appended. The file is included by name, so a version bump without its notes fails the build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol * fix(startos): rebuild on a notes edit, translate the welcome strings The notes file is compiled in, so it belongs in the StartOS build prerequisites and in the workflow path filters, which excluded all markdown — a corrected file otherwise left the binary carrying the old text while the release and registry showed the correction. Addresses helix-nine's review on #3927. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol * fix(startos): quote the buttons and the page the UI actually shows Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol * refactor(startos): package release notes outside binary Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Co-authored-by: Helix <267227783+helix-nine@users.noreply.github.com> | 4 天前 | |
ci: head the sync-next conflict PR with a scratch branch (#3726) Co-authored-by: Matt Hill <9935159+MattDHill@users.noreply.github.com> | 1 个月前 | |
chore(fmt): normalize formatting — one config per language, reproducible rustfmt (#3437) * chore(fmt): one config per language + reproducible rustfmt Our rustfmt.toml uses nightly-only options (group_imports, imports_granularity) but nothing pinned the nightly, so output drifted between contributors — and CI never even checked Rust formatting. Configs were also duplicated and partial. Consolidate to one config per language and make the output reproducible: - rustfmt: single root rustfmt.toml (was 5 duplicate copies + ~14 crates with none). Runs in start9/fmt-env — start9/cargo-zigbuild (the same image the Rust build uses) plus the pinned nightly + rustfmt component (build/fmt/fmtenv.Dockerfile) — via build/fmt/run-fmt.sh, which runs it --user so output stays host-owned. FMT_NATIVE=1 runs on the host against the same pinned toolchain (read from the Dockerfile ARG — one source of truth for the version). - prettier: single root .prettierrc.json (was 3-4 drifted copies, incl. container-runtime on double quotes). One repo-wide pass with a hardened .prettierignore (excludes .sqlx cache, the generated exver.ts parser, conformance vectors, locales, snapshots/fixtures, proxy.pac, patch-db/client). - taplo: single root taplo.toml over all TOML (was one stray copy), pinned via @taplo/cli. Only rustfmt needs the container; prettier and taplo run natively. - CI `make format-check` now covers rustfmt (previously unchecked) + taplo. - Remove the dead husky v4 / lint-staged pre-commit hook (no lint-staged config existed). Per-project `<project>-format` targets are kept (routed through the same tools/config). The formatting content itself lands in the next commit. * style: apply repo-wide formatting Mechanical output of `make format` using the configs from the previous commit (rustfmt in the pinned-nightly container, prettier and taplo). No behavior changes. * chore: ignore the repo-wide reformat in git blame | 2 个月前 | |
fix(ci): check live-docs pull request formatting (#3973) * fix(ci): check live-docs pull request formatting Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol * fix(ci): limit live-docs checks to formatting Helix-Harness: pi Helix-Model: openai-codex/gpt-5.6-sol | 2 天前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 30 天前 | ||
| 1 个月前 | ||
| 16 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 1 天前 | ||
| 1 个月前 | ||
| 1 天前 | ||
| 16 天前 | ||
| 4 天前 | ||
| 16 天前 | ||
| 16 天前 | ||
| 16 天前 | ||
| 1 个月前 | ||
| 8 天前 | ||
| 8 天前 | ||
| 8 天前 | ||
| 8 天前 | ||
| 4 天前 | ||
| 1 个月前 | ||
| 2 个月前 | ||
| 2 天前 |