Repository navigation
Conversation
|
Important Review skippedWe couldn't safely recover the incremental review. No full review was started, and the last reviewed checkpoint was preserved. Retry later, or explicitly request a full review by commenting You can disable this status message by setting the Use the checkbox below for a quick retry:
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the
Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
No actionable comments were generated in the recent review. ℹ️ Recent review info
Walkthrough
Priority: Merge Risk:
|
fde6b7b to
8c4e9e3
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to GitHub limitations.
🟡 Minor · Use the repository routing connection ID for the known-host probe. · gitlab.ts:39-42
src/main/ipc/gitlab.ts:39-42
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winUse the repository routing connection ID for the known-host probe.
The reachable desktop
gitlab:knownHostshandler passesrepoConnectionId(repo), which ignores anexecutionHostIdrouting target. For a self-hosted GitLab repository, the probe can use the wrong execution context and omit the host known in the actual context. Provider matching then keeps the repository in the GitHub query instead of skipping it, which causes a cross-forge lookup failure.Suggested fix
import type { GitLabRepoSelectorArgs } from './gitlab-repo-access' +import { getRepoRoutingConnectionId } from '../../shared/execution-host' import { assertRegisteredRepo, hostedReviewOptionArgs, localGitOptionArgs, repoConnectionId @@ - return getGlabKnownHosts(repoConnectionId(repo), ...localGitOptionArgs(store, repo)) + return getGlabKnownHosts(getRepoRoutingConnectionId(repo), ...localGitOptionArgs(store, repo))
🟡 Minor · Scope availability notices to each provider’s… · use-task-page-source-summary.ts:69-92
src/renderer/src/components/use-task-page-source-summary.ts:69-92
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winScope availability notices to each provider’s repositories.
After mixed GitHub/GitLab selections, these notices still derive contexts and counts from
selectedRepos.getTaskPageRepoSourceContextcreates a context for the requested provider even for an opposite-forge repository. Therefore, an unavailable GitLab host can affect the GitHub notice, and an unavailable GitHub host can affect the GitLab notice. The total count can also mark all actual GitHub sources as only partially unavailable, leaving the GitHub button enabled.Use
githubTaskReposandgitlabTaskReposfor their respective notices.Suggested fix
selectedRepos, githubTaskRepos, + gitlabTaskRepos, @@ - sourceCount: selectedRepos.length, + sourceCount: githubTaskRepos.length, hostLabelById, hostAvailability: availabilityForContexts( 'github', - selectedRepos + githubTaskRepos .map((repo) => getTaskPageRepoSourceContext(repo, 'github')) .filter((context): context is TaskSourceContext => context !== null) @@ - sourceCount: selectedRepos.length, + sourceCount: gitlabTaskRepos.length, hostLabelById, hostAvailability: availabilityForContexts( 'gitlab', - selectedRepos + gitlabTaskRepos .map((repo) => getTaskPageRepoSourceContext(repo, 'gitlab')) .filter((context): context is TaskSourceContext => context !== null)
🟡 Minor · Scope the GitLab dialog fallback to GitLab repositories. · use-task-page-github-detail.ts:127-145
src/renderer/src/components/use-task-page-github-detail.ts:127-145
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winScope the GitLab dialog fallback to GitLab repositories.
When the stamped item has no matching selected row,
primaryRepocan be a GitHub repository. The dialog then sends that repository path and execution host to the GitLab detail request. UsegitlabPrimaryRepoas the fallback.Suggested fix
selectedRepos, + gitlabPrimaryRepo, githubTaskRepos, primaryRepo, @@ - gitlabDialogItem ? (getWorkItemRepo(selectedRepos, gitlabDialogItem) ?? primaryRepo) : null, - [gitlabDialogItem, primaryRepo, selectedRepos] + gitlabDialogItem + ? (getWorkItemRepo(selectedRepos, gitlabDialogItem) ?? gitlabPrimaryRepo) + : null, + [gitlabDialogItem, gitlabPrimaryRepo, selectedRepos]
ℹ️ Review info
⚙️ Run configuration
- Configuration used: Repository UI
- Review profile: CHILL
- Plan: Advanced
- Run ID:
14384d0d-043f-4568-8c30-ffefc49fe0f3
📥 Commits
Reviewing files that changed from the base of the PR and between fde6b7b1698fa23692ce5248a3daad0d7d930522 and 8c4e9e3468b8553e8bf49a0cb4676aa3cfd93da5.
⛔ Files ignored due to path filters: 1
src/shared/rpc-contract/rpc-params-catalog.generated.tsis excluded by!**/*.generated.*
📒 Files selected for processing: 2
src/main/runtime/runtime-gitlab-query-commands.tssrc/renderer/src/components/task-page/github/Filters.tsx
Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.
8c4e9e3 to
826b803
Compare
d31e35f to
b82b08f
Compare
…g them The Tasks page shares one project selection across GitHub, GitLab, Linear and Jira. With a mixed selection the GitHub source tried to resolve every GitLab project and listed each as "No GitHub source detected" with a Retry that could never succeed, and the GitLab source ran a cwd-inferred `glab mr list` against GitHub projects. Each repo-backed source now narrows the selection before it queries anything, using the remote identity Orca already stores. A repo whose origin is known to be on the other forge is never queried, never counted as failed, and is listed in one collapsed row without Retry. A self-hosted GitLab origin is recognized through glab's known hosts, exposed as gitlab.knownHosts and gated by a runtime capability for older servers. Repos Orca cannot place keep the existing resolve-and-retry path. The GitLab project-ref parser moves to src/shared so the renderer can reuse it; the CLI now loads it from out/shared like other shared modules. Fixes stablyai#15784 Refs stablyai#16473 Refs stablyai#13817 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
b82b08f to
c9eae38
Compare
|
Closing in favor of #34219, which landed the provider-boundary version of this fix (thanks again for the credit there). Two pieces of this PR are not covered by #34219 and still show up in #15784: a user-visible "Skipped — hosted on GitHub/GitLab (n)" row instead of a silent empty result, and the same skip for repos on remote hosts ( |
ELI5
The Tasks page uses one project picker for GitHub, GitLab, Linear and Jira. If you pick both GitHub and GitLab projects, the GitHub tab used to try every GitLab project and list each one as "No GitHub source detected" with a Retry button that could never work, and the GitLab tab ran
glabagainst GitHub projects. Now each tab quietly sets aside the projects that clearly live on the other service, shows them in one folded line, and never asks GitHub or GitLab about them.What Changed
Before
glab. On the MR view a local GitHub repo fell through to a cwd-inferredglab mr list, which fails with "None of the git remotes configured for this repository point to a known GitLab host" (the error in [Bug]: Shared project filter in Tasks generates errors #15784). GitLab Todos used whichever project was selected first, even a GitHub one.After
originis known to be on the other forge is not queried, not counted as failed, and is listed in a single collapsed row — "Skipped — hosted on GitLab (N)" / "Skipped — hosted on GitHub (N)" — that expands to the project names. No Retry, since a retry cannot change the answer.origin/upstream) keep today's resolve-and-Retry behaviour — nothing is hidden silently.Mechanism
src/shared/task-source-repo-host-match.ts: a purematch | mismatch | unknownverdict per repo and source, built only from what Orca already stores —gitRemoteIdentity, plus GitHub fork metadata and the GitHub avatar, which are both read from origin. It reuses the existing parsers:getProjectProviderIdentityfor GitHub hosts (github.com,ssh.github.com, GHES-named hosts) and the GitLab project-ref parser with glab's known hosts (port-aware) for GitLab.mismatchneeds the origin to be on the other forge.gitRemoteIdentitykeeps only one remote andupstreamoutranksorigin, while both resolvers also readorigin; so a storedupstreamcan only prove a match, never a mismatch. Conflicting signals (for example, a stale GitHub avatar on a repo now on GitLab) resolve to "query it", never to "skip it".gl.knownHosts/gitlab.knownHostsreturns the cachedgetGlabKnownHosts()for the repo's own context. On a remote server it is gated by a newgitlab.knownHosts.v1capability; an older server is never asked and answersgitlab.comonly, so its self-hosted repos stayunknown(today's behaviour).useTaskPageSourceRepoScope, between the availability prelude and summary) derivesgithubTaskRepos/gitlabTaskReposand their keys; the GitHub fetch, count, cache, pagination and reconciliation hooks and the GitLab loader read those instead of the sharedselectedRepos.selectedRepositself is untouched, so Linear and Jira are unaffected.gitlab.comonly, so the repo staysunknown(queried as today) for the rest of the session.src/main/gitlabtosrc/sharedso the renderer can reuse it. The CLI already shippedout/shared/**, so its dedicated CLI main entry (out/main/gitlab/project-ref-parser.js) is removed from the build entries,asarUnpackand the CLI tsconfig.Why
gitRemoteIdentityis kept fresh by the existing enrichment sweep, so the decision costs no git or forge call for github.com / gitlab.com / GHES-named hosts.git.company.exampleis indistinguishable from a custom-named GHES by name. glab's known hosts are the same signal main already uses to resolve GitLab projects, so the renderer now asks main for them instead of inventing a heuristic.TaskPage; this PR narrows what each source queries and does not touchTaskPage), so they can land in either order. A persisted per-source selection would also change the saveddefaultRepoSelectionshape and need a migration; this PR changes nothing users have saved.gh auth status --hostnameprobe) per repo per load, and changes what the host publishes to older clients.Linked Issue
Fixes #15784
Refs #16473 — skipped projects no longer count toward "N of M projects failed", and permanently non-GitHub projects no longer get a Retry. The separate case where a repo is counted as failed without any rendered row is not addressed here.
Refs #13817 — a project is excluded from the GitLab source once its stored origin is known to be on GitHub. A move to a host neither CLI knows (the
10.x.x.xcase) still staysunknown, because "not a known GitLab host" is not proof the host is not GitLab (main may still discover it viaglab auth status --hostname).Related open PRs (all from outside contributors, none reviewed yet):
not_found. Overlaps on the GitLab side: this PR decides from the stored origin before any glab call and leaves hosts it cannot place on today's path, which is where anot_foundrule like fix(gitlab): soft-skip migrated non-GitLab projects in Tasks #13962's would still apply.task-page/github/List.tsx, so whichever lands second needs a small rebase.Visual Proof
Four projects selected together:
github-cloud(github.com),gitlab-cloud(gitlab.com),gitlab-self-hosted(a self-hosted GitLab that glab is signed in to) andunknown-host(a host neither CLI knows).GitHub tab — before: every project that is not on GitHub gets a "No GitHub source detected" row with a Retry that can never succeed.
GitHub tab — after: the two GitLab projects fold into one "Skipped — hosted on GitLab (2)" row;
unknown-hostkeeps today's row, because Orca cannot tell where it lives.GitHub tab — after, expanded:
GitLab tab — before: looks the same, but glab was run against the GitHub project (see the call log below).
GitLab tab — after: the GitHub project is listed as skipped and never reaches glab.
Dark mode
GitHub tab — before:
GitHub tab — after:
GitLab tab — before:
GitLab tab — after:
Captured from a background-launched e2e build (Playwright over CDP, isolated HOME;
upstream/mainfor Before, this branch for After), cropped to the top of the window.gh/glabwere stubbed so the capture is deterministic, and the stubs logged every call:glab auth status --hostname github.comand a cwd-inferredglab mr listfor the GitHub project. After, neither runs; the onlyglab mr listleft belongs to the unknown-host project, which still takes today's path by design.Testing
Automated:
src/shared/task-source-repo-host-match.test.ts— github.com /ssh.github.com/ gitlab.com / self-hosted GitLab via known hosts / ported hosts (only the known port matches) / unknown hosts / missing or unsettled identity / GHES by name and via avatar /upstream-only identities / fork metadata behind anupstreamremote / conflicting stale metadata / unexpanded SSH aliases.task-page-source-repo-scope.test.ts,use-task-page-source-repo-scope.test.tsx— skipped vs queried vs pending; glab is asked only about a self-hosted origin; a rejected lookup is queried and asked about again on the next visit; composed with the GitLab loader, glab never receives a GitHub-origin repo and the GitLab source never waits on glab hosts; twin rows of one project on a paired server that differ only by SSH target each ask their own glab.use-task-page-source-summary.test.ts— availability notices and the banner count only the repos each source actually queries;gitlab.test.ts— the IPC known-hosts probe routes to a row that names its SSH host only as its execution host.task-page-github-landing-refresh-run.test.ts(new) — gh receives only GitHub-source repos, so skipped repos can never count as failed; with every selected repo off GitHub, the previous rows are cleared without querying.knownHostsrouting (SSH connection, WSL distro, remote server) and the older-server fallback (asksstatus.getonly, answersgitlab.com).Manual: ran the branch with
pnpm devagainst my own mix of GitHub and GitLab projects selected together; the errors from #15784 no longer appear on either tab.Local checks (macOS, arm64, run on
upstream/main33e6785):pnpm typecheck✅pnpm lint✅ (run as CI does, before the mobile install)node config/scripts/check-changed-code-quality.mjs <upstream/main>, CI's "Enforce changed-code quality") ✅pnpm test --changed upstream/main(4,559 test files related to this change): every suite this PR adds or edits passes. 19 files failed: 15 of them fail the same way onupstream/main(the same 39 cases; mostly macOS/varvs/private/vartemp paths in agent-session and pty suites), and the other 4 pass when run on their own.pnpm build:build:desktop(typecheck, CLI, electron-vite, web, mobile web) ✅.build:nativestops in the macOS computer-use helper because Xcode 27 / Swift 6.4 writesswift buildproducts to.build/out/Products/Release/whilebuild-computer-macos.mjsexpects.build/<triple>/release/. This PR touches neither the helper nor its build script.upstream/mainb99552c (conflicts with fix(tasks): bound GitLab all-projects fan-out to avoid runtime queue overflow #30157, the per-area capability lists from refactor(protocol): each area owns its published runtime capability list #30641, the twin-host fixes in the task list such as fix(github): GitHub routing takes the caller's host for a twin; the task filters pass theirs #31263 and fix(tasks): GitLab items and project-view dialogs act on the twin host that returned them #31271, and the CLI typecheck change in build(cli): typecheck the CLI by following its imports, not a hand list #30632), re-ranpnpm typecheck,pnpm lint, the changed-code quality gate and the related test files (424 files, 3,688 tests) ✅. The full test run andpnpm buildabove were not repeated. After CodeRabbit's review, the IPC known-hosts probe uses the routing connection id, availability notices are scoped to each forge's repos, and the GitLab dialog falls back to a GitLab repo; typecheck, the quality gate and the related test files were re-run ✅.As a fork PR, CI waits for maintainer approval, so the checks above were run locally first.
Platforms: verified on macOS. Linux/Windows rely on the same renderer path and the existing per-context glab probe (WSL distro and SSH connection routing are covered by tests).
AI Disclosure
Implemented with Claude Code (Claude Opus 5.5), reviewed and directed by the author.
Review
AI coding agent review summary:
getGlabKnownHostsprobe, which already handles the WSL distro (allowDefaultWslFallback: false) and native contexts.gitlab.knownHosts.v1); older servers are never called and degrade to today's behaviour. No new fields in existing wire payloads. A project registered on several hosts (twin rows) is placed row by row: the known-hosts cache is keyed by host and connection, and the GitHub rows keep each twin's own host routing.selectedReposand account-backed contexts. CLI behaviour is unchanged; it now imports the parser fromout/shared.glab auth statusper context (at most 10 s) — once per session. The other repos load meanwhile; when the held repo is placed, the list re-runs for the new set, with each repo's items served from the existing 60 s cache and in-flight dedupe, and the per-repo counts requested again, as on any selection change.Collapsible+ ghostButton(size="xs") with tokens only (text-muted-foreground,border-border/50); the design-system lint gate passes. Copy states only facts the code has ("hosted on GitLab", decided from the stored origin). Checked in light and dark.assertRegisteredRepoguard (including the source-host check), and it returns only host names glab reports as signed in — never tokens.Agent skill upstream boundary
Notes
task-source-repo-host-match.ts(GitHub host rules via the existing projection helpers; GitLab via known hosts). Bitbucket/Azure/Gitea origins areunknownand keep today's behaviour (after the one-time wait for glab's hosts described under Performance).mobile/src/tasks/) builds its own repo list and queries every selected hosted repo for both GitHub and GitLab, so it can still show the other forge's projects as failures. Its repo summaries do not carrygitRemoteIdentity, so applying the same verdict there needs a host-side change; left as a follow-up.Checklist
src/shared;knownHostsacross IPC, runtime RPC, preload, web routes and a capability). Happy to split that plumbing into its own PR if it is easier to review.N/Awith reasonpnpm lint,pnpm typecheck,pnpm test, andpnpm buildpass (or CI will cover; local preferred)Author
X: @yasu00000
🤖 Generated with Claude Code