landon/md-manuscript
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Create the Gitea repository from the app, not a template hook

Browse Source 
Repository creation was delegated entirely to a cookiecutter template's
post-gen hook. That only ever covered projects made through New project,
and when it went wrong it went wrong inside someone else's Python, where
all this app could report was that a hook exited non-zero.

The app now talks to Gitea itself. Settings > Git remote... gains a
"Create and attach" button: it POSTs to /api/v1/user/repos with the
configured server, user and token, then points origin at the clone URL
that comes back. A name that is already taken is fetched and attached to
rather than raised as an error, so retrying after a failure works.

The call runs on a worker thread with the existing channel-and-poll
pattern, so the UI does not block on the network. Errors are mapped by
status code, because a rejected token, a URL that is not a Gitea API and
a name the server refuses each need a different fix.

Uses ureq's send_string rather than send_json, whose feature this build
does not enable; no new dependency, and ldd still shows only
libc/libgcc/libm.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GBWj9TphFMCoh7VHaSRnvQ
This commit is contained in:
landon
2026-09-09 18:13:21 -05:00
parent 91718f7487
commit c4391155cd
7 changed files with 561 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+21 -7
View File
@@ -75,6 +75,15 @@ Terminal=false
Either way the URL lives in the repository's own `.git/config`, not in this
app's settings, so every workspace keeps its own.
The same dialog can **make the repository for you**. Fill in the Gitea rows
under **Settings ▸ New project** (server, user, token — the token needs write
access to repositories), then give the repository a name and press **Create
and attach**. The app calls Gitea's API itself, then points `origin` at what
came back. A name that already exists is attached to rather than treated as
an error, so a second attempt after a failure does the right thing. Untick
**Attach over SSH** to use the HTTPS clone URL instead, which asks for a
credential on every push.
After that, the **⟳ Sync (git)** button commits all changes, `pull --rebase`s,
and pushes (setting the upstream on the first push). Until origin is set it
commits locally and says so in the log.
@@ -516,13 +525,18 @@ push command alone and is not written into the project's `.git/config`.
The token is stored in `config.json` in plain text, the same as the Mistral API
key.
Note that this is the *only* place the app creates a remote repository, and it
runs entirely inside the template's hook — the app itself never talks to Gitea.
So it applies to projects made through **New project** and nothing else, and it
does nothing if **Run the template's hooks** is off, if any of the three Gitea
settings is blank, or if the template has no such hook. For any workspace that
did not come from the template, attach the remote with **Settings ▸ Git
remote…** instead.
This path runs entirely inside the template's own hook, so it applies to
projects made through **New project** and nothing else, and it does nothing if
**Run the template's hooks** is off, if any of the three Gitea settings is
blank, or if the template has no such hook. When it fails it fails in someone
else's Python, and all this app can report is that a hook exited non-zero — the
Git log window carries whatever the hook printed.
**Settings ▸ Git remote… does not go through the template at all.** It calls the
Gitea API directly, works on any workspace, and reports what the server actually
said (a rejected token, a URL that is not a Gitea API, a name the server would
not take). If the hook is not publishing and you would rather not debug it, that
is the way round.
## New files from a template