Connect to GitHub from onboarding and the host picker #86

New issue

deadstyle · 2026-10-09T09:36:02-05:00

deadstyle commented

2026-10-09 09:36:02 -05:00

Problem

Even with the adapter built, nobody can pick GitHub: onboarding lists it as "coming soon", connecting rejects the type, and the sign-in screen gives Forgejo's token page and scopes. Parent: #83. Depends on #84; pick this up after #84 merges.

Acceptance criteria

Onboarding's Forge type step lets you select GitHub, and only GitLab stays "coming soon" (design.md → Onboarding step 2).
The Address step is pre-filled with https://github.com for GitHub, and accepts a GitHub Enterprise address (design.md → Onboarding step 3; ticket #83).
The Address step checks that the server is reachable and really is GitHub. A Forgejo server entered for GitHub, or the reverse, gets "That server runs X, not Y". An address with no forge API at all names the chosen type ("No GitHub API at that address") (design.md → Onboarding step 3).
The Sign in step for GitHub links to <web root>/settings/tokens and lists GitHub's permissions: classic token scope repo (or a fine-grained token with Contents, Pull requests and Issues read/write, plus Actions, Checks and Commit statuses read), each with what it's for. Failure messages name GitHub's scopes, not Forgejo's (design.md → Onboarding step 4: "links to the page where a token is created … and lists the permissions it needs").
A host with type = "github" in the config connects, from the picker, --host or Settings → add host (design.md → Settings; architecture.md config example).
docs/design.md v1 scope records that the GitHub adapter ships with the public release (the PM's call in #83), and the README lists GitHub as supported.

Plan

cmd/lazyforge/main.go: connect dispatches on h.Type, sending github to github.New. Deps.Probe keeps its signature. cmd composes it so it tries the gitea probe, then the GitHub probe, and returns the first kind found, or ErrNotFound when neither answers. ui still never imports an adapter (architecture.md → UI).
internal/ui/onboarding.go: raise selectableForges to 3. Pre-fill the address when the kind is GitHub. Make the token help, scope list, signInError text and the "No … API" message depend on the kind (a small per-kind table in onboarding).
Tests: onboarding Update/View tests for the GitHub path (pre-fill, scope text, kind mismatch), and a cmd test that connect routes github. Verify in tmux at 80x24 per architecture.md → UI.

Context

Onboarding flow: internal/ui/onboarding.go (forgeRows, selectableForges, submit, probed, signInError, view). App deps: internal/ui/app.go (Deps.Probe, Deps.Connect).
The config already accepts github (internal/config/config.go hostTypes).
gh auth token works as a token_cmd. Its OAuth token carries repo and read:org (verified 2026-10-09).

Out of scope

The adapter itself (#84, #85). GitLab.

## Problem Even with the adapter built, nobody can pick GitHub: onboarding lists it as "coming soon", connecting rejects the type, and the sign-in screen gives Forgejo's token page and scopes. Parent: #83. **Depends on #84**; pick this up after #84 merges. ## Acceptance criteria - Onboarding's Forge type step lets you select GitHub, and only GitLab stays "coming soon" *(design.md → Onboarding step 2)*. - The Address step is pre-filled with `https://github.com` for GitHub, and accepts a GitHub Enterprise address *(design.md → Onboarding step 3; ticket #83)*. - The Address step checks that the server is reachable and really is GitHub. A Forgejo server entered for GitHub, or the reverse, gets "That server runs X, not Y". An address with no forge API at all names the chosen type ("No GitHub API at that address") *(design.md → Onboarding step 3)*. - The Sign in step for GitHub links to `<web root>/settings/tokens` and lists GitHub's permissions: classic token scope `repo` (or a fine-grained token with Contents, Pull requests and Issues read/write, plus Actions, Checks and Commit statuses read), each with what it's for. Failure messages name GitHub's scopes, not Forgejo's *(design.md → Onboarding step 4: "links to the page where a token is created … and lists the permissions it needs")*. - A host with `type = "github"` in the config connects, from the picker, `--host` or Settings → add host *(design.md → Settings; architecture.md config example)*. - `docs/design.md` v1 scope records that the GitHub adapter ships with the public release (the PM's call in #83), and the README lists GitHub as supported. ## Plan - `cmd/lazyforge/main.go`: `connect` dispatches on `h.Type`, sending `github` to `github.New`. `Deps.Probe` keeps its signature. cmd composes it so it tries the gitea probe, then the GitHub probe, and returns the first kind found, or `ErrNotFound` when neither answers. `ui` still never imports an adapter (architecture.md → UI). - `internal/ui/onboarding.go`: raise `selectableForges` to 3. Pre-fill the address when the kind is GitHub. Make the token help, scope list, `signInError` text and the "No … API" message depend on the kind (a small per-kind table in onboarding). - Tests: onboarding `Update`/`View` tests for the GitHub path (pre-fill, scope text, kind mismatch), and a cmd test that `connect` routes `github`. Verify in tmux at 80x24 per architecture.md → UI. ## Context - Onboarding flow: `internal/ui/onboarding.go` (`forgeRows`, `selectableForges`, `submit`, `probed`, `signInError`, `view`). App deps: `internal/ui/app.go` (`Deps.Probe`, `Deps.Connect`). - The config already accepts `github` (`internal/config/config.go` `hostTypes`). - `gh auth token` works as a `token_cmd`. Its OAuth token carries `repo` and `read:org` (verified 2026-10-09). ## Out of scope The adapter itself (#84, #85). GitLab.

deadstyle referenced this issue

2026-10-09 09:36:35 -05:00

GitHub adapter: client and core Forge methods #84

deadstyle referenced this issue

2026-10-09 09:36:36 -05:00

Add a GitHub adapter #83

deadstyle added the

feature

sonnet

labels

2026-10-09 09:36:39 -05:00

deadstyle referenced this issue