[Bug]: Forgejo PRs carry no checks state, so merge-readiness sort and check badges are flat#28194

opened11d agobyEemlm244

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server (Forgejo pull request mapping), surfaced in the PR tab and thread PR badges

Steps to reproduce

  1. Connect a Forgejo repository through tea (no fj), on a base branch whose protection requires commit-status contexts.
  2. Open PRs whose required statuses are passing, pending and failing.
  3. Open the PR tab and sort by merge readiness, or look at the PR badges on threads that link them.

Expected behavior

Forgejo PR rows and link snapshots carry a rolled-up checks state (failed / pending / passed over the required set), so merge-readiness ordering and check badges work as they do for GitHub PRs.

Actual behavior

Every open, non-draft Forgejo PR lands in the same merge-readiness tier and shows no check badge. forgejoPullRequestJson.ts (lines 126-148 at the tag below) maps list rows and summaries without checksState or reviewDecision, so rankPullRequestsByMergeReadiness (pullRequestList.logic.ts, 667-685) has nothing to rank on. On our server none of 837 linked Forgejo PR snapshots has a checks state.

The data is already read: the Forgejo provider fetches commit statuses for the head (ForgejoPullRequestProvider.ts 226-263) and the base branch's required contexts (forgejoRequiredChecks.ts 41-73) for PR detail and the PR watcher, which works well here: it wakes on required checks passing and on failed checks. Only the list/snapshot mapping drops it.

Impact

Minor: on a Forgejo-only setup the PR tab cannot surface which PRs are ready or red without opening each one.

Version or commit

Nightly 0.1.6-nightly.20261031.3973 (tag v0.1.6-nightly.20261031.3973, commit 85bd3f2a2a); line numbers above are at that tag.

Environment

Self-hosted Forgejo 16.0.5 (gitea-1.22.0 API), tea 0.16.0 login, Linux server reached from desktop, web and iOS clients.

  • #16575, #18770 and #18775 fixed how the watcher reads Forgejo checks; this is the list/snapshot side of the same data.
  • Conflicts are deliberately not inferred from Forgejo's mergeable (#15441); this issue is about checks only.