dsh-plugins/dsh-gitea

Watch

Fork 0

fix(wiki): gitea_wiki get answers OK and can never return page content #4

New issue

Closed

opened 2026-10-23 17:17:53 +00:00 by dsh · 1 comment

dsh commented

2026-10-23 17:17:53 +00:00

Owner

Symptom

gitea_wiki get { pageName: "Home" } → OK. No title, no URL, no content. The page exists (the bootcamp page is real; its wiki-repo clone contains Home.md).

Root cause — two layers

API: Forgejo's GET /repos/{owner}/{repo}/wiki/page/{pageName} returns metadata only:
```
{"title":"Home","html_url":"…/wiki/Home","sub_url":"Home","last_commit":{…}}
```
There is no body. Wiki content lives in the separate .wiki.git repo; probing /wiki/raw/Home, /wiki/Home?action=raw and /raw/wiki/Home all 404 for this private repo.
Formatter: lib/handlers/formatters.js has no wiki branch, and {title, html_url, sub_url} matches none of the fallbacks (login, path, number, array), so it falls through to the default OK (see #5).

Fix

Minimum: a wiki formatter showing title, html_url, sub_url, last-commit summary. That alone removes the "OK".
Real content: the tool must read the wiki git repo — e.g. shallow clone/fetch ssh://…/<repo>.wiki.git and git show the page, or call the API's git endpoints against it. If that is too heavy for a tool call, change the description to "wiki page metadata" and document that content requires cloning the wiki repo (the DSH bootcamp currently documents exactly that workaround).

Acceptance

get returns at least title + URL (never OK).
either the markdown body is returned, or the tool description / docs say plainly that it is metadata-only and how to get content.

## Symptom `gitea_wiki get { pageName: "Home" }` → `OK`. No title, no URL, no content. The page exists (the bootcamp page is real; its wiki-repo clone contains `Home.md`). ## Root cause — two layers 1. **API:** Forgejo's `GET /repos/{owner}/{repo}/wiki/page/{pageName}` returns **metadata only**: ```json {"title":"Home","html_url":"…/wiki/Home","sub_url":"Home","last_commit":{…}} ``` There is no body. Wiki content lives in the separate `.wiki.git` repo; probing `/wiki/raw/Home`, `/wiki/Home?action=raw` and `/raw/wiki/Home` all 404 for this private repo. 2. **Formatter:** `lib/handlers/formatters.js` has no wiki branch, and `{title, html_url, sub_url}` matches none of the fallbacks (`login`, `path`, `number`, array), so it falls through to the default `OK` (see #5). ## Fix - **Minimum:** a wiki formatter showing `title`, `html_url`, `sub_url`, last-commit summary. That alone removes the "OK". - **Real content:** the tool must read the wiki git repo — e.g. shallow clone/fetch `ssh://…/<repo>.wiki.git` and `git show` the page, or call the API's git endpoints against it. If that is too heavy for a tool call, change the description to "wiki page metadata" and document that content requires cloning the wiki repo (the DSH bootcamp currently documents exactly that workaround). ## Acceptance - [ ] `get` returns at least title + URL (never `OK`). - [ ] either the markdown body is returned, or the tool description / docs say plainly that it is metadata-only and how to get content.

dsh referenced this issue

2026-10-23 17:17:53 +00:00

fix(tools): empty and unrecognised results render as a bare OK #5

dsh added the

type/bug

area/forgejo

priority/next

labels

2026-10-23 17:18:02 +00:00

dsh referenced this issue

2026-10-23 17:18:08 +00:00

Tool bugs seen from issue-tracker work (2026-10-23): wiki get, repo contents, issue pagination, empty responses, label assignment #1

dsh referenced this issue

2026-10-23 17:44:28 +00:00

fix(wiki): gitea_wiki list fails with "The target couldn't be found" on an empty wiki #9

dsh referenced this issue

2026-10-23 17:44:32 +00:00

feat(wiki): gitea_wiki cannot create/edit/delete pages although the Forgejo API supports it #10

dsh referenced this issue

2026-10-23 17:44:32 +00:00

fix(tools): empty and unrecognised results render as a bare OK #5

dsh referenced this issue from a commit

2026-10-23 22:37:53 +00:00

fix(wiki): render wiki page metadata instead of a bare identifier (#4)

dsh referenced this issue from a pull request that will close it,

2026-10-23 22:37:56 +00:00

fix(wiki): render wiki page metadata instead of a bare identifier #14

dsh closed this issue

2026-10-23 22:38:01 +00:00

dsh commented

2026-10-23 22:38:07 +00:00

Author

Owner

Fixed in 30ce29d (PR #14).

Note the symptom had drifted: the bare OK was already removed by 4d77e9f (#5). The remaining defect was two-layer: no wiki formatter, and slimRecord stripped sub_url/last_commit before the formatter ran. Both are fixed; get now renders title, slug, URL, last-commit summary, and states plainly that the body requires cloning <owner>/<repo>.wiki.git.

Live check through the running plugin (pvlb-infra/vps-setup, page Home):

Wiki page: Home
Slug: Home
URL: https://git.pvlb.dev/pvlb-infra/vps-setup/wiki/Home
Last commit: 4bc73399 docs: add DSH bootcamp page for agents
Content: not available from the REST API; clone <owner>/<repo>.wiki.git to read the body.

Fixed in `30ce29d` (PR #14). Note the symptom had drifted: the bare `OK` was already removed by `4d77e9f` (#5). The remaining defect was two-layer: no wiki formatter, and `slimRecord` stripped `sub_url`/`last_commit` before the formatter ran. Both are fixed; `get` now renders title, slug, URL, last-commit summary, and states plainly that the body requires cloning `<owner>/<repo>.wiki.git`. Live check through the running plugin (`pvlb-infra/vps-setup`, page `Home`): ``` Wiki page: Home Slug: Home URL: https://git.pvlb.dev/pvlb-infra/vps-setup/wiki/Home Last commit: 4bc73399 docs: add DSH bootcamp page for agents Content: not available from the REST API; clone <owner>/<repo>.wiki.git to read the body. ```

dsh referenced this issue from a commit

2026-10-23 22:41:32 +00:00

docs: index the wiki fixes and note the pageName slug