v0.8.17: ci improvements, outdated docs i18n removal, desktop improvements - #7273
Merged
Conversation
The docs shipped `es`, `fr`, `de`, `ja`, and `zh` alongside `en` through fumadocs i18n and a lingo.dev translation pipeline. Neither is used any more, so this removes the locale layer end to end rather than leaving a vestigial `en` directory behind it. - Delete the five translated content trees (995 files) and flatten `content/docs/en/**` up to `content/docs/**`. - Delete `lib/i18n.ts`, `i18n.json`, `i18n.lock`, and the `i18n.cache` gitignore entry; drop `createI18nMiddleware` from `proxy.ts` and the `i18n` option from the source loader. - Collapse `app/[lang]/**` into `app/**`, merging the locale layout's html/body shell into the root layout. The OpenAPI virtual pages moved off `baseDir: 'en/api-reference/(generated)'`, which was the `en` segment the dir parser used to consume. - Strip locale branching from the sitemap, `llms.txt`, `llms-full.txt`, the `llms.mdx` route, the sidebar's active-path matching, structured data, and the hreflang/`alternateLocale` metadata. - Simplify the search route to English-only: one `english` text-search config, unconditional vector search, and no locale-prefix filtering of `sourceDocument`. The docs-embeddings job already runs with `--clear`, so the now-unprefixed paths are rewritten on the next run. - Repoint every script, test, and the CI path filter at `content/docs`, and de-loop the API-reference sidebar checks over the six locales. The execution-guide wire-shape test covered only the removed locales; it is retargeted at the English guides, which already satisfy it. `check:audits` (39 audits), the docs build (666 paths), the docs and OpenAPI suites, and the netsuite docs-path test all pass.
The max-cache-size-mb input added in 8fa7f0c never did anything. setup-docker-builder v1 accepted it and pruned in its own post step, but the v2 rewrite dropped the input, and the repo pins v2.1.0. GitHub only WARNS on an unknown composite input, so every build since has logged Unexpected input(s) 'max-cache-size-mb', valid inputs are ['cache-key', ...] and pruned nothing. Scanned every tag to confirm: the input exists in v1.8.0 through v1.12.0 and in none of v2.0.0, v2.0.1, v2.1.0. Rather than downgrade a builder rewrite to reach a config knob, run the prune ourselves — v1's command verbatim, against the fixed address v2 itself uses for `buildctl du` and `debug workers`: sudo buildctl --addr tcp://127.0.0.1:1234 prune --all --keep-storage <MB> Both flags read from BuildKit master rather than assumed. buildctl's --all is not `docker buildx prune --all`: it means "include internal/frontend references", and cache/manager.go shows the only records skipped without it are those typed internal or frontend plus refs shared with an external source. It does not wipe the cache. --keep-storage maps onto the modern MaxUsedSpace field, so it is buildctl's spelling of --max-used-space, not a deprecated alias, and it is the only size flag buildctl exposes. Two guards, both for failure modes that are silent and expensive: Reject a non-positive-integer budget. buildctl parses --keep-storage as a float, and BuildKit treats keepBytes==0 as "no cap" (`gcMode := opt.keepBytes != 0`), pruning everything eligible instead of trimming. A typo like '40GB' — valid in turbo.json, but this flag is a bare MB number — would empty the cache and make every later build cold, costing far more than the storage saved. Wait for `du` to settle after pruning. buildctl prune returns before buildkitd has finished deleting (moby/buildkit#1198), and the builder's post step SIGTERMs buildkitd then SIGKILLs it after 30s (shutdownBuildkitd: `const a=3e4`); on SIGKILL it sets sigkillUsed and skips the sticky disk commit outright, discarding the run's cache and risking a corrupt bbolt metadata DB. The wait is bounded, and a steady-state trim settles almost immediately — it is the first catch-up prune against a 200 GB backlog that would otherwise run into that window. Warn rather than fail throughout, since an oversized cache is not worth failing a deploy over — but print `buildctl du` either side, because a silent no-op is exactly the failure mode that hid this regression for a day.
…7252) The settle loop added in 4f65103 reads `cur="$(total)"`, and composite steps run under `bash -e -o pipefail`, where an assignment takes its command substitution's exit status. So any failing `buildctl du` aborts the step and fails the build. `echo "$(total)"` survives the same failure, which is why this was invisible in the paths that ran first. That is not hypothetical. Deleting a sticky disk out from under a running job makes buildkitd panic inside cache.(*cacheManager).DiskUsage, and it took a Build AMD64 job down that way. `grep` also exits 1 whenever du prints no Total line, so an empty cache would have done it too. A cache-hygiene step must never be able to fail a deploy, so `total()` now always returns 0. The prune's own failure was already handled — it is an `if` condition, and a failing condition does not trip `-e`.
…-examples (#7250) * docs(library): update what-is-an-ai-agent-definition-how-it-works-and-examples * fix(library): remove markdown from FAQ answer --------- Co-authored-by: Sim Pi Agent <pi@sim.ai> Co-authored-by: Waleed Latif <walif6@gmail.com>
* docs(library): update automation-anywhere-alternative * fix(library): canonicalize overlapping RPA article --------- Co-authored-by: Sim Pi Agent <pi@sim.ai> Co-authored-by: Waleed Latif <walif6@gmail.com>
* fix(connectors): stop hydration after rate limits * fix(connectors): normalize provider throttles * fix(connectors): inspect all drive error reasons
…ny (#7270) These two harnesses are the template every service copied when the path hardening sweep began, and both open with `type AnyTool = ToolConfig<any, any>` plus an `as any` at the `url(...)` call. CLAUDE.md forbids `any` outright, and because they are the template the violation propagated into ten in-flight PRs before review flagged it. Fixing the source stops the next copy inheriting it. The obvious repair does not compile. `ToolConfig` takes its param type in the contravariant position of `request.url`, so no concrete member of the barrel's union is assignable to a widened `ToolConfig<Record<string, unknown>, ...>`, and `filter`'s type-predicate overload intersects rather than replaces -- filtering the union directly leaves the mismatch standing. Seeding the enumeration as `Object.values<unknown>(...)` makes the existing `isVercelTool` / `isDaytonaTool` predicate the single narrowing point, which is the `unknown`-plus-type-guard form the guidelines actually ask for, and removes the need for a cast at the call site. Note these files have no type coverage in CI from either direction: `apps/sim/tsconfig.json` excludes `**/*.test.ts`, and vitest does not typecheck. Verified with a temporary tsconfig lifting the exclusion, confirming via `--listFiles` that both files were genuinely in the program -- an empty program also reports zero errors. That config was not committed. Behaviour is unchanged: 1129 tests pass, identical to before.
* fix(browser): harden desktop tool lifecycle * fix(browser): preserve screenshot coordinate contract * fix(browser): close native execution races * fix(browser): reconcile native unload claims * fix(copilot): interrupt pending tool waits on stop
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Contributor
|
Too many files changed for review (1557 files, 100 file limit). |
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
There was a problem hiding this comment.
All reported issues were addressed across 1557 files
Note: This PR contains a large number of files. cubic selects up to 200 of the highest-priority eligible files for this review, so some files may not have been reviewed.
Tip: instead of fixing issues one by one fix them all with cubic
Re-trigger cubic
6 tasks
) The settle loop initialised prev='' and, after 4795d04 made total() return empty on failure, two consecutive failed `buildctl du` reads compared equal and tripped the stability counter. The loop then exited after ~2s instead of its 120s bound — exactly when du is failing and the prune is most likely still deleting, which is the case the wait exists to cover. Handing back early there risks the builder post-step SIGKILLing buildkitd and skipping the sticky disk commit. An empty reading can only mean du failed. buildctl prints its `Total:` line unconditionally (cmd/buildctl/diskusage.go), so an empty cache still reports `Total: 0B` and settles normally. Guarding on a non-empty reading therefore costs nothing in the healthy paths: verified a steady value and an empty cache both still exit after 3 iterations, while a persistently failing du now waits out all 60. Reported by cubic on #7273.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.