Overview

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Failed
36465
aa42ab0b fix(core): prune worktrees for the output watcher and for worktrees added later Two gaps let a linked worktree's directories back into the daemon. The walker only resolved worktrees when `use_ignores` was set, on the grounds that the `use_ignores: false` caller expands cache outputs and never sees one. There is a second such caller: `watchOutputFiles` in daemon/server/watcher.ts builds a Watcher over the workspace root with `use_ignore` false, and on Linux every directory that walk yields costs a non-recursive inotify descriptor - including every directory inside every nested worktree, and inside the gitignored trees that `standard_filters(false)` also stops skipping. Hitting MaxFilesWatch is fatal there, so this is the exact failure the prune exists to prevent. Resolution costs a handful of syscalls and nothing per entry when the repository has no worktrees, so the gate is gone. The filterer's worktree list was a boot-time snapshot, and the compensating check in new_directories_from_event is compiled only off macOS - which is the platform that watches the root recursively. So `git worktree add` against a running daemon, the workflow this change exists for, flooded the pipeline with a whole new checkout until the daemon restarted. The watcher now picks a new worktree up from the event stream: git writes the checkout's `.git` gitfile before populating the tree, so tracking it there keeps the rest out. It runs on every platform, which also covers the race where the directory event arrives before its gitfile. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LsFgrnFJPfpqf9X7qfAXtW
by Craigory C...
Succeeded
36465
8501d0c5 fix(core): resolve the main worktree root without shelling out to git get_main_worktree_root duplicated worktree detection: it re-derived the git common dir by running `git rev-parse --git-common-dir`, while the walker reads git's own metadata. Point it at the shared gitfile helpers so there is one implementation, and so resolving a cache directory no longer depends on a git binary being on PATH. Verified to return the same root as `git rev-parse --git-common-dir` for a real worktree. Two fixes fall out of it: A submodule also replaces `.git` with a gitfile, so it was treated as a worktree and resolved to a "main root" of <superproject>/.git/modules/<..> - putting a submodule workspace's cache and workspace-data inside the superproject's git directory. Only a gitfile pointing into <git-dir>/worktrees/ is a worktree, so a submodule now keeps its own. The memoized root was a OnceLock initialized from the first caller's workspace_root and returned for every later call regardless of the argument. It is now keyed by workspace root. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011kgSn1ebFhZyguoKS5eeBs
by Claude
Failed
36465
Environment issue→
836287fa fix(core): resolve the main worktree root without shelling out to git get_main_worktree_root duplicated worktree detection: it re-derived the git common dir by running `git rev-parse --git-common-dir`, while the walker reads git's own metadata. Point it at the shared gitfile helpers so there is one implementation, and so resolving a cache directory no longer depends on a git binary being on PATH. Verified to return the same root as `git rev-parse --git-common-dir` for a real worktree. Two fixes fall out of it: A submodule also replaces `.git` with a gitfile, so it was treated as a worktree and resolved to a "main root" of <superproject>/.git/modules/<..> - putting a submodule workspace's cache and workspace-data inside the superproject's git directory. Only a gitfile pointing into <git-dir>/worktrees/ is a worktree, so a submodule now keeps its own. The memoized root was a OnceLock initialized from the first caller's workspace_root and returned for every later call regardless of the argument. It is now keyed by workspace root. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011kgSn1ebFhZyguoKS5eeBs
by Claude
Succeeded
36465
3fd11b2e fix(core): keep linked worktree events out of the watcher Pruning the walk keeps a worktree's directories out of the initial watch registration on Linux and Windows, but macOS watches the workspace root recursively - nothing stopped those events. Resolve the worktrees when the watcher boots and hand them to the filterer, which matches them as path prefixes rather than compiling them into its synthetic gitignore, so a worktree path containing gitignore metacharacters cannot build a bad pattern or fail the watcher's construction. The boot-time list cannot describe a worktree created later, which is the common case while a daemon is running. On Linux and Windows new directories are registered from watch events, so check there whether the directory is itself a worktree root - its gitfile points into <git-dir>/worktrees/ rather than <git-dir>/modules/, which is what separates a worktree from a submodule. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011kgSn1ebFhZyguoKS5eeBs
by Claude
Failed
36465
Flaky task→
ddeed299 fix(core): prune git linked worktrees from workspace walks A linked worktree created inside the workspace (`git worktree add`, and the `.claude/worktrees` directory agent tooling uses) is a full second checkout of the repository. Nx walks it like any other directory, so the project graph hashes the whole workspace twice and the daemon registers watches for every directory in it. Git already records every linked worktree under <git-dir>/worktrees/<name>, so read that rather than probing the workspace: one read_dir plus a small file per worktree, no subprocess, and O(worktrees) rather than O(directories). The list is resolved per walk, so worktrees created while the daemon runs are picked up. Submodules use the same gitfile mechanism but are registered under <git-dir>/modules/, so they are untouched and keep being scanned. A registration whose worktree was deleted by hand is skipped, so an ordinary directory later created at that path does not silently vanish from the graph. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011kgSn1ebFhZyguoKS5eeBs
by Claude
Canceled
36465
ddeed299 fix(core): prune git linked worktrees from workspace walks A linked worktree created inside the workspace (`git worktree add`, and the `.claude/worktrees` directory agent tooling uses) is a full second checkout of the repository. Nx walks it like any other directory, so the project graph hashes the whole workspace twice and the daemon registers watches for every directory in it. Git already records every linked worktree under <git-dir>/worktrees/<name>, so read that rather than probing the workspace: one read_dir plus a small file per worktree, no subprocess, and O(worktrees) rather than O(directories). The list is resolved per walk, so worktrees created while the daemon runs are picked up. Submodules use the same gitfile mechanism but are registered under <git-dir>/modules/, so they are untouched and keep being scanned. A registration whose worktree was deleted by hand is skipped, so an ordinary directory later created at that path does not silently vanish from the graph. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_011kgSn1ebFhZyguoKS5eeBs
by Claude