Skip to content

Add GitLab as a first-class forge alongside GitHub#366

Open
tftio wants to merge 2 commits into
supabitapp:mainfrom
tftio:feat/gitlab-forge-v1
Open

Add GitLab as a first-class forge alongside GitHub#366
tftio wants to merge 2 commits into
supabitapp:mainfrom
tftio:feat/gitlab-forge-v1

Conversation

@tftio
Copy link
Copy Markdown

@tftio tftio commented May 28, 2026

Summary

Adds GitLab support as a first-class forge, so worktree pull/merge-request status is no longer GitHub-only. Read-only for this first cut. Per the direction in #365 (this comment), the GitHub and GitLab settings are unified into a single Forges pane with a shared "Pull Request" section, modeled on the per-agent integration rows under Developer.

Refs #365

What's included

  • Forge abstraction. A Forge enum detected from the remote host; GitClient parsing returns a forge-tagged ForgeRemoteInfo (with GitLab subgroup support). Per-row state carries a ForgePullRequest sum type (.github / .gitlab) with a shared projection — views read common fields and only branch where the data genuinely differs (GitLab pipelines vs. GitHub status checks).
  • GitLabCLIClient shelling out to glab, mirroring the existing gh client (availability, auth status, remote resolution, batched merge-request GraphQL query).
  • Per-forge refresh dispatch in the repositories reducer.
  • Unified Forges settings pane replacing the separate GitHub pane: a per-forge integration row (enable toggle + CLI availability + auth status + install link) plus one shared Pull Request section (merge strategy, merged-worktree action).

Scope — read-only v1 (being explicit)

GitLab MRs surface their number, state, draft flag, and pipeline status in the sidebar, toolbar, and detail view. Mutations are not implemented yet: merge / close / mark-ready, pipeline rerun, and failing-job log copy remain GitHub-only and are gated behind the .github case (the command palette and reducer skip them for GitLab MRs). Closing the gap toward full parity is the intended follow-up.

Build note (please read — not a blocker)

The second commit pins the build to Xcode 26.3 via a scoped, overridable SUPACODE_DEVELOPER_DIR. Two unrelated toolchain breakages on macOS 26.5 forced this:

  • macOS 26.4+ SDKs dropped the plain arm64-macos slice from libSystem.tbd; zig 0.15.2 (pinned by Ghostty) can't link against the arm64e-only stubs and fails to link its own build runner (ziglang/zig#31658, fixed in zig 0.16).
  • Xcode 26.5's Swift 6.3 fails to compile the pinned swift-composable-architecture (1.23.1).

Xcode 26.3 satisfies both. The export is guarded and auto-disables when that Xcode is absent (CI / other OS versions are unaffected), and the build scripts defer to any DEVELOPER_DIR the caller already set. It's isolated in its own commit so you can adjust or drop it — flagging it explicitly since the default path is environment-specific. The same commit also makes xcbeautify optional so a missing formatter no longer fails the build.

Testing

  • Unit tests: forge detection, GitLab MR GraphQL decoding, glab auth status parsing, pipeline-status mapping, plus a GitLab refresh-dispatch integration test in RepositoriesFeatureTests.
  • Confirmed locally: built and ran the app against a real gitlab.com remote — the MR badge/notification, pipeline status, and the unified Forges settings pane all render and behave as expected.
make build-app   # (on Xcode 26.3 per the build note above)
make test

tftio added 2 commits May 28, 2026 14:39
Introduce a forge abstraction so worktree pull/merge-request status is no
longer GitHub-only. A `Forge` enum is detected from the remote host, and
`GitClient` parsing now returns a forge-tagged `ForgeRemoteInfo` (with GitLab
subgroup support). Per-row state carries a `ForgePullRequest` sum type
(`.github` / `.gitlab`) with a shared projection, so most views read common
fields and only branch on the forge where the data genuinely differs
(GitLab pipelines vs. GitHub status checks).

A parallel `GitLabCLIClient` shells out to `glab` (mirroring the existing
`gh` client) for availability, auth status, remote resolution, and a batched
merge-request GraphQL query. The repositories reducer dispatches the PR
refresh per forge.

Settings unify both forges into a single "Forges" pane (replacing the
separate GitHub pane): a per-forge integration row shows the enable toggle,
CLI availability, and auth status, and a single shared "Pull Request" section
holds the merge strategy and merged-worktree action.

v1 is read-only: GitLab MRs surface their number, state, draft flag, and
pipeline status in the sidebar, toolbar, and detail view. Mutations
(merge/close/mark-ready), pipeline rerun, and failing-job log copy remain
GitHub-only and are gated behind the `.github` case; the command palette and
reducer skip those actions for GitLab MRs.
macOS 26.4+ SDKs dropped the plain arm64-macos slice from libSystem.tbd,
leaving only arm64e-macos. zig 0.15.2's Mach-O linker (pinned by Ghostty)
won't match the two, so it fails to link its own build runner with every
libSystem symbol undefined (ziglang/zig#31658, fixed in zig 0.16). Xcode
26.5's Swift 6.3 separately fails to compile the pinned
swift-composable-architecture. Xcode 26.3 satisfies both.

Resolve a developer dir from SUPACODE_DEVELOPER_DIR (default Xcode 26.3) and
export it for every recipe, so `tuist generate` (Ghostty) and `xcodebuild`
(zmx + the app) all use it. The export is overridable and auto-disables when
that Xcode is absent, so CI and machines on an older OS are unaffected. The
Ghostty and zmx build scripts defer to an already-set DEVELOPER_DIR and only
fall back to 26.3 for standalone runs.

Also make xcbeautify optional: pretty-print xcodebuild output when it is
available via mise or PATH, otherwise pass the raw log through `cat` so a
missing formatter no longer fails the build under pipefail.
@tftio tftio mentioned this pull request May 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant