mi/werkator
1
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

remote: authenticated clone for private origins (#22)

Browse Source 
repo-init/repo-add clone https repos with shared defaults.git
credentials from ~/.werkator.yml via one-shot GIT_ASKPASS
This commit is contained in:
mhoennig
2026-09-05 13:59:09 +02:00
parent 092183ca30
commit c6e2155485
4 changed files with 177 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/deployment.md
+4 -3
View File
@@ -120,9 +120,10 @@ Adding a repository is editing a registry entry — never a data migration, beca
tools/remote --env-file .env.<instance> werkator repo-add https://github.com/<owner>/<repo>.git [<name>]
```
It clones the repository next to the ones already served, runs `init` in it, and **prints** the registry entry.
It does not write `~/.werkator.yml`: that file is the instance's own — port, global concurrency, possibly shared credentials — and a script editing it in place would rewrite the operator's configuration behind their back.
Cloning and initialising is mechanical; registering is a decision.
It clones the repository next to the ones already served, runs `init` in it, and **prints** the registry entry.
It does not write `~/.werkator.yml`: that file is the instance's own — port, global concurrency, possibly shared credentials — and a script editing it in place would rewrite the operator's configuration behind their back.
Cloning and initialising is mechanical; registering is a decision.
A private `https` origin authenticates with the shared `defaults.git.account`/`defaults.git.token` of `~/.werkator.yml` (the token travels via a one-shot `GIT_ASKPASS` on the host, never in a URL or process list); enter those once before cloning a private repository — without them only public origins clone.
4. **Restart** the service; startup recovery re-enqueues what was in flight: