Repository navigation
feat(forge): From a PR picks GitLab MRs, and can list all open PRs - #393
Merged
Merged
Conversation
From a PR answered "not wired up for GitLab yet" for both the list and the paste-a-number path, so on GitLab the column was a dead end. The branch fetch already handled refs/merge-requests/<n>/head; only the two lookups were missing. GitLab now goes through `glab api`, the REST API, like the issue list, because glab's own JSON output has moved between versions: scope=created_by_me for your MRs, scope=reviews_for_me for the review list, scope=all for All open, and merge_requests/<iid> for a pasted number. A 404 reads as "not found". A server that does not accept reviews_for_me answers 400, which hides the review section instead of putting an error under your own MRs. The column also gets two chips. For you is the default and is what the column showed before: your PRs and the review list. All open is the repo's open PRs, newest first, one page of 50, on all three forges. It is fetched on the click, so the default view costs nothing extra, and a full page says so and points at the number box. On a 1,300-PR repo the newest 50 are rarely the one you want; on a small team repo they are exactly it. On kubernetes/kubernetes (1,306 open) an unfiltered `gh pr list --limit 50` came back in under a second, about the same as the --author @me list. Azure drops --creator me for All open, in the CLI's own order, which is not verified. project_forge_prs takes `scope` (mine / review / open) in place of the `review` flag. Rust: path and parser pins for GitLab MRs, PrScope parsing, the gh open-list args and the Azure creator filter. e2e: no scope chips draw for a non-ok lookup. A populated list cannot be faked in a spec: Tauri defines __TAURI_INTERNALS__.invoke read-only, so a page-side wrapper is silently ignored. The lists and the chip switch are a manual check.
simion
approved these changes
Oct 11, 2026
simion
left a comment
simion
left a comment
Owner
There was a problem hiding this comment.
Verified the GitLab wiring (404 to not found, 400 on reviews_for_me degrades only that section) and the PrScope refactor is consistent across Rust and TS. All open is opt-in, fetched on click, capped at 50, matching docs/ui.md. Thanks for the contribution!
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.
From a PR didn't work on GitLab.
Both the list and the paste-a-number path answered "not wired up for GitLab yet", even though the branch fetch already knew
refs/merge-requests/<n>/head.This wires up those two lookups, and adds an opt-in list of every open PR.
GitLab. Every lookup goes through
glab api(REST, same as the issue picker, since glab's own JSON output has moved between versions):scope=created_by_mefor your MRs,scope=reviews_for_mefor the review list, andmerge_requests/<iid>for a pasted198,!198or MR URL.A wrong number is a 404 and shows as "not found".
If a server doesn't accept
reviews_for_meit answers 400, and the review section just stays hidden.All open. The PR column gets two chips under the number box.
For you is the default and is exactly what the column showed before.
All open lists the repo's open PRs, newest first, one page of 50, on GitHub, GitLab and Azure DevOps.
It's fetched when you click it, not when the column opens, so staying on For you costs nothing extra.
A full page says "Showing the newest 50" and points at the number box for anything older.
I know
docs/ui.mdargued against a repo-wide list, which is why For you stays the default.That argument is about busy repos, where the newest 50 of 1,300 rarely include the one you want.
On a small team repo with a handful of open MRs, the full list is exactly what you want, and that's the case this is for.
Fetching isn't the cost either: on kubernetes/kubernetes (1,306 open) an unfiltered
gh pr list --limit 50came back in under a second, about the same as--author @me.project_forge_prsnow takesscope(mine/review/open) instead of thereviewflag.Azure's All open just drops
--creator me.I can't test Azure, so its order is whatever the CLI returns.
Tests: Rust pins for the GitLab request paths and MR parser,
PrScopeparsing, the gh open-list args and Azure's creator filter.The e2e case checks that no chips draw when the lookup fails (
git.e2e.ts80/80).I couldn't fake a populated list in a spec.
Tauri defines
__TAURI_INTERNALS__.invokeread-only (scripts/core.jsin the tauri crate), so wrapping it in the page is silently ignored.That also means the wrapper in
agent.e2e.tshas never intercepted anything, which matches its comment about the count reading 0.Tested by hand in the dev app against a self-hosted GitLab: For you showed an MR I'd added myself to as a reviewer, and All open listed every open MR in the repo.