Support GitHub repos in the issues/PRs panel drawer #46

Closed
opened 2026-09-20 11:27:36 +01:00 by pedromcaraujo · 0 comments

The panel drawer's issues/PRs tabs (plus the Alt+K # issue palette) currently
only work against Forgejo. Several of my repos live on GitHub — this asks to
teach the panel to speak GitHub too, so a channel can point at a GitHub repo.

Why it's tractable

The feature is well-seamed. The sidecar (web/panel.py) already normalises
forge JSON into a thinned payload before the browser sees it, and those field
names (number, title, state, html_url, user.login, labels[].name/.color,
PR draft/base.ref/head.ref, …) match GitHub's API almost exactly. So the
frontend rendering and the whole palette (#auth filter, #31 jump,
inject-#N-into-terminal) should work unchanged once the sidecar returns GitHub
data in the same shape. There's already a plugin seam: PANEL_RENDERERS in
web/index.html and the type enum in config — nobody's added a second
provider yet, so it's all hardcoded to forgejo.

What actually differs for GitHub

Concentrated in web/panel.py:

  1. API host ≠ web host. Forgejo uses {baseUrl}/api/v1/repos/{owner}/{repo}/…
    where baseUrl is also the web UI. GitHub splits them: API at
    api.github.com/repos/…, web/html_url at github.com/…. The current code
    assumes one baseUrl serves API, web UI, and attachments — that
    assumption needs unpicking.
  2. Auth scheme. Forgejo: Authorization: token <t>. GitHub: Bearer <t>.
  3. Markdown render. Sidecar POSTs to Forgejo's /api/v1/markdown with
    capitalised fields {"Text","Mode","Context"}. GitHub's /markdown is
    lowercase ({"text","mode","context"}) and rate-limited.
  4. Attachments. Forge proxies Forgejo's auth-gated /attachments/ images
    (#42/#43). GitHub serves user-content from public *.githubusercontent.com,
    so the proxy is likely a no-op for GitHub — but the URL-rewriting is keyed on
    Forgejo path shapes and needs a GitHub branch (probably passthrough).

Suggested shape

Since GitHub would be the second provider, factor a thin Provider abstraction
inside the sidecar (list_issues / issue_detail / render_markdown /
rewrite_urls) rather than sprinkling if type == "github". Then small
additions elsewhere:

  • extend the type enum in modules/forge.nix
  • the panelUrl computation in modules/launcher.nix
  • the three type === 'forgejo' checks in web/index.html (registry,
    channelHasIssues, drawerTitleHref/openIssueInForgejo)
  • generalise cosmetic strings ("Open in Forgejo", renderForgejo, default title)

Rough effort: half a day to a day.

The panel drawer's issues/PRs tabs (plus the Alt+K `#` issue palette) currently only work against Forgejo. Several of my repos live on GitHub — this asks to teach the panel to speak GitHub too, so a channel can point at a GitHub repo. ## Why it's tractable The feature is well-seamed. The sidecar (`web/panel.py`) already **normalises** forge JSON into a thinned payload before the browser sees it, and those field names (`number`, `title`, `state`, `html_url`, `user.login`, `labels[].name/.color`, PR `draft`/`base.ref`/`head.ref`, …) match GitHub's API almost exactly. So the frontend rendering and the whole palette (`#auth` filter, `#31` jump, inject-`#N`-into-terminal) should work unchanged once the sidecar returns GitHub data in the same shape. There's already a plugin seam: `PANEL_RENDERERS` in `web/index.html` and the `type` enum in config — nobody's added a second provider yet, so it's all hardcoded to `forgejo`. ## What actually differs for GitHub Concentrated in `web/panel.py`: 1. **API host ≠ web host.** Forgejo uses `{baseUrl}/api/v1/repos/{owner}/{repo}/…` where `baseUrl` is also the web UI. GitHub splits them: API at `api.github.com/repos/…`, web/`html_url` at `github.com/…`. The current code assumes one `baseUrl` serves API, web UI, **and** attachments — that assumption needs unpicking. 2. **Auth scheme.** Forgejo: `Authorization: token <t>`. GitHub: `Bearer <t>`. 3. **Markdown render.** Sidecar POSTs to Forgejo's `/api/v1/markdown` with capitalised fields `{"Text","Mode","Context"}`. GitHub's `/markdown` is lowercase (`{"text","mode","context"}`) and rate-limited. 4. **Attachments.** Forge proxies Forgejo's auth-gated `/attachments/` images (#42/#43). GitHub serves user-content from public `*.githubusercontent.com`, so the proxy is likely a no-op for GitHub — but the URL-rewriting is keyed on Forgejo path shapes and needs a GitHub branch (probably passthrough). ## Suggested shape Since GitHub would be the second provider, factor a thin `Provider` abstraction inside the sidecar (`list_issues` / `issue_detail` / `render_markdown` / `rewrite_urls`) rather than sprinkling `if type == "github"`. Then small additions elsewhere: - extend the `type` enum in `modules/forge.nix` - the `panelUrl` computation in `modules/launcher.nix` - the three `type === 'forgejo'` checks in `web/index.html` (registry, `channelHasIssues`, `drawerTitleHref`/`openIssueInForgejo`) - generalise cosmetic strings ("Open in Forgejo", `renderForgejo`, default title) Rough effort: half a day to a day.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
pedromcaraujo/forge#46
No description provided.