mirror of https://github.com/getpaseo/paseo.git synced 2026-07-29 12:01:31 +00:00

Files

nllptrx a8ebd390fa feat(forge): pluggable forge abstraction + GitLab and Gitea/Forgejo/Codeberg (#1913 )

* refactor(forge): forge-neutral foundation (GitHub-only)

Decouple git-hosting from GitHub behind a neutral abstraction (issue #1616), GitHub-only for now; existing GitHub behaviour is unchanged.

- Forge manifest, neutral ForgeService contract, forge registry + resolver, and a client forge-module registry.
- GitHub code renamed to the neutral shape; PR/Issue attachment wording preserved.
- forge.search.response enums parse tolerantly (unknown kind/auth state degrade instead of breaking the client).
- createPullRequest reports typed CLI/auth errors instead of a generic message.
- forge-resolver host/remote caches are LRU-bounded.
- Forge host trust is explicit: only a known cloud host or a CLI-authenticated host is ever talked to; an unauthenticated GitHub Enterprise host fails resolution instead of routing to github.com.
- Docs: forge-providers guide, glossary and i18n forge-copy conventions, architecture and rpc-namespacing terminology.
- Vitest React Native mocks (unistyles, svg, linking, lucide) consolidated into shared aliased test-stubs.

* feat(forge): GitLab adapter, forge-aware UI, pipelines and approvals

GitLab adapter over the glab CLI on the neutral contracts: MR status, forge-aware UI, pipeline tree, and N-of-M approvals.

- threadIsResolved is part of the neutral timeline item.
- Pipeline load failures show an error instead of an empty section.
- Manual pipeline jobs render as pending.
- Fork/detached MR head pipelines are fetched by MR iid (glab ci get --merge-request).

* feat(forge): Gitea family adapter (Gitea, Forgejo, Codeberg)

One adapter over the tea CLI serving Gitea, Forgejo, and Codeberg on the neutral contracts.

- CI status aggregates commit statuses and Actions runs together.
- Gitea's terminal "warning" state maps to failure on server and client.
- Gitea Actions check details are reachable from the PR pane by workflowRunId.

* refactor(forge): localize compatibility handling

* test(forge): expect normalized GitLab facts

---------

Co-authored-by: Mohamed Boudra <boudra.moha@gmail.com>

2026-07-17 15:03:26 +08:00

2.6 KiB

Raw Permalink Blame History

RPC Namespacing

New WebSocket session RPCs use dotted names with the direction as the final segment:

checkout.forge.set_auto_merge.request;
checkout.forge.set_auto_merge.response;

The namespace reads left to right:

Domain: checkout
Namespace segment: forge
Operation: set_auto_merge; this segment is a verb, not a noun. If you would name an RPC noun.request, name it get_noun.request instead.
Direction: request or response

Use dots, not slashes. Dots are protocol namespaces; slashes imply paths or transport routing.

Request/Response Pairs

For ordinary correlated RPCs, a .request has a matching .response with the same prefix. The daemon client may derive the response type mechanically:

checkout.forge.set_auto_merge.request;
// -> checkout.forge.set_auto_merge.response

Most new RPCs should follow this shape. If a request does not have a one-to-one response, call that out in the code near the schema.

Message Shape

Requests keep their parameters at the top level:

{
  type: "checkout.forge.set_auto_merge.request",
  cwd: "/repo",
  enabled: true,
  mergeMethod: "squash",
  requestId: "req_123"
}

Responses put correlated result data under payload:

{
  type: "checkout.forge.set_auto_merge.response",
  payload: {
    cwd: "/repo",
    enabled: true,
    success: true,
    error: null,
    requestId: "req_123"
  }
}

Keep requestId in both request and response payloads. It is the correlation key.

Forge Namespacing

Forge-neutral behavior currently uses checkout.forge.* for checkout-scoped operations and forge.search.* for forge search; forge-specific names belong here only after schema and session handlers exist:

checkout.forge.* for operations whose request/response shape is genuinely forge-neutral and whose implementation dispatches through the forge resolver.
checkout.github.* for existing GitHub-specific compatibility RPCs while callers migrate to the neutral checkout.forge.* shape

Do not put GitHub-specific enums or semantics into checkout.forge.* RPC names. A generic forge RPC should only exist when the behavior is genuinely forge-neutral.

Compatibility

The existing flat RPC names remain part of the protocol until they are intentionally migrated:

checkout_pr_merge_request;
checkout_pr_merge_response;

Do not add new flat names. When migrating old RPCs, keep protocol compatibility rules in mind:

Add the new names first.
Gate new feature behavior through server_info.features.* when an old host cannot support it.
Keep old names accepted until the compatibility window expires.
Mark shims with COMPAT(...) and a removal date.

2.6 KiB Raw Permalink Blame History