[Bug]: Forgejo PRs carry no checks state, so merge-readiness sort and check badges are flat#28194
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
- Connect a Forgejo repository through
tea(nofj), on a base branch whose protection requires commit-status contexts. - Open PRs whose required statuses are passing, pending and failing.
- 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.
Related
- #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.