2 Commits

Author	SHA1	Message	Date
Bohan Jiang	ecce589867	MUL-5265: GitHub API-snapshot PR cards — CI status + mergeability (#5889) ... * feat(github): API-snapshot PR cards — CI status + mergeability (MUL-5265) Fetch each linked PR's CI checks and mergeability from the GitHub GraphQL API as the single source of truth (Plan C). Webhooks, page visits and a bounded TTL sweep are refresh triggers only; nothing is inferred from webhook payloads anymore. Backend (server/internal/integrations/ghsnapshot): - installation-token cache + GraphQL client (private key / tokens never logged) - one paginated pullRequest query -> normalized per-check snapshot - outbound queue: (installation,repo,PR) dedup + single in-flight per PR, bounded worker pool, Retry-After / rate-limit backoff, jitter - head-SHA-guarded atomic batch replace (a slow response for an old head can never overwrite a newer head's snapshot) - bounded chase window (30s->5m, stops on terminal/closed) + page-visit + TTL refresh; clean degradation when no App private key is configured Removes the old suite-level webhook aggregation display path (query + handlers + tests). check_suite / check_run / status are now pure triggers. Frontend: PR card shows two independent tri-state elements (CI status + mergeability). "Ready to merge" only when merge state is clean; no-checks and unknown-mergeable never assert a positive verdict; progress strip removed; four locales; stale marker. Docs: github-integration + environment-variables (four languages) — now required App private key, read-only Checks/Commit-statuses permissions, new event subscriptions, capability boundaries and troubleshooting. Co-authored-by: multica-agent <github@multica.ai> * fix(github): address PR snapshot review blockers Co-authored-by: multica-agent <github@multica.ai> * fix(github): bound snapshot refresh scheduling Co-authored-by: multica-agent <github@multica.ai> * fix(github): concurrent check-run index migration + singleflight token mint Address Elon's third-round review on the MUL-5265 PR snapshot pipeline. Must-fix — migration built a non-concurrent index. The github_pull_request_check_run table declared PRIMARY KEY (pr_id, ordinal) inside CREATE TABLE, which builds a unique index synchronously and violates the repo rule that every migration-created index (including on a new table) use CREATE UNIQUE INDEX CONCURRENTLY in its own single-statement file. Split: 222 now creates the table without a primary key; new 223 adds the (pr_id, ordinal) unique index CONCURRENTLY. The atomic delete-all/insert write path already guarantees ordinal uniqueness, so a plain unique index is sufficient; the index also serves the pr_id-prefix list aggregation and the workspace/PR cleanup deletes. Nit — token mint now singleflights per installation. installationToken released the lock before minting, so the N workers of one installation could mint N tokens on a cold cache or a simultaneous renew. Concurrent callers for the same installation are now collapsed via singleflight into one HTTP mint; added a -race concurrent-mint test asserting a single mint under 16 callers. Verified: fresh DB migrates through 223 (table has no PK, concurrent unique index present); ghsnapshot suite + new test pass under -race; migration lint and handler github/workspace-delete tests pass; sqlc produced no diff; go build / vet / gofmt / git diff --check clean. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-24 18:30:20 +08:00
Jiayuan Zhang	668cab6022	feat(github): mirror PR CI checks and merge conflict status (MUL-2228) (#2632) ... * feat(github): mirror PR CI checks and merge conflict status (MUL-2228) Surface "checks passed/failed" and "conflicts/no conflicts" badges under each linked PR on the issue page so users can judge readiness without flipping over to GitHub. CI state is fed by check_suite webhooks (GitHub Actions + apps using the Checks API; legacy status events are out of scope for MVP); conflicts are read from pull_request.mergeable_state. Data model: * github_pull_request: add head_sha + mergeable_state * github_pull_request_check_suite: per-suite rows keyed by (pr_id, suite_id) * Aggregation done at query time, filtering by current head_sha so late-arriving suites for a stale head can't contaminate the new head's pending view; per-app latest suite chosen first so a single app firing multiple suites isn't counted N times. Webhook hardening: * synchronize/opened/reopened/edited(base) explicitly clear mergeable_state * single-row ordering protection on the check_suite upsert prevents a late-delivered older event from overwriting a newer one * check_suite.pull_requests is iterated; unknown PRs are logged and dropped UI: * PR row shows Checks + Conflicts badges; opaque mergeable values (blocked/behind/unstable/...) render as no badge, not as conflicts. * Terminal PR states (merged/closed) suppress the status row entirely. Tests: * Pure unit coverage for derivePRMergeableState + aggregateChecksConclusion * Webhook integration tests: multi-app aggregation, old-head ignore, late-older-event ignore, synchronize clears mergeable_state * Vitest coverage for pull-request-list badge rendering across CI/conflict combinations and the legacy (null) fallback. Co-authored-by: multica-agent <github@multica.ai> * fix(github): scope check_suite PR lookup; preserve mergeable on metadata Addresses code review on PR #2632. 1. check_suite handler now resolves the PR through the workspace-scoped GetGitHubPullRequest query instead of GetGitHubPullRequestByRepoNumber. The (workspace_id, repo_owner, repo_name, pr_number) tuple is the real uniqueness key, so a bare (owner, repo, number) lookup could return a stale row from another workspace and either land the suite on the wrong PR or skip the right one when the installation ids drifted. The old unscoped query is removed. 2. derivePRMergeableState now returns (value, clear) and the upsert SQL distinguishes three cases: state-changing actions clear the column to NULL, non-empty payloads write the value, and metadata events with an empty payload preserve the existing column. Previously every empty payload became NULL, so a labeled/assigned event silently wiped a known clean/dirty verdict in violation of the RFC's "metadata empty payload preserves" rule. 3. ListPullRequestsByIssue narrows to the issue's PR ids before running the per-app check_suite aggregation, avoiding a full-table scan over github_pull_request_check_suite when only a handful of rows belong to the requested issue. New helper test covers labeled+empty preserves; new integration test verifies a metadata event after a known mergeable_state keeps the value. Co-authored-by: multica-agent <github@multica.ai> * feat(github): PR card layout v3 increment — stats + segmented progress bar Replaces the row + badge layout under "Pull requests" on the issue detail sidebar with a card that mirrors the GitHub PR summary look: title, author/avatar, +N −M · K files diff stats, segmented progress bar (failed → pending → passed, failure leftmost), and a one-line status caption following an explicit priority pass-through. Backend - Migration 092: github_pull_request adds additions / deletions / changed_files (INT NOT NULL DEFAULT 0). Zero defaults are what the new frontend treats as "legacy backend — hide the stats row" so old PR rows that pre-date this migration don't render "+0 −0 · 0 files". - pull_request webhook handler reads stats off the top-level payload. - ListPullRequestsByIssue now surfaces per-suite counts (checks_passed / failed / pending) alongside the existing aggregate conclusion, so the segmented bar reuses the already-computed counts with no new aggregation. Frontend (packages) - core/github/pull-request-status.{ts,test.ts}: pure-function module for the status-kind priority table and the segment derivation; 15 cases covered, includes the "all-zero → hide stats" guard. - views/issues/components/pull-request-list.tsx: PullRequestCard plus a compact-row fallback used when count > 4 (first 3 as cards, the remainder collapsed behind a Show more toggle). - i18n: new `pull_request_card_*` keys in en + zh-Hans. Tests - 12 component tests covering each rule of the priority table, the legacy-zero stats fallback, and the collapse threshold. - Reuse of the v3 webhook handler tests confirmed. Verification - pnpm typecheck + pnpm test green (60 test files, 536 tests). - go build ./... + go vet ./... clean. - 6 demo issues (DEV-2..DEV-7) screenshotted via Playwright; see the PR comments for the visual check matrix. Co-authored-by: multica-agent <github@multica.ai> * fix(views): collapse PR cards at N>=4, not N>4 The card-vs-collapse threshold used `>` so 4 PRs slipped past it and all rendered as full cards, contrary to RFC v3 (N >= 4 collapses to 3 cards + compact tail). Switch to `>=` and update the threshold- boundary test to expect "Show 1 more". Co-authored-by: multica-agent <github@multica.ai> * fix(views): align PR sidebar rows with existing list style Co-authored-by: multica-agent <github@multica.ai> * fix(views): hide terminal PR status badges Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-16 21:26:30 +02:00