feat: add gitealike Actions CI parity

[mariusvniekerk]

Merge Forgejo and Gitea Actions workflow runs into provider CI checks without duplicating commit statuses. Gitea Actions are gated to servers with the pinned SDK's 1.26+ workflow run API, leaving older hosts status-only.

[mariusvniekerk]

This change is part of the following stack:

• docs: plan Forgejo provider implementation #265
  • feat: recognize Forgejo and Gitea provider configuration #266
    • 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
              • 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 #277 ◀

_{Change managed by git-spice.}

[roborev-ci]

roborev: Combined Review (f1a86e9)

High: PR has correctness and coverage issues that should be fixed before merge.

High

• internal/platform/gitealike/normalize.go:344
NormalizeState(conclusion) is used as a fallback for Actions run conclusions. That function maps PR/issue states and defaults unknown values to "open", which can produce an invalid CI status for conclusions like "cancelled" or "skipped".
  Fix: Use a CI-specific conclusion mapping or preserve the raw conclusion when appropriate.

• tests/e2e/ / Entire PR
  End-to-end coverage is missing for the new Gitea Actions sync behavior. This affects provider ingestion, SQLite persistence, and HTTP API output.
  Fix: Add an e2e test with a mock Gitea 1.26 server returning commit statuses and Actions runs, then verify synced CI checks through the API/database, including status-only fallback behavior.

Medium

• internal/platform/gitealike/normalize.go:256
  Actions runs are deduplicated solely because their title matches any commit status context. Unrelated checks with common names like Build could cause a failing Actions run to be hidden behind a successful status.
  Fix: Deduplicate using a stronger identity, such as URL/external identity or a name+URL pair, and add a regression test where a same-name status and Actions run are distinct.

---

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

[roborev-ci]

roborev: Combined Review (f1cc7a2)

Medium issue found; no Critical or High findings.

Medium

• internal/platform/gitealike/normalize.go:253
  Action runs are appended wholesale for a commit, so reruns of the same workflow can leave older failed runs in CIChecksJSON. The aggregate CI calculation treats any completed non-success check as failure, meaning a PR can remain failed after a later successful rerun.

  Fix: Collapse action runs by a stable workflow key, preferably WorkflowID with a name fallback, and keep only the newest run by stopped/started time and ID before deriving and persisting CI status.

---

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

[roborev-ci]

roborev: Combined Review (ed4c175)

CI ingestion looks mostly sound, but one Medium issue can misrepresent the current run state.

Medium

• internal/platform/gitealike/normalize.go:317
latestActionRuns ranks runs only by stopped/started time, so a newer queued rerun with no started/completed timestamp can lose to an older completed run and leave stale CI shown as current.

  Suggested fix: Preserve an Actions run created/updated timestamp or run number in ActionRunDTO, and use that before falling back to ID. Add coverage for a queued rerun superseding an older completed run.

---

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

[roborev-ci]

roborev: Combined Review (18600b5)

CI support has two medium-risk stale/missing data paths to address before merge.

Medium

• internal/platform/gitealike/normalize.go:310
actionRunIsNewer prefers timestamp ordering before ID ordering, so a newly queued rerun with no started/stopped timestamp will not replace an older completed run for the same workflow. The dashboard can keep showing stale successful/failed CI while the latest rerun is pending.
  Fix: Include a creation/update/run timestamp in ActionRunDTO, or use the monotonic run ID/run number as the fallback that can supersede older completed runs when the candidate has no timestamps.

• internal/platform/gitea/client.go:93
  Actions support is decided once during client construction by treating any CheckServerVersionConstraint error as “unsupported.” A transient version endpoint failure or startup network issue permanently disables Gitea Actions reads for that process even if the host supports them.
  Fix: Distinguish “known older server” from probe/transport errors, and retry or lazily cache the capability during sync; only disable Actions permanently after a definitive unsupported-version response.

---

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

[roborev-ci]

roborev: Combined Review (d2ce2dd)

No Medium, High, or Critical findings were reported.

All reviewed agents found the code clean.

---

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

[roborev-ci]

roborev: Combined Review (cbf8f20)

No Medium, High, or Critical findings were reported.

All agents that provided review content found the code clean.

---

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