Add a GitHub adapter #83

New issue

deadstyle · 2026-10-09T09:30:16-05:00

deadstyle commented

2026-10-09 09:30:16 -05:00

Problem

lazyforge supports Forgejo and Gitea only. Add a GitHub adapter so it works against github.com (and GitHub Enterprise) before the public release. GitLab comes later, after the release.

Acceptance criteria

A user can onboard a GitHub host (github.com or Enterprise) and use every v1 feature that works on Forgejo: repo list, boxes [1]–[3], details, ★ Renovate, merge, approve, close, comment, labels, open in browser (ticket; design.md → v1 scope).
All four children below are merged or closed with evidence.

Tracking

This is a tracking issue. Too big for one MR, so the work is split:

#	Child	Driver	Depends on
#84	Client and core Forge methods (repos, PRs + CI, merge, approve, issues, comments, close, releases), ADR 0017	opus	none
#85	Runs, job logs and labels	sonnet	#84
#86	Connect to GitHub from onboarding and the host picker; design.md + README	sonnet	#84
#87	Inline images on GitHub (checks first whether GitHub's image URLs open with a token)	opus	#84

Order: #84 first. #85, #86 and #87 are independent of each other afterwards. Close this issue when the last child lands.

Context

Design and paper mapping already exist: ADR 0002 (adapters, build order), ADR 0006 (paper check against GitHub), docs/architecture.md → API mapping (GitHub column, unverified until #84/#85).
Engineering decisions, settled in #84: a thin net/http client (no SDK, as ADR 0005), conditional requests so refreshes don't spend GitHub's 5,000/hour budget, and the CI fold across check runs plus commit statuses.
Derived product rule, stated in #84: GitHub has no single "repo default" merge method, so lazyforge uses the first one GitHub's merge button offers among those the repo allows (merge commit, then squash, then rebase).

## Problem lazyforge supports Forgejo and Gitea only. Add a GitHub adapter so it works against github.com (and GitHub Enterprise) before the public release. GitLab comes later, after the release. ## Acceptance criteria - A user can onboard a GitHub host (github.com or Enterprise) and use every v1 feature that works on Forgejo: repo list, boxes `[1]`–`[3]`, details, ★ Renovate, merge, approve, close, comment, labels, open in browser *(ticket; design.md → v1 scope)*. - All four children below are merged or closed with evidence. ## Tracking This is a tracking issue. Too big for one MR, so the work is split: | # | Child | Driver | Depends on | |---|---|---|---| | #84 | Client and core Forge methods (repos, PRs + CI, merge, approve, issues, comments, close, releases), ADR 0017 | opus | none | | #85 | Runs, job logs and labels | sonnet | #84 | | #86 | Connect to GitHub from onboarding and the host picker; design.md + README | sonnet | #84 | | #87 | Inline images on GitHub (checks first whether GitHub's image URLs open with a token) | opus | #84 | Order: #84 first. #85, #86 and #87 are independent of each other afterwards. Close this issue when the last child lands. ## Context - Design and paper mapping already exist: ADR 0002 (adapters, build order), ADR 0006 (paper check against GitHub), `docs/architecture.md` → API mapping (GitHub column, unverified until #84/#85). - Engineering decisions, settled in #84: a thin `net/http` client (no SDK, as ADR 0005), conditional requests so refreshes don't spend GitHub's 5,000/hour budget, and the CI fold across check runs plus commit statuses. - Derived product rule, stated in #84: GitHub has no single "repo default" merge method, so lazyforge uses the first one GitHub's merge button offers among those the repo allows (merge commit, then squash, then rebase).

deadstyle added the

feature

label

2026-10-09 09:30:18 -05:00

deadstyle referenced this issue

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

GitHub adapter: client and core Forge methods #84

deadstyle referenced this issue

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

GitHub adapter: runs, job logs and labels #85

deadstyle referenced this issue

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

Connect to GitHub from onboarding and the host picker #86

deadstyle referenced this issue

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

Show inline images on GitHub #87

deadstyle commented

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

🤖 Split into #84 (adapter core, first), #85 (runs, logs, labels), #86 (onboarding + connect), #87 (inline images). This issue now tracks them; the plan is in the body.

deadstyle referenced this issue

2026-10-09 09:52:49 -05:00

feat(github): add the GitHub adapter's client and core methods #88

deadstyle referenced this issue

2026-10-09 10:09:23 -05:00

feat(github): list runs and jobs, stream job logs, edit labels #89

deadstyle referenced this issue

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

feat(ui): connect to GitHub from onboarding and the host picker #90

deadstyle referenced this issue

2026-10-09 10:16:58 -05:00

feat(github): open on-host images so they draw inline #91

deadstyle commented

2026-10-09 10:18:27 -05:00

🤖 All children merged: #84 (!88), #85 (!89), #86 (!90), #87 (!91). GitHub (github.com and Enterprise) is selectable in onboarding and supports every v1 feature that works on Forgejo. Private-repo images stay links (see #87).