The shared Publish wiki workflow (tools/publish_wiki.py, tag v1.1.0) succeeds the first time and then fails on every later run that includes a page whose file name contains a hyphen, for example Getting-started.md.
ERROR: [api] Gitea API request failed with HTTP 400 (Bad Request)
Preflight passed: Gitea accepted the token and the wiki is enabled.
Seen in TirSystem-BashScript/repo-foundry, run 785 (first run 780 passed). Gitea 1.27.3.
Cause
Gitea stores a wiki page whose name contains - under an escaped address with a .- suffix. For the pages created by run 780 the API reports:
title
sub_url
Getting-started
Getting-started.-
SSH-and-tokens
SSH-and-tokens.-
Home
Home
list_wiki_titles builds its set from sub_url (unquoted), so it contains Getting-started.-, while read_pages keys the local page as Getting-started. The page is therefore treated as missing and publish calls POST /wiki/new for a page that already exists, which Gitea answers with 400. The lookup GET /wiki/page/Getting-started also returns 404, while DELETE /wiki/page/Getting-started.- works.
Pages without a hyphen (Home, Troubleshooting) are unaffected, which is why the wiki of this repository, which uses CamelCase names, does not show it.
The 400 is inferred from the page-list mismatch; the body of the failing request was not read.
Reproduce
In a repository with wiki/.publish, add wiki/Getting-started.md and merge.
Change the page and merge again.
The second run fails with the 400 above; the wiki keeps the first version.
Suggested fix
Match local pages against the remote title (through page_key), not against sub_url.
Address a page in GET, PATCH and DELETE by its sub_url, which is the name the API accepts, and create new pages by title. (Only DELETE by sub_url was tried; PATCH is untested.)
Add an offline test with a fake API that returns title and sub_url differing by the .- suffix, covering create, update and prune.
If a fix is not wanted, document the limit in guides/onboarding.md: page names must not contain a hyphen.
Workaround
Use hyphen-free page names (CamelCase). A page that was already created with the escaped name has to be deleted through the API (DELETE /repos/{owner}/{repo}/wiki/page/<title>.-) or with prune.
## Problem
The shared Publish wiki workflow (`tools/publish_wiki.py`, tag `v1.1.0`) succeeds the first time and then fails on every later run that includes a page whose file name contains a hyphen, for example `Getting-started.md`.
```
ERROR: [api] Gitea API request failed with HTTP 400 (Bad Request)
Preflight passed: Gitea accepted the token and the wiki is enabled.
```
Seen in `TirSystem-BashScript/repo-foundry`, run 785 (first run 780 passed). Gitea 1.27.3.
## Cause
Gitea stores a wiki page whose name contains `-` under an escaped address with a `.-` suffix. For the pages created by run 780 the API reports:
| title | sub_url |
| --- | --- |
| `Getting-started` | `Getting-started.-` |
| `SSH-and-tokens` | `SSH-and-tokens.-` |
| `Home` | `Home` |
`list_wiki_titles` builds its set from `sub_url` (unquoted), so it contains `Getting-started.-`, while `read_pages` keys the local page as `Getting-started`. The page is therefore treated as missing and `publish` calls `POST /wiki/new` for a page that already exists, which Gitea answers with 400. The lookup `GET /wiki/page/Getting-started` also returns 404, while `DELETE /wiki/page/Getting-started.-` works.
Pages without a hyphen (`Home`, `Troubleshooting`) are unaffected, which is why the wiki of this repository, which uses CamelCase names, does not show it.
The 400 is inferred from the page-list mismatch; the body of the failing request was not read.
## Reproduce
1. In a repository with `wiki/.publish`, add `wiki/Getting-started.md` and merge.
2. Change the page and merge again.
3. The second run fails with the 400 above; the wiki keeps the first version.
## Suggested fix
- Match local pages against the remote `title` (through `page_key`), not against `sub_url`.
- Address a page in `GET`, `PATCH` and `DELETE` by its `sub_url`, which is the name the API accepts, and create new pages by `title`. (Only `DELETE` by `sub_url` was tried; `PATCH` is untested.)
- Add an offline test with a fake API that returns `title` and `sub_url` differing by the `.-` suffix, covering create, update and prune.
If a fix is not wanted, document the limit in `guides/onboarding.md`: page names must not contain a hyphen.
## Workaround
Use hyphen-free page names (CamelCase). A page that was already created with the escaped name has to be deleted through the API (`DELETE /repos/{owner}/{repo}/wiki/page/<title>.-`) or with `prune`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Problem
The shared Publish wiki workflow (
tools/publish_wiki.py, tagv1.1.0) succeeds the first time and then fails on every later run that includes a page whose file name contains a hyphen, for exampleGetting-started.md.Seen in
TirSystem-BashScript/repo-foundry, run 785 (first run 780 passed). Gitea 1.27.3.Cause
Gitea stores a wiki page whose name contains
-under an escaped address with a.-suffix. For the pages created by run 780 the API reports:Getting-startedGetting-started.-SSH-and-tokensSSH-and-tokens.-HomeHomelist_wiki_titlesbuilds its set fromsub_url(unquoted), so it containsGetting-started.-, whileread_pageskeys the local page asGetting-started. The page is therefore treated as missing andpublishcallsPOST /wiki/newfor a page that already exists, which Gitea answers with 400. The lookupGET /wiki/page/Getting-startedalso returns 404, whileDELETE /wiki/page/Getting-started.-works.Pages without a hyphen (
Home,Troubleshooting) are unaffected, which is why the wiki of this repository, which uses CamelCase names, does not show it.The 400 is inferred from the page-list mismatch; the body of the failing request was not read.
Reproduce
wiki/.publish, addwiki/Getting-started.mdand merge.Suggested fix
title(throughpage_key), not againstsub_url.GET,PATCHandDELETEby itssub_url, which is the name the API accepts, and create new pages bytitle. (OnlyDELETEbysub_urlwas tried;PATCHis untested.)titleandsub_urldiffering by the.-suffix, covering create, update and prune.If a fix is not wanted, document the limit in
guides/onboarding.md: page names must not contain a hyphen.Workaround
Use hyphen-free page names (CamelCase). A page that was already created with the escaped name has to be deleted through the API (
DELETE /repos/{owner}/{repo}/wiki/page/<title>.-) or withprune.