feat: read Forgejo and Gitea through shared provider core

[mariusvniekerk]

Wire the Forgejo and Gitea SDK clients into the shared gitealike provider so repository, merge request, issue, release, tag, and CI read paths use the same pagination and typed error behavior. Forgejo includes action runs in CI checks where the SDK exposes them; Gitea stays on commit statuses only.

[mariusvniekerk]

This change is part of the following stack:

• docs: plan Forgejo provider implementation #265
  • feat: add Forgejo and Gitea SDK client skeletons #267
    • feat: share Forgejo and Gitea provider core #268
      • feat: convert Forgejo and Gitea SDK records #269
        • feat: read Forgejo and Gitea through shared provider core #270 ◀
          • feat: start Forgejo and Gitea providers at runtime #271
            • feat: recognize Forgejo and Gitea provider configuration #266
              • test: cover Forgejo and Gitea repository imports #272
                • feat: expose Forgejo and Gitea repository imports #273
                  • test: add Forgejo and Gitea container fixtures #274
                  • feat: enable proven Forgejo and Gitea mutations #275
                  • docs: document Forgejo and Gitea setup #276
                  • feat: add gitealike Actions CI parity #281

_{Change managed by git-spice.}

[roborev-ci]

roborev: Combined Review (b01a2a4)

High: Forgejo/Gitea read capabilities need end-to-end coverage before merge.

High

• internal/platform/forgejo/client.go:90, internal/platform/gitea/client.go:87
  • The new Forgejo and Gitea providers now advertise full read capabilities for repository, PR/issue, release/tag, and CI sync paths, but coverage appears limited to package-level unit/httptest tests.
  • This is a major data-flow change through sync, SQLite persistence, and the HTTP API, so integration regressions could ship undetected.
  • Add E2E coverage for Forgejo and Gitea sync/import using the real server/API path and SQLite, asserting persisted repositories, PRs/issues, events, releases/tags, and CI checks.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (22d5fab)

No Medium, High, or Critical findings were reported.

All agents either found no issues or provided no findings in scope for this PR comment.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (529ef18)

PR review summary: one medium-risk issue remains; no high or critical findings were reported.

Medium

• internal/platform/forgejo/read.go:279 - Forgejo CI reads always call the Actions runs endpoint after reading commit statuses. If Actions are disabled or unsupported on a Forgejo host, a 404 from /actions/runs makes ListCIChecks fail and discards otherwise valid commit statuses, causing MR CI refresh to fail. Treat action-run 404/unsupported errors as optional and return the status checks already collected, or feature-detect/configure Actions support before enabling ReadActions.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (e409f6a)

Medium-severity coverage gaps remain in the new Gitea/Forgejo read-provider integration.

Medium

• internal/server/api_test.go:8494
  The full-stack read-sync coverage only registers platform.KindForgejo. The new Gitea read path advertises capabilities and participates in the same server/API/SQLite workflow, but lacks e2e coverage for provider identity, persisted data, and API responses.
  Fix: Table-drive the e2e over both platform.KindForgejo and platform.KindGitea, asserting repo, MR, issue, events, CI status, provider, and capabilities for each.

• internal/server/api_test.go:8494
  The Forgejo e2e uses gitealike.Options{} and a transport without ActionsTransport, while the real Forgejo client enables ReadActions: true. Action-run CI sync is not covered through SQLite persistence and the HTTP API.
  Fix: Add a Forgejo full-stack case with ReadActions: true and an actions-capable fake transport, then assert action-run checks are persisted and surfaced correctly.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (6c16c83)

Review found one medium-severity issue that should be addressed before merge.

Medium

• internal/platform/gitea/read.go:74, internal/platform/forgejo/read.go:76
  The new read transport methods accept context.Context but do not apply it to SDK requests. Sync cancellation, server shutdown, and caller deadlines will not stop Gitea/Forgejo HTTP reads, so a stalled platform request can hang maintainer sync flows.

  Suggested fix: wire the provided context into every SDK request path using the SDK’s request context support or request-scoped HTTP calls, and add coverage for cancellation/deadline propagation.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (89ebd24)

No Medium, High, or Critical findings were reported.

All review agents found the changed code paths clean.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (e525542)

High-level verdict: Not ready to merge due to a production startup blocker for the new Gitea/Forgejo providers.

High

• cmd/middleman/provider_startup.go:36
  The new Forgejo and Gitea read clients are never registered in defaultProviderFactories, so real configs using platform = "forgejo" or platform = "gitea" still fail startup with unsupported platform. The new read/sync implementation is only reachable from tests that manually inject a provider.

  Fix: Register Forgejo and Gitea factories that construct clients with rate tracking and return them as platform.Providers. Add coverage for the production startup path.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (73793e8)

Summary verdict: One medium reliability issue remains; no high or critical findings were reported.

Medium

• internal/platform/forgejo/client.go:93
  Forgejo clients unconditionally enable action-run reads, and ListActionRuns propagates HTTP errors. On Forgejo instances or repositories where Actions is disabled or unavailable, CI sync can fail even though commit statuses are still readable.
  Suggested fix: Treat unsupported or not-found action-run responses as an empty action-run list, or enable action reads only after capability detection/configuration.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (565114c)

Clean: no Medium, High, or Critical findings were reported.

All reviewers found no actionable issues.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (5f77a5d)

No Medium, High, or Critical findings were reported.

All reviewed outputs agree the code is clean for reportable issues.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)

[roborev-ci]

roborev: Combined Review (bd27b9f)

No Medium, High, or Critical issues found across the reviews.

All agents that reported results found the code clean for applicable findings.

---

Synthesized from 3 reviews (agents: codex, gemini | types: default, security)